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

[Bastien Nocera]

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.

or

- IFDA_CAPABILITY_EVDEV_EV_ABS=foo;bar;actually-readable-text;
and IFDA_CAPABILITY_EVDEV_EV_KEY=foo1;foo2;other-human-readable-text

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.

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).