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.
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.hutte...@who-t.net] Sent: Friday, September 25, 2015 3:13 PM To: �ڼ��� Cc: wayland-devel@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel