[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: For Those Who Care About X (Bits from the X Strike Force)



Hello!

On Sun, Aug 17, 2008 at 11:21:45PM +0200, Julien Cristau wrote:
...
> Next steps
> ----------
...
> At around the same time, we'd like to enable hotplugging of input
> devices, and their configuration through hal.  This means using the
> "evdev" driver for mice and keyboards instead of the traditional "mouse"
> and "keyboard" drivers, which will for example use of different keymaps
> for different keyboards, per-device configuration (not only statically,
> but also at runtime), etc.
> /usr/share/doc/hal/examples/10-x11-input.fdi and
> /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi in the hal package
> contain an example config, which you can modify to suit your needs and
> install in /etc/hal/fdi/policy/ to get a feel for this.

No bug filed yet, just FYI:

"evdev" currently has a problem with suspend/undock: I have an external mouse
and keyboard connected to the docking station of a Lenovo R61, the keyboard
configured for evddev. On suspend/undock, the X-server doesn't release the
device node /dev/input/event?. The Linux kernel forcefully unpluggs all devices
on suspend/undock and re-pluggs them on resume/dock. Since the old device-node
is still open (and thus used), a new device-node with a new number is created.
The external keyboard is thus dead, until I restart the server.
"lsof -p `pidof X`" shows the node as still be opened, but deleted.
The mouse uses /dev/input/mice and thus doesn't have the problem.
Switching to console before suspending/undocking doesn't help either.

This basically happens because
xserver-xorg-input-evdev-2.0.3/src/evdev.c:EvdevProc(DeviceIntPtr device, int what)
doesn't release the node on DEVICE_OFF and re-opens it on DEVICE_ON, but opens
it in EvdevPreInit() and closes it in DEVICE_CLOSE.
But according to http://www.x.org/wiki/XOrgInputDriverSpec that should actually
what should be done.

Googling for this shows that others have this problem, too. I currently don't
have time to fix it myself, but others should know and perhaps have time and
more experience with writing XOrg input drivers to fix this properly.

BYtE
Philipp
-- 
Philipp Matthias Hahn <pmhahn@debian.org>
 GPG/PGP: 9A540E39 @ keyrings.debian.org


Reply to: