On 09/29/2014 01:48 AM, Peter Hutterer wrote: > On Fri, Sep 26, 2014 at 02:44:15PM +0200, Hans de Goede wrote: >> Hi, >> >> On 09/26/2014 09:06 AM, Thomas Hellstrom wrote: >>> Hi! >>> >>> On 09/26/2014 03:36 AM, Peter Hutterer wrote: >>>> On Wed, Sep 24, 2014 at 11:12:50AM +0200, Thomas Hellstrom wrote: >>>>> While looking at a vmmouse kernel driver, I wonder how the Xorg evdev >>>>> driver can be configured to receive both absolute and relative events >>>>> from the same device as the vmmouse sometimes sends absolute events and >>>>> sometimes relative. Is the "IgnoreAbsoluteAxes" "False" option sufficient? >>>> at the same time, or depending on the configuration? The >>>> IgnoreAbsoluteAxes/IgnoreRelativeAxes options simply disable one of the two >>>> on startup, allowing the other one to be initialized. that's for virtual >>>> devices mostly used in VMs because our device autodetection fails there. >>>> >>>> So short answer: yes, should be sufficient provided you stay in that mode >>>> for the lifetime of the device. >>> Thanks for the answer. The problem is we don't. We could suddenly decide >>> that apparently somebody applied a screen tranformation or is running a >>> game and revert back to relative events. >>> Otherwise the preferred choice is absolute events for minimal cursor >>> latency. >>> >>> I know that for this reason the virtual USB mice are duplicated: one for >>> absolute events and one for relative events but I haven't looked to >>> closely at what level this actually happens. >>> >>> But whatever solution that emerges needs to work also with the new >>> compositors. I guess I have to look at somehow make the mouse appear as >>> two different ps2 mice from within the kernel driver... >> Actually one ps/2 device(mouse) which registers 2 input devices, that is >> more or less quite normal for trackpoint / touchpad combo's which are >> interfaced over a single ps/2 connection (some use ps/2 multiplexing, but >> others both touchpad and trackpoint ps/2 packets are send over the same >> ps/2 device). >> >> See drivers/input/mouse/alps.c for an example of this, search for "dev2" >> to all the code dealing with the second device. This way you can simply >> register both an absolute and a relative device, and send events out of >> the right one depending on the mode. That is probably the best way to deal >> with this. > I agree with Hans here, if you have runtime mode changes it's best to break > them out into multiple kernel devices that stay static for their lifetime. > > we could work around this in the X driver by changing the mode between > relative/absolute when we detect the change (doable, but technically > awkward right now) but the end result won't be nearly as useful as just > having two devices in the first place. > > Cheers, > Peter OK,
Thanks guys. I'll look through the code Hans suggested and see if I can come up with something. /Thomas > _______________________________________________ > [email protected]: X.Org development > Archives: > https://urldefense.proofpoint.com/v1/url?u=http://lists.x.org/archives/xorg-devel&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=%2FgktOCbSuWF6940vclQaCQqv9nnDIo2RPD%2F1eHacVCM%3D%0A&s=d3b0638ac651985ce3aca4e838c863a48c16e552f5c21ffd779c496ad2dbbfaf > Info: > https://urldefense.proofpoint.com/v1/url?u=http://lists.x.org/mailman/listinfo/xorg-devel&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=%2FgktOCbSuWF6940vclQaCQqv9nnDIo2RPD%2F1eHacVCM%3D%0A&s=b057595643a51c16de1a9da6f2d766c658d7970371778149eeee46ea742b4fa0 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
