[Spice-devel] [Qemu-devel] paravirtual mouse/tablet

[Peter Hutterer]

Hi guys,

I apologize for replying this way, I wasn't on the spice-list, jrb pointed
out this thread to me. For those who don't know me, I'm the input maintainer
for X.Org. I also know very little about spice, so please take the comments
below accordingly. Comments regarding a few things that showed up in this
thread, slightly out of order because I read through the web-interface:

= Multiple Devices =
X has supported multiple independent pointer/keyboard devices. Not just
physical devices, multiple cursors since late 2009 and it's now standard on
any up-to-date linux distribution (including RHEL6). Not having device
identifiers in the core protocol was one of our greatest regrets with input
handling.

X abstracts into so-called master devices and slave devices. The default
setup is to have all slave devices (==physical devices) send events through
the first master device pair (first cursor and first keyboard focus). This
can be reassigned at runtime, so one can create a second cursor and assign
any device to this. The cursors can be used simultaneously. Same for
keyboards, including gimmicks such as different layouts.

= Mouse Wheel =
Mouse wheel is buttons 4,5,6,7 in X by convention, but that is not true in
other systems. And there are patches floating around on the xorg-devel list
to export mouse wheel data through axes. And given the demand for this, I'd
wager that this change would be picked up reasonably quickly. 

The wheel mapping causes issues in drivers, because what's physical button 4
in the device must be mapped to button 8 now. it's surprising how many bugs
we get into drivers where we screw this up.

Also, there's devices that don't use PS/2 but provide scrollwheels (Wacom
ArtPen for example). These devices have higher resolution scrollwheels that
cannot map easily into buttons without getting awkward UI effects. Likewise
with that Logitech (?) mouse that can free-flow the mouse wheel.
The kernel will give you the proper data as it comes from the device and
that is not always 0 or one.

= Two Axes =
The reason the wheel is exported as buttons is because the core protcol only
allowed for 2 axes. If it wasn't for that, we'd have decent wheel
acceleration etc.

Likewise, touchpads these days have pressure, tablets have multiple axes
such as pressure, distance, tilt, and rotation. Two axes is not enough for
anything but a standard mouse.

= Axis range =
The axis range is quite important to clients, as it allows them to do custom
scaling etc. Hence the need for feature negotiation as Anthony pointed out.
e.g. wacom devices have an x axis range of around 0 - 50000, the synaptics
touchpads are iirc roughly 1400 - 5400.
In both cases, the range itself carries information as to how precise the
device can be.

= Button handling =
"Buttons really have no standard meaning so usually a button count is
sufficient."
we've started labelling buttons in X a few releases back for exactly that
reason. the kernel can in many cases tell us what a button is and devices
that have a number of special buttons (remote controls) benefit from button
labelling. Having said that, I don't think 32 buttons are enough.
Why not just send the button state as it changes?

= Multitouch =
Seriously, multitouch is complicated. The kernel now has two multitouch
protocols, depending on whether the hardware has tracking built-in or not.
Both protocols with a multitude of identifiers (currently up to 11 "axes",
x, y, pressure, tool type, etc.).  These are identifiers for parallel
information, touchpoints themselves are serialised. We've seen hardware that
supports more than 16 touchpoints already, anything that limits the number
of touchpoints (or other information) in the protocol is bound to be
obsoleted soon.

Note that there's devices that are both pointer and multitouch devices
(Apple's MagicMouse and MagicTrackpad).

= Pressure =
Pressure is not a binary state. All devices that I've had to deal with so
far have a pressure range (usually client-configured) and then events happen
based on passing that threshold (+ a tolerance range, if applicable).
This goes as far as auto-adjusting the threshold to accommodate worn styli
tips as we do in the wacom driver.

It's not quite as simple as Alex wrote:
"Touching means:
    Touchpad: movement of cursor
    Tablet: pressing down a pen"

We use the tool type identifier for this as there are devices that are
_both_ touch and tablet devices (e.g. ISDV4 serial tablets). I've had one of
these on my desk for months now, it's not a hypothetical device at all.


I think that's enough for now. If someone is happy to fill me in on the
details of what exactly you're trying to do, I'm happy to help with the
architectural decisions. 

Cheers,
  Peter