Re: State of Wayland protocol development

[Jonas Ådahl]

On Mon, Oct 12, 2015 at 10:07:19AM +0300, Pekka Paalanen wrote:
> On Fri, 9 Oct 2015 15:24:04 +0100
> Daniel Stone  wrote:
> 
> > On 9 October 2015 at 14:36, Jonas Ådahl  wrote:
> > > On Fri, Oct 09, 2015 at 02:11:28PM +0100, Daniel Stone wrote:
> 
> > >> >> > I still have the '_' prefix which, mentioned by Pekka, violates some
> > >> >> > rule in C. I'm not sure we need to care (we've been doing this in 
> > >> >> > weston
> > >> >> > since 2013), but if anyone has a better suggestion or objection 
> > >> >> > please
> > >> >> > say so.
> > >>
> > >> Unfortunately it does, and I think it makes newer g++ in particular
> > >> quite unhappy. dmabuf is currently using 'z' as an experimental
> > >> prefix, which seems reasonable enough - but again that falls into the
> > >> stable-naming problem. If zlinux_dmabuf v7 is the blessed stable
> > >> version, then it means clients written to zlinux_dmabuf v7 have to
> > >> completely unnecessarily port everything to being linux_dmabuf v1. I'd
> > >> be much more in favour of keeping a single stable name throughout its
> > >> development.
> > >
> > > My idea of this is that, an experimental/unstable protocol is just that.
> > > When declared stable, it's more or lesst the final break. If you want to
> > > have linux_dmabuf with no special unstable naming during all of its
> > > development stages, then that means you start being stable at version 1,
> > > with the difference that it may be incomplete. The point of unstable
> > > protocols is that changes may break the protocol, and to make tha
> > > possible, we need to do a rename when declaring it stable. It's the pain
> > > that comes with being an early adopter, while still enabling the
> > > possibility to actually fix the protocol during its early stages instead
> > > of duct tape it.
> > >
> > > If you see some way to avoid renaming then please explain, because its
> > > not clear to me how (across multiple projects and code bases) it'd work.
> > 
> > Oh, sure. I was just hoping to avoid, if possible, the following kind
> > of situation:
> >   - zlinux_dmabuf v4 (or whatever) gets widely deployed in GStreamer,
> > Weston and Mutter
> >   - everyone agrees it's perfect and that exact protocol becomes 
> > linux_dmabuf v1
> >   - everyone now needs to either support both, or break backwards 
> > compatibility
> > 
> > For similar reasons, everyone doing voice calls ended up implementing
> > the org.freedesktop.Telepathy.CallDRAFT interface.
> > 
> > But I get that our protocol versioning should really be additive -
> > i.e. no rewriting of existing requests - so that's fair enough I
> > guess.
> 
> Renaming the XML file is a sure way to indicate at build time which
> incompatible version is required.
> 
> We will also need renaming all the related globals, so that a client
> compiled with one incompatible version will not try to bind the
> interface of a server compiled with a different incompatible version.
> 
> This is more graceful than what we tried with xdg-shell's do-or-die
> experimental versioning which was basically non-detectable at runtime.
> 
> If we really need to do incompatible changes, then I do not see a way
> to avoid the renames.
> 
> The open question here that I see is that should we expect a final
> break at stabilization time to move on to a "proper" name, or end up
> using zlinux_dmabuf_v4 for the stable iteration rather than
> linux_dmabuf, for instance.
> 
> On one hand, using linux_dmabuf_v4_create_params() looks a little odd
> to me, OTOH having to fix everything at stabilization time is slightly
> annoying too.
> 
> We should favour non-breaking changes, sure, but sometimes it's better
> to clean things up.
> 
> Should we encode experimental version in the global interface name or
> not?

Either we encode the version in the name together with a prefix, or we
only have a prefix and redefine the meaning of the interface version.
I'm fine with having it in the name, allowing compatible changes during
the unstable phase.

> 
> If we do, we might be inclined to do an "unneeded" rename when we
> decide the interface is stable. If we do not, we might end up with the
> problem that wl_scaler has right now: I would like to clean up the
> interface, but the change will be incompatible, so I have to come up
> with a new name. Coming up with good names is one of the hardest things
> in programming, IMO.

I wonder, has anyone else implemented it? Maybe you can get away with a
not renaming it before its too late.

> 
> Are we all ok with the final break caused by the rename, even if there
> were no incompatible changes?

I'm in favor of a final rename of the global, the protocol name and the
XML file name when declaring stable.


Jonas

> 
> I think we should expect to have incompatible changes during protocol
> development, and not having any would be the exception, so I am fine
> with the final mandatory rename.
> 
> 
> Thanks,
> pq

Re: State of Wayland protocol development

[Jonas Ådahl]

On Fri, Oct 09, 2015 at 05:31:10PM +0200, Mariusz Ceier wrote:
> Hi,
> 
> On 9 October 2015 at 15:36, Jonas Ådahl  wrote:
> 
> > On Fri, Oct 09, 2015 at 02:11:28PM +0100, Daniel Stone wrote:
> > > Hi,
> > >
> > > On 9 October 2015 at 11:15, Jonas Ådahl  wrote:
> > > > On Fri, Oct 09, 2015 at 12:36:54PM +0300, Pekka Paalanen wrote:
> > > >> On Fri, 9 Oct 2015 14:41:31 +0800
> > > >> Jonas Ådahl  wrote:
> > > >> > I implemented one of the brought up ideas to see how it'd work.
> > > >> > More specifically, I created a repository called
> > "wayland-protocols"[0]
> > > >> > and adapted weston[1] to use it for the fullscreen shell. I also
> > added
> > > >> > pointer gestures to make it obvious that its not only protocols
> > that are
> > > >> > implemented in weston that are part of it.
> > > >> >
> > > >> > The way I imagine it would work is, for new protocols to be
> > introduced,
> > > >> > it'd have to be a agreed upon "correct" path (i.e. probably not
> > > >> > wl_absolute_coordinates etc), which should simply mean that such a
> > > >> > protocol should have been at least Acked-by one or more core
> > developer
> > > >> > that have acknowledged that it is a suitable thing to do in the
> > Wayland
> > > >> > ecosystem.
> > > >> >
> > > >> > Protocol changes (including introduction) would also require
> > > >> > Reviewed-by's by someone with enough knowledge*, and if a protocol
> > has a
> > > >> > maintainer(s), at least Acked-by one of them.
> > >
> > > Excellent. One really important thing I think to have would be some
> > > documentation around the protocol: what are the known open issues /
> > > missing pieces / pitfalls? What is the rough plan going forward - is
> > > it expected to be marked stable imminently, or expected to be
> > > rewritten? We should really make this a hard requirement, rather than
> > > having to search through the list every time to remember the most
> > > recent discussion on it.
> >
> > I wonder if this could be done via directory structure. Something like:
> >
> > stable/ - .. well, stable
> > unstable/ - in-progress, future goal is being declared stable
> > deprecated/ - deprecated for some other reason, at some point removed
> >
> > With each protocol having a README with some kind of plan / status and
> > a list of maintainers.
> >
> > >
> > > >> > Releases of this repository would not be tied to releases of
> > > >> > wayland/weston, and it wouldn't be a requirement to have a protocol
> > > >> > implemented in weston to make it part of a wayland-protocols
> > release.
> > > >> >
> > > >> > Fast paced protocol development would be done on topic branches, and
> > > >> > wouldn't be part of any release until properly reviewed. External
> > > >> > projects would be encouraged to not release software releases that
> > > >> > exposes such intermediate versions; if expected to use a common
> > > >> > namespace, they should use a version from a wayland-protocols
> > release.
> > > >> >
> > > >> > Declaring a protocol stable could either be done by doing the
> > renaming
> > > >> > and moving it to wayland, or we could just move it to a stable/
> > > >> > subdirectory in the same repository. I actually think this might be
> > a
> > > >> > better idea, so that we don't tie down protocol development to the
> > > >> > reference compositor release cycle.
> > >
> > > Yeah. Given that we've decided that new protocols shouldn't be a part
> > > of libwayland-client, I think maintaining it externally to the core
> > > library is pretty attractive.
> > >
> > > >> > Patch merging could be done in the same way as with wayland/weston,
> > > >> > assuming the patch merger makes sure the right persons have acked or
> > > >> > reviewed.
> > > >> >
> > > >> > Release management could either be done by the wayland/weston
> > release
> > > >> > manager or someone else. I could volunteer doing this if no one
> > else has
> > > >> > a strong urge.
> > > >> >
> > > >> > For the more practical parts, the protocols in the repo now have
> > > >> > versions in the XML file names and in the protocol element
> > attribute, but
> > > >> > not in the interface names. Having version numbers in the interface
> > names
> > > >> > would enable us to implement multiple versions in clients and
> > servers,
> > > >> > but it'd mean that each interface would have both a _ prefix and a
> > > >> > version number. Maybe thats fine, and I wouldn't object if someone
> > thought
> > > >> > that would be better. It'd get rid of the redefinition of interface
> > > >> > versioning for unstable protocols.
> > > >> >
> > > >> > I still have the '_' prefix which, mentioned by Pekka, violates some
> > > >> > rule in C. I'm not sure we need to care (we've been doing this in
> > weston
> > > >> > since 2013), but if anyone has a better suggestion or objection
> > please
> > > >> > say so.
> > >
> > > Unfortunately it does, and I think it makes newer g++ in particular
> > > 

Re: State of Wayland protocol development

[Pekka Paalanen]

On Fri, 9 Oct 2015 15:24:04 +0100
Daniel Stone  wrote:

> On 9 October 2015 at 14:36, Jonas Ådahl  wrote:
> > On Fri, Oct 09, 2015 at 02:11:28PM +0100, Daniel Stone wrote:

> >> >> > I still have the '_' prefix which, mentioned by Pekka, violates some
> >> >> > rule in C. I'm not sure we need to care (we've been doing this in 
> >> >> > weston
> >> >> > since 2013), but if anyone has a better suggestion or objection please
> >> >> > say so.
> >>
> >> Unfortunately it does, and I think it makes newer g++ in particular
> >> quite unhappy. dmabuf is currently using 'z' as an experimental
> >> prefix, which seems reasonable enough - but again that falls into the
> >> stable-naming problem. If zlinux_dmabuf v7 is the blessed stable
> >> version, then it means clients written to zlinux_dmabuf v7 have to
> >> completely unnecessarily port everything to being linux_dmabuf v1. I'd
> >> be much more in favour of keeping a single stable name throughout its
> >> development.
> >
> > My idea of this is that, an experimental/unstable protocol is just that.
> > When declared stable, it's more or lesst the final break. If you want to
> > have linux_dmabuf with no special unstable naming during all of its
> > development stages, then that means you start being stable at version 1,
> > with the difference that it may be incomplete. The point of unstable
> > protocols is that changes may break the protocol, and to make tha
> > possible, we need to do a rename when declaring it stable. It's the pain
> > that comes with being an early adopter, while still enabling the
> > possibility to actually fix the protocol during its early stages instead
> > of duct tape it.
> >
> > If you see some way to avoid renaming then please explain, because its
> > not clear to me how (across multiple projects and code bases) it'd work.
> 
> Oh, sure. I was just hoping to avoid, if possible, the following kind
> of situation:
>   - zlinux_dmabuf v4 (or whatever) gets widely deployed in GStreamer,
> Weston and Mutter
>   - everyone agrees it's perfect and that exact protocol becomes linux_dmabuf 
> v1
>   - everyone now needs to either support both, or break backwards 
> compatibility
> 
> For similar reasons, everyone doing voice calls ended up implementing
> the org.freedesktop.Telepathy.CallDRAFT interface.
> 
> But I get that our protocol versioning should really be additive -
> i.e. no rewriting of existing requests - so that's fair enough I
> guess.

Renaming the XML file is a sure way to indicate at build time which
incompatible version is required.

We will also need renaming all the related globals, so that a client
compiled with one incompatible version will not try to bind the
interface of a server compiled with a different incompatible version.

This is more graceful than what we tried with xdg-shell's do-or-die
experimental versioning which was basically non-detectable at runtime.

If we really need to do incompatible changes, then I do not see a way
to avoid the renames.

The open question here that I see is that should we expect a final
break at stabilization time to move on to a "proper" name, or end up
using zlinux_dmabuf_v4 for the stable iteration rather than
linux_dmabuf, for instance.

On one hand, using linux_dmabuf_v4_create_params() looks a little odd
to me, OTOH having to fix everything at stabilization time is slightly
annoying too.

We should favour non-breaking changes, sure, but sometimes it's better
to clean things up.

Should we encode experimental version in the global interface name or
not?

If we do, we might be inclined to do an "unneeded" rename when we
decide the interface is stable. If we do not, we might end up with the
problem that wl_scaler has right now: I would like to clean up the
interface, but the change will be incompatible, so I have to come up
with a new name. Coming up with good names is one of the hardest things
in programming, IMO.

Are we all ok with the final break caused by the rename, even if there
were no incompatible changes?

I think we should expect to have incompatible changes during protocol
development, and not having any would be the exception, so I am fine
with the final mandatory rename.


Thanks,
pq


pgpnvgGPco177.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Separating X clients under Wayland

[Pekka Paalanen]

On Sat, 10 Oct 2015 12:59:49 +0200
Ole Kliemann  wrote:

> Sometime ago a question was posted on this list whether X clients 
> under XWayland are separated from each other like Wayland clients 
> are. It was concluded that they are not. [1]
> 
> However, it was suggested that of course one could start a 
> separate X server for each client to achieve separation. [2]
> 
> My question now is: Can XWayland be configured or modified to 
> behave this way? 

Hi,

I don't think you will need anything extra in Xwayland to support this.

What you do need though is the Wayland compositor to support it. The
compositor needs to know to launch more Xwayland servers, and the XWM
(proxying X11 window manager) embedded in the compositor needs to be
able to deal with it too.

So, this question is specific to the compositor you choose to run. I
suspect no current compositor implementation supports this by
configuration alone, you'd need to actually implement the feature first.


Thanks,
pq

> I was trying Xephyr to separate X clients under X once; I believe 
> Red Hat has a sandboxing utility that works similar. But 
> something like this is usually tedious to setup and clunky to 
> use.
> 
> Thus it would be very useful if Wayland simply would handle 
> starting separate X servers for each client.
> 
> 
> 
> [1] 
> http://lists.freedesktop.org/archives/wayland-devel/2014-January/012705.html
> [2] 
> http://lists.freedesktop.org/archives/wayland-devel/2014-January/012777.html


pgpE4tlClCVEj.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Enums, bitfields and wl_arrays

[Pekka Paalanen]

On Mon, 12 Oct 2015 10:41:22 +0200
Erik De Rijcke  wrote:

> Adding enum members is backward compatible for Java. If you compile against
> an enum with 2 members, and later on a new member is added, you can simply
> use the new version of the enum.
> 
> Important however is that the order of old members do not change when new
> members are added.

This is important. I don't think anyone has ever mentioned anything
like this before.

We certainly have not expected the order to matter inside an 
tag, since we require the value to be explicitly given. Not when you
are coming from C, anyway.

Apparently we would need to start enforcing the rule:

"Only ever add new enum value to the end of a closed enum."

Yeah, now we also need the concept of open and closed enums, because
for something like used in xdg-shell for window states, the whole enum
concept doesn't work e.g. in Java (I hear).

Should we be adding all these to the Wayland XML language or not?


Thanks,
pq


pgpHONLY0Z_zc.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: State of Wayland protocol development

[Pekka Paalanen]

On Mon, 12 Oct 2015 15:18:47 +0800
Jonas Ådahl  wrote:

> On Mon, Oct 12, 2015 at 10:07:19AM +0300, Pekka Paalanen wrote:
> > On Fri, 9 Oct 2015 15:24:04 +0100
> > Daniel Stone  wrote:
> > 
> > > On 9 October 2015 at 14:36, Jonas Ådahl  wrote:
> > > > On Fri, Oct 09, 2015 at 02:11:28PM +0100, Daniel Stone wrote:

> > > >> Unfortunately it does, and I think it makes newer g++ in particular
> > > >> quite unhappy. dmabuf is currently using 'z' as an experimental
> > > >> prefix, which seems reasonable enough - but again that falls into the
> > > >> stable-naming problem. If zlinux_dmabuf v7 is the blessed stable
> > > >> version, then it means clients written to zlinux_dmabuf v7 have to
> > > >> completely unnecessarily port everything to being linux_dmabuf v1. I'd
> > > >> be much more in favour of keeping a single stable name throughout its
> > > >> development.
> > > >
> > > > My idea of this is that, an experimental/unstable protocol is just that.
> > > > When declared stable, it's more or lesst the final break. If you want to
> > > > have linux_dmabuf with no special unstable naming during all of its
> > > > development stages, then that means you start being stable at version 1,
> > > > with the difference that it may be incomplete. The point of unstable
> > > > protocols is that changes may break the protocol, and to make tha
> > > > possible, we need to do a rename when declaring it stable. It's the pain
> > > > that comes with being an early adopter, while still enabling the
> > > > possibility to actually fix the protocol during its early stages instead
> > > > of duct tape it.
> > > >
> > > > If you see some way to avoid renaming then please explain, because its
> > > > not clear to me how (across multiple projects and code bases) it'd work.
> > > 
> > > Oh, sure. I was just hoping to avoid, if possible, the following kind
> > > of situation:
> > >   - zlinux_dmabuf v4 (or whatever) gets widely deployed in GStreamer,
> > > Weston and Mutter
> > >   - everyone agrees it's perfect and that exact protocol becomes 
> > > linux_dmabuf v1
> > >   - everyone now needs to either support both, or break backwards 
> > > compatibility
> > > 
> > > For similar reasons, everyone doing voice calls ended up implementing
> > > the org.freedesktop.Telepathy.CallDRAFT interface.
> > > 
> > > But I get that our protocol versioning should really be additive -
> > > i.e. no rewriting of existing requests - so that's fair enough I
> > > guess.
> > 
> > Renaming the XML file is a sure way to indicate at build time which
> > incompatible version is required.
> > 
> > We will also need renaming all the related globals, so that a client
> > compiled with one incompatible version will not try to bind the
> > interface of a server compiled with a different incompatible version.
> > 
> > This is more graceful than what we tried with xdg-shell's do-or-die
> > experimental versioning which was basically non-detectable at runtime.
> > 
> > If we really need to do incompatible changes, then I do not see a way
> > to avoid the renames.
> > 
> > The open question here that I see is that should we expect a final
> > break at stabilization time to move on to a "proper" name, or end up
> > using zlinux_dmabuf_v4 for the stable iteration rather than
> > linux_dmabuf, for instance.
> > 
> > On one hand, using linux_dmabuf_v4_create_params() looks a little odd
> > to me, OTOH having to fix everything at stabilization time is slightly
> > annoying too.
> > 
> > We should favour non-breaking changes, sure, but sometimes it's better
> > to clean things up.
> > 
> > Should we encode experimental version in the global interface name or
> > not?
> 
> Either we encode the version in the name together with a prefix, or we
> only have a prefix and redefine the meaning of the interface version.
> I'm fine with having it in the name, allowing compatible changes during
> the unstable phase.

I agree having it on the name. I would not like repurposing the
interface version in any case.


> > 
> > If we do, we might be inclined to do an "unneeded" rename when we
> > decide the interface is stable. If we do not, we might end up with the
> > problem that wl_scaler has right now: I would like to clean up the
> > interface, but the change will be incompatible, so I have to come up
> > with a new name. Coming up with good names is one of the hardest things
> > in programming, IMO.
> 
> I wonder, has anyone else implemented it? Maybe you can get away with a
> not renaming it before its too late.

Compositors I don't know, but I'm pretty sure there is GStreamer code
somewhere using it. So, I'd rather rename, just in case. (Renaming
isn't the blocker, my priority queue of tasks is. :-)

Besides, Weston already implements it, so it's nice to not crash a gst
app if they happen to disagree, even if the app was just a demo.

> > Are we all ok with the final break caused by the rename, even if there
> > 

Re: [PATCH] libinput device capability modification regarding combo input devices

[Peter Hutterer]

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

Re: [PATCH] Extending wayland protocol for helping a wayland client to identify the event source of device (pointer/keyboard)

[Peter Hutterer]

On Fri, Sep 25, 2015 at 04:14:25PM +0900, �ڼ��� wrote:
> Dear all,
> 
> Let me share a patch for extending wayland protocol for helping a wayland
> client to identify which events are coming from which physical
> keyboard/pointer device.
> 
> I��d like to discuss with you guys about this patch. : )
> 
> In this patch, I added ��name�� event both for wl_pointer and for
> wl_keyboard.
> 
> Under wayland protocol applied this patch, a wayland compositor will send
> the name event when a wayland client add a listener for wl_pointer or
> wl_keyboard.
> 
> Then, the client can store the name of the keyboard or pointer and will use
> it when it is required.
> 
>  
> 
> Usually in desktop environment, we don��t need to care the source device
> name of events.
> 
> In vehicle, mobile and TV environment, there will be many input devices and
> will be many special requirements for them.
> 
> For instance, in TV, ��1�� key in an usual keyboard will be used as a
> character ��1�� and will be sent to the focus surface/window.
> 
> By the way ��1�� key in remote control for TV will be used as a action key
> and will be sent to channel managing process which doesn��t have any focus
> surface/window.
> 
> In addition to this example, there can be many examples.
> 
> Thus, I share this patch. Any ideas on this ? : )

At least based on this example, I think this is fixing the wrong problem.
knowing which device sends a key is fairly meaningless unless you have
direct access to the devices anyway (which you probably don't, at least not
in the default setups). And there are plenty of devices that have
meaningless names made from the pid/vid hex codes or even worse - "USB
Keyboard".

the source of your problem is IMO that you're treating the remote control
like a keyboard when it isn't one. This is what we've been trying to solve
with the buttonset interface in libinput (still WIP and needs a wayland
protocol extension). Those devices are merely sets of buttons and require
their own focus control and behaviour, separate to (and more domain-specific
than) keyboards. But it moves the issue into its own separate corner where
it can be handled correctly, rather than papering over the issues.

Cheers,
   Peter

> 
> ==
> 
> From ceeb8e2a10dce59a3fda9aca113b64ea97a85746 Mon Sep 17 00:00:00 2001
> 
> From: Sung-Jin Park 
> 
> Date: Fri, 25 Sep 2015 14:01:57 +0900
> 
> Subject: [PATCH] Add name event for wl_pointer and wl_keyboard in wayland
> 
> protocol
> 
>  
> 
> ---
> 
> protocol/wayland.xml | 38 --
> 
> 1 file changed, 36 insertions(+), 2 deletions(-)
> 
>  
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> 
> index 42c9309..7e98720 100644
> 
> --- a/protocol/wayland.xml
> 
> +++ b/protocol/wayland.xml
> 
> @@ -1402,7 +1402,7 @@
> 
>  
> 
>
> 
>  
> 
> -  
> 
> +  
> 
>  
> 
>The wl_pointer interface represents one or more input devices,
> 
>such as mice, which control the pointer location and pointer_focus
> 
> @@ -1569,9 +1569,26 @@
> 
>
> 
>  
> 
>  
> 
> +
> 
> +
> 
> +
> 
> +  
> 
> +This can be used by the client to help identify which pointer
> events
> 
> +come from which physical pointer device.
> 
> +
> 
> +In some cases, a specific client application can acts in different
> ways
> 
> +when it gets pointer events from different pointer devices.
> 
> +For instance, a series of motion events coming from a mouse
> 
> +will be used as a cursor mover while the other series of motion
> events coming
> 
> +from a pointer device which has a special wheel will be used as a
> scroller
> 
> +of list of items.
> 
> +  
> 
> +  
> 
> +
> 
> +
> 
>
> 
>  
> 
> -  
> 
> +  
> 
>  
> 
>The wl_keyboard interface represents one or more keyboards
> 
>associated with a seat.
> 
> @@ -1683,6 +1700,23 @@
> 
> 
> summary="delay in milliseconds since key down until repeating
> starts"/>
> 
>  
> 
> +
> 
> +
> 
> +
> 
> +
> 
> +  
> 
> +This can be used by the client to help identify which key events
> 
> +come from which physical keyboard device.
> 
> +
> 
> +In some cases, a specific client application can acts in different
> ways
> 
> +when it gets an identical key from different keyboard devices.
> 
> +For instance, in TV like environment, '1' key coming from a
> keyboard
> 
> +will be used as a character. Meanwhile '1' key coming from a remote
> 
> +control key device will be used as a channel switching key.
> 
> +  
> 
> +  
> 
> +
> 
> +
> 
>
> 
>  
> 
>
> 
> --
> 
> 1.9.1
> 
>  
> 
>  
> 


> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
>