ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Moprius has quit [Remote host closed the connection]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
hardening has joined #wayland
immibis is now known as Guest797
immibis has joined #wayland
Guest797 has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
Azem has joined #wayland
dcz_ has joined #wayland
jgrulich has joined #wayland
manuel1985 has joined #wayland
lanodan has joined #wayland
lanodan_ has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
<pq>
Lumpio-, mind, taking screenshots is different to screencasting is different to remote control. A former is a conceptual part of a latter, but may not be the same code or API at all. So it's best not to simplify remote control to "take screenshots, and fake input".
<Lumpio->
Yes, "taking screenshots" is just what mostly came up when googling, since that's something people have made a lot of tools for (it's simpler afterall)
<Lumpio->
And I was just trying to come up with a more reasonable usecase that's not just my stupid idea.
<Lumpio->
It was made pretty clear to me that what I was trying to do is dumb and I'm probably the only person who wants to do it so no point in talking about that specifically.
<pq>
right, but caming up with imaginary use cases you think would be representative or your actual use case has a risk of backfiring.
<pq>
Taking remote control of an already running desktop seems like a very common and desirable use case to me.
<pq>
Taking screenshots from command line at random less so.
<Lumpio->
I gess the main difference is that I would like to do it without interaction on the computer
<Lumpio->
Something that "just works"
<pq>
If you would be willing to let the setup be the DE's problem, I believe it would just work.
<Lumpio->
And it does
<Lumpio->
In Gnome at least, I tried it.
<Lumpio->
But in all honesty delegating that to the myriad of different DEs is a cop-out.
<Lumpio->
I can send pictures and receive input via Wayland - why not the other way round?
<Lumpio->
There was an unstable extension for screen capture, and I hope it will become standard.
<pq>
Wayland is not display server. Wayland does not implement anything, it's just a language that programs can use to talk to each other. Even if you introduce new words to do remote control, they will be useless until display servers support them.
<Lumpio->
No matter how you define it people will see Wayland as "the new X"
<pq>
Given that things like RDP and VNC exist and have been developed to years and years on to do well in exactly remote control, why should one re-invent remote control in Wayland protocol?
<Lumpio->
Even though it's "just a protocol"
<pq>
*developed for
<Lumpio->
s/people/users/
<Lumpio->
I'm sure the developers involved know and care about the difference.
<Lumpio->
Is this discussion even going anywhere
<pq>
I'm not sure what point you are trying to make.
<Lumpio->
Even forgetting my own thing, my point is I could just fire up x11vnc on _any computer_ running X, and use it.
<Lumpio->
No matter what DE it runs
<Lumpio->
There isn't a program that does the same on Wayland and that's a limitation.
<dottedmag>
pq: "Be better at selecting names next time"
<pq>
well, yeah. You also know why it's like that. What should I say?
<Lumpio->
And yes "it's just a protocol, it's not its job" but once sometimes switches from X to Wayland, things break. It's not nice.
<Lumpio->
So for now I'm hopeful the unstable screen capture extension to Wayland becomes standard, although people already said Gnome and KDE already did their own thing and will probably never implement that
<Lumpio->
Or, alternatively, that the desktop portal DBus/Pipewire thing will gain a way to accept the requests without using a GUI.
<Lumpio->
Because then you can write an x11vnc.
<dottedmag>
It might gain a configuration knob you have to turn, but portal in default configuration will continue to nag, it's a security measure that was missing from X.
<Lumpio->
Sounds promising
<Lumpio->
Maybe add the ability to create a permanent password/token that you can use to access the portal without a dialog
<Lumpio->
The most absurd bit is that since DE's were forced to do their own thing, Gnome on vanilla Ubuntu for one is set up so that it gives you literally none of the security benefits of Wayland
<Lumpio->
Because if screen capture and input simulation weren't included for security reasons, Gnome sure gives people a way to sidestep that security and do it anyways. Outside Wayland of course.
<Lumpio->
Well I guess "literally none" is a bit of an overstatement
<Lumpio->
But you can see the screen and send input, freely, from any normal process running as the user.
<Lumpio->
I know Gnome is not Wayland and in no way the responsibility of the people who designed the protocol, but that's one example that's pretty common in practice (literally vanilla Ubuntu) where leaving it out was pointless.
<Lumpio->
For one I tried the screencasting portal and I liked how it popped up a DE dialog rather than just relying on a browser to keep track of who can see the desktop. That's an improvement.
<daniels>
delegating to all the desktop environments is not a cop-out, because it can and does allow them to do a vastly better job in the vastly common case. no-touch remote telemetry where you have pre-configured SSH but an unknown desktop environment with no remote access is not a common case. so yes things do become more difficult for you specifically, in order to benefit a hugely larger number of people. that’s why we built it that
<daniels>
way.
<Lumpio->
I'm sure I wasn't the only one who had a script that conveniently accesses their home computer with x11vnc but I guess we are a minority
<Lumpio->
Plain "you can't do that even though it's your computer" is giving he heavy Android/iPhone vibes though.
<pq>
I can't use my computer to watch HDR videos on a HDR TV either, but it doesn't really give any Android/iPhone vibes to me.
<pq>
my point being, there are always use cases you can't do, because you didn't install the software or the software wasn't written yet, but that is no way some external party or vendor saying you are forbidden from doing that.
rasterman has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
<daniels>
Lumpio-: you can do absolutely whatever you want to with your own computer. unfortunately your ‘no installation of anything other than this thing I wrote myself’ doesn’t work out of the box.
<daniels>
we very much get that you don’t like the design choices, but that doesn’t mean they’re bad or restrict your freedom. sorry it’s inconveniencing you but let’s move on rather than keep on drowning out scrollback.
Lucretia has quit []
<MrCooper>
LaserEyess: "waypipe is a sort of x11 forwarding proxy" just like X11 forwarding over SSH, the former just happens not to be integrated into openssh yet :)
<kennylevinsen>
the -w and -W options are unfortunately already taken. :(
<MrCooper>
Lumpio-: the fact that something like x11vnc can work without the local user having any idea what's happening should make one pause and realize that Wayland's protections are very much needed
<jadahl>
kennylevinsen: maybe we can get -3 instead, a 90° rotated w, while also looking like a chandelier
<MrCooper>
or maybe -Z in continuation of -Y
<kennylevinsen>
I feel like -3 should implicitly force a 90 degree output rotation
Lucretia has joined #wayland
<Lumpio->
daniels: I didn't even restart this conversation but I'm happy with ending it
<kennylevinsen>
-w, -3, -m, -ε...
<Lumpio->
The desktop portal seems like something that will become a reasonable solution for this, so I guess I'll wait and see how that turns out.
<jadahl>
Lumpio-: there are various ideas about how to improve portals for "managed computers" setups, e.g. avoid dialogs for IT depoartment remote assistance etc, but it's still loose ideas and will definitely if it will become a thing not be something that works out of the box for arbitrary applications to silently hook into
Arnavion has joined #wayland
<Lumpio->
I'm sure I'll find a way around that. With root permissions if need be.
<Lumpio->
Speaking of which I wonder if /dev/dri has readback
<mort_>
I have found out that SDL_SetWindowSize only works most of the time, not every time, so I've resorted to calling it in every iteration of the main loop and I hate it
<pq>
Lumpio-, it has for root I think, assuming you can tolerate occasional glitches.
<any1>
See ffmpeg's kmsgrab. It's quite glitchy
<kennylevinsen>
oh didn't know that
<emersion>
no synchronization for you!
<Lumpio->
Neat. It could be an interesting into how video actually works on Linux.
<Lumpio->
+adventure
<Lumpio->
Thanks
<pq>
the fundamental design of anything like kmsgrab is that it will never be reliable
<pq>
When you start your adventure, I guess you might be tempted to disregard everything about synchronization because it makes things complicated, but it also makes things reliable. Without synchronization images can be badly broken.
<Lumpio->
Small glitches just add character. I wasn't going to try to reliable replace VNC/RDP anyways.
<pq>
depending on luck, they might not be small :-)
<daniels>
pq: yeah, I was looking at it from the 'how was this mapped without a buffer' angle, but you definitely picked up some good parts in gl-renderer being inconsistent
<pq>
daniels, I suspect something might destroy the buffer too early, given the wl_buffer.release in mvlad's trace, but I couldn't follow the lifetimes.
<LaserEyess>
question about client implementations for WIP protocols: do they have to "work", or do they have to demonstrate how they will be used in a client
<LaserEyess>
in other words: do I need to patch a compositor and then use that with my client
<pq>
I would say yes.
<daniels>
yeah
<LaserEyess>
alright
<daniels>
if you don't show it in real-world scenarios, you've just typed out a bunch of C which compiles
<daniels>
the interesting thing is to understand the real-world implications
<emersion>
"toy" or incomplete implementations might miss some real-world issues
<LaserEyess>
that's fair
<emersion>
:P
<LaserEyess>
this is for single pixel buffer btw
<LaserEyess>
so luckily for this case there are a couple of WIP compositor implementations
lanodan has quit [Ping timeout: 480 seconds]
<pq>
a protocol proposal requires a compositor implementation anyway, so there'd better be at least one :-)
<LaserEyess>
well, it requires one to be merged
<pq>
huh?
<LaserEyess>
it doesn't require one to open a MR
<LaserEyess>
though I guess usually most people pair the two
<pq>
oh, yes!
<pq>
you don't need *any* implementations whatsoever to open a MR
<pq>
landing a MR needs reviewed and not-merged implementations
fmuellner has joined #wayland
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
<daniels>
^
fahien has joined #wayland
fmuellner has quit [Read error: Connection reset by peer]
fmuellner has joined #wayland
lanodan has joined #wayland
lsd|2 has joined #wayland
CME has quit []
CME has joined #wayland
Company has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
ahartmetz has joined #wayland
maxzor has joined #wayland
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
mclasen_ has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: Konversation terminated!]
ppascher has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]