05:25 slattann: #Test Mesg
05:27 slattann: Anyone interested in reviewing this MR for : "Add Support for Display Hardware/engine based adaptive sharpening"
05:27 slattann: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3665
05:27 slattann: This MR tries implementing in Compositor for Kernel Patch: https://patchwork.freedesktop.org/series/138754/
05:30 DemiMarie: MrCooper: Is Weston used in any major desktop? My understanding is that it was only ever used for testing and for embedded systems.
06:29 wlb: weston Merge request !1693 opened by LI Qingwu (Qingwu-Li) ivi-shell: Add desktop surface ping timeout notification https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1693
11:08 swick[m]: zamundaaa: any good way to test the mesa changes? a quick search didn't find a vulkan hdr sample...
11:13 MrCooper: doesn't mpv use that?
11:14 swick[m]: right, it does, but I'd still like to test with something that generates content
11:17 JEEB: yea there are not any HDR test patterns in FFmpeg's avfilter atm, so you can't just utilize generated test pattern with mpv easily
11:19 JEEB: of course taking an SDR test source and bumping it to HDR graphics white levels is something you can do, but it involves the whole bumping process
11:43 swick[m]: JEEB: mpv doesn't check the set_mastering_display_primaries feature so it currently doesn't work on mutter
11:47 zamundaaa[m]: swick: quake ii rtx with SDL_VIDEODRIVER=wayland is an option
11:48 zamundaaa[m]: swick: mpv does check it though?
11:48 swick[m]: yeah, I started looking at the code and noticed as well...
11:55 swick[m]: zamundaaa: I should really start reading the queue names... it's mesa!
11:57 zamundaaa[m]: Oh right, mastering luminance is set unconditionally
12:01 swick[m]: zamundaaa: thanks, I'll try quake ii rtx
12:14 swick[m]: meh, it wants VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT
12:14 swick[m]: btw, what does proton need for hdr?
12:25 zamundaaa[m]: Right now, very very terrible hacks
12:26 zamundaaa[m]: Gamescope implements a Vulkan layer that redirects rendering through a Wayland surface instead of the actual X11 window, and supports additional colorspaces and buffer formats through that
12:27 llyyr: if you're testing the mesa wsi MR, then it shouldn't matter what mpv does no? it will just use VK_EXT_hdr_metadata with --vo=gpu-next and vulkan
12:27 llyyr: mpv's implementation of color-management-v1 only matters vo=dmabuf-wayland
12:27 swick[m]: yeah, I noticed that too at some point :)
12:27 swick[m]: I should test vo=dmabuf-wayland as well...
12:28 swick[m]: that works as well!
12:28 llyyr: neat
12:48 swick[m]: zamundaaa: does the version on steam work for you? I get `q2rtx: ../src/vulkan/runtine/vk_render_pass.c:396: vk_common_CmdBeginRenderPass2: Assertion “image_view->format == pass_att->format’ failed`
12:49 zamundaaa[m]: swick: you need to build Mesa without asserts
12:50 zamundaaa[m]: The game is broken
12:50 swick[m]: lol, okay
13:02 swick[m]: it does work, but the hdr implementation is suboptimal
13:03 zamundaaa[m]: That's a good description for the vast majority of games
13:14 Fxzxmic: Do we have, or will we have, a permission protocol that controls what programs can read and write to the clipboard?
13:18 kchibisov: That sounds compositor specific, wayland doesn't introspect clipboard.
13:18 kchibisov: and it's also not stored anywhere other than in applications itself.
13:19 vyivel: we do have {wlr,ext}-data-control
13:19 kchibisov: I mean, there's no concept of clipboard content.
13:19 vyivel: the permissions part would probably be managed outside of wayland, maybe via the security context protocol
13:20 kchibisov: I think they talk about regular wl_data_device transfers without wlr-data-control.
13:20 vyivel: ah
13:20 kchibisov: disabling wlr-data-control is also compositor specific, as in, it may just disable protocol.
13:21 Fxzxmic: But wayland prevents programs that lose focus from interacting with the clipboard, right?
13:21 kchibisov: yes, it's prevented.
13:22 kchibisov: only focused client can pull the clipboard or unless it's a special protocol to implement clipboard manager.
13:23 kchibisov: but clipboard content is unknown and if you want to manage it, it should be a part of the compositor, since your compositor will become a clipboard manager.
13:25 kchibisov: You may filter mimetypes apps recieve, but it could be done in compositor without anything in protocol.
13:25 Fxzxmic: So I envision changing the current behavior to allow the user to decide if a program can still interact with the clipboard after losing focus. Or go a step further and control whether the entire runtime cycle of an application can interact with the clipboard.
13:26 Fxzxmic: Is that possible?
13:26 kchibisov: you can do that inside the compositor already, though not clipboard part.
13:26 kchibisov: but focus interaction doesn't apply to {wlr,ext}-data-control, in case you're writing a clipboard manager.
13:27 kchibisov: not clipboard when it's not in focus, since it's a protocol violation.
13:27 kchibisov: if you want to hide clipboard, you can just hide the global for the application in compositor.
13:30 Fxzxmic: I was writing a program that needs to write to the clipboard, but unfortunately, the best solution for it is to still be able to write to the clipboard after the program loses focus.
13:31 kchibisov: what kind of program is that?
13:31 kchibisov: maybe you want data-control then.
13:34 kchibisov: Also, I think you can set selection when it's not focused, but you can not load from clipboard when you're not in focus.
13:35 davidre: of course it depends on the compositor if the request will have an effect
13:35 kchibisov: Yeah, but it's not prevented from what I can read, unlike e.g. load.
13:39 davidre: I think a theoretical compositor sending selection event will not explode clients, but a close reading indeed does not allow
13:40 kchibisov: event or request? You can request to create a new selection, but you won't receive a new selection(data_offer) event.
13:40 kchibisov: Thus it reads like you can set it, but not load it, even if you set yoursel.f
13:41 Fxzxmic: Because my program needs to write to the clipboard when it loses focus, because losing focus means that the user is going to use the contents of the clipboard and paste it somewhere else. Otherwise I would need to keep writing to the clipboard when the data changes to ensure that the user is getting the most up-to-date data when they leave the program, which would make a mess of the clipboard.
13:42 kchibisov: implicit copy for the user sounds like a mess.
13:42 kchibisov: UX wise.
13:42 llyyr: then you need to use ext-data-control
13:42 zamundaaa[m]: Fxzxmic: you're supposed to make data offers as the clipboare content changes, yes
13:43 zamundaaa[m]: Otherwise you circumvent clipboard managers for example
13:43 Fxzxmic: kchibisov: That's why I think there should be a permission control for users to proceed with explicit permission.
13:44 kchibisov: it's a compositor policy.
13:47 kchibisov: I'd also assume that you've tried storing to clipboard when you're unfocused, and it hasn't worked.
13:48 Fxzxmic: Yes, I tried.
13:51 Fxzxmic: It really just needs to write to the clipboard once while losing focus, but by the time the focus loss event is triggered it's already too late.
13:53 kchibisov: theoretically if you set it once and then just update data you serve it should kind of work.
13:55 kchibisov: And it's not a popup that you close, etc, you just have a regular app that always changes your clipboard?
13:59 Fxzxmic: Part of what my program does is automatically write the content to the clipboard and then the user pastes it where they need to use it. There is no need for the user to select and then copy.
13:59 kchibisov: Then you can just have a hotkey to copy?
14:00 kchibisov: or button.
14:00 kchibisov: like every other program does.
14:00 kchibisov: like overwritting what user copied before sounds like a bad ux tbh.
14:01 Fxzxmic: The data is changing, that means the user still needs to manually click the button before going to paste.
14:01 kchibisov: it'll click once when they done input?
14:01 selckin: isn't there content negotiation on paste, can you not send the latest data there?
14:02 Fxzxmic: selckin: I don't know about this.
14:04 selckin: me neither really, don't know if my mental model is correct, but it negotiates what kind of data you want to paste, like text or image, and then requests it
14:04 Fxzxmic: kchibisov: If the user initiates the replication, it means that the user needs to make sure that the data hasn't changed and re-copy it as soon as it does, even worse.
14:04 kchibisov: Fxzxmic: you can change the content on the fly.
14:04 zamundaaa[m]: Fxzxmic: could you elaborate on what your application is?
14:05 kchibisov: it's just won't play nice with clipboard managers, but it's not like you can not dynamically change what you serve.
14:06 kchibisov: All you have to change is what you write to FD once user asks you to load clipboard.
14:09 Fxzxmic: zamundaaa[m]: It's about getting dynamically changing data and writing it to the clipboard when the user leaves, because the user opening my program means he's going to get that data and paste it somewhere else.
14:09 zamundaaa[m]: Fxzxmic: that you've been saying
14:10 zamundaaa[m]: What is the application actually doing though?
14:10 zamundaaa[m]: From the user's perspective, not what you're trying to achieve on a low level
14:12 Fxzxmic: zamundaaa[m]: Probably a program that no one has written at the moment, so I'm not sure what it should be called; it's not a program for wide public use.
14:13 zamundaaa[m]: I don't need a name, just a description
14:14 Fxzxmic: Leave for a while, sorry.
14:19 Consolatis: Fxzxmic: announcing the offer is unrelated to the actual content. Once its accepted you will receive a fd from the pasted-into application and at that time you can send the latest state of your application. So I don't see any issue for your use-case.
14:19 kchibisov: yeah, the only issue is when clipboard manager start messing with all of that.
14:22 Consolatis: only if they take ownership of the selection (which IMHO they should only do if there is no offer anymore, e.g. clipboard owning client terminated)
14:36 Fxzxmic: The fact that there is a gap between the GTK toolkit and the actual wayland protocol causes me to not fully understand what you guys are talking about.
14:38 Fxzxmic: gdk_clipboard_set_text(clipboard, text); This function always writes a new entry to the clipboard.
14:40 Consolatis: no, it does not. It rather stores it somewhere within GTK and sadly prevents access to the fd when the clipboard content is requested by the pasted-into application
14:41 Consolatis: so this is a GTK restriction, not a wayland one
14:42 kchibisov: yeah, toolkit issue.
14:45 Fxzxmic: And at the same time wayland actually prevents the application that loses focus from writing to the clipboard, so both of these causes my usage to fail?
14:46 d_ed[m]: lets back up to:
14:46 d_ed[m]: >Otherwise I would need to keep writing to the clipboard when the data changes to ensure that the user is getting the most up-to-date data when they leave the program, which would make a mess of the clipboard.
14:46 d_ed[m]: what's the program that would require constantly updating the clipboard
14:47 Fxzxmic: Data is changing and users need it to be up-to-date.
14:48 Fxzxmic: You can think of it as a sort of two-step authenticator, although there's a big gap.
14:58 Fxzxmic: Let's see if I understand correctly: wayland allows the program that gets the clipboard fd to keep updating what belongs to it, regardless of whether or not it loses focus, but every time gtk writes to the clipboard it is getting a new fd, which makes it impossible to write to the clipboard after it loses focus.
14:59 kchibisov: your program writes clipboard data yourself when it asks for clipboard content.
14:59 kchibisov: so you can constantly change it.
15:05 Fxzxmic: But that's not how it works when I actually use it. I've tried using gdk_clipboard_set_text when the program loses focus, but when pasting there is nothing.
15:07 kchibisov: it's gtk issue on what API you have.
15:07 Fxzxmic: And if you use gdk_clipboard_set_text when the data changes, then the clipboard will keep all the history, resulting in a messy clipboard.
15:10 Consolatis: the clipboard has no history, unless you are talking about some external application serving as a clipboard manager
17:57 wlb: weston Issue #996 opened by Christian Borao (cborao) Hide VNC Server Cursor https://gitlab.freedesktop.org/wayland/weston/-/issues/996
18:34 wlb: wayland Merge request !456 opened by felix lionardo (felixlionardo) connection: Add support for QNX platform memstream https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/456
19:37 wlb: wayland Merge request !457 opened by felix lionardo (felixlionardo) os: Add QNX support for wl_os_socket_peercred() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/457
20:12 wlb: wayland Merge request !458 opened by felix lionardo (felixlionardo) server: Add QNX resource manager-based locking support https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/458
20:49 wlb: wayland Issue #525 opened by Joe Mason (joenotcharles) Crash realizing cursor with KDE Plasma after upgrading to wayland-1.23.0 / xwayland-24.1.4 https://gitlab.freedesktop.org/wayland/wayland/-/issues/525