Xorg Input Hotplugging
ben at mw0.ath.cx
Mon Oct 15 13:50:54 PDT 2007
First, I have occasionally experienced Xorg seg faults when removing
input devices. Any suggestions as to how to collect debugging
information about these incidents as they are relatively sporadic
(constantly run X in gdb locally, run xorg in gdb over ssh, anyone know
where gdm puts its xorg coredumps?)?
Secondly, anyone have any ideas as to why key repeats (typematic) would
work with all of the arrow keys except the left? Thanks,
P.S. Daniel, you were right about the desktop environment resetting the
keyboard model. Changing it in gnome keyboard preferences fixed the
problem for the most part (see above). Also, I think the xkbcomp error
might be caused by the libX11 version (the latest release) which doesn't
have commit 7c996f78914c77fe17e9f4feede980d895d9df51 which adds the new
keysyms. Might be time for a new push of libX11. Just a thought though.
On Mon, 2007-10-15 at 11:31 +0300, Daniel Stone wrote:
> On Sun, Oct 14, 2007 at 09:46:02PM -0400, ext Ben Gamari wrote:
> > I have been trying to get Xorg input hotplugging to work on my laptop.
> > To start, I attempted starting Xorg with an xorg-enabled build of hal.
> > Unfortunately, I was surprised when I quickly found that my keyboard
> > mappings were off in several places (the up arrow acts like print
> > screen, etc).
> > Some investigation revealed that the evdev driver had taken the liberty
> > of claiming my keyboard and track stick in addition to the newly
> > hotplugged usb mouse. After deleting my old InputDevice section (using
> > the kbd driver), I restarted xorg and found that my keyboard issues
> > continued. Looking through the manpage of the evdev driver produced that
> > most QWERTY keyboard users will need to pass "evBits," "keyBits", and
> > "Pass" options to the evdev driver. After trying to add a new
> > InputDevice section using the evdev driver and the required options,
> > restarting xorg failed with:
> You've almost certainly got it backwards. What I'm betting has happened
> is that the input-hotplug code has done the right thing and added the
> evdev devices, but either keymap compilation has failed (see below), or
> your desktop environment has reset the layout from evdev to pc105.
> pc105 layout on an evdev keyboard means that Up turns into Print Screen.
> Don't worry about the evdev driver manpage, all the bit options are
> sheer insanity that the i-h code renders useless.
> > expected keysym, got XF86KbdLightOnOff: line 70 of pc
> > [...]
> > expected keysym, got XF86KbdBrightnessUp: line 142 of inet
> You need to rebuild xkbcomp against a more recent verison of x11proto.
> > Does xorg infer the evdev options when hal notifies it of a new keyboard
> > device?
> It doesn't need them.
> > Additionally, it looks like evdev attempts to take over my
> > synaptics touchpad as well. Should the driver be checking whether
> > devices are already in use before it claims them for itself? Thanks a
> > ton,
> Well, if they're already in use by another driver, it won't be able to
> open them, but yes, making that more explicit is on my TODO list for
> xorg-server 1.4.1. As for the Synaptics bit, you can resolve that by
> changing the FDI to use synaptics instead of evdev for that particular
> PS: Due to mail problems, I'm not getting anything to xorg@ or
> daniel at fooishbar.org, only mail to hal@ which goes to my work
> hal mailing list
> hal at lists.freedesktop.org
More information about the xorg