[PATCH] libinput device capability modification regarding combo input devices

[박성진]

Dear Peter,
from the techinical point of view, calling an API several times doesn't matter. I'm with you, 
as we call dequeue() for a queue to get the queued item in order.
Regarding a queue, we know that we're using a queue therefore we'll call dequeue in natural ways.
By the way, regarding a capability stuff, IMHO, by calling once we can get the whole capabilities of a device
and it's more intuitive way because the user of the API doesn't know that how many capabilities are in the device.
Actually, as of now, we need to make a loop to get whole capabilities properly.

Thanks and regards,
Sung-Jin Park

------- Original Message -------
Sender : Peter Hutterer<peter.hutterer at who-t.net> 
Date   : 2015-09-26 13:09 (GMT+09:00)
Title  : Re: [PATCH] libinput device capability modification regarding combo
 input devices

On Fri, Sep 25, 2015 at 03:32:43PM +0900, 박성진 wrote:
> Dear Peter, thanks.
> That's right. If we modify the enum with the new one, ABI break will be made.
> Then how about add new capabilities ?
> IMO, it's better to get capabilities by calling once an API than calling libinput_device_has_capability twice.

we can add new capabilities (we already have two scheduled for future
merging, tablet and buttonset) but I don't really see a technical reason why
calling the API twice is a problem. Can you expand on this?

Cheers,
   Peter

> Otherwise, we can enhance wayland protocol to get keyboard/pointer name from the compositor by event(s).
> Please share your opinion.
> 
> Thanks and regards,
> Sung-Jin Park
> 
> -----Original Message-----
> From: Peter Hutterer [mailto:peter.hutterer at who-t.net] 
> Sent: Friday, September 25, 2015 3:13 PM
> To: ?????
> Cc: wayland-devel at lists.freedesktop.org
> Subject: Re: [PATCH] libinput device capability modification regarding combo input devices
> 
> On Wed, Sep 23, 2015 at 11:29:13AM +0900,  ?    wrote:
> > Dear all,
> > 
> > as you guys know, there are some combo input devices which support 
> > both keyboard functionality and pointer functionality.
> > 
> > We can also see some of input devices supports both keyboard 
> > functionality and touch functionality.
> > 
> >  
> > 
> > In theory, each input device functionality needs to be provided 
> > through each kernel device node.
> > 
> > By the way, there are many combo input devices whose input events is 
> > coming from one device node.
> > 
> > Now and in near future, many vendors can make many combo input devices.
> > 
> >  
> > 
> > For these kinds of input devices, how about adding new enums for combo 
> > devices?
> > 
> > Otherewise, how about defining enums with masks ?
> > 
> >  
> > 
> > For example, we can modify the definition of 
> > libinput_device_capability enum like the following:
> > 
> >  
> > 
> > diff --git a/src/libinput.h b/src/libinput.h
> > 
> > index 9057446..458f256 100644
> > 
> > --- a/src/libinput.h
> > 
> > +++ b/src/libinput.h
> > 
> > @@ -51,14 +51,22 @@ enum libinput_log_priority {
> > 
> > /**
> > 
> >   * @ingroup device
> > 
> >   *
> > 
> > - * Capabilities on a device. A device may have one or more 
> > capabilities
> > 
> > + * Capability masks and capabilities on a device. A device may have 
> > + one or
> > more capabilities
> > 
> >   * at a time, capabilities remain static for the lifetime of the device.
> > 
> >   */
> > 
> > +#define LIBINPUT_DEVICE_CAP_KEYBOARD_MASK (1L<<0)
> > 
> > +#define LIBINPUT_DEVICE_CAP_POINTER_MASK (1L<<1)
> > 
> > +#define LIBINPUT_DEVICE_CAP_TOUCH_MASK (1L<<2)
> > 
> > +#define LIBINPUT_DEVICE_CAP_GESTURE_MASK (1L<<3)
> > 
> > +
> > 
> > enum libinput_device_capability {
> > 
> > -       LIBINPUT_DEVICE_CAP_KEYBOARD = 0,
> > 
> > -       LIBINPUT_DEVICE_CAP_POINTER = 1,
> > 
> > -       LIBINPUT_DEVICE_CAP_TOUCH = 2,
> > 
> > -       LIBINPUT_DEVICE_CAP_GESTURE = 5,
> > 
> > +       LIBINPUT_DEVICE_CAP_KEYBOARD = 
> > + LIBINPUT_DEVICE_CAP_KEYBOARD_MASK,
> > 
> > +       LIBINPUT_DEVICE_CAP_POINTER = 
> > + LIBINPUT_DEVICE_CAP_POINTER_MASK,
> > 
> > +       LIBINPUT_DEVICE_CAP_TOUCH = LIBINPUT_DEVICE_CAP_TOUCH_MASK,
> > 
> > +       LIBINPUT_DEVICE_CAP_GESTURE = 
> > + LIBINPUT_DEVICE_CAP_GESTURE_MASK,
> > 
> > +       LIBINPUT_DEVICE_CAP_KEYBOARD_POINTER =
> > LIBINPUT_DEVICE_CAP_KEYBOARD_MASK | LIBINPUT_DEVICE_CAP_POINTER_MASK,
> > 
> > +       LIBINPUT_DEVICE_CAP_KEYBOARD_TOUCH =
> > LIBINPUT_DEVICE_CAP_KEYBOARD_MASK | LIBINPUT_DEVICE_CAP_TOUCH_MASK,
> > 
> > +       LIBINPUT_DEVICE_CAP_TOUCH_GESTURE = 
> > + LIBINPUT_DEVICE_CAP_TOUCH_MASK
> > | LIBINPUT_DEVICE_CAP_GESTURE_MASK,
> > 
> > };
> > 
> >  
> > 
> > /**
> > 
> > With this kinds of modification,
> > 
> > A wayland compositor is able to recognize the actual input device 
> > capabilities and able to interpret events properly.
> > 
> >  
> > 
> > Any ideas ?
> 
> Two things: libinput's API has been stable for a while now and cannot be changed, you can only add to it in backwards-compatible manner. The above isn't backwards-compatible, so it's a non-starter.
> 
> The mask-like behaviour you ask for is provided by these enums. if you want to check if a device is both pointer and keyboard, you call libinput_device_has_capability twice, once with CAP_POINTER, once with CAP_KEYBOARD. There's no need for specific combination defines or masks.
> 
> Cheers,
>    Peter
> 
> 
<p> </p><p> </p>