Earlier quoted context omitted.
Yes. Show me how to make zoom screen sharing work without pipewire and prayer.
Since you edited your post I'll rephrase my question: Which desktop are you running where you can't figure out how to share your screen? Maybe some of the more tech-savvy folks here at HN can help you figure it out.
State of multi-player Wayland
31–40 of 115 posts
Re: State of multi-player Wayland
#32I'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...
> It's actually a lot more work than you'd think to support this... Like: how would one support multiple keyboards? Is there an experimental or logical model for that?
It's an incredible hacky piece of software that does work by putting together like 10 oss. Incredible and cool.
They have some UX around this
Re: State of multi-player Wayland
#33cant read the entire article on ios because the left part is just somehow cut off :(
Same on Android, insane that people aren't validating for mobile in current year
Setting a minimum width that works on your screen is a bad habit that’s luckily mostly dead, in favor of responsiveness.
Re: State of multi-player Wayland
#34The more "typical" use for a feature like this is drawing tablets and touch screens. You don't necessarily want a touch/drawing tablet input to move your actual "main" mouse cursor.
Re: State of multi-player Wayland
#35Focus of controls is the hard part. You end up needing a Per-seat version of focus in an application.
Re: State of multi-player Wayland
#36Earlier quoted context omitted.
Which desktop are you running where you can't figure out how to take a screenshot? Maybe some of the more tech-savvy folks here at HN can help you figure it out.
Yes. Show me how to make zoom screen sharing work without pipewire and prayer.
Re: State of multi-player Wayland
#37I'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!
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.Re: State of multi-player Wayland
#38I'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...
> It's actually a lot more work than you'd think to support this... Like: how would one support multiple keyboards? Is there an experimental or logical model for that?
Multiple mice is esoteric.
Re: State of multi-player Wayland
#39Earlier quoted context omitted.
Since you edited your post I'll rephrase my question: Which desktop are you running where you can't figure out how to share your screen? Maybe some of the more tech-savvy folks here at HN can help you figure it out.
KDE plasma. go wild.
The fact you're griping about implementation details like pipewire makes me think you also tried micromanaging your env and broke something. If you use a fresh install and leave everything default, I'm sure it would work for you like it does for everyone else. I use KDE too btw.