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@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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xorg mailing list xorg@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg