pages tagged hackPlein de truchttp://blog.lot-of-stuff.info//Tags/hack/Plein de trucikiwiki2015-11-03T21:49:14ZXorg and special keyshttp://blog.lot-of-stuff.info//Blog/Posts/Xorg_and_special_keys/2015-11-03T21:49:14Z2013-08-03T13:57:50Z
<h1 id="xorgandspecialkeys:onesolutionforkeycode255">Xorg and special keys: one solution for keycode>255</h1>
<h2 id="anhistoric">An historic</h2>
<p>I've buy an
<a href="http://www.materiel.net/telecommande-multimedia/antec-veris-multimedia-station-ez-45019.html">IR receiver</a>,
and an
<a href="http://www.lesnumeriques.com/telecommande-universelle/logitech-harmony-600-p8628/test.html">universal controller</a>
to control my multimedia computer, my TV, my ADSL box and my 2.1 Home
cinema.</p>
<p>I've been pleased to see that my universal controller do now more
control than the remote that was sold with my IR receiver. But a lot
of those control didn't work with Xorg, so I had to find someway to
use them.</p>
<p>At first, my logs where spamed with line like:</p>
<pre><code>imon 4-4:1.0: imon_incoming_packet: unknown keypress, code 0x100000e
</code></pre>
<p>(imon is the real builder of the IR receiver).</p>
<p>I looked for this on the internet and found</p>
<ul>
<li>the problem was known</li>
<li>the fix was in the Linus kernel git repository</li>
<li>but not in any released kernel</li>
</ul>
<p>So I waited, and Linux 3.10 was released, and the Debian Kernel Team
did include it in debian sid, so I could easily use it.</p>
<p>But some command was still unrecognized as key by Xorg, so I had to
find how to let X know them.</p>
<p>Reading documentation on internet, and trying some command lead
nowhere: the kernel did in fact understood very well the command, but
X did ignore them. After two day of trying to understood XKB, I found this
<a href="https://bugs.freedesktop.org/show_bug.cgi?id=11227">bug</a>: those key
was unavailable to X and XKB because their keycode was bigger than 255.</p>
<p>The first solution to this problem is this
<a href="http://www.thenautilus.net/cgit/xf86-input-evdev/commit/?h=code-remap-2.8.0">patch</a>,
but I prefer to use standard tool. I finally found that udev can remap
key, hence my solution:</p>
<h2 id="thesolution">The Solution</h2>
<p>To use key that have keycode bigger than 255, you need to have keycode
smaller than 255. keycode are determined by a map in the kernel,
that udev can set when the receiver is plugged.</p>
<p>You need a keymap. <code>input-kbd</code> from the <code>input-utils</code> package will
list the available scancode, and their current keycode (to know the
number of your input device, use <code>lsinput</code>):</p>
<pre><code>% sudo input-kbd 6
0x100007f = 106 # KEY_RIGHT
0x1000080 = 105 # KEY_LEFT
0x1007f00 = 108 # KEY_DOWN
0x1008000 = 103 # KEY_UP
0x1010000 = 272 # BTN_LEFT
0x1010080 = 272 # BTN_LEFT
0x1020000 = 273 # BTN_RIGHT
0x1020080 = 273 # BTN_RIGHT
0x200001e = 513 # KEY_NUMERIC_1
0x200001f = 514 # KEY_NUMERIC_2
</code></pre>
<p>(There is more, I just cut it there).</p>
<p>Putting this in some file (say <code>keymap</code>), editing it, and running
<code>sudo input-kbd -f keymap 6</code> should change the kernel
mapping. <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625759">But it don't</a>.</p>
<p>It's not a problem, because the best solution is to use udev.</p>
<p>Wrote a keyboard mapping in say <code>/etc/udev/imon</code>:</p>
<pre><code>0x200001e KP1
0x200001f KP2
0x2000020 KP3
0x2000021 KP4
0x2000022 KP5
0x2000023 KP6
0x2000024 KP7
0x2000025 KP8
0x2000026 KP9
0x2000027 KP0
0x2800000 MENU
0x288795b7 PAGEDOWN
0x289395b7 PAGEUP
</code></pre>
<ul>
<li>You don't need to put there the scancode and keycode you don't divert,</li>
<li>the interesting scancode are found by <code>input-kbd</code></li>
<li>you can also use <code>input-events</code> to find which scancode correspond to one key</li>
<li>the interesting keycode are in <code>/usr/include/linux/input.h</code>, note that this is not the same thing than X keycode...</li>
</ul>
<p>You then need to tell udev to load this mapping, with
<code>/etc/udev/rules.d/96-local-keymap.rules</code>:</p>
<pre><code>ACTION=="remove", GOTO="mykeyboard_end"
KERNEL!="event*", GOTO="mykeyboard_end"
ENV{ID_INPUT_KEY}=="", GOTO="mykeyboard_end"
SUBSYSTEMS=="bluetooth", GOTO="mykeyboard_end"
SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id"
ENV{ID_VENDOR}=="15c2", ENV{ID_MODEL_ID}=="0042", RUN+="keymap $name /etc/udev/imon"
LABEL="mykeyboard_end"
</code></pre>
<p>You will need to adapt <code>15c2</code> and <code>0042</code> to you own remote. I've found
those using <code>lsusb</code></p>
<pre><code>Bus 004 Device 014: ID 15c2:0042 SoundGraph Inc.
</code></pre>
<p>I could now use xkb to further refine the way those key are used by xorg...</p>
Sofware as servicehttp://blog.lot-of-stuff.info//Blog/Posts/Sofware_as_service/2015-11-03T21:49:13Z2012-07-16T06:24:21Z
<p>Someone recently give me a link to a web picasa photo album. I wanted to download all the photo in good resolution, but the only official way to download it is by using the picasa proprietary software. </p>
<p>Not only I'm not thrilled to install yet another unfree software, but Google refuse me to download it because "Picasa is not currently available for your operating system". Another solution exist, but need some research:</p>
<ul>
<li>You need a Grease monkey <a href="http://userscripts.org/scripts/show/119849">userscript</a> that add links in the overview to download the image</li>
<li>Then the <a href="http://www.downthemall.net/">DownThemAll extension</a> will download all those link...</li>
</ul>
<p>Some time, its great to be able to beat limitation of unfree software thanks to free software. </p>
Logwatch and ikiwikihttp://blog.lot-of-stuff.info//Blog/Posts/Logwatch_and_ikiwiki/2015-11-03T21:49:12Z2012-04-14T06:27:39Z
<p>As said in a recent comment, I use logwatch to look at the logs on my server. Every night logwatch send me a mail with a report of what has happen.</p>
<p>One thing lacking was logs analysis for ikiwiki: ikiwiki don't produce log per-se. Access are logged and reported because they are done by the http server, but modification are only seen in the git repository, and comment waiting moderation are only in the ikiwiki directory.</p>
<p>So I needed a way for logwatch to report specific ikiwiki activity.</p>
<ul>
<li><p>First we need to have a file logging activity in the ikiwiki's git repository. So in cron.daily, before logwatch is run, I put:</p>
<pre><code>git --git-dir $IKIWIKI_MAIN_DIR/.git log --after="6 month ago" --format="%cd (%h) %an: %s" --date=iso > /var/log/ikiwiki.log
</code></pre>
<p>of course a better way to do it would be to create a git hook that generate the logs when modification are done, and not once everyday just before the logs are generated.</p></li>
<li><p>Then we need to tell logwatch to look at this file, so in <code>/etc/logwatch/conf/logfiles/ikiwiki.conf</code> I put</p>
<pre><code>########################################################
# Define log file group for ikiwiki
########################################################
# What actual file? Defaults to LogPath if not absolute path....
LogFile = ikiwiki.log
*ApplyEuroDate
</code></pre>
<p>The ApplyEuroDate make ikiwiki read the date in iso format, so it will only report commit done today. I've found no way to tell logwatch to look at the output of a program instead of looking at a file.</p></li>
<li><p>We then must tell logwatch that it must generate the report for a new service, so in <code>/etc/logwatch/conf/services/ikiwiki.conf</code></p>
<pre><code>########################################################
# Configuration file for ikiwiki filter
########################################################
Title = "Ikiwiki"
# Which logfile group...
LogFile = ikiwiki
</code></pre></li>
<li><p>Finally, we have to taught to generate the report, in <code>/etc/logwatch/scripts/services/ikiwiki</code></p>
<pre><code>#!/bin/bash
# First look at pending comment
find $IKIWIKI_MAIN_DIR/ -name "*_pending" -exec echo "Pending comment:" \; -quit
(
cd $IKIWIKI_MAIN_DIR/
find . -name "*_pending" -exec echo " {}" \;
)
# we then look at new commit
fst=true
while read d t tz j; do
if [ $fst == true ]; then
echo "New commit:"
fst=false
fi
echo -n " "
echo $j
done
</code></pre></li>
</ul>
Booting rarely used oshttp://blog.lot-of-stuff.info//Blog/Posts/Booting_rarely_used_os/2015-11-03T21:49:14Z2011-03-25T03:47:23Z
<p>For some time, I was looking for a way to change grub default entry
for only one boot. I want to tell it that next time it should boot the
entry 0, and the time after that, use the usual default (the entry 1).</p>
<p>Founding documention for this is not as easy at it should, and the
information on the <a href="http://wiki.debian.org/GrubReboot">debian wiki</a>
wasn't clear enough for me to understand.</p>
<p>So I edit the wiki page to make clear that <code>grub-reboot</code> also
available for those using grub2, and that it will only configure the
boot, but not reboot the computer itself. As each time I wrote some text in
English, I'm not sure my version correctly transmit my meaning.</p>
<p>By the way, I'm changing my blog. The <a href="http://remi.vanicat.free.fr/blog">old
one</a> contain a
<a href="http://remi.vanicat.free.fr/blog/index.php/2011/03/25/booting-a-grub-entry-onc-used-os/">post</a>
on my search of a solution for this. Thanks to stbuehler and Jochen
for the indication leading to the correct solution for this.</p>
<p>Thanks also to Vadim Solomin for a
<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=yes&bug=589553#15">patch</a>
to make pm-hibernate notice the configured method for shutting-down
the computer.</p>