Wayland Relative Pointer API Progress

[Michal Suchanek]

On 20 April 2015 at 13:44, x414e54 <x414e54 at linux.com> wrote:
> This is kinda completely derailed from the whole include mice in the
> game controller protocol talk.
>
> On Mon, Apr 20, 2015 at 6:44 PM, Michal Suchanek <hramrach at gmail.com> wrote:
>> On 20 April 2015 at 10:48, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>> On Mon, 20 Apr 2015 10:13:34 +0200
>>> Michal Suchanek <hramrach at gmail.com> wrote:
>>>
>>>> On 20 April 2015 at 09:36, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>>> > 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.
>>>
>>> That is not a unique position, hence it cannot be a home position. That
>>> is only a unique velocity. By definition, if your measurement is a
>>> velocity, it does not directly give you an absolute position.
>>>
>>> When we talk about absolute, we really mean absolute position.
>>
>> And what does absolute position of a sensor somewhere outside of the
>> PC give you?
>>
>> A trackball and touchpad has as absolute position as joystick.
>>
>> Trackball measures velocity, touchpad finger position(s), joystick
>> stick position.
>>
>> None of these is almost ever used for absolute input mapping
>> particular reading of a sensor to a particular screen coordinate.
>>
>>>
>>>> > 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.
>>>
>>> Accelerometers measure acceleration. Acceleration, like velocity, is
>>> not a position. It does not give you an absolute position directly.
>>
>> And what is practical impact of accelerometers not giving an absolute
>> position compared to joystick?
>
> You can warp a relative motion cursor but cannot warp an absolute
> position cursor.

Indeed. But that's property of how the sensor data is used by the
compositor to move the cursor and not of the sensor.

If joystick was ever used to position the cursor it would most likely
be done in relative mode although you repeat that joystick is
'absolute'. There is no practical mapping of raw stick excentricity to
absolute screen coordinates.

>
> Warping a relative motion cursor is still a UX pain because you may be
> at the edge of your physical reach but warping an absolute position
> cursor is actually an offset and may make the interface unusable.

Warping a cursor that is operated using an input device in absolute
mode is completely possible. However, unless the cursor is also
confined it will likely warp back on the next input event. When the
cursor is confined you effectively get the situation that you have a
sensor reading that puts the cursor through mapping to absolute screen
coordinates outside of (active) screen area. You can also implement
the confinement by changing the mapping - not necessarily only the
offset.

>
>>
>> Joystick can stay in an extreme position, mouse cannot. But if you
>> take a nunchuck attached to a string and rotate it above your head the
>> reading stays in an extreme position all the same.
>>
>> There is no sense in saying the sensor reading itself as absolute or
>> relative. Either gives you some number in unknown units which you
>> calibrate to get usable results. You have no idea where the stick is
>> from the numbers you get. And there is absolutely no point caring. It
>> may have some sense for a particular application and no sense for
>> other.
>
> One of my original points was that a user should be able to hot-swap a
> mouse and a gamepad thumbstick without a game caring and that games do
> not care about mice/joystick/touchpad they just want raw axis values
> that they can use, evdev makes this abstraction.
>
> But you certainly need to know if the axis is relative or absolute to
> convert it to what the application needs.

And my point is that there is no such thing as relative and absolute
axis. There are sensors that give numbers as readings. Sometimes you
know that a bunch of sensors are actually axis which are physically
connected and orthogonal on a device which is nice.

It might be worthwhile to provide adapting filters that try to mimic
the dynamic input interface properties of one type of device using
another type of device. However, this is nxn filters for n kinds of
devices. Certainly more than 2.

Thanks

Michal