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
st3r4g has quit [Quit: おやすみ]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
lanodan has joined #wayland
lanodan_ has quit [Read error: Connection reset by peer]
Moprius has quit [Quit: Konversation terminated!]
CodeSpelunker has joined #wayland
lsd|2 has quit []
Company has quit [Quit: Leaving]
dcz_ has joined #wayland
jgrulich has joined #wayland
tzimmermann has joined #wayland
lanodan_ has joined #wayland
lanodan has quit [Ping timeout: 480 seconds]
CodeSpelunker has quit [Ping timeout: 480 seconds]
CodeSpelunker has joined #wayland
lanodan has joined #wayland
lanodan_ has quit [Ping timeout: 480 seconds]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
hardening has joined #wayland
danvet has joined #wayland
erle- has joined #wayland
mvlad has joined #wayland
bittin has joined #wayland
rv1sr has quit []
jpnurmi has quit [Remote host closed the connection]
jpnurmi has joined #wayland
jpnurmi has quit [Remote host closed the connection]
jpnurmi has joined #wayland
mahkoh has joined #wayland
jpnurmi has quit [Remote host closed the connection]
jpnurmi has joined #wayland
rasterman has joined #wayland
CodeSpelunker has quit [Quit: CodeSpelunker]
bittin has quit [Remote host closed the connection]
bittin has joined #wayland
<pq>
unfortunately *nothing* in Weston's test suite is touching xdg-shell at all yet, so starting on that will take some effort. But it only means there are no helpers for it, so you are just writing a pure libwayland client from scratch.
<pq>
you can also write such client outside of Weston's test suite, and if it works to trigger the crash, it's relateively easy to insert into the test suite
novakane_ is now known as novakane
rv1sr has joined #wayland
Lucretia has quit []
mahkoh has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
bittin has quit []
Lumpio- has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
tzimmermann has joined #wayland
flacks has quit [Quit: Quitter]
mahkoh has joined #wayland
flacks has joined #wayland
jgrulich has quit [Remote host closed the connection]
lanodan has quit [Read error: Connection reset by peer]
<Lumpio->
So am I right in my understanding that there's no way to capture the screen or simulate input via wayland as it is? No equivalent of XGetImage for the root window and xtest?
<Lumpio->
Feels like a pretty serious limitation, and I understand it's for security, but normally there's a way to authorize a program to go around security limitations
<kennylevinsen>
no, you can capture the screen and on certain compositors simulate input. See documentation for your compositor.
<Lumpio->
wayvnc sounds pretty good, but it says "Gnome and KDE are not supported"
<Lumpio->
Gnome is kind of the default on vanilla Ubuntu for one...
<emersion>
GNOME doesn't support the screencopy protocol that wayvnc uses
<LaserEyess>
Lumpio-: I posted gnome-remote-desktop, but maybe I wasn't clear early: KDE and GNOME have their own *server* implementations of VNC that do not work across compositors
<LaserEyess>
e.g. you cannot use gnome-remote-desktop on KDE or krfb on GNOME
<LaserEyess>
but they all work with any VNC *client*
<Lumpio->
Yes I understood that
<Lumpio->
It just feels like a big step back to have all these random implementations instead of one that I can use with any desktop environment
<emersion>
i know, right
<LaserEyess>
ubuntu will have GNOME and gnome-remote-desktop installed by default, likewise any KDE flavor of a distro should come with krfb
<LaserEyess>
so what do you need to install or set up for your users?
<any1>
If only there was a common standard wayland protocol for screen capturing... :)
<any1>
Oh, yeah, that's the one.. It's even ready for another round of reviews. :p
<LaserEyess>
a nice addition for compositors but I don't think gnome or KDE will implement it, so that doesn't particular help this "problem"
marex has quit [Remote host closed the connection]
marex has joined #wayland
<Lumpio->
Well I guess my usecase is a bit weird
<Lumpio->
What I was actually thinking of making was the graphical equivalent of ssh, just type a hostname and it gives you your desktop. I've wanted that more than once to just take a quick look at something on a computer elsewhere, or on devices where I'd rather not install extra packages or daemons
<Lumpio->
Works perfectly for X11 but then I tried it with Ubuntu...
<Lumpio->
xwayland lies about supporting xtest and xrender just renders black for the screen, so welp
<kennylevinsen>
ah
<daniels>
well I mean that's called VNC/RDP
<kennylevinsen>
depending on specific needs, there's also wayfire. Works like X forwarding, but way better
<Lumpio->
I've honestly never even looked at how wayland works before last weekend. Lots of neat ideas there.
<kennylevinsen>
you can get entire DE's over that for compositors supporting nesting
<any1>
kennylevinsen: you mean waypipe
<kennylevinsen>
uhm yes waypipe
<kennylevinsen>
brainfart
<Lumpio->
X forwarding only forwards stuff you start using it though
<kennylevinsen>
wayfire is also neat though if you like them wobbly windows, but quite a different topic
<Lumpio->
I want to see what I left open at home, just as an example.
<Lumpio->
daniels: Yes, and with X11 I could just start "x11vnc" via ssh, but no such luck with wayland
<Lumpio->
I'm not even using wayland yet, but I thought it'd be nice to support it.
<Lumpio->
Because I'm sure it'll eventually make its way onto every platform
<any1>
There's probably some way to enable VNC using some dbus interface..
<Lumpio->
In other news Gnome's VNC server was pretty easy to start from the command line. I'm a bit surprised!
<Lumpio->
Although again, it's a pretty annoying situation to have to implement hacks for specific environments
<Lumpio->
On X everything works the same with Gnome, KDE, whatever.
<LaserEyess>
this should autostart as a dbus service
<LaserEyess>
you don't need to enable it
<Lumpio->
Well it was faster to just use the "grdctl" tool to enable and test it than writing a DBus client
<LaserEyess>
I mean to say you can do systemctl --global enable gnome-remote-desktop.service
<LaserEyess>
socket activation would be nice in this case I guess
<LaserEyess>
I'm assuming you're shipping some distro where you want users to interact with it remotely, hence you can do this on install
<LaserEyess>
but I guess I'm making assumptions, I don't know why a single command isn't enough per DE
<Lumpio->
heh
<Lumpio->
What I'm doing is "ssh me@machine.net" except it's graphical
<Lumpio->
I already have it working for X11
<LaserEyess>
well ok but on machine.net you clearly have to enable x11 forwarding or start a VNC server or something, right?
<Lumpio->
nope
<Lumpio->
It requires no configuration or installation of stuff on the target machine, besides having an ssh server with default settings
<kennylevinsen>
and installation of x11vnc, and necessary access to the DISPLAY, and...
<Lumpio->
Doesn't require any of that with X11
<kennylevinsen>
uh yeah, how do you plan to use x11vnc without x11vnc?
<dottedmag>
bring a statically linked binary ;)
<Lumpio->
It doesn't use x11vnc
<LaserEyess>
... what does it use?
<Lumpio->
It logs in via ssh, sniffs the environment for the X11 magic cookie, uses ssh's socket forwarding to connect to X's socket, and then just uses XGetImage/xrender/xtest
<Lumpio->
Works surprisingly well for being an absolute hack
<LaserEyess>
ok, well, you should have mentioned you were using an undocumented hack in X11 for this
<Lumpio->
Bet some of you didn't know ssh can forward UNIX sockets in addition to TCP ones
<LaserEyess>
that changes everything, wayland should implement this immediately
<Lumpio->
How is it an undocumented hack though
<Lumpio->
The X socket location and protocol are well documented
<Lumpio->
I don't think anything in the documentation says you're not allowed to connect to the socket via ssh forwarding
<Lumpio->
dottedmag: In the first iteration I did actually, and that works fine too. But only on X.
<LaserEyess>
well really what I'm tryign to say is "wayland is not X11", and I'm sorry but you're going to have to add an extra step in your thing to get it to work with wayland
<LaserEyess>
or just not use wayland at all, force x11
<LaserEyess>
those are your options
<Lumpio->
The only "undocumented hack" is the part for finding the Xauthority file but that can be made fairly generic.
<dottedmag>
X11 allows any client to grab the whole screen. Wayland doesn't, and won't. Either make your client a privileged (compositor-specific), or configure a portal implementation (compositor-specific) to give your client access.
<Lumpio->
LaserEyess: And I don't want wayland to be X11! I'd be perfectly fine with writing a different implementation for wayland
<Lumpio->
But having to write a different implementation for gnome/KDE/wlroots/everything else feels a bit excessive.
<LaserEyess>
I don't think you do...
<LaserEyess>
I am so confused why you think you do
<Lumpio->
Honestly it's not that far-fetched of a usecase. I'm just running it over an ssh connection.
<Lumpio->
Many other things need to capture the screen, and simulate input.
<Lumpio->
You don't think I do what?
<ManMower>
just run your desktop in a vmware vm and connect to it with vmrc. ;)
<emersion>
so you're running x11vnc locally, capturing the screen over X11 forwarding?
<emersion>
that sounds horrible :P
<Lumpio->
emersion: In the X version I'm not using VNC at all
<Lumpio->
It is horrible! But the usecase of "I want to see the desktop of a random computer I can log onto via SSH" calls for it.
<dottedmag>
Lumpio-: Authors of "many other things" may speak for themselves.
<kennylevinsen>
Lumpio-: note that xdg-desktop-portal is universal to all compositors and a "normal" way to access e.g. screen capture, with your issue being that we ask for permission in cases.
<kennylevinsen>
not sure if the portal has plans for remote control
<dottedmag>
Lumpio-: SSH has nothing to do with your issue. The issue is that you wish an unprivileged client to access the whole screen. This is not how Wayland security works.
<feaneron>
yeah, this really sounds like something that the Remote Desktop portal should handle for you
<LaserEyess>
Lumpio-: at first I thought you wanted to use a VNC server with wayland, which the solution would be all of the things I talked about, now you want to have an X11 forwarding like solution that will Just Werk™ on any wayland compositor and forward the whole screen with 0 interaction on the server side
<LaserEyess>
well, that doesn't exist
<LaserEyess>
I don't know what to tell you
<Lumpio->
Does "server side" here mean a user physically sitting in front of the computer to click a button?
<Lumpio->
Or can the user be logged in remotely via ssh
<LaserEyess>
server side means installing some software, enabling some service, running some command/script*, etc
<LaserEyess>
things like that
<Lumpio->
I can work with that
<LaserEyess>
ok then just enable gnome-remote-desktop and access it with a VNC client!
<LaserEyess>
done!
<Lumpio->
Does the desktop portal allow me to accept the request to capture the screen via a terminal command, as opposed to clicking a button?
<LaserEyess>
it has the ability to store previous permissions, yes
Azem has joined #wayland
<LaserEyess>
hm, wait, that might just be the screencast portal
<Lumpio->
And if the computer is very far away with nobody there to click the button for the first time?
<feaneron>
you can't accept that remotely, as it would clearly be a remote code execution vector
<feaneron>
restoring previously accepted sessions is something that could be implemented, but i didn't because nobody asked at that time
<feaneron>
if this use case is important to you, i would be glad to review the patches :)
<Lumpio->
heh
<Lumpio->
That's a bit too far beyond a quick weekend project
<Lumpio->
Just out of interest, did I understand correctly that shared memory is a requirement for implementing a wayland client?
<Lumpio->
Or is there a way to access buffers via just the unix socket
<daniels>
they are a requirement
<Lumpio->
Alright
<Lumpio->
Thanks
<daniels>
np
<Lumpio->
I guess I'll go read more about the protocol just to know what's in stock for me when everybody starts switching from X
<Lumpio->
...although I guess I'm a bit late to the party
<Lumpio->
I guess "waypipe" was one thing that synchronizes those buffers via the network
<LaserEyess>
waypipe is a sort of x11 forwarding proxy that needs explicit setup on the server
<LaserEyess>
it does one window at a time, not a whole desktop
<kennylevinsen>
it streams the buffer content of clients by h264 encoding the buffers (for efficiency)
<Lumpio->
oo very neat
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #wayland
hergertme has quit [Remote host closed the connection]
hergertme has joined #wayland
<Lumpio->
oh and
<Lumpio->
18:27:41 < dottedmag> Lumpio-: Authors of "many other things" may speak for themselves.
<Lumpio->
For what it's worth, while googling for ways to just take a screenshot remotely, they definitely did
<Lumpio->
I'm definitely not the only one annoyed by the fact there is no way to take a screenshot without user interaction, and how a lot of screenshot tools people liked to use just stopped working. Even though that might be a design choice, a lot of people still want to do that.
<Lumpio->
"Oh that portal thing pops up a dialog every time, that's too annoying to use". And those were posted by people who aren't trying to implement something stupid like me.
<Lumpio->
But ah well, I guess the fact the protocol didn't start out with a method for that wasn't the fault of anyone here, so I guess there's no point in complaining about it.
<Lumpio->
Maybe it'll evolve in the future to get more features
rgallaispou has quit [Ping timeout: 480 seconds]
luc4 has joined #wayland
erc has quit [Read error: Connection reset by peer]
___nick___ has joined #wayland
luc4 has quit [Remote host closed the connection]
mahkoh has quit [Quit: WeeChat 3.5]
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
devilhorns has quit []
mvlad has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
jgrulich has quit [Remote host closed the connection]
kitzman has joined #wayland
<mort_>
there's no way to get weston to just dump its list of windows is there
<mort_>
wayland is much harder to debug when something goes wrong
<daniels>
mort_: run it with --debug, then execute 'weston-debug scene-graph'
<mort_>
oh, that's useful
<daniels>
yw
<mort_>
do you know if it lists the windows in their stacking order?
lanodan has joined #wayland
lanodan_ has quit [Ping timeout: 480 seconds]
<daniels>
yes it does
txtsd has quit [Ping timeout: 480 seconds]
<mort_>
with the topmost first or last
<mort_>
sorry for all the questions, I'm completely unable to find any docs for this
<mort_>
the top first it looks like
<daniels>
first yeah
<mort_>
is there a way to get weston to respond to whatever SDL does when you `SDL_RaiseWindow` by actually putting the window at the top of the stacking order
<daniels>
SDL_RaiseWindow() appears to return and do nothing in SDL/video/wayland/, so there's nothing to respond to
<mort_>
oh you're right, everything in that log is from what happens after SDL_RaiseWindow
<mort_>
I keep assuming that things are implemented in SDL when they're just stubs
<mort_>
one thing I'm a bit confused by is, I keep hearing that these sorts of things are intentionally not in wayland because you're supposed to configure these things in the compositor instead of in the application; but then compositors are lacking the features too and so things just become impossible