evdev-1.2.0 / hal-0.5.10 combo broken?

[Sascha Hlusiak]

Hi Daniel,

> > > 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.
Right. After some testing I take back what I said and claim that it is working 
just right, altough I have 11 input devices then instead of 5, which looks 
ugly. 
The user won't have a clue which device is actually used. If the user uses the 
evdev driver in the xorg.conf, it wins, if he uses the mouse or kbd driver, 
the hal one wins and he is unable to pass options to the driver. 

And if he is not using Linux if could be that hal uses the mouse driver and 
then events will be recognized twice, by the xorg.conf device and the hal 
device, right?

> > 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.
Sorry, it seems the report was about a different glitch. The user had a mouse 
device in the xorg.conf and it was set to "SendCoreEvents". Xorg complained 
about no CorePointer and added the first one as core pointer, which was that 
mouse, so it was added twice and it used /dev/input/mice as input. 
The user can be blamed for this but since the introduction of the "Virtual 
core pointer" it's confusing that a CorePointer is still necessary. 

> > 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.
If I have a synaptics section in the xorg.conf, hal fails to add an input 
device using the evdev driver because synaptics grabbed the device and that's 
what I want. But I am a bit scared when I switch vts, because it seems the 
input devices are disabled and enabled in the same order, and the hal device 
is disabled first but enabled first as well; _before_ my xorg.conf device. 
Isn't that dangerous, since there are drivers fighting for the same device? 
(hw/xfree86/common/xf86Events.c at 875,915)
The evdev driver is nice enough so it still works but with other input drivers 
the devices could get mixed up.

I tried to write a fdi file for my touchpad using synaptics but I stopped 
because I can't pass options to the synaptics driver. It does not work well 
with the default options so I ended up to add it to the xorg.conf file again. 

Please review these two posts to the mailinglist and consider to make it 
possible to pass arbitrary options to drivers through hal fdi files:

http://lists.freedesktop.org/archives/xorg/2007-December/030964.html
http://lists.freedesktop.org/archives/xorg/2007-August/027515.html


Thanks,
Sascha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.x.org/archives/xorg/attachments/20080119/d49afb9b/attachment.pgp>