[RFC v2 wayland-protocols] inputfd - direct input access protocol

[Peter Hutterer]

On Thu, Apr 27, 2017 at 02:26:24AM +0200, Bastien Nocera wrote:
> On Thu, 2017-04-27 at 08:35 +1000, Peter Hutterer wrote:
> > On Wed, Apr 26, 2017 at 03:49:55PM +0200, Bastien Nocera wrote:
> > > On Wed, 2017-04-26 at 12:00 +1000, Peter Hutterer wrote:
> > > > 
> <snip>
> > > > diff --git a/README.md b/README.md
> > > > index 2f611c5..95e9d9b 100644
> > > > --- a/README.md
> > > > +++ b/README.md
> > > > @@ -62,6 +62,27 @@ In alphabetical order.
> > > >    The bus type of this device. Permitted values are
> > > >    * **```bluetooth```**
> > > >    * **```usb```**
> > > > +* **```IFDA_CAPABILITY_EVDEV_EV_ABS```**:
> > > > +  A device capability denoting the EV_ABS capability on an
> > > > evdev-
> > > > like file
> > > > +  descriptor. The value is a sequence of six hexadecimal values
> > > > +  describing the absinfo struction, in the order of: event code,
> > > > value,
> > > > +  minimum, maximum, fuzz, flat, resolution. For example:
> > > > +  "0x01;0x10;0x00;0x20;0x04;0x00;0x3" sets ABS_Y with a current
> > > > value of
> > > > +  (decimal) 16, an axis range of 0..32, fuzz 4, flat 0 and a
> > > > resolution of
> > > > +  3. The event code is limited to 16 bits, all others are 32 bit
> > > > values.
> > > > +
> > > > +  This property is sent once per supported event code.
> > > > +* **```IFDA_CAPABILITY_EVDEV_EV_KEY```**:
> > > > +  A device capability denoting the EV_KEY capability on an
> > > > evdev-
> > > > like file
> > > > +  descriptor. The value is a sequence of hexadecimal 1-byte
> > > > values
> > > > +  describing the bitmask, with the least sigificant byte first.
> > > > The
> > > > sequence
> > > > +  "0x02;0x01" are bits 1 and 8 (zero-indexed), respectively and
> > > > thus
> > > > the
> > > > +  mask for KEY_ESC and KEY_7.
> > > > +* **```IFDA_CAPABILITY_EVDEV_EV_REL```**:
> > > > +  A device capability denoting the EV_REL capability on an
> > > > evdev-
> > > > like file
> > > > +  descriptor. The value is a sequence of hexadecimal 1-byte
> > > > values
> > > > +  describing the bitmask, with the least sigificant byte first.
> > > > See
> > > > +  IFDA_CAPABILITY_EVDEV_EV_KEY for an explanation.
> > > 
> > > Do we really expect this to be human-readable? I really wouldn't
> > > bother, and have a single property for the EV_KEY and EV_REL values
> > > (";" separated I guess), and not bother with enunciating the flag
> > > values. That makes using the same or similar code easy in the
> > > toolkit
> > > implementations. And as that property is evdev specific anyway...
> > 
> > human-readable means human-understandable which means human-
> > programmable and
> > thus human-debugabale :) debugging this is a nightmare otherwise and
> > need to convert from one form to the other anyway human-readable is a
> > big
> > bonus. and the lot is only sent once per device, so speed is not an
> > issue.
> > 
> > > and not bother with enunciating the flag values. 
> > 
> > I'm not sure what you mean with this? not to specify it as bitmask?
> > then the
> > format wouldn't be defined at all, making implementation more
> > ambiguous. or
> > just not separating it by type?
> > 
> > fwiw, evemu started with just dumping bits to the file, but it's
> > almost
> > incomprehensible. Have a look at the "B: " lines from evemu-record.
> > We needed extra steps to look at the logs each time. That's why it's
> > now
> > dumping human-readable formats into the same logs. Same here,
> > something like
> > "0x03;0x02" for EV_KEY can be eyeballed for correctness.
> 
> I meant that we either do something like:
> 
> - IFDA_CAPABILITY_EVDEV_FLAGS=0xff;0x00;
> where the first item in the list is for ABS, the 2nd for KEY, etc.

then you'd have to mess around with how to separate the lists or how to
express numbers higher than uint64_t, etc.

Right now the specs for lists of integers is fairly simple, so you can split
it consistently and the same way everywhere (admittedly that's just a blurb
in a paragraph and nothing more, but having the same number sequence format
everywhere seems like it's a good idea ;)
 
> or
> 
> - IFDA_CAPABILITY_EVDEV_EV_ABS=foo;bar;actually-readable-text;
> and IFDA_CAPABILITY_EVDEV_EV_KEY=foo1;foo2;other-human-readable-text

full human readable won't work here unless you want to rely on the source to
know every bit by name. Which won't work for some axes anyway (ABS_MISC + N)
and those axes are very common on joysticks.

> The code here:
> http://hg.libsdl.org/SDL/file/0992354a77aa/src/joystick/linux/SDL_sysjoystick.c#l175
> could easily be modified to handle the data from the first case, so it
> would matter too much whether the data came from an ioctl() call on the
> compositor and the toolkit side.

doesn't the propsal do exactly that? all you have to do is parse the bytes
and push them into the arrays, then the result is the same as the ioctl will
give you.

Cheers,
   Peter

> 
> Anyway, either of those is fine, but I don't like the human readable
> format that still requires opening a header file (and probably figuring
> out the power of 2 in hex that corresponds to a bitshifted 1).