wl_tablet draft v2

[Jason Gerecke]

On Tue, Jul 29, 2014 at 12:44 PM, Lyude <thatslyude at gmail.com> wrote:
> I'm more then willing to add something to get the resolution
> information, it wouldn't be too difficult to implement. I think I'm
> missing or forgetting something here though; why wouldn't we be able to
> get an actual value in degrees from the normalized values we're getting
> from the compositor? The value should be mapped from (-65535.0) -
> 65535.0 by the compositor (libinput is the portion that maps it from
> (-1.0) - 1.0), couldn't we just map that to 0-180°? I would have thought
> the max value tilt value on a tool should always be equal to 180°, and
> the minimum 0°.
>
It is my understanding that libinput normalizes the values so that the
minimum tilt => -1.0 and maximum tilt => +1.0. This data is then
up-scaled by the compositor so that -1.0 => 65535 and +1.0 => +65535.
This alone does not provide enough information to an application to
recover the physical angle. One tablet may have a maximum tilt from
vertical of 45°, another 60°, and yet another 90°. In each case
maximum tilt would be represented by +1.0 or +65535, but there's no
way an application can figure out how many degrees that corresponds
to.

One solution -- as you suggest -- is to have libinput/Wayland define a
unit system and send what I call "canonicalized" instead of
"normalized" data. You could define that in libinput -1.0 == 0° and
+1.0 == 180°; in Wayland -65535 == 0° and +65535 == 180°. In this
case, reports of 0.50/0.67/1.0 and 32768/43690/65535 would be sent
when my hypothetical tablets above were at maximum tilt. As long as
the correspondences were documented, a programmer would have enough
information to convert the values to whatever values they want.

Of course, the unit system you define for your canonical data is
arbitrary, as you point out:

> Also, since we're talking about getting the value in degrees, it might
> be worth it just to have the Wayland protocol return the values in
> degrees by default to save some time for the clients.
>

This is one of the downsides of canonical data. There's always someone
out there who disagrees on units and so needs to perform a conversion.
Degrees would make things easy for Qt and could be expressed directly
in Wayland's 24.8 fixed-point format with a fair amount of precision.
Radians are used natively by all the trigonometric functions, are the
unit of choice for Android, and are the front-runner in designing
Enlightenment's pen API. The "half-turn" is an uncommon units, but
it's what GTK+ applications like GIMP and Inkscape assume they've been
handed.

There are other reasons I'm not a big fan of passing around data in
canonical forms as well (can't send data from devices that don't
advertise a resolution, inconsistent API, doesn't really cut down on
the amount of data that needs to be exposed, etc.). As an alternative
to the canonical route, you can leave the data normalized but provide
a function that returns a scale factor defining what +1.0 (or +65535)
means in physical units. Whatever program receives the value /may/ do
a conversion if they wish, or can leave the value normalized for
others further down the line.

I wouldn't have libinput use degrees, but it might make some sense for
Wayland. The downsides probably don't outweigh the ugliness involved
with shuttling normalized data across the wire*.


* Seriously, can anyone explain why the wire protocol doesn't have a
floating-point type? Practically every system supports the 32-bit
IEEE754 single-precision binary format, and to for those that don't,
we can pull a play from the fixed-point playbook and define a
"wl_single_t" and associated conversion functions (which would just do
a cast unless you happen to be on one of those weird architectures).
Should I just make a patch for this already? :P

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....


> On Tue, 2014-07-29 at 10:07 -0700, Jason Gerecke wrote:
>> On Mon, Jul 28, 2014 at 10:54 AM, Bill Spitzak <spitzak at gmail.com> wrote:
>> > On 07/28/2014 09:41 AM, Jason Gerecke wrote:
>> >
>> >> Normalizing the data is fine, but the resolution data needs to be
>> >> available somewhere as well. The GTK+ API doesn't require anything
>> >> more than the former, but Qt requires that there be some way to turn
>> >> the normalized value into degrees. For libinput this could be
>> >> something as simple as a "get_axis_resolution" function that returns
>> >> the number of radians (or mm, or newtons, or some other physical unit)
>> >> that the normalized value +1.0 corresponds to. I suppose Wayland would
>> >> let make the value available through the wl_tablet_manager somehow.
>> >
>> >
>> > Are you sure about these terms? I would think "resolution" should be used to
>> > identify how many discreet positions the device can obtain. What you are
>> > asking for I think would be better to call a "range" or "scale".
>> >
>>
>> Yeah, good catch. Looks like I'm getting imprecise with my terminology *wince*
>>
>> I think I prefer "scale" over "range" personally, since it's only a
>> single logical-to-physical scaling factor (not the physical minimum
>> and maximum extents of the axis).
>>
>> Jason
>> ---
>> Now instead of four in the eights place /
>> you’ve got three, ‘Cause you added one  /
>> (That is to say, eight) to the two,     /
>> But you can’t take seven from three,    /
>> So you look at the sixty-fours....
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>