vmmouse kernel driver

[Thomas Hellstrom]

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





> _______________________________________________
> xorg-devel at lists.x.org: 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