Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
On Fri, Nov 18, 2016 at 11:29:53AM +0800, Jonas Ådahl wrote:
> On Fri, Nov 18, 2016 at 12:25:21PM +1000, Peter Hutterer wrote:
> > On Thu, Nov 17, 2016 at 10:42:41AM +0800, Jonas Ådahl wrote:
> > > On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote:
> > > > Hi,
> > > >
> > > > On 15 November 2016 at 09:42, Jonas Ådahl wrote:
> > > > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote:
> > > > >> But this I'd prefer to drop. We need to describe the button codes,
> > > > >> but
> > > > >> the key codes are _already_ perfectly described in the keymap.
> > > > >> Leaving
> > > > >> this undefined opens the door to making life much easier for, e.g.,
> > > > >> RDP-based compositors.
> > > > >
> > > > > Maybe it'd make it easier for RDP based compositors, but it'd make it
> > > > > harder for clients who don't care about keymaps and just wants
> > > > > keycodes
> > > > > (think WASD using games). Such clients doesn't care if it's actually
> > > > > > > > > would
> > > > > make such clients rely on undefined behaviour.
> > > >
> > > > Those clients can trivially introspect the keymap, then ... ?
> > >
> > > Instrospect how? I don't see how I can get anything resembling a
> > > physical position on a keyboard from a xkb_keycode_t and a struct
> > > xkb_keymap.
> >
> > coincidentally, that actually outlines the problem Daniel was talking about.
> > The physical position of KEY_W is not guaranteed. It could be in a different
> > postcode and no-one would notice as long as it sends the same key code.
> > So by relying on KEY_W to be where you think it is, you're contributing to
> > exactly that problem we had switching to evdev.
> >
> > The only thing that could've provided actual physical positioning for the
> > key was the geometry stuff but that was discarded in libxkbcommon, for
> > a number of good reasons.
>
> So lets assume we define wl_keyboard.key to be useless by itself, and
> that its meaning only depends on the keymap_format enum value.
>
> If the keymap_format is 'xkb_v1', the keycode can only be offset by 8
> then passed to a libxkbcommon state set up with the keymap passed via
> wl_keyboard.keymap. The client will AFAICS have no information about the
> keymap; it'll just feed it key-up/down events. Would it be possible to
> add API to libxkbcommon to provide enough information about the passed
> keyboard layout so the client can create its own variant (such as
> xkb_rule_names::model,rules, so that the client can create its own
> layout but with the known layout). That would at least give something
> resembling a key position.
the xkb key names are that. e.g.
struct xkb_context *ctx = xkb_context_new(0);
struct xkb_rule_names names = { "evdev", "pc104", "us", "", "" };
struct xkb_keymap *keymap = xkb_keymap_new_from_names(ctx, &names, 0);
xkb_keycode_t min = xkb_keymap_min_keycode(keymap),
max = xkb_keymap_max_keycode(keymap);
for (int i = min; i < max; i++)
printf("key name for %d: %s\n", i, xkb_keymap_key_get_name(keymap, i));
xkb_context_unref(ctx);
this prints out e.g. "AE01" which is "row E, key 01" and refers to F1, A is
AC01, etc. These names are semi-standard in that xkb has been using them
for decades but they're technically freeform (e.g. LALT or I147 and new
xkb models may define anything)
xkb also gives you the syms for each key code per level, so you should be
able to reconstruct everything you need this way. One problem is that XKB
is largely uni-directional, i.e. keycode->keysym is defined but
keysym->keycode is not always unique. but afaict the tools are already there
to re-build the layout on the client side, albeit without exact position
information.
> If 'no_keymap' is the enum value used, which says the keycode should be
> interpreted directly, how could that be possible if it's undefined?
> Should we then instead define it to only be valid in a tightly
> integrated system (where a certain software only ever runs on a specific
> hardware/software setup)? This is awkward by itself btw, the server
> seems to be required to send a useless fd just to have something to
> pass. I guess that can be avoided by having 'no_keymap' as default,
> assuming one never goes xkb_v1 -> no_keymap.
isn't no_keymap the default anyway, merely by the wl_keyboardf.keymap being
an event that may or may not be sent? It's not spelled out explicitly but
that's how we've been treating other interfaces. Technically, no_keymap
isn't even necessary if the event is skipped altogether.
As for "how could that be possible if it's undefined", I guess there's a
slight difference between the technical term "undefined" and the more blurry
term "not defined". Having no keymap means the latter and as the doc says
"client must understand how to interpret the raw keycode".
Cheers,
Peter
>
>
> Jonas
>
> >
> > Cheers,
> >Peter
> >
> > > > We can't always guarantee that we even _have_ a map to KEY_*, and I
> > > > really d
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
On Fri, Nov 18, 2016 at 12:25:21PM +1000, Peter Hutterer wrote: > On Thu, Nov 17, 2016 at 10:42:41AM +0800, Jonas Ådahl wrote: > > On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote: > > > Hi, > > > > > > On 15 November 2016 at 09:42, Jonas Ådahl wrote: > > > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > > > >> But this I'd prefer to drop. We need to describe the button codes, but > > > >> the key codes are _already_ perfectly described in the keymap. Leaving > > > >> this undefined opens the door to making life much easier for, e.g., > > > >> RDP-based compositors. > > > > > > > > Maybe it'd make it easier for RDP based compositors, but it'd make it > > > > harder for clients who don't care about keymaps and just wants keycodes > > > > (think WASD using games). Such clients doesn't care if it's actually > > > > > > > make such clients rely on undefined behaviour. > > > > > > Those clients can trivially introspect the keymap, then ... ? > > > > Instrospect how? I don't see how I can get anything resembling a > > physical position on a keyboard from a xkb_keycode_t and a struct > > xkb_keymap. > > coincidentally, that actually outlines the problem Daniel was talking about. > The physical position of KEY_W is not guaranteed. It could be in a different > postcode and no-one would notice as long as it sends the same key code. > So by relying on KEY_W to be where you think it is, you're contributing to > exactly that problem we had switching to evdev. > > The only thing that could've provided actual physical positioning for the > key was the geometry stuff but that was discarded in libxkbcommon, for > a number of good reasons. So lets assume we define wl_keyboard.key to be useless by itself, and that its meaning only depends on the keymap_format enum value. If the keymap_format is 'xkb_v1', the keycode can only be offset by 8 then passed to a libxkbcommon state set up with the keymap passed via wl_keyboard.keymap. The client will AFAICS have no information about the keymap; it'll just feed it key-up/down events. Would it be possible to add API to libxkbcommon to provide enough information about the passed keyboard layout so the client can create its own variant (such as xkb_rule_names::model,rules, so that the client can create its own layout but with the known layout). That would at least give something resembling a key position. If 'no_keymap' is the enum value used, which says the keycode should be interpreted directly, how could that be possible if it's undefined? Should we then instead define it to only be valid in a tightly integrated system (where a certain software only ever runs on a specific hardware/software setup)? This is awkward by itself btw, the server seems to be required to send a useless fd just to have something to pass. I guess that can be avoided by having 'no_keymap' as default, assuming one never goes xkb_v1 -> no_keymap. Jonas > > Cheers, >Peter > > > > We can't always guarantee that we even _have_ a map to KEY_*, and I > > > really don't want to encourage the line of thinking that keycodes are > > > somehow special and usable in and of themselves. GNOME did that a long > > > time ago with AT keycodes, and it took literal years to unpick when we > > > tried to move to evdev. Keymaps exist for a reason, and I don't want > > > to encourage people to route around them. > > > > At least don't leave it undefined then, but define it to "useless > > anywhere other than xkbcommon" or something. Having it completely > > undocumented as it is now doesn't seem like a good thing. > > > > > > Jonas > > > > > > > > Cheers, > > > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
On Thu, Nov 17, 2016 at 10:42:41AM +0800, Jonas Ådahl wrote: > On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote: > > Hi, > > > > On 15 November 2016 at 09:42, Jonas Ådahl wrote: > > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > > >> But this I'd prefer to drop. We need to describe the button codes, but > > >> the key codes are _already_ perfectly described in the keymap. Leaving > > >> this undefined opens the door to making life much easier for, e.g., > > >> RDP-based compositors. > > > > > > Maybe it'd make it easier for RDP based compositors, but it'd make it > > > harder for clients who don't care about keymaps and just wants keycodes > > > (think WASD using games). Such clients doesn't care if it's actually > > > > > make such clients rely on undefined behaviour. > > > > Those clients can trivially introspect the keymap, then ... ? > > Instrospect how? I don't see how I can get anything resembling a > physical position on a keyboard from a xkb_keycode_t and a struct > xkb_keymap. coincidentally, that actually outlines the problem Daniel was talking about. The physical position of KEY_W is not guaranteed. It could be in a different postcode and no-one would notice as long as it sends the same key code. So by relying on KEY_W to be where you think it is, you're contributing to exactly that problem we had switching to evdev. The only thing that could've provided actual physical positioning for the key was the geometry stuff but that was discarded in libxkbcommon, for a number of good reasons. Cheers, Peter > > We can't always guarantee that we even _have_ a map to KEY_*, and I > > really don't want to encourage the line of thinking that keycodes are > > somehow special and usable in and of themselves. GNOME did that a long > > time ago with AT keycodes, and it took literal years to unpick when we > > tried to move to evdev. Keymaps exist for a reason, and I don't want > > to encourage people to route around them. > > At least don't leave it undefined then, but define it to "useless > anywhere other than xkbcommon" or something. Having it completely > undocumented as it is now doesn't seem like a good thing. > > > Jonas > > > > > Cheers, > > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote: > Hi, > > On 15 November 2016 at 09:42, Jonas Ådahl wrote: > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > >> But this I'd prefer to drop. We need to describe the button codes, but > >> the key codes are _already_ perfectly described in the keymap. Leaving > >> this undefined opens the door to making life much easier for, e.g., > >> RDP-based compositors. > > > > Maybe it'd make it easier for RDP based compositors, but it'd make it > > harder for clients who don't care about keymaps and just wants keycodes > > (think WASD using games). Such clients doesn't care if it's actually > > > make such clients rely on undefined behaviour. > > Those clients can trivially introspect the keymap, then ... ? Instrospect how? I don't see how I can get anything resembling a physical position on a keyboard from a xkb_keycode_t and a struct xkb_keymap. > > We can't always guarantee that we even _have_ a map to KEY_*, and I > really don't want to encourage the line of thinking that keycodes are > somehow special and usable in and of themselves. GNOME did that a long > time ago with AT keycodes, and it took literal years to unpick when we > tried to move to evdev. Keymaps exist for a reason, and I don't want > to encourage people to route around them. At least don't leave it undefined then, but define it to "useless anywhere other than xkbcommon" or something. Having it completely undocumented as it is now doesn't seem like a good thing. Jonas > > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
On Wed, Nov 16, 2016 at 04:00:23PM +, Daniel Stone wrote: > Hi, > > On 15 November 2016 at 09:42, Jonas Ådahl wrote: > > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > >> But this I'd prefer to drop. We need to describe the button codes, but > >> the key codes are _already_ perfectly described in the keymap. Leaving > >> this undefined opens the door to making life much easier for, e.g., > >> RDP-based compositors. > > > > Maybe it'd make it easier for RDP based compositors, but it'd make it > > harder for clients who don't care about keymaps and just wants keycodes > > (think WASD using games). Such clients doesn't care if it's actually > > > make such clients rely on undefined behaviour. > > Those clients can trivially introspect the keymap, then ... ? > > We can't always guarantee that we even _have_ a map to KEY_*, and I > really don't want to encourage the line of thinking that keycodes are > somehow special and usable in and of themselves. GNOME did that a long > time ago with AT keycodes, and it took literal years to unpick when we > tried to move to evdev. Keymaps exist for a reason, and I don't want > to encourage people to route around them. mind you, the issue there was that the doc said "undefined" and it wasn't intepreted that way so when undefined changed to undefined-but-something-else, happy times ensued. The goal here would be to change "undefined" to "defined", so any conversion would have to be done on the server side. But I fully agree with you otherwise. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
Hi, On 15 November 2016 at 09:42, Jonas Ådahl wrote: > On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: >> But this I'd prefer to drop. We need to describe the button codes, but >> the key codes are _already_ perfectly described in the keymap. Leaving >> this undefined opens the door to making life much easier for, e.g., >> RDP-based compositors. > > Maybe it'd make it easier for RDP based compositors, but it'd make it > harder for clients who don't care about keymaps and just wants keycodes > (think WASD using games). Such clients doesn't care if it's actually > make such clients rely on undefined behaviour. Those clients can trivially introspect the keymap, then ... ? We can't always guarantee that we even _have_ a map to KEY_*, and I really don't want to encourage the line of thinking that keycodes are somehow special and usable in and of themselves. GNOME did that a long time ago with AT keycodes, and it took literal years to unpick when we tried to move to evdev. Keymaps exist for a reason, and I don't want to encourage people to route around them. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > Hi, > > On 10 November 2016 at 05:19, Peter Hutterer wrote: > > A side-note here: my first version sent to Jonas privately had a reserved > > range for any key with the highest bit set. The idea here was to have a > > range defined that we'll never touch during protocol updates so that vendors > > who need some custom key code have a place to escape to. > > > > Note that by custom key code I don't mean "gaming mouse sends custom key X" > > but rather "this is an integrated compositor + client stack solution and the > > key only makes sense in this context". > > > > I took it out of this version now, maybe it makes sense to add this though. > > > > Also, I think the DTD needs a tag :) > > > > protocol/wayland.xml | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 6c6d078..dcc29fe 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -1893,6 +1893,14 @@ > > enter event. > > The time argument is a timestamp with millisecond > > granularity, with an undefined base. > > + > > + The button is a button code as defined in the Linux kernel's > > + linux/input-event-codes.h header file, e.g. BTN_LEFT. > > + > > + Any 16-bit button code value is reserved for future additions to the > > + kernel's event code list. All other button codes above 0x are > > + currently undefined but may be used in future versions of this > > + protocol. > > This bit is fine, though I'm not sure why we want to give ourselves > the room to invent new buttons. > > > > > @@ -2154,6 +2162,16 @@ > > A key was pressed or released. > > The time argument is a timestamp with millisecond > > granularity, with an undefined base. > > + > > + The key is a key code as defined in the Linux kernel's > > + linux/input-event-codes.h header file, e.g. KEY_A. The key > > + represents a physical key on the keyboard and is unaffected by the > > + keyboard layout applied. > > + > > + Any 16-bit key code value is reserved for future additions to the > > + kernel's event code list. All other key codes above 0x are > > + currently undefined but may be used in future versions of this > > + protocol. > > > > But this I'd prefer to drop. We need to describe the button codes, but > the key codes are _already_ perfectly described in the keymap. Leaving > this undefined opens the door to making life much easier for, e.g., > RDP-based compositors. Maybe it'd make it easier for RDP based compositors, but it'd make it harder for clients who don't care about keymaps and just wants keycodes (think WASD using games). Such clients doesn't care if it's actually > Cheers, > Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
On Thu, Nov 10, 2016 at 10:22:41AM +, Daniel Stone wrote: > Hi, > > On 10 November 2016 at 05:19, Peter Hutterer wrote: > > A side-note here: my first version sent to Jonas privately had a reserved > > range for any key with the highest bit set. The idea here was to have a > > range defined that we'll never touch during protocol updates so that vendors > > who need some custom key code have a place to escape to. > > > > Note that by custom key code I don't mean "gaming mouse sends custom key X" > > but rather "this is an integrated compositor + client stack solution and the > > key only makes sense in this context". > > > > I took it out of this version now, maybe it makes sense to add this though. > > > > Also, I think the DTD needs a tag :) > > > > protocol/wayland.xml | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 6c6d078..dcc29fe 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -1893,6 +1893,14 @@ > > enter event. > > The time argument is a timestamp with millisecond > > granularity, with an undefined base. > > + > > + The button is a button code as defined in the Linux kernel's > > + linux/input-event-codes.h header file, e.g. BTN_LEFT. > > + > > + Any 16-bit button code value is reserved for future additions to the > > + kernel's event code list. All other button codes above 0x are > > + currently undefined but may be used in future versions of this > > + protocol. > > This bit is fine, though I'm not sure why we want to give ourselves > the room to invent new buttons. the evdev protocol is great because it gives a semantic value for every button/key. It's terrible because it gives a semantic value for every button/key :) In the past I've had to deal with devices that were just devices with numbered buttons (more than 10) and there is no way in the evdev protocol to express this. Same with axes, we have an ABS_MISC range but it's surprisingly narrow and has a tendency to leak into the MT range which is why a concept of a fake multi-touch device exists. I don't have a concrete example thought through, but I can imagine a wayland-specific range for simple sequential buttons, without forcing every wayland client into knowing that after BTN_9 there comes BTN_A, B, C, X, Y, Z and then possibly something else random. > > > > @@ -2154,6 +2162,16 @@ > > A key was pressed or released. > > The time argument is a timestamp with millisecond > > granularity, with an undefined base. > > + > > + The key is a key code as defined in the Linux kernel's > > + linux/input-event-codes.h header file, e.g. KEY_A. The key > > + represents a physical key on the keyboard and is unaffected by the > > + keyboard layout applied. > > + > > + Any 16-bit key code value is reserved for future additions to the > > + kernel's event code list. All other key codes above 0x are > > + currently undefined but may be used in future versions of this > > + protocol. > > > > But this I'd prefer to drop. We need to describe the button codes, but > the key codes are _already_ perfectly described in the keymap. Leaving > this undefined opens the door to making life much easier for, e.g., > RDP-based compositors. ok, makes sense. I'll drop this bit and/or reword it, thanks. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
Hi, On 10 November 2016 at 05:19, Peter Hutterer wrote: > A side-note here: my first version sent to Jonas privately had a reserved > range for any key with the highest bit set. The idea here was to have a > range defined that we'll never touch during protocol updates so that vendors > who need some custom key code have a place to escape to. > > Note that by custom key code I don't mean "gaming mouse sends custom key X" > but rather "this is an integrated compositor + client stack solution and the > key only makes sense in this context". > > I took it out of this version now, maybe it makes sense to add this though. > > Also, I think the DTD needs a tag :) > > protocol/wayland.xml | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 6c6d078..dcc29fe 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1893,6 +1893,14 @@ > enter event. > The time argument is a timestamp with millisecond > granularity, with an undefined base. > + > + The button is a button code as defined in the Linux kernel's > + linux/input-event-codes.h header file, e.g. BTN_LEFT. > + > + Any 16-bit button code value is reserved for future additions to the > + kernel's event code list. All other button codes above 0x are > + currently undefined but may be used in future versions of this > + protocol. This bit is fine, though I'm not sure why we want to give ourselves the room to invent new buttons. > > @@ -2154,6 +2162,16 @@ > A key was pressed or released. > The time argument is a timestamp with millisecond > granularity, with an undefined base. > + > + The key is a key code as defined in the Linux kernel's > + linux/input-event-codes.h header file, e.g. KEY_A. The key > + represents a physical key on the keyboard and is unaffected by the > + keyboard layout applied. > + > + Any 16-bit key code value is reserved for future additions to the > + kernel's event code list. All other key codes above 0x are > + currently undefined but may be used in future versions of this > + protocol. > But this I'd prefer to drop. We need to describe the button codes, but the key codes are _already_ perfectly described in the keymap. Leaving this undefined opens the door to making life much easier for, e.g., RDP-based compositors. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
Because we already rely on it for xkb anyway. This is a retrofit, which is not ideal but I'm not sure any compositor out there uses anything else. Might as well define it. Signed-off-by: Peter Hutterer --- A side-note here: my first version sent to Jonas privately had a reserved range for any key with the highest bit set. The idea here was to have a range defined that we'll never touch during protocol updates so that vendors who need some custom key code have a place to escape to. Note that by custom key code I don't mean "gaming mouse sends custom key X" but rather "this is an integrated compositor + client stack solution and the key only makes sense in this context". I took it out of this version now, maybe it makes sense to add this though. Also, I think the DTD needs a tag :) protocol/wayland.xml | 18 ++ 1 file changed, 18 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 6c6d078..dcc29fe 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1893,6 +1893,14 @@ enter event. The time argument is a timestamp with millisecond granularity, with an undefined base. + + The button is a button code as defined in the Linux kernel's + linux/input-event-codes.h header file, e.g. BTN_LEFT. + + Any 16-bit button code value is reserved for future additions to the + kernel's event code list. All other button codes above 0x are + currently undefined but may be used in future versions of this + protocol. @@ -2154,6 +2162,16 @@ A key was pressed or released. The time argument is a timestamp with millisecond granularity, with an undefined base. + + The key is a key code as defined in the Linux kernel's + linux/input-event-codes.h header file, e.g. KEY_A. The key + represents a physical key on the keyboard and is unaffected by the + keyboard layout applied. + + Any 16-bit key code value is reserved for future additions to the + kernel's event code list. All other key codes above 0x are + currently undefined but may be used in future versions of this + protocol. -- 2.9.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
