Xorg Input Hotplugging
pcpa at mandriva.com.br
pcpa at mandriva.com.br
Sat Dec 1 06:27:02 PST 2007
Quoting Daniel Stone <daniel at fooishbar.org>:
> On Sat, Dec 01, 2007 at 10:49:42AM -0200, pcpa at mandriva.com.br wrote:
>> The main problem is that there isn't a mapping from hal devices
>> to xorg.conf devices, and the hal code in the X Server, if hal is
>> "properly configured", will load a new module to handle an input
>> device that already have a module loaded for it, as listed in
> With evdev, this isn't a problem. EVIOCGRAB means that even if you have
> the 'mouse' driver on /dev/input/mice and evdev drivers on
> /dev/input/eventN, you'll never get duplicate events.
> For the mouse and kbd drivers, yes, this is an issue.
>> For example, if I change hal to use the mouse driver for my ps2
>> mouse, and have an input device section in xorg.conf also using
>> the mouse driver, I will get double clicks for every mouse click.
> I'm not really sure why you'd do that, but yes, I do see the problem. I
> guess one solution is just to remove the keyboard and mouse fallbacks in
> the HAL FDI, and only ever do drivers that we know don't intefere with
This was in experimental code to fallback to xorg.conf configuration,
but afaik, the evdev driver also doesn't provide 3 buttons emulation.
And at first, I did not want to make a patch that would ignore xorg.conf
settings. This probably will also break in some other way on *BSD, as
hal is very Linux dependant for the moment, at least regarding to
>> 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.
Maybe that is because xorg.conf is "properly" configured, and hal
defaults to pc105/us :-), and you will notice that there is buggy
code in config/hal.c. I don't remember the details, but if I recall
correctly, after fixing it, the keyboard worked (no multiple events
for every keypress and correct mapping), but the mouse still had the
problems, as the hal/config.c would load a new instance of the mouse
>> For the moment, I disabled hal support in the Mandriva X Server
>> a few days ago as I got no reply to the bugzilla above, but hope
>> to work again on it in the next days. I did not finish the patch
>> because it may be required some guessing, or some detail I am
>> missing :-) that would allow mapping hal devices to xorg.conf
>> devices, and then, code in the server would notice it and load
>> only one driver for the device.
> The patch as it is is obviously extremely DDX-dependent, and thus breaks
> KDrive and others horribly. We already have NewInputDeviceRequest, so
> handling it in the DDX would be utterly trivial.
Yes, it wasn't meant to be sent to upstream, but a possible way to
fix the problem for the users, and also an exercise to understand
the code. But I did not add it to Mandriva's X Server package because
I knew it wasn't correct, and knew there were also problems with Kdrive
that I still did not completely analyze neither fully understand.
More information about the xorg