vmmouse kernel driver

[Peter Hutterer]

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