[rant] keeping policy in HAL

[Peter Hutterer]

On Tue, Dec 02, 2008 at 04:18:36AM -0200, Paulo César Pereira de Andrade wrote:
> >>   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.

if you mount /dev/sda1 to /usr, /root and /home it would also cause confusion.

You have two options:
Don't configure input devices in xorg.conf and let HAL do the job. This is the
standard use-case and we've actually gone to some effort to support this even
on legacy setups.

Configure input devices manually (in which case you'll need to tell the server
to not automagically do things for you).

The combination of both is just a bad idea unless you know the trickery
involved.

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

I repeat - config/hal won't let you add a device with a known UDI. If you go
through HAL, it's fine.

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

There's a reason why we don't use EVIOCGRAB anymore, it breaks too many other
(in-kernel) things.
 
>   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.

Then don't use it and configure the devices manually. kbd/mouse still work,
just like in the olden days.

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

Unless the these problems float past me (i.e. Red Hat or FDO bugzilla), I
can't do much about it. Upstream them, I'm really trying to fix input issues
as soon as possible.

Cheers,
  Peter