Ubuntu 8.10 – evdev

[Marius Gedminas]

On Sun, Dec 21, 2008 at 12:12:49PM +0100, Johnny Rosenberg wrote:
> I need to understand how the evdev thing works.

Previously, X would use the 'kbd' driver by reading from the /dev/ttyN
representing the virtual console and converting scan codes to keysyms
with XKB.

Now X uses the 'evdev' driver to read a different set of keycodes from
/dev/input/eventX devices and converts those to keysyms with XKB using a
slightly different rules file.

One important difference was that while kbd dealt with a single scan
code stream, evdev can see every keyboard (and mouse) as a separate
input device, and thus can set different properties (such as the
keyboard layout) on them.

X relies on HAL for device hotplugging.  Whenever the kernel detects a
new device, it sends a notification to userspace, where HAL gets it,
sees that this is a keyboard device, and hands it off to X.org.

I learned all this by reading mailing list and blog posts by X.org
developers.  Any inaccuracies are a fault of my memory.

> I can now select my layout and it works perfectly. All the characters are
> available where I expect them. The problem is that every now and then,
> sometimes after several hours and sometimes after a few seconds, the system
> switch back to the standard Swedish layout. I can see when this happens,
> because right before it happens (often when I type something), the system
> doesn't seem to react to one of the key strokes. I then hit the same key
> again and it seems to work, but when I try to use my own characters, they
> are not there anymore.

It seems that for some reason your keyboard falls out of the world for a
microsecond or so, causing the system to think you've unplugged it and
plugged it back.

Currently there's no mechanism for remembering keyboard settings when it
gets unplugged and plugged back in, so the default settings are applied.
The default settings are assigned by HAL instead of the old xorg.conf,
for various reasons.  There's probably a .fdi file somewhere in /etc/hal
on your system saying the default keyboard layout is Swedish.

... Unless there isn't one, in which case I'm totally wrong in my guess.

> Then I open the layout dialogue (in *gnome-keyboard-properties → layouts*)
> and add a new layout, doesn't matter which, then I select my own (Sweden
> Johnny Rosenberg) in the list. Then I remove the layout I just added,
> whichever that was. Now it works again, until the same thing happens again
> after a while. Can be a couple of hours or maybe only a couple of seconds.
> 
> I have looked in /var/logs/ but I am not sure what to look for, and I found
> nothing so far.

/var/log/Xorg.0.log is the place to look.  When a keyboard gets
detected, you see something like

    (II) config/hal: Adding input device AT Translated Set 2 keyboard
    (**) AT Translated Set 2 keyboard: always reports core events
    (**) AT Translated Set 2 keyboard: Device: "/dev/input/event1"
    (II) AT Translated Set 2 keyboard: Found keys
    (II) AT Translated Set 2 keyboard: Configuring as keyboard
    (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
    (**) Option "xkb_rules" "evdev"
    (**) AT Translated Set 2 keyboard: xkb_rules: "evdev"
    (**) Option "xkb_model" "pc105"
    (**) AT Translated Set 2 keyboard: xkb_model: "pc105"
    (**) Option "xkb_layout" "us"
    (**) AT Translated Set 2 keyboard: xkb_layout: "us"

If you see the same thing again every time the keyboard layout resets to
default, that would mean I was right in my guess.

> *Solution?*
> 
> What I need now, I think, is to understand how evdev works. It seems like
> some error happens and that the system switch back to something "safe", just
> in case. I don't know if my layout is the problem or if the problem is
> located somewhere else. Sometimes when strange things happens the problem is
> Compiz-Fusion. Maybe in my case too, I don't know. I use it when I switch
> desktop and applications, but hardly ever for anything else.
> 
> I just need to understand better how evdev works, which files the system use
> and things like that. How to proceed with debugging etc.
> 
> I was also thinking of an ugly solution: When I type *xprop -root | grep -i
> xkb*, I get the following information:
> 
> *_XKB_RULES_NAMES_BACKUP(STRING) = "evdev", "pc105", "se", "", ""
> _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "se", "johnny",
> "grp:alts_toggle,lv3:ralt_switch,compose:caps,altwin:left_meta_win"*
>
> Is there a way that I can make the *_XKB_RULES_NAMES_BACKUP(STRING)* the
> same as *_XKB_RULES_NAMES(STRING)*? Because it seems to me that what happens
> is that when some kind of fault occurs, the keyboard layout is switched to
> whatever *_XKB_RULES_NAMES_BACKUP(STRING)* says.

I've no idea were _XKB_RULES_NAMES_BACKUP comes from, or what uses it.

setxkbmap is the one that both sets and uses _XKB_RULES_NAMES to
remember the current setting.  AFAIU GNOME uses setxkbmap behind the
scenes to manipulate the keyboard layout.

> So if I could setboth of
> them to  *"evdev", "pc105", "se", "johnny",
> "grp:alts_toggle,lv3:ralt_switch,compose:caps,altwin:left_meta_win"*, I
> could just ignore what ever happened…

Maybe

> Or maybe that's the dangerous way…?

I don't see how.

The worst thing that can happen if you play with XKB too much is you'll
end up with a broken layout that doesn't let you type anything or do any
stuff like switch to a text terminal with Ctrl+Alt+F1.  You can always
recover by copying and pasting 'setxkbmap us' letter-by-letter into a
terminal, or ssh'ing in and killing the X server to restart it.

Marius Gedminas
-- 
Si hoc legere scis nimium eruditionis habes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20081222/5505d0b1/attachment.sig>