Re: [PATCH] libinput device capability modification regarding combo input devices
Sorry about the delay, I was on vacation.
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 ?
we can add new capabilities - gestures was added fairly recently and we have
two more capabilities in the pipe for graphics tablets/button set devices.
> IMO, it's better to get capabilities by calling once an API than calling
> libinput_device_has_capability twice.
"better" is hard to quantify :) There's no real technical difference between
passing a mask in or calling the function twice.
> Otherwise, we can enhance wayland protocol to get keyboard/pointer name from
> the compositor by event(s).
> Please share your opinion.
The wayland protocol is quite a different beast to libinput though. libinput
gives you per-device handling (since it aims to be for the compositor), the
wayland protocol hides all input devices behind the virtual
pointer/keyboard/touch interface. Two very different things, maybe you
should specify the problem you're trying to solve in more detail.
Right now, even if you send the device name for each input event down the
protocol, it still wouldn't gain you much (or anything?).
Cheers,
Peter
>
> 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_MAS
Re: Re: [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
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.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_DEVI
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.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
Re: [PATCH] libinput device capability modification regarding combo input devices
On 24/09/15 07:38 PM, 박성진 wrote: > Dear Bill Spitzak, thanks for your opinion. : ) > > > > As we know, there are a lot of keyboards or keyboard-like devices. > > Some of them will be keypads or special keyboards for game or other > purposes. > > For those kinds of keyboards, we don’t need to care and we can deal with > the events in the usual manner (e.g. send them to focus surface/window). > > > > When it comes to mobile or TV, we can have another stories. > > In mobile/TV, in some cases, we need to deal with a set of keys attached > in the device in a special manner, therefore we need to distinguish the > keys in the set from the normal keyboard keys. > > > > For instance, in mobile, we can see some keys attached in our mobile > devices. > > Those kinds of keys are usually not for input texts but for triggering > some actions. > > In a usual application, volume up/down keys will be the keys for > raising/lowering the volume. > > By the way, in an application like a message application, volume up/down > keys can be used to adjust the font size. This sounds like it would make me very angry, especially if I wanted to make the device quiet in a hurry. ;) > Therefore each key attached in mobile device needs to be sent to each > needed surface/window in a dynamically changeable delivery policy for > each key because there are many applications which want to get a key > even they don’t have the input focus. > > Actually in many requirements in mobile devices, distinguishing between > the normal(?) keyboards and the special set of key/buttons are needed > and we need to have a key delivery manager which resides in a window > manager for sending the special set of keys to the proper application(s). Would it be possible to achieve this same effect by subdividing keyboards virtually into multiple seats? (multimedia keys into a multimedia control seat, camera button to a seat named camera...) The compositor or some manner of plug-in could handle this. If an application bound the seat containing the media keys they would be sent to that app if it had keyboard focus... If no app bound that seat then the compositor could use the keys internally to control volume levels, launch camera app, etc... I think perhaps the needed functionality is too high level for libinput... (there's still a little more text below.) > > Thanks and regards, > > Sung-Jin Park > > > > *From:*Bill Spitzak [mailto:spit...@gmail.com] > *Sent:* Friday, September 25, 2015 4:37 AM > *To:* 박성진 > *Cc:* Andreas Pokorny; Peter Hutterer; wayland > *Subject:* Re: [PATCH] libinput device capability modification regarding > combo input devices > > > > > > > > On Wed, Sep 23, 2015 at 6:52 PM, 박성진 <mailto:sj76.p...@samsung.com>> wrote: > > Dear Andreas Pokorny, thanks for your reply. J > > > > As you mentioned, we also need to distinguish between a full keyboard > and a device which has a set of few keys. I've written a patch to do just that: http://patchwork.freedesktop.org/patch/48595 The intent being to add the ability to auto-hide a virtual keyboard if a full keyboard is present... I just need to get back to it and finish it up :) Full keyboards can have multimedia keys as well though... > Each key coming from the full keyboard will be sent to the focus > surface(window). > > However, a key coming from the device which has a few keys sometimes > needs to be sent to the other surface(window) other than the focused > surface(window). > > > > Seems like the keyboard flag can just indicate a "full keyboard". It is > hard to imagine an input device that does not have a few buttons so this > can be assumed. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH] libinput device capability modification regarding combo input devices
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
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
RE: [PATCH] libinput device capability modification regarding combo input devices
Dear Bill Spitzak, thanks for your opinion. : ) As we know, there are a lot of keyboards or keyboard-like devices. Some of them will be keypads or special keyboards for game or other purposes. For those kinds of keyboards, we don’t need to care and we can deal with the events in the usual manner (e.g. send them to focus surface/window). When it comes to mobile or TV, we can have another stories. In mobile/TV, in some cases, we need to deal with a set of keys attached in the device in a special manner, therefore we need to distinguish the keys in the set from the normal keyboard keys. For instance, in mobile, we can see some keys attached in our mobile devices. Those kinds of keys are usually not for input texts but for triggering some actions. In a usual application, volume up/down keys will be the keys for raising/lowering the volume. By the way, in an application like a message application, volume up/down keys can be used to adjust the font size. Therefore each key attached in mobile device needs to be sent to each needed surface/window in a dynamically changeable delivery policy for each key because there are many applications which want to get a key even they don’t have the input focus. Actually in many requirements in mobile devices, distinguishing between the normal(?) keyboards and the special set of key/buttons are needed and we need to have a key delivery manager which resides in a window manager for sending the special set of keys to the proper application(s). Thanks and regards, Sung-Jin Park From: Bill Spitzak [mailto:spit...@gmail.com] Sent: Friday, September 25, 2015 4:37 AM To: 박성진 Cc: Andreas Pokorny; Peter Hutterer; wayland Subject: Re: [PATCH] libinput device capability modification regarding combo input devices On Wed, Sep 23, 2015 at 6:52 PM, 박성진 wrote: Dear Andreas Pokorny, thanks for your reply. J As you mentioned, we also need to distinguish between a full keyboard and a device which has a set of few keys. Each key coming from the full keyboard will be sent to the focus surface(window). However, a key coming from the device which has a few keys sometimes needs to be sent to the other surface(window) other than the focused surface(window). Seems like the keyboard flag can just indicate a "full keyboard". It is hard to imagine an input device that does not have a few buttons so this can be assumed. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] libinput device capability modification regarding combo input devices
On Wed, Sep 23, 2015 at 6:52 PM, 박성진 wrote: > Dear Andreas Pokorny, thanks for your reply. J > > > > As you mentioned, we also need to distinguish between a full keyboard and > a device which has a set of few keys. > > Each key coming from the full keyboard will be sent to the focus > surface(window). > > However, a key coming from the device which has a few keys sometimes needs > to be sent to the other surface(window) other than the focused > surface(window). > Seems like the keyboard flag can just indicate a "full keyboard". It is hard to imagine an input device that does not have a few buttons so this can be assumed. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH] libinput device capability modification regarding combo input devices
Dear Andreas Pokorny, thanks for your reply. J As you mentioned, we also need to distinguish between a full keyboard and a device which has a set of few keys. Each key coming from the full keyboard will be sent to the focus surface(window). However, a key coming from the device which has a few keys sometimes needs to be sent to the other surface(window) other than the focused surface(window). Dear Peter Hutterer, any ideas on this patch ? J Thanks and regards, Sung-Jin Park From: Andreas Pokorny [mailto:andreas.poko...@gmail.com] Sent: Wednesday, September 23, 2015 3:48 PM To: 박성진 Cc: wayland-devel@lists.freedesktop.org Subject: Re: [PATCH] libinput device capability modification regarding combo input devices Hi, 2015-09-23 4:29 GMT+02:00 박성진 : 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 that reason we do use masks inside mir to describe input devices. We do use a few additional masks to also indicate whether the device, i.e. it might be interesting to know whether the device is a full keyboard or just offers a few buttons.. So yes I aggree with that. Right now we do the evdev based device detection in parallel to what udevd and libinput do.. regards Andreas Pokorny ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] libinput device capability modification regarding combo input devices
Hi, 2015-09-23 4:29 GMT+02:00 박성진 : > 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 that reason we do use masks inside mir to describe input devices. We do use a few additional masks to also indicate whether the device, i.e. it might be interesting to know whether the device is a full keyboard or just offers a few buttons.. So yes I aggree with that. Right now we do the evdev based device detection in parallel to what udevd and libinput do.. regards Andreas Pokorny ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
