[PATCH] libinput device capability modification regarding combo input devices

박성진 sj76.park at samsung.com
Thu Sep 24 23:32:43 PDT 2015


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



More information about the wayland-devel mailing list