Xorg Input Hotplugging

[pcpa at mandriva.com.br]

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
>> xorg.conf.
>
> 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
> others.

  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
default/fallback values.

>> 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
driver.

>>   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.

> Cheers,
> Daniel

Paulo