09:29tokyovigilante: hi, I'm just implementing an xdg_toplevel_listener, but am a bit confused by the configure event docs - "Clients must send an ack_configure in response to this event." AFAICT no xdg_toplevel_ack_configure method exists, and xdg_surface_ack_configure is expecting an xdg_surface pointer not an xdg_toplevel one. No client I can find does this either.
09:35ifreund: it refers to xdg_surface.ack_configure
09:43tokyovigilante: thanks, so should I just cast the xdg_toplevel pointer to an xdg_surface?
09:43vyivel: you should use the same xdg_surface which has been used to create xdg_toplevel
09:45tokyovigilante: oh right, makes sense thanks. Also, which serial? or is the intent that you accumulate the latest serial from xdg_surface.configure?
09:46vyivel: yep
09:47vyivel: the flow is: you get configuration data (xdg_toplevel.configure, maybe other events if you have some extensions), then xdg_surface.configure which marks the end of a configuration sequence and carries a serial
09:48vyivel: then you change whatever needs to be changed, send xdg_surface.ack_configure with the received serial, and wl_surface.commit
09:48tokyovigilante: ah right, thanks. so practically I don't actually need to respond to the toplevel configure events, just the surface one, which I'm guaranteed to get at the end?
09:49vyivel: yes, in toplevel configure handler you just store the requested size but don't actually do anything yet
09:50tokyovigilante: great, then just use that saved state when preparing a frame, send the ack_configure, and call wl_commit
09:50vyivel: that's right
09:51tokyovigilante: nice, I get it now. thanks!
11:20hacksenwerk: Hey. I red that wayland supports gui-level isolation only when the programs that should be isolated from each other are supporting that too. But it was an old post, is it still correct?
11:50llyyr: what do you mean specifically?
11:52selckin: what is gui-level isolation? do you mean like flatpak/appimage
11:53hacksenwerk: On xorg every programm that runs in a xsession can read the keyboard input every other programm runnin gin the same xsession gets.
11:54llyyr: the post you read was never correct, even at the time it was written
11:54llyyr: wayland apps can't see other wayland apps
11:54hacksenwerk: So for example firefox could keylog when you type in your passphrase for pass, or your root password on a xterm
11:54llyyr: unless you specifically allow it to, i.e. screenshare or such
11:54hacksenwerk: llyyr: that's good to hear :)
11:55llyyr: depending on how old such post was, and the authors thoughts and feelings on wayland, I guess they meant "every wayland app is actually xwayland so none of the security benefits apply"
11:55hacksenwerk: 10 years: https://security.stackexchange.com/questions/88680/gui-isolation-in-x11-when-entering-truecrypt-password
11:57llyyr: >All programs which do not support Wayland fall back to the legacy X11 protocol, which Wayland supports as a fallback, but which it cannot provide any window isolation for.
11:57hacksenwerk: And for the keylogger "feature" of xorg, I refer to this, what I only found out today: https://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
11:57llyyr: yep :p
11:57hacksenwerk: But it still works.
11:58hacksenwerk: llyyr: so that fallback thing is still the case?
11:58llyyr: yes, if you run x11 applications they can see other x11 applications
11:58llyyr: even on a wayland session
11:58hacksenwerk: It's not about 'seeing' it's about that keysniffing
11:59llyyr: it's the same thing really, a x11 application can sniff keys from other x11 applications
12:00llyyr: but almost everything supports wayland these days, so this isn't really a concern. Only thing I use xwayland for is Steam nowadays
12:00hacksenwerk: You can test as follows: instal package xinput. Run xinput --list. Look for the keyboard id in the output that contains also AT [foobar] keyboard. Run xinput --test id_here. Open another xterm and login as root. The xinput should show the keys you are pressing, also __after__ you log in as root
12:01hacksenwerk: And of course also in passes TUI password prompt
12:01hacksenwerk: 12:59 < llyyr> it's the same thing really, a x11 application can sniff keys from other x11 applications
12:01hacksenwerk: yes but can wayland apps too?
12:01llyyr: no
12:02hacksenwerk: llyyr: :) good
12:02hacksenwerk: llyyr: How to find out if an application uses wayland?
12:03llyyr: you can run xeyes and if it doesn't react to your cursor in a window, it's using wayland. But it depends on your compositor
12:03llyyr: on sway for example I can see with swaymsg -t get_tree
12:04hacksenwerk: hmm.. so there's no programm that can give you a list or something?
12:05llyyr: I don't think such a thing has been made yet, but it is possible with ext-foreign-toplevel-list
12:06mclasen: you can make a wayland program that does it without breaking the promise that clients can't see each other
12:08hacksenwerk: Ok.
12:09hacksenwerk: I never used wayland before, but that xorg issue is a dealbreaker for me and I want to switch.
12:09hacksenwerk: Were there any security audits done for wayland already?
12:11llyyr: wayland is just a protocol, the security audits would need to be done on specific compositor implementations to have any value
12:12hacksenwerk: llyyr: Ok.
12:13hacksenwerk: Just one last question, I aksed for some other user: The user needs vnc and want to know if there's a way to remote desktop yet.
12:18llyyr: there's a few solutions, depending on your choice of compositor
12:19mclasen: remoting isn't so much a display protocol question, more of a system question. There are wayland-based desktops that support remoting
12:19mclasen: for example, gnome supports rdp nowadays
12:20llyyr: wayvnc for most wlroots compositors.
12:21hacksenwerk: llyyr: mclasen: ok thank you I will tell that the user. I don't use vnc.
12:22hacksenwerk: I only use ssh
12:24hacksenwerk: btw: does wayland somehow depends on systemd or other poetterware?
12:25hacksenwerk: Because I use only systemd-free distros, or at list distros that allow me to choose what initsystem I use, without having to hustle arround.
12:26llyyr: no
12:26hacksenwerk: llyyr: awesome! :)
12:27hacksenwerk: llyyr: mclasen: Well thank you very much for your helping answers. My next task is now learning a bit wayland. ;)
12:30mclasen:reminds me that I haven't talked to Lennart in a while
12:35hacksenwerk: gtg bye :)
15:39kchibisov: If you use wayland-scanner on LGPL licensed wayland protocol xml, what the end license of generated C code is?
15:46ifreund: kchibisov: my take is that copyright for protocol xml is probably meaningless given that it is essentially an API, and APIs have been found in court to not be copyrightable
15:46ifreund: am not a lawyer and all that though
15:47vyivel: i'm curious where did you find a lgpl-licensed xml
15:50kchibisov: https://wayland.app/protocols/kde-server-decoration
15:50kchibisov: was brought here https://github.com/Smithay/wayland-rs/issues/796
15:51kchibisov: I think it also applies to wlroots, since it generates code from it as well and thus uses.
17:57vyivel: epic https://0x0.st/8QjN.png
18:19kennylevinsen: I don't understand this person
18:23kennylevinsen: kchibisov: The XML file to be LGPL-licensed documentation, and would not consider wayland-scanner's output to be dependent on the input it read.
18:24kennylevinsen: but it's an interesting question
18:24kennylevinsen: If a HTML file is GPL, does that make the pixels on your screen GPL-protected when your browser renders them? What if a shader modifies them?
18:25kchibisov: the file says in license 'program' but documentation is not 'program'
18:26vyivel: >“The Program” refers to any copyrightable work licensed under this License.
18:27kchibisov: indeed.
18:28vyivel: anyway kde won't sue you so you're fine :^)
18:29kchibisov: fedora just complains about MIT license.
18:30kchibisov: because wayland-rs has an xml that is LGPL, thus entire thing should be LGPL.
18:30kchibisov: where I think it's not the case, because it's not present in the end binary.
18:33vyivel: somewhat related https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/119
18:46wlb: wayland Issue #530 opened by Julian Orth (mahkoh) Adding wl_proxy_marshal_array_flags_queue to assign a queue atomically https://gitlab.freedesktop.org/wayland/wayland/-/issues/530
23:00wlb: wayland Merge request !463 opened by Simon Ser (emersion) shm: fix comment about wl_shm_buffer_begin_access() safety https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/463
23:01wlb: wayland/main: Simon Ser * scanner: use separate guards for validator functions https://gitlab.freedesktop.org/wayland/wayland/commit/dbfa8d784eed src/scanner.c tests/data/example-server.h tests/data/small-server-core.h tests/data/small-server.h
23:01wlb: wayland Merge request !461 merged \o/ (scanner: use separate guards for validator functions https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/461)
23:10wlb: wayland/main: Julian Orth * client: document get_listener behavior for dispatchers https://gitlab.freedesktop.org/wayland/wayland/commit/7033e74857a0 src/wayland-client.c
23:10wlb: wayland Merge request !462 merged \o/ (client: document get_listener behavior for dispatchers https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/462)
23:15wlb: wayland/main: Michel Dänzer * protocol: Clarify wl_buffer.release description https://gitlab.freedesktop.org/wayland/wayland/commit/6137c8c21383 protocol/wayland.xml
23:15wlb: wayland Merge request !447 merged \o/ (protocol: Clarify wl_buffer.release description https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/447)
23:34wlb: wayland Merge request !464 opened by Simon Ser (emersion) protocol: drop reference to linux-explicit-synchronization https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/464 [Protocol]