keyboard, evdev, hald questions

[Peter Hutterer]

On Thu, Apr 23, 2009 at 02:21:26AM +0200, Harald Braumann wrote:
> Hi,
> 
> I'd like to understand a view details about keyboard input with regard
> to the evdev driver and hal. If someone could be so nice as to answer
> the following questions:
> 
> 1) How are input events mapped to KeyCodes?
> If I'm not mistaken, evdev reads input events from
> the /dev/input/eventX. How are those events (from linux/input.h) mapped
> to KeyCodes? Is this a static mapping somewhere or is there some
> configuration tool?

scancode + 8. min-keycode is 8 (for some reason I can't remember), so if the
kernel gives us KEY_ESCAPE we pass it on as keycode 9 to the server.

> 2) What does hald do?
> From what I understand, hald does the following (please correct me, if
> I'm wrong):
> - apply quirks for certain keyboard models (re-mapping scancodes to
> input events)
> - listen for attachment/detachment of input devices and informs
> listeners of these events

yep.
 
> 3) What's the relation between X an hald?
> X uses hald to get notifications for attached/detached input devices
> and uses those for input hotplugging, right?

yep.

> 4) How does X interact with hald?
> Does X use some hal-interface or D-Bus?

the X server uses libhal, but that in turn uses DBus.

> 5) What do the options in x11-input.fdi do?
> Does hald do anything on its own with the XkbLayout and XkbVariant
> options in the fdi file, or is this just an attribute that is queried
> by the X server to set up key mapping? This key mapping (KeyCode to
> Keysym) is still done by the X server, and there's no hald involvement,
> right?

hal merges the fdi stuff into it's own device list. it doesn't actually do
anything with it though.
when the X server queries hal for the devices, these options are given to the
server too. The server then parses them and configures accordingly (or passes
them to the driver).
 
the actual keycode to keysym mapping is done (mostly) by the client. the
server maintains the keyboard configuration (based on the files in
xkeyboard-config) and clients can obtain that mapping. the server still only
sends keycodes to the client - conversion into a string or an action still
depends on the client.

the only exception are "compat" (xkb actions). here the server actually does
stuff depending on the keysym (e.g. Terminate_Server). in the case of modifier
keys, the server adjusts the keyboard state accordingly.

the whole sequence is:

kernel -> evdev  -->  xserver -> client <-> keycode/keysym mapping
 kernel keycode   |   kernel keycode + 8

Cheers,
  Peter