evdev-1.2.0 / hal-0.5.10 combo broken?
daniel at fooishbar.org
Fri Jan 18 20:15:30 PST 2008
On Fri, Jan 18, 2008 at 11:06:24AM +0100, Sascha Hlusiak wrote:
> > > Other issue is that there is no full integration with configuration
> > > from xorg.conf, and to make things worse, hal configuration code doesn't
> > > know about xorg.conf configuration code, and both do "its own thing"
> > > when starting the X Server, i.e. frequently 2 instances of the same
> > > module or 2 different modules handling the same device.
> > 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.
> 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.
> 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,
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the xorg