[rant] keeping policy in HAL

[Paulo César Pereira de Andrade]

>>   One possible solution, that I proposed some time ago (but got no
>> response) would be to add something like an "UDI" option to input
>> devices. So, one could have something like this in his xorg.conf:
>>
>> Section "InputDevice"
>>     Identifier "Mouse1"
>>     Driver "mouse"
>>     Option "UDI"
>> "/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input"
>>     Option "Protocol" "ExplorerPS/2"
>>     Option "Device" "/dev/mouse"
>> EndSection
>
> why not just use Option "Device" "/dev/input/by-id/blahblahblah"?

  That could be a better approach. But maybe would still cause
confusion, i.e. for example, in the computer I am typing I have
/dev/input/mice, /dev/input/mouse0 and /dev/input/event1, all
with different major/minor, but referring to the same ps2 mouse.

>>   Then, the code in config/hal.c:device_added() or somewhere in
>> hw/xfree86/xf86Xinput.c could check that, and if it matches the
>> device that was about to be added, just leave it alone...
>
> evdev won't let you add a device with an already known major/minor again.
> hal won't a device with a known UDI.

  But that would also require using the evdev driver, or somehow
telling it that other driver is using that major/minor.
  Other option is to change other drivers to use EVIOCGRAB on the
descriptor, but this could cause some race conditions if two
drivers tries to manage the same input device.

  The problem is that hal/dbus consume a lot of time and resources
to be functional, and on low profile computers, needing to wait for
those being load to be able to use keyboard/mouse may not be a good
option.

  I also have seem reports of a users having problems after the
switch to hal/evdev due to not restoring keyboard/mouse after
suspend/resume.

> Cheers,
>   Peter

Thanks,
Paulo