State of multi-player Wayland
blinry.org
State of multi-player Wayland
1–10 of 115 posts
Re: State of multi-player Wayland
#2I've always thought this was a cool idea. It's obviously been on the minds of Wayland protocol developers since the beginning, otherwise it wouldn't be possible!
Re: State of multi-player Wayland
#3To add to the long list of caveats: This also breaks assumptions GUI toolkit and applications make about only one of their windows being focused at a time: `gtk_application_get_active_window`, `QApplication::activeWindow`, etc.
Re: State of multi-player Wayland
#4The original title, "State of multi-player Wayland" is a much better summary of the article. This ain't just about the pointers! In fact, the author is very explicit about that:
> I think there could be a term that’s describing this concept even better – in the title of this post, I picked “multi-player”, to make clear that it’s mostly about multiple people who are collaborating. I’ve also seen “multi-cursor” or “multi-pointer” (which are missing the keyboard component).
Re: State of multi-player Wayland
#5It's not as weird as you might think: laptops may have touchscreens (which can be multi-touch) on top of the "normal" cursor. IIRC, X.org can't really handle such cases cleanly.
Re: State of multi-player Wayland
#6Another possible use case might be mixed reality/VR displays, for simultaneous mouse cursor + eye tracking/control.
Re: State of multi-player Wayland
#7It's not as weird as you might think: laptops may have touchscreens (which can be multi-touch) on top of the "normal" cursor. IIRC, X.org can't really handle such cases cleanly.
That's not what this article is about. You still only have one mouse cursor in that case, but two things (the touchscreen and touchpad) drive it.
This is about actually having multiple, independent mouse cursors on the screen at once, with different input devices controlling different cursors.
Re: State of multi-player Wayland
#8I'm building a compositor now, and I've been thinking about multi-seat from the beginning, but I know there are lots of places that assume a single seat, and so this sort of thing won't work for me. It's actually a lot more work than you'd think to support this...
Re: State of multi-player Wayland
#9To add to the long list of caveats: This also breaks assumptions GUI toolkit and applications make about only one of their windows being focused at a time: `gtk_application_get_active_window`, `QApplication::activeWindow`, etc.
I guess they could add a parameter cursorIndex defaulting to 0!
Re: State of multi-player Wayland
#10It's not as weird as you might think: laptops may have touchscreens (which can be multi-touch) on top of the "normal" cursor. IIRC, X.org can't really handle such cases cleanly.
That's not what this article is about. You still only have one mouse cursor in that case, but two things (the touchscreen and touchpad) drive it. This is about actually having multiple, independent mouse cursors on the screen at once, with different input devices controlling different cursors.
Sometimes that's true, but sometimes (imo the superior approach) the touchscreen is independent from the cursor. I think touchscreen Chromebooks are like that, for example.