Xorg Input Hotplugging

[pcpa at mandriva.com.br]

Quoting Sergio Monteiro Basto <sergio at sergiomb.no-ip.org>:

(replying only to list because my other reply, to other message,
earlier today is still waiting moderator approval due too much
recipients...)

> On Sat, 2007-12-01 at 20:17 +0100, Pixel wrote:
>> > On Fri, 2007-11-30 at 21:15 +0300, Andrey Borzenkov wrote:
>> >> On Thursday 15 November 2007, Nicolas Mailhot wrote:
>> >> > > at least one of the properties for your devices should contain their
>> >> > > usb vendor/product IDs.
>> >> > >
>> >> > > other properties xorg understands for keyboards:
>> >> > >  - input.xkb.rules
>> >> > >  - input.xkb.model
>> >>
>> >> Should not it be actually "evdev" always? As evdev is really the 
>> only driver
>> >> that would work?
>>
>> agreed. IMO XkbModel should not even be supported by evdev driver

  Hal has also an option to "not handle" a device. Maybe this
could be used for keyboards and mouses using the kbd and mouse
driver, i.e. for desktops where the user isn't going to
attach/detach input devices during a X session. Either way, if
hal is configured to use the kbd or mouse driver, and there isn't
an input session for the device in xorg.conf, it "just works" (once
the bug in handling string lists is fixed), but may require some
"magic" to specify multiple layouts or other xkb options.

>> Daniel Stone <daniel at fooishbar.org> writes:
>>
>> [...]
>>
>> >> Simillar problems will happen with the keyboard, like arrow keys
>> >> not working, in my case it was mapping to Print Screen, and calling
>> >> ksnapshot when running kde.
>> >
>> > That's just your XKB model being set wrong.  I know the underlying
>> > infrastructure works, because I've tested with multiple keyboards having
>> > different layouts, etc.
>>
>> agreed. the "arrow keys" syndrom :)

  That can easily happen if an there is an entry in xorg.conf
telling X to use the kbd driver, and then evdev is also loaded
using a different setup, usually the default pc105/us. Either
way, if xorg.conf is configured to use evdev, problems may still
happen as there will exist 2 X drivers managing the keyboard.

>> it is caused by apps like gnome-keyboard-properties which sets the xkb
>> model when the user asked for some "internet" keyboard model.
>> (cf http://lists.freedesktop.org/archives/xorg/2007-November/030433.html)
>>
>> out of the 134 "model"s possible (rules/xorg.lst), 127 are based on
>> keycodes/xfree86. if you apply one of these 127 models to a evdev
>> keyboard, you can be *sure* it will be wrong.
>>
>> here is the list of keysyms that will *always* be broken when applying
>> a keycodes/xfree86 based model on evdev keyboard:
>>
>> : Home Up Prior Left Right End Down Next Insert Delete
>> : KP_Enter KP_Divide XF86_Ungrab KP_Equal
>> : Mode_switch Control_R ISO_Level3_Shift Super_L Multi_key Menu
>> : Pause Break Print Sys_Req
>>
>> internet & multimedia keys will always be broken too.

  It seens interesting that, in the computer I am using now it is
using the kbd driver, and "setxkbmap -keycodes evdev" breaks the
arrow keys, but "setxkbmap -print" does not show any changes;
running "setxkbmap -keycodes xfree86" fixes the problem, but still
no changes in "setxkbmap -print". And the diff of "setxkbmap -print |
xkbcomp -xkb - -o <whatever-keycodes-was-set-with-setxkbmap>.xkb"
generates identical  output.


> Hi, I use kde and don't set any xkb model, kde could apply a xkb model
> but I prefer put the keyboard configuration on xorg.conf.
> Questions:
> if evdev breaks so many things what is the point on use it ?

  There is "gratuitous" incompatibility with xfree86 keycodes
in the xkb configuration files, I believe the changes are not
a "hey, I am different" change, so it should be incompatible
to fix some issue with xfree86 keycodes, but maybe the xfree86
keycodes should be fixed in that case...
  It has special handling done at kernel level, but afaik it
is Linux specific, i.e. BSD users probably are not having this
problem. I trust the kernel level implementation is correct,
but the X Server code is somewhat buggy, as the code that
communicates with hal basically ignore the existence of
xorg.conf, and what code elsewhere does to load the input
devices specified in xorg.conf.
<sarcasm>But it has a huge infrastructure behind it, involving
kernel, hal, x server and it uses xml configuration files !!!
So it must be the next step in the technology</sarcasm>

> On xorg.conf what should be the configuration for pt xkblayout on an
> compaq/HP laptop, presario model ? with evdev module.
>
> you write "set keycodes/xfree86 based model on evdev keyboard
> breaks ...", so, have we some command to unset keycodes/xfree86 based
> model ?

  If you are using an external keyboard, probably you will need to
use evdev (just remove the keyboard input section in xorg.conf). You can
try to change the default values by hand in the file
/usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi and
restart the related programs, or temporalily change using some program
like hal-set-property.
  Otherwise, try removing the evdev x11-input package, and make sure
the kbd driver is specified in xorg.conf.

> Thanks,
> --
> Sérgio M. B.

Paulo