[rant] keeping policy in HAL

[Daniel Stone]

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.

/dev/input/mice and /dev/mouse are not your PS/2 mouse.  evdev will not
(repeat, not) work with either /dev/input/mice or /dev/mouse.  I don't
think it'll work with /dev/input/mouse0 either.

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

Well, yes.  If you're using HAL, then you're using evdev.  If you're
using HAL to tell X that you're using another driver, then you're using
another driver.  Oh yeah, and HAL won't add the same UDI twice.

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

--disable-config-dbus --disable-config-hal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20081202/6bfebb1c/attachment.pgp>