Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • This feels like a step in the right direction from this talk on desktop UX. Finally some cool innovation here!

    https://youtube.com/watch?v=1fZTOjd_bOQ

  • cant read the entire article on ios because the left part is just somehow cut off :(
  • I wish libinput gave the option for pointer inertia, where the pointer glides to a gradual rather than a hard halt after you stop moving it. I’m limited to a trackpad these days and it’s a really nice feature on my Steamdeck that I’d love to have on my Thinkpad.

    Come to think of it, Steamdeck is Wayland? How do they implement it?

  • I'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...
  • The 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).

  • I have never liked split keyboards but I might if each keyboard was also a mouse with its own cursor, it seems fun to develop the skill to work that way. Would also be useful at times if the the Thinkpad trackpoint and trackpad could each have their own cursor and I could leave one somewhere. Or maybe a cursor stack like pushd/popd, registers would probably work better; instead of virtual desktops just give me one massive desktop with cursor locations I can jump between, switch to cursor 3 it saves the location of the current cursor and jumps.
  • 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.
  • > This is obviously not a great solution, and VNC in general feels like ancient technology

    It's not obvious to me. This looks like software ageism. :)

    There are at least 2 things that could be done to improve performance in the author's setup:

      1. Use the --gpu flag which enables dmabuf capture and h264 encoding via vaapi. 
      2. Connect using a dedicated VNC client like TigerVNC. This reduces latency by roughly 50 ms.
    
    For more details on 2. see second paragraph in the following blog post https://andri.yngvason.is/measuring-latencies.html

    That being said, noVNC has gained hardware decoding of h264 via WebCodecs since the writing of that blog post, so performance will have improved some. It's unlikely that the 50 ms latency has gone down, but it might be worth measuring again since browsers may opt to render video through a dedicated overlay plane that bypasses regular rendering. However, it would be silly not to synchronise frame presentation between overlays.

    by any1

Explore Birbla archives