00:00 danieldg: hmm, that relies on the transparency being the indicator of a true prompt *and* there being no screenshots available *and* people actually noticing that the transparency is there (vs "oh, it has a distro logo no")
00:00 soreau: the point is, if a compositor doesn't want to do this, it doesn't have to but it's now considered buggy/broken/insecure because of one misplaced line that oversteps the scope of the protocol
00:00 danieldg: we can do better than that for secure UI elements
00:01 danieldg: present a user-chosen or random-assigned image for all secure elements, for example
00:01 outfoxxed[m]: And if this in particular is such a concern couldn't you just NOOP a client's fullscreen request
00:02 rpigott: I don't think its a strong argument against dropping it anyway. There's not really any implied requirement of the compositor, so if a compositor wants to be paranoid and has limited screencapture privilege then surely it would be permitted to draw a black bg even wihtout the xdg-shell text mandating that behavior.
00:02 soreau: if a compositor is concerned with security, this part is only the tip of the iceberg.. it's a very small thing that is irrelevant when considering how many other ways things can get hacked
00:02 danieldg: a better security proposal would include an overlay at all times that changes if in secure mode
00:03 danieldg: but that's annoying on its own, I'd only want it if I chose to turn it on
00:04 danieldg: anyway, allowing the compositor to choose wouldn't make it worse
00:05 emersion: danieldg: any security feature only makes sense if the app is sandboxed and unprivileged
00:05 danieldg: for this to be relevant you'd also have to prevent normal xdg windows from covering the whole output
00:08 danieldg: atm in sway, if you make an excessively sized floating window, it'll end up covering the output. Make it properly transparent and you can fake the prompt without fullscreen at all
00:08 danieldg: you may be able to do similar with popups
00:09 rpigott: toplevels can't be reliably positioned in global coords, which makes that also difficult for an imposter client
00:09 danieldg: basically if you want a 'no faking this security concept' it has to be written as a goal that everything is evaluated against
00:09 danieldg: rpigott: but popups can be
00:10 danieldg: they're relative to the parent window, but make it big enough and centered and you'll end up at the goal
00:10 danieldg: and an attacker is likely fine with a 90% success rate
00:11 danieldg: (that 90% success could actually be "assume maximized app")
00:11 rpigott: I mean I still think the text should be dropped I'm not arguing there
00:51 zamundaaa[m]: rpigott: check out https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/116, this was all discussed before
00:52 zamundaaa[m]: And I agree, given that not all compositors implement this, I'd prefer changing the existing wording to may instead of pretending the world is different than it is
00:53 zamundaaa[m]: and add fullscreen requests for transparency or opaqueness + relevant caps, so that clients that rely on either behavior can explicitly ask for it
00:57 danieldg: just defining it as compositor policy is reasonable imo, since that's what the reality is today even with the protocol as written
00:58 danieldg: if you're concerned about faking the dialog (and have somehow fixed all the other ways to do it) then you can block transparency
01:04 karenw: So this is a bit of an open ended question, but I'm currently between jobs and looking for something to keep me busy and my github profile green. What projects around the wayland/linux graphics community would appreciate my assistance? I'm familiar with vulkan/OpenGL and wayland/X protocol.
01:10 soreau: karenw: there are plenty of projects that wouldn't mind a helping hand, it just kinda depends on what you want to work on
01:11 soreau: there are drivers like mesa, clients like gstreamer and compositors.. wlroots and more
01:12 soreau: I'd probably try and find some bug(s) that need solving in the area of interest and see about fixing them
01:17 karenw: I ask that question and then amdgpu panics and murders my system. There's something poetic there...
01:19 soreau: that's one that has more recently been piped back to userland - gpu reset robustness
01:20 soreau: clients and compositors typically just crash into an unrecoverable state in this case, and sadly, so does the gpu :)
01:21 karenw: Yup, I think it apt upgrading a package that caused my machine to commit sudoku
01:21 karenw: But unfortunately my knowledge of the graphics stack beyond the surface level of mesa is extremely limited.
01:25 karenw: The general guidance over on the vulkan discord is similar. "Don't both supporting device loss, just terminate", although that's *mainly* application developers and not compositor/driver/etc. devs.
01:26 soreau: well the chance to do something is there, even if that means spitting a message, bt or saving something?
01:27 karenw: Certainly worth a look. yeah.
01:27 zamundaaa[m]: karenw: I assume that's mostly about games, and not about normal applications?
01:27 soreau: but I think it's different when you're a game as opposed to compositor
01:27 soreau: heh
01:27 zamundaaa[m]: Though for games it might be even more important to save, as they're often the cause of the reset
01:28 soreau: the holy grail of this is that your compositor and client handle things gracefully and you just see a flicker/blackscreen for a few and then back to work
01:28 karenw: zamundaaa: Yeah, games or something like CAD applications. The kind of program and end user would expect to go to an app store and install. Not infrastructure like a compositor or display server.
01:29 zamundaaa[m]: karenw: I wasn't talking about infrastructure, but normal apps
01:29 zamundaaa[m]: IIRC Qt supports device loss recovery with its Vulkan renderer
01:29 karenw: I think we are agreeing agressively.
01:30 soreau: I like to think of compositor code as kernel code - if it crashes, game over.
01:32 zamundaaa[m]: Certainly a good stance to have as a compositor developer
01:32 zamundaaa[m]: On the client side, please do assume the compositor may crash and try to recover from that
01:33 zamundaaa[m]: KWin development has become a lot nicer since Qt gained support for recovering from compositor crashes/restarts
01:34 karenw: It's pretty reliable on Windows at least to be able to test that by (re)installing your graphics driver.
01:34 karenw: Is there a reliable way to inject a reset on *nix?
01:34 karenw: Or just desktop linux I guess
01:34 zamundaaa[m]: With AMD, sudo cat /sys/kernel/debug/dri/1/amdgpu_gpu_recover
01:35 zamundaaa[m]: I think Intel had something similar
01:35 soreau: karenw: sway has gpu reset handling and wayfire needs it
01:35 soreau: FWIW
01:36 karenw: Well, that's certainly a material goal, thanks! I will look into wayfire.
01:43 karenw: interesting, I have /0/radeon_gpu_reset and /1/amdgpu_gpu_recover. I assume they both do the same thing, intentionally reset the respective gpu?
02:24 wlb: wayland-protocols Merge request !377 opened by Xaver Hugl (Zamundaaa) stable/xdg-shell: allow compositors to support transparent fullscreen windows https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/377
02:25 soreau: karenw: some prior art, since you're showing interest: https://github.com/WayfireWM/wayfire/issues/2458
02:25 soreau: there it says `cat /sys/kernel/debug/dri/0/amdgpu_gpu_recover`
02:26 soreau: I'm not sure if 1 means another device or instead of soft, and hard reset or what
02:26 soreau: maybe ask #dri-devel
02:28 zamundaaa[m]: 1 means another device
02:28 zamundaaa[m]: It's the cardN number
02:30 karenw: Yeah, this laptop is a cursed dual-graphics with the low-power output-connected gpu being too old for amdgpu and therefore using radeon.
02:30 karenw: While the high-performance gpu is amdgpu.
02:30 soreau: sounds like double the fun
03:26 kchibisov: zamundaaa[m]: do you happen to know if there's a way to trigger context lost by doing gpu_recover? for me it does nothing other than bliking a screen and showing logs in dmesg.
03:26 zamundaaa[m]: It's supposed to trigger a context loss
03:27 kchibisov: will it trigger it if you don't have robustness?
03:27 zamundaaa[m]: And on my desktop it does, Xwayland goes down and KWin shows a notification that the GPU reset happened
03:27 zamundaaa[m]: kchibisov: as Xwayland crashes, I'd say yes
03:27 kchibisov: for me it just never crashes me.
03:28 kchibisov: maybe on apu it's a bit different.
05:08 outfoxxed[m]: <RAOF> "The docs for _that_ are not..." <- Would someone mind pointing me to the documentation here? I haven't found anything in or out of mesa apart from the header itself.
07:16 outfoxxed[m]: Oh I see they're in the source files not the headers
11:37 wlb: weston Issue #987 opened by maze ma (maze.ma1251228) Inquire about dumb buffer and pixman renderer with buffer sync issue https://gitlab.freedesktop.org/wayland/weston/-/issues/987
11:47 Consolatis: zamundaaa, zamundaaa[m]: (assumingly accidental) tab vs space changes in !377
11:47 Consolatis:would still prefer some CI run that at least ensures that a single protocol xml is always using tab or space indentation
12:27 zamundaaa[m]: Or just convert this xml to spaces, to match all the other protocols
15:18 Consolatis: I think I've seen mixed tabs/spaces in other protocols as well, not sure right now though. maybe it was in fact xdg-shell
15:18 Consolatis: there are however various other protocols using tabs: grep -R $'^\t' wayland-protocols/
15:21 Consolatis: I am not advocating for either tabs or spaces. But within a xml file it should at least be consistent IMHO
16:46 mattst88: emersion: are there plans for a wayland release with wl_fixes support?
16:46 mattst88: https://invent.kde.org/plasma/kwin/-/commit/b7c74cec41dbbbfdac6cfe5be91bfcb76724d78b added wl_fixes support
16:46 mattst88: but it's detected at build-time
16:46 mattst88: and that commit is in KDE 6.3
16:47 emersion: we haven't planned the next release yet
16:47 emersion: need to look at pending MRs and see what we want to get in
17:03 mattst88: okay, thanks. evidently this commit will be released with KDE Plasma 6.3 in 1 month
17:09 emersion: wayland won't be released by that time, the release process itself takes longer
17:09 emersion: also keep in mind any unreleased change might be broken
17:23 wlb: weston Merge request !1670 opened by Derek Foreman (derekf) Add perfetto instrumentation to weston https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1670 [Core compositor]
20:26 Guest5541: With two machines running wayland desktops, are there any programs to have one machine act as a second monitor for the other machine over a network? A VNC (or similar) viewer on the second computer fullscreened would work to recieve & display the picture, but is there a way to have a VNC (or similar) server on the first computer act like an extra monitor rather than sharing the existing one?
20:28 soreau: wayvnc?
20:28 Arnavion: Create a headless output and have the VNC server broadcast that. Depends on the compositor
20:28 soreau: weston vnc backend?
20:29 Guest5541: soreau: Oh I looked it up it seems like wayvnc may be able to do that. Ill try it