Draft XI 2 protocol specification

[Simon Thum]

Peter Hutterer wrote:
> that detail the changes made? If so, yes - definitely an option and I'll try
> to spec something decent out.
Yep, that's what I meant.

> I remember now. We said that we can basically include axis information twice,
> once in its raw state, unclipped and unaccelerated, once in its processed
> form. In GPE, both forms are easily accessible, so stuffing that in may not be
> too hard.
Cool.

> I think 16.16 for screen coordinates is definitely viable.
We're approaching 4k resolutions. 16.16 doesn't feel too comfortable
with me, 24.8 is more like it. I don't know that to do with 16 bit
subpixel tbh.
> For actual axis information it's more tricky. Absolute axes with a defined
> range are easy enough as integers, as scaling and thus subpixel information
> has to be achieved on the client side anyway.
Maybe we have different things in mind here. I'd say a class of widgets,
e.g. sliders and panning controls (gimp in LR edge), can make sense of
sub-pixel screen coordinates. If that's what "achieved on the client
side" refers to, then yes. But the server ideally should deliver a
sub-pixel screen translation, independent of what my device looks like.
 Maybe that should be covered in corresponding master dev events.

> Relative axes are more complicated as they lack a defined axes range. One
> option would be the definition of a per-axis scaling factor as part of the
> device capabilities. Data in the valuators is then always INT32, multiplied by
> this scaling factor (for many devices this scaling factor is probably 1
> anyway).
I don't see what this buys. At the end of the day, a client wants to
know what the value reflects, which properties (in the math sense) it
has. Something like "the (sub-)pixel distance in screen coordinates
since the previous event, ignoring clipping. If the axis is not
translated to screen, device values are reported." Or simply device
(driver) values always.

It may make sense to have different specs for master and slave devs, and
a bit indicating master-ness in the (relative) event.

> This gives us the ability to do subpixel precision with an arbitrary per-axis
> subpixel resolution. But then again, the same can be achieved by just using
> floats in the first place.
> 
> Just thinking out aloud here.
:) You know I'm not a float-hater, but wrt devices one needs to ensure
decent precision is available over the whole (potentially large) screen.
May get difficult to achieve.

In general, XRelativeMotionEvent and XDeviceEvent have a large overlap.
If you implement raw/cooked, an extra rel event may be superfluous.

I assumed master devs are not core-only, as that correct? If yes, I'm
all "let master/slave decide on coordinate system issues".

Cheers,

Simon