From fbd7bd6081d173ec7fee189db7769d0646c04c84 Mon Sep 17 00:00:00 2001
From: dakkar <dakkar@thenautilus.net>
Date: Tue, 15 Sep 2009 15:20:28 +0200
Subject: page about the evdev patch

---
 src/SW/xf86-input-evdev/document.en.rest.txt | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)
 create mode 100644 src/SW/xf86-input-evdev/document.en.rest.txt

(limited to 'src/SW/xf86-input-evdev/document.en.rest.txt')

diff --git a/src/SW/xf86-input-evdev/document.en.rest.txt b/src/SW/xf86-input-evdev/document.en.rest.txt
new file mode 100644
index 0000000..a1ce1be
--- /dev/null
+++ b/src/SW/xf86-input-evdev/document.en.rest.txt
@@ -0,0 +1,58 @@
+=========================================
+ Code-remapping for ``xf86-input-evdev``
+=========================================
+:CreationDate: 2009-09-15 12:49:41
+:Id: SW/xf86-input-evdev
+:tags: - software
+       - keyboard
+
+The standard ``xf86-input-evdev`` driver that comes with `xorg` only
+uses keycodes between 8 and 255, dropping all others. This is fine
+most of the time (who ever saw a keyboard with more than 247 keys on
+it?), but it causes problems when the keycodes generated are not
+compact.
+
+For example, the Apple Aluminum Keyboard (USB ID ``05ac:0221``)
+produces at least one code above 255: the "fn" key is 464. People have
+found other cases, and have `reported them as a bug
+<http://bugs.freedesktop.org/show_bug.cgi?id=11227>`_.
+
+Since I needed my keyboard to work as I want it, I did the only
+sensible thing: I `cloned the repository
+<http://www.thenautilus.net/cgit/xf86-input-evdev/>`_ and patched the
+code.
+
+My patch adds a configuration option, called ``event_key_remap``. Its
+value must be a (whitespace-separated) list of "assignments" of the
+format ``$evdev_code = $x11_code``; the ``$evdev_code`` can be
+obtained with ``showkey -k``, the ``$x11_code`` can be found in
+``/usr/share/X11/xkb/keycodes/evdev`` (or wherever your distribution
+put it).
+
+The implementation is rather simple, creating a look-up table from the
+configuration; the table is not implemented as a simple array, since
+that would have meant taking 64KiB for each device (`evdev` uses 16
+bits for a key event). Instead, I allocate "pages" of 256 bytes, and
+only the pages needed. This way, devices with no remapping use only
+one more pointer in their structures, and devices with very few codes
+to remap use only 256 bytes.
+
+Of course, the configuration can be set either in the ``xorg.conf``
+file, or via `HAL`. My ``/etc/hal/fdi/policy/10-x11-input.fdi`` file
+contains::
+
+ <?xml version="1.0" encoding="utf-8"?>
+ <deviceinfo version="0.2">
+  <match key="info.capabilities" contains="input.keyboard">
+   <append key="input.x11_options.XkbOptions" type="strlist">compose:ralt</append>
+   <append key="input.x11_options.XkbOptions" type="strlist">altwin:meta_win</append>
+  </match>
+  <match key="input.product" string="Apple, Inc Apple Keyboard">
+   <merge key="input.x11_options.XkbLayout" type="string">dakkar</merge>
+   <merge key="input.x11_options.XkbModel" type="string">evdev</merge>
+   <merge key="input.x11_options.XkbVariant" type="string">dvorak-apple-al</merge>
+   <merge key="input.x11_options.event_key_remap" type="string">464=118 120=210 204=211</merge>
+  </match>
+ </deviceinfo>
+
+(Details about my keyboard layout are `elsewhere <../my-layout/>`_.
-- 
cgit v1.2.3