--- title: State of multi-player Wayland | daily.dev description: A deep investigation into multi-seat (multi-pointer/multi-cursor) support on Linux with Wayland, where multiple people share one desktop environment with... canonical: https://daily.dev/posts/state-of-multi-player-wayland-7ptplj0pa twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: State of multi-player Wayland | daily.dev og:description: A deep investigation into multi-seat (multi-pointer/multi-cursor) support on Linux with Wayland, where multiple people share one desktop environment with... og:url: https://daily.dev/posts/state-of-multi-player-wayland-7ptplj0pa og:image: https://api.daily.dev/og/posts/7PTPlj0pA.png og:image:alt: State of multi-player Wayland og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # State of multi-player Wayland **[Hacker News](https://daily.dev/sources/hn)** · 17 min read · 2 upvotes · 0 comments ## Summary A deep investigation into multi-seat (multi-pointer/multi-cursor) support on Linux with Wayland, where multiple people share one desktop environment with independent mice and keyboards. The core Wayland protocol has excellent built-in seat support. Sway and Weston compositors support multiple seats well, while niri and River have partial or no support. GTK4 has conceptual multi-seat support but bugs prevent dynamic seat detection; SDL3.3.4+ added basic seat awareness with caveats in absolute mouse mode. No end-user applications currently use multi-seat, so the author built prototypes: a GTK text widget, a LÖVE physics playground, and a VNC setup using wayvnc's transient-seat feature to let remote collaborators join with their own virtual input devices. Several open project ideas are highlighted throughout for contributors interested in expanding this space. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 111 comments across hackernews, lobsters (as of 2026-07-29). **TL;DR:** The community is broadly enthusiastic about multi-seat/multi-cursor support in Wayland, seeing it as a long-overdue feature with interesting use cases (collaborative work, split keyboards, touchscreens, gaming), though many note the significant practical hurdles around toolkit assumptions, screen sharing, and compositor support. **Sentiment:** 60% positive · 30% mixed · 10% skeptical **The case for** - Touchscreen-as-independent-seat allows interacting with apps without moving the main cursor or changing keyboard focus, enabling natural multi-tasking. - Multi-seat support enables genuinely interesting collaborative and multiplayer local experiences (e.g., two people sharing one machine with separate cursors and keyboards). - Wayland's protocol design anticipated multi-seat from the start, making it architecturally feasible at the compositor level even before toolkits catch up. - Space mice and drawing tablets are real-world examples where a second independent pointer already makes sense and is used. - X11's MPX already proved the concept works, so Wayland catching up is a natural progression. **The pushback** - GUI toolkits (GTK, Qt) assume a single focused window per application, so multi-seat breaks `gtk_application_get_active_window` and equivalents without significant toolkit work. - Screen sharing on Wayland still requires pipewire, dbus, and portals all correctly configured, unlike X11 where it 'just works'. - Compositors like kwin can't switch backends at runtime, making advanced scenarios like roaming sessions between physical and remote seats very difficult. - Most Wayland clients make single-seat assumptions, so compositor-level support alone doesn't fully solve the problem for applications. - The article/site had a mobile rendering bug cutting off content on iOS and Android. **By community** - hackernews (positive): Commenters are genuinely excited about multi-seat Wayland with rich discussion of use cases and technical challenges, tempered by realistic concerns about toolkit and ecosystem readiness. - lobsters (mixed): No comments were present, so no signal beyond the story being submitted. **Hottest debate:** Whether Wayland's screen sharing difficulties are a fundamental design problem or simply a matter of users not having core services (pipewire, portals, dbus) properly set up. **Open questions** - Will GUI toolkits ever be updated to support per-seat focus, or will multi-seat remain a compositor-only feature with limited app support? - How should fast-user-switching / session roaming between physical and remote seats be handled in non-systemd environments? - Is there a standard way to visually distinguish which seat 'owns' a focused window (e.g., colored decorations per seat)? **Highlights** > One very nice use case that I haven't seen anyone else talk about is touchscreens. I have assigned my touchscreen to be in a separate seat. This allows me to interact with apps without moving my cursor or changing my window focus. For instance: web browser on the left, with a document. Text editor on the right. I am writing some notes with my keyboard, scrolling the document with my touchscreen. The editor stays focused, no back-and-forth with the mouse. It feels very natural this way, instead of having your cursor jump where you touched the screen and change your M/K focus. > — [MayeulC on hackernews](https://news.ycombinator.com/item?id=49095066) > On the note of the two different kinds of seats, a tangent: better multi physical seat support is something I am passionate about, specifically, I want Windows-style "Fast User Switching" on Linux with RDP. Today's Linux RDP support usually acts like screen mirroring; you get a mirror of a physical seat. With GNOME I believe there is also now support to do remote login: you can log in remotely, and even disconnect and reconnect to a remote login session. But what you can't do is continue a physical session remotely or a remote session physically, and the reason why is sorta to do with seats. Sort of. See, when you start a graphical session on modern systemd-based Linux, a new logind session is created, and it is immutably tied to a seat. So you can't just remove the seat from a running logind session and then make it remote, or add the seat to a running logind session and make it physical. I actually tried patching systemd-logind to do this, but when I proposed it upstream, Lennart Poettering himself actually took the time to explain that this wasn't the intended way to do it: instead, you would actually just create a new logind session and drop the old one entirely, or literally whatever you want. Which to me sounded perposterous, but then I realized that it really wasn't that ridiculous. As it was, when you boot a desktop using systemd-logind, the desktop itself doesn't typically run much of anything directly in the session context anyway - the compositor and almost all services actually run as user services, as in systemd-land having more than one active desktop session per user isn't really supported. Okay so we can do this! And so I set out to prototype this with KDE, but there are still a few issues... - First and foremost, $XDG_SESSION_ID. Believe it gets set by the systemd PAM module somehow? I don't fully recall. Either way, it gets used by various programs to determine the current logind session, but if our graphical session can "roam" between them we need a mechanism that can handle changing over time. I propose we stuff the current logind session ID into a file in $XDG_RUNTIME_DIR instead. - Secondly, compositors need to be redesigned to handle this. Compositors today can hotplug displays and input devices - that's a good start. Unfortunately, at least kwin can't switch backends at runtime. You can really go one of two ways, and I tried a bit of both and either can work but both are a bit ugly: one is to make a single backend that can handle either case and the other is to allow switching the backend at runtime. Either way, when running remotely the card* DRM nodes are unavailable so you need to switch to renderD* nodes instead. You can also use both, and only use card* for scanout when available, but it seems a bit trickier. - Finally, I genuinely have no idea how this could or should be handled in non-systemd environments. I have admittedly forgotten how that all works. It would be rather lame to simply require logind for this to work, but sadly it is the path of least resistance at least at first. And maybe some more, but otherwise the concept does indeed broadly work. I mainly have only tested it in virtual machines with DRM native context, but I can see everything working switching in either direction at least once before things start to get screwed up. Even OpenGL clients and audio playback can move seamlessly! It's just like what Windows accomplished over 20 years ago! Aside from convenience and being cool, it would also solve a couple problems. No need to worry about the limit of only one session per user: just move your session with you. No need to worry about your physical session being unlocked when remotely connected: when you log in this way your physical seat gets disconnected from the session entirely and the display manager takes it back over. I actually would really like to at least make some progress on ground work that would be needed to make this happen, although I'm not really that sure that an > — [jchw on hackernews · 1 comments](https://news.ycombinator.com/item?id=49093002) > > micromanaging your env All the "micromanaging" you need to do to not have screensharing is one of the following; 1. Don't have a started dbus session 2. Don't have portals installed and setup 3. Don't have pipewire installed and setup Meanwhile on X what you need is: 1. Have X So no, it wouldn't work, the reason why it works for those people in the Reddit post is because they use distros and sessions that do all the things I listed that make screensharing not work if any one is not done. PS: Wayland does have testing protocols for screenshots and screenrecording like 'wlr-screencopy' and some DMA buff one I forgot the name of. But for screen sharing there's nothing that Wayland implements itself afaik. > — [arxari on hackernews · 2 comments](https://news.ycombinator.com/item?id=49094120) > I thought it was the other way around, X11 has supported multiple cursor since 2009 and Wayland didn't add support for it since toolkit developers weren't making use of it anyway. Enabling in X works via: xinput list # find second mouse id xinput create-master second xinput reattach "second pointer" and to get rid of it: xinput reattach 'Virtual core pointer' xinput remove-master 'second pointer' Works great for clicking, but keyboard doesn't work in some applications when enabled. Dragging windows might attach them to the wrong cursor and other issues. Playing around with xinput can also crash some apps (libgdk-3 here) or leave you in a state without a keyboard or mouse. > — [grumbel on hackernews](https://news.ycombinator.com/item?id=49093613) > To 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. > — [ben-schaaf on hackernews · 2 comments](https://news.ycombinator.com/item?id=49092823) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49092112) · 52 points · 111 comments - [lobsters](https://lobste.rs/s/anvtjk/state_multi_player_wayland) · 2 points · 0 comments ## Similar posts on daily.dev - [RustDesk Pulls Ahead of TeamViewer, AnyDesk with Wayland Multi-Scaled Display Support](https://daily.dev/posts/rustdesk-pulls-ahead-of-teamviewer-anydesk-with-wayland-multi-scaled-display-support-ckjw4ntmr) · It's Foss · 83 upvotes · 2 comments - [KDE is finally killing X11, and I'm not as sad as I thought I'd be](https://daily.dev/posts/kde-is-finally-killing-x11-and-i-m-not-as-sad-as-i-thought-i-d-be-otvp5h692) · XDA Developers · 7 upvotes · 0 comments - [SDL Fixes Support For More Than Five Mouse Buttons For Gaming On Wayland](https://daily.dev/posts/sdl-fixes-support-for-more-than-five-mouse-buttons-for-gaming-on-wayland-ow5jwwifk) · Phoronix · 0 upvotes · 0 comments - [Can I finally start using Wayland in 2026?](https://daily.dev/posts/can-i-finally-start-using-wayland-in-2026--i3zcmnhze) · Lobsters · 0 upvotes · 0 comments --- Tags: [#linux](https://daily.dev/tags/linux) [View this post on daily.dev](https://daily.dev/posts/state-of-multi-player-wayland-7ptplj0pa) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"State of multi-player Wayland","url":"https://daily.dev/posts/state-of-multi-player-wayland-7ptplj0pa","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/state-of-multi-player-wayland-7ptplj0pa"},"datePublished":"2026-07-29T03:38:09.324Z","dateModified":"2026-07-29T09:19:24.867Z","description":"A deep investigation into multi-seat (multi-pointer/multi-cursor) support on Linux with Wayland, where multiple people share one desktop environment with...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bcc5bb1a68517f4d4bf4d6d2575b2756?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bcc5bb1a68517f4d4bf4d6d2575b2756?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/state-of-multi-player-wayland-7ptplj0pa","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"linux","timeRequired":"PT17M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"State of multi-player Wayland"}]} ```