evdev-1.2.0 / hal-0.5.10 combo broken?

[pcpa at mandriva.com.br]

Quoting Daniel Stone <daniel at fooishbar.org>:

>> > Can you please show me where this ever happens?  evdev was specifically
>> > designed to avoid this, and I'd like to see some proof of it going
>> > wrong.  I've seen it go badly wrong when Ubuntu merged a patch from some
>> > derivative distro whose name I forget (maybe it was PepperPad) that
>> > broke evdev, but that's it.
>> If people have their mouse device in the xorg.conf (using 
>> /dev/input/mice for
>> example) hal will add the mouse again with the /dev/input/event* device,
>> resulting in two modules handling the same device.
>
> The EVIOCGRAB call in the evdev driver means that /dev/input/mice will
> no longer receive any events for that particular device, so no problem.

  How is this addressed on other operating systems? Or if hal is configured
to use a driver other than evdev for the given input device? I am talking
about "static" input devices, not hot plugable ones.


>> If people remove the mouse from the xorg.conf, it results in the x-server to
>> add the default mouse device, which is /dev/input/mice again!
>>
>> After adding the (in current stable) undocumented
>> Option  "AllowEmptyInput" "true", X-Server will stop adding default 
>> mouse and
>> keyboard and you can live with a hal-only setup. To most users I recommend
>> adding the (in current stable) undocumented Option "AutoAddDevices" to stop
>> that conflict that both hal AND xorg-server add input devices which is
>> probably not what users wants. I'd like to see AllowEmptyInput to be a
>> default and to have an opt-out instead of an opt-in that nobody knows about
>> but is needed to make things work right. The default behaviour is 
>> not good in
>> my eyes.
>
> I agree, the default should be AutoAddDevices, AutoEnableDevices, and
> AllowEmptyInput.  I'd recommend distributions make these the default.

  This is somewhat related to what I asked before, i.e. if what should
be done is to ignore xorg.conf or not? This also relates to my question
of what would be the handling of the case where xorg.conf is either
ignored or doesn't have input devices specified, but the hal config code
fails to initialize.


>> Quite some users on the gentoo mailinglist compained about single button
>> clicks reported as double clicks because of that.
>
> Either the kernel or evdev driver is broken in that case, because that's
> exactly what EVIOCGRAB does: it removes the mouse from /dev/input/mice,
> among others.

  I think the most common cause is to have mouse and evdev drivers managing
the mouse. And most setups have mouse driver reading from /dev/mouse, that
is a symlink to /dev/input/mice.


>> Gentoo Hal adds the touchpad with the evdev driver instead of the synaptics
>> driver, making the touchpad report absolute coordinates instead of relative.
>> This is rather a hal or gentoo bug than xorg. To achieve this, the 
>> user needs
>> to be a hal fdi policy ninja to stop hal from adding touchpads or he just
>> completely disables adding devices by xorg.
>
> If you have any patches to the FDI, I promise to do the work to get them
> accepted by HAL.

  This relates to another thing that I think is not very clear. How to
pass options to modules? The procedure should now be something like
using sysfs or ioctls and leave everything for the kernel to resolve?
Otherwise, the config/hal.c code should be modified to just pass options
it doesn't know, possibly converting data types to match X modules options
format, or modifiy modules to understand hal data.

> Cheers,
> Daniel

Paulo