Wayland Relative Pointer API Progress

[Michal Suchanek]

On 20 April 2015 at 09:36, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> >> On 18 April 2015 at 16:58, x414e54 <x414e54 at linux.com> wrote:
>>
>> >>> USB HID specifications define a pointer and a mouse as two completely
>> >>> different inputs. A mouse can be a used as a pointer because it is
>> >>> pushing the cursor around but the pointer points at a specific
>> >>> location.
>
> Okay. Using different definitions for terms from different places and
> interpreting the terms used by other people with your own different
> definitions is obviously going to cause disagreement.
>
> I explained what a wl_pointer in Wayland terms is in another email.
> Sounds like it is specifically not a HID pointer device.
>
>
> On Sun, 19 Apr 2015 09:46:39 +0200
> Michal Suchanek <hramrach at gmail.com> wrote:
>
>> So the device is always absolute and interpretation varies.
>
> I disagree.
>
> Let's take a mouse, optical or ball, doesn't matter. What you get out
> is a position delta over time. This is also know as velocity. Sampling
> rate affects the scale of the values, and you cannot reasonably define
> a closed range for the possible values. There is no home position. All

There is a home position. That is when you do not move the mouse. The
reading is then 0.

And there is range. The construction of the mouse sensor defines
maximum speed measurable in hardware. Although you do not get this
speed in mouse specifications on many low end mice this threshold is
actually reachable.

> this reads to me as "relative". The home position is the important
> thing, and that the home position is observable by the human user.

Indeed, and both a joystick and a mouse have a home position.

>
> Take a joystick. The stick has a home position, the center. You can
> only tilt the stick up to it's hardware limits. Those limits are well
> established and obvious to the human using the stick without knowing
> anything else than just looking at the device. The measurements you get
> tell you the position of the stick. Sampling rate does not affect the
> readings, and they are not related to time. Therefore the readings are
> not velocity but position. This is what I would call "absolute".

Sampling rate does not actually affect measured speed either so long
as what you measure is speed. It affects measured distance in the
sampling period so you have to take sampling period into account when
determining speed. And since the sampling period is typically fixed
for a mouse what you get is a sensor reading which is absolutely
comparable with any other reading from the same sensor. It's the
distance the mouse moved in the sampling interval or the mouse
movement speed in some unspecified units.

>
> Yes, the trackpoint has been raised here before, and it seems much
> closer to a joystick than a traditional mouse. That's ok, you probably
> could use it as a joystick, since it does have a home position that is
> obvious to a human user. Like you said, for trackpoints the absolute
> measurement is only interpreted as a velocity through some
> non-decreasing function.

The practical difference between mouse and joystick is that you can
move the stick to an extreme position and hold it in that position
which is not possible with a mouse. That's why trackpoint is a
joystick unless the hardware cooks the stick data in a very weird way.

>
> A mouse could be an absolute device only if you were never able to lift
> it off the table and move it without it generating motion events. This
> is something you cannot do with an absolute device like a joystick.

You are too much fixed on the construction of the sensor. Mouse is a
velocity sensor similar to some nunchuck or whatever device with
reasonable precision accelerometer. That you can and do lift it off
the table is only relevant to how you use such sensor in practice.

Or is by your definition of relative a trackball bolted to the table
an absolute input device because you cannot lift it?

>
>> You are trying to make a distinction that is only relevant to use of
>> the device readings for generating pointer motion events but otherwise
>> does not exist.
>
> Converting one input device to emulate another (trackpoint -> mouse,
> touchpad -> mouse, keyboard -> mouse, mouse -> keyboard, mouse ->
> joystick) is one thing. I don't think that is on topic here.
>
> A mouse is inherently a relative input device. What we're discussing
> here is exposing the relative measurements to apps, rather than the
> absolute position that the compositor manufactures by integrating over
> the relative measurements.

But that's confusing things. Mouse is as absolute as joystick. The
compositor input is all about converting absolute sensor data into
relative pointer movement because the sensor range cannot be
practically mapped 1-to-1 to absolute screen coordinates for most
sensors.

What the programs that eschew this conversion want is access to raw
unconverted sensor readings as much as possible so that they can
convert it to other input such as scene rotation. And they want to
convert the sensor reading to relative or absolute input in an
application-specific way.

Thanks

Michal