Re: [ANNOUNCE] wayland 1.13.0

2017-05-05 Thread Derek Foreman
On 26/04/17 11:47 AM, Daniel Stone wrote: Hi, On 21 February 2017 at 22:59, Bryce Harrington wrote: Our next major release will be version 1.14, which will be scheduled tentatively as follows: √ Development opens immediately - 1.14-alpha in early May And here we are. - 1.14-beta ar

[RESEND] [PATCH] weston: Add support for "--foo bar" style options

2017-05-05 Thread Lyude
A little earlier today I ended up spending a lot of time trying to figure out why weston wasn't managing to launch over SSH and telling me that I did not have a --tty option specified, despite me passing the option strings ["--tty", "3"]. Turns out weston just doesn't support that. So, add support

Re: Skylane - implementation of Wayland in Rust

2017-05-05 Thread Wojciech Kluczka
> Borrowing the idea from Daniel Stone from whom I heard it first, the > only other option is to reimplement libwayland *including* its C ABI in > Rust. You need to completely throw away the C implementation of > libwayland and replace that with your own libwayland-*.so built with > Rust. Then you

Re: Skylane - implementation of Wayland in Rust

2017-05-05 Thread Auke Booij
On 5 May 2017 at 09:53, Pekka Paalanen wrote: > What could you do then, if you don't want to wrap the C implementation > of libwayland... > > Borrowing the idea from Daniel Stone from whom I heard it first, the > only other option is to reimplement libwayland *including* its C ABI in > Rust. You n

Re: Skylane - implementation of Wayland in Rust

2017-05-05 Thread Pekka Paalanen
On Thu, 4 May 2017 17:59:03 +0200 Wojciech Kluczka wrote: > Hello, > > This was supposed to be only a short announcement of Skylane - > implementation of Wayland in Rust - but it was pointed to me that one can > not use hardware acceleration without original libwayland so I have to also > ask so

[PATCH libinput 2/3] touchpad: remove the lid switch listener on device_removed

2017-05-05 Thread Peter Hutterer
Sequence triggered by the xorg driver, but basically: if the touchpad is destroyed before the lid switch, the event listener wasn't removed and an assertion was triggered. Signed-off-by: Peter Hutterer --- src/evdev-mt-touchpad.c | 6 ++ test/test-lid.c | 26

[PATCH libinput 1/3] util: add asserts with useful error messages to catch uninitialized lists

2017-05-05 Thread Peter Hutterer
Signed-off-by: Peter Hutterer --- src/libinput-util.c | 9 + 1 file changed, 9 insertions(+) diff --git a/src/libinput-util.c b/src/libinput-util.c index 38594fa4..ca07 100644 --- a/src/libinput-util.c +++ b/src/libinput-util.c @@ -50,6 +50,9 @@ list_init(struct list *list) void li

[PATCH libinput 3/3] lid: remove the keyboard listener on remove and re-init the listener

2017-05-05 Thread Peter Hutterer
If the event listener is added, then removed again on a lid switch on/off event, the list is set to null. This can trigger two crashes: * when the keyboard is removed first, the call to libinput_device_remove_event_listener() dereferences the null pointer * when the switch is removed first, the c