Use seat interface version 5

[WLCIssuesBot]

Issue by DenialAdams Monday Feb 06, 2017 at 15:35 GMT Originally opened as https://github.com/Cloudef/wlc/issues/235

---

It is my understanding that currently wlc supports seats version 4 (wlc code). I have encountered in the wild some wayland windowing code that requires seats version 5 (winit code).

It is unclear to me what exactly was added in seats version 5... I can find absolutely no documentation on this. This is the only potential I could find: wayland example code (Which looks like a related function is already defined in wlc? So maybe that's not relevant, but I really have no idea.)

I wouldn't mind trying to take this on myself, but I would need someone to give me some guidance as I have no idea where to begin.

Thanks for reading!

[WLCIssuesBot]

Comment by Cloudef Monday Feb 06, 2017 at 15:45 GMT

---

https://github.com/Cloudef/wlc/blob/master/src/compositor/seat/seat.c#L95 Maybe for starters change the 4 there to 5 and see what explodes.

[WLCIssuesBot]

Comment by DenialAdams Monday Feb 06, 2017 at 20:51 GMT

---

Thanks for the start! I ended up changing https://github.com/Cloudef/wlc/blob/master/src/compositor/seat/seat.c#L323 instead, because I think this actually changes the version instead of just the expected version. Then I got... somewhere? When I tried running sway against my compiled libwlc (with LD_LIBRARY_PATH) I was getting the same seats version assertion error, so I must be doing something wrong there.

However, I was able to get a new error if I try to run winit in the example WM in the wlc source.

thread 'main' panicked at 'Wayland connection unexpectedly lost: Error { repr: Os { code: 12, message: "Cannot allocate memory" } }'

..which if I follow the back trace takes me to

 pub fn init() -> Option<WaylandContext> {
    // attempt to connect to the wayland server
    // this handles both "no libwayland" and "no compositor" cases
    let (display, mut event_queue) = match default_connect() {
        Ok(ret) => ret,
        Err(e) => return None
    };

    // this "expect" cannot trigger (see https://github.com/vberger/wayland-client-rs/issues/69)
    let registry = display.get_registry().expect("Display cannot be already destroyed.");
    let env_id = event_queue.add_handler_with_init(WaylandEnv::new(registry));
    // two syncs fully initialize
    event_queue.sync_roundtrip().expect("Wayland connection unexpectedly lost");
    event_queue.sync_roundtrip().expect("Wayland connection unexpectedly lost");

    Some(WaylandContext {
        evq: Mutex::new(event_queue),
        display: display,
        env_id: env_id
    })
}

It is the second:

event_queue.sync_roundtrip().expect("Wayland connection unexpectedly lost");

That is failing now.

I have plenty of available memory, so I'm afriad the "Cannot allocate memory part" is a red herring. Going to try and dig into this more tomorrow, at a loss for the moment.

[WLCIssuesBot]

Comment by Cloudef Tuesday Feb 07, 2017 at 09:31 GMT

---

You most likely need to change the binds too, not just global version. Use weston-info to confirm what versions are shown. WAYLAND_DEBUG=1 can be useful as well.

[WLCIssuesBot]

Comment by vberger Sunday Feb 12, 2017 at 14:11 GMT

---

Hi, I'm the person who wrote this code in winit.

The major addition of version 5 of wl_seat actually comes from wl_pointer : the handling of pointer events has changed a lot with the addition of these events (as well as a few enums to support them):

• wl_pointer::frame
• wl_pointer::axis_source
• wl_pointer::axis_stop
• wl_pointer::axis_discrete

also, this request has been added

• wl_seat::release

[WLCIssuesBot]

Comment by DenialAdams Sunday Feb 12, 2017 at 16:14 GMT

---

Thank you so, so, so much @vberger. I couldn't find that information anywhere - I was able to find that they added wl_seat::release, but that's it!

I'm still working on this, but with my level of experience and ability it will take awhile before it goes anywhere :) if someone else wanted to do this work, please don't let me stop you.

[WLCIssuesBot]

Comment by Timidger Sunday Apr 02, 2017 at 02:32 GMT

---

Toyed around with this with my fork, got it to run the examples in conrod, but all of the winit examples failed to launch anything. However I noticed that the winit examples didn't work in Weston, so perhaps that's a different problem...

I also noticed that the cursor disappears in the conrod examples. At first I thought that was a problem on our side, but it seems it doesn't set the cursor at all. On Weston it just uses whatever was last in the cursor buffer. E.g, if you move the cursor from the edge of a re-sizable window right into the example window space it keeps the "Resizing" look for the cursor.

This is certainly not a complete implementation of all the changes in the protocol, but I'm just happy I got the conrod examples to work in Way Cooler :)

[WLCIssuesBot]

Comment by vberger Sunday Apr 02, 2017 at 13:10 GMT

---

I noticed that the winit examples didn't work in Weston

Yes, that's a known issue from these. The glutin examples should work though. (Basically, as the winit examples do not draw any content in the surfaces, they are never displayed and thus don't receive any events and the event loop gets stuck).

Regarding cursor issues, if conrod uses winit, it's also possible that https://github.com/vberger/wayland-window (which handles cursor changes on decorations) has some bugs on its side, too.