ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
narodnik3 has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Plasm0duck has quit [Quit: Konversation terminated!]
Plasm0duck has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
wb9688 has quit [Ping timeout: 480 seconds]
wb9688 has joined #wayland
mtj has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
ramblurr has quit [Ping timeout: 480 seconds]
ramblurr has joined #wayland
mupuf has quit [Remote host closed the connection]
mupuf has joined #wayland
slattann has joined #wayland
<slattann>
#Test Mesg
<slattann>
Anyone interested in reviewing this MR for : "Add Support for Display Hardware/engine based adaptive sharpening"
<swick[m]>
zamundaaa: any good way to test the mesa changes? a quick search didn't find a vulkan hdr sample...
<MrCooper>
doesn't mpv use that?
<swick[m]>
right, it does, but I'd still like to test with something that generates content
<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
<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
fmuellner has joined #wayland
Moprius has joined #wayland
kenny has joined #wayland
<swick[m]>
JEEB: mpv doesn't check the set_mastering_display_primaries feature so it currently doesn't work on mutter
<zamundaaa[m]>
swick: quake ii rtx with SDL_VIDEODRIVER=wayland is an option
<zamundaaa[m]>
swick: mpv does check it though?
<swick[m]>
yeah, I started looking at the code and noticed as well...
<swick[m]>
zamundaaa: I should really start reading the queue names... it's mesa!
<zamundaaa[m]>
Oh right, mastering luminance is set unconditionally
<swick[m]>
zamundaaa: thanks, I'll try quake ii rtx
feaneron has joined #wayland
<swick[m]>
meh, it wants VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT
<swick[m]>
btw, what does proton need for hdr?
Plasm0duck has quit [Quit: Konversation terminated!]
Plasm0duck has joined #wayland
<zamundaaa[m]>
Right now, very very terrible hacks
<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
<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
<llyyr>
mpv's implementation of color-management-v1 only matters vo=dmabuf-wayland
<swick[m]>
yeah, I noticed that too at some point :)
<swick[m]>
I should test vo=dmabuf-wayland as well...
<swick[m]>
that works as well!
<llyyr>
neat
<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`
<zamundaaa[m]>
swick: you need to build Mesa without asserts
<zamundaaa[m]>
The game is broken
<swick[m]>
lol, okay
abeltramo58952382719 has joined #wayland
<swick[m]>
it does work, but the hdr implementation is suboptimal
rgallaispou1 has quit [Read error: Connection reset by peer]
<zamundaaa[m]>
That's a good description for the vast majority of games
abeltramo5895238271 has quit [Ping timeout: 480 seconds]
abeltramo58952382719 is now known as abeltramo5895238271
rgallaispou has joined #wayland
DodoGTA has quit [Quit: DodoGTA]
<Fxzxmic>
Do we have, or will we have, a permission protocol that controls what programs can read and write to the clipboard?
DodoGTA has joined #wayland
<kchibisov>
That sounds compositor specific, wayland doesn't introspect clipboard.
<kchibisov>
and it's also not stored anywhere other than in applications itself.
<vyivel>
we do have {wlr,ext}-data-control
<kchibisov>
I mean, there's no concept of clipboard content.
<vyivel>
the permissions part would probably be managed outside of wayland, maybe via the security context protocol
<kchibisov>
I think they talk about regular wl_data_device transfers without wlr-data-control.
<vyivel>
ah
<kchibisov>
disabling wlr-data-control is also compositor specific, as in, it may just disable protocol.
<Fxzxmic>
But wayland prevents programs that lose focus from interacting with the clipboard, right?
<kchibisov>
yes, it's prevented.
<kchibisov>
only focused client can pull the clipboard or unless it's a special protocol to implement clipboard manager.
<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.
<kchibisov>
You may filter mimetypes apps recieve, but it could be done in compositor without anything in protocol.
<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.
<Fxzxmic>
Is that possible?
<kchibisov>
you can do that inside the compositor already, though not clipboard part.
<kchibisov>
but focus interaction doesn't apply to {wlr,ext}-data-control, in case you're writing a clipboard manager.
<kchibisov>
not clipboard when it's not in focus, since it's a protocol violation.
<kchibisov>
if you want to hide clipboard, you can just hide the global for the application in compositor.
<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.
<kchibisov>
what kind of program is that?
<kchibisov>
maybe you want data-control then.
alatiera has quit [Quit: Ping timeout (120 seconds)]
<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.
alatiera has joined #wayland
<davidre>
of course it depends on the compositor if the request will have an effect
<kchibisov>
Yeah, but it's not prevented from what I can read, unlike e.g. load.
<davidre>
I think a theoretical compositor sending selection event will not explode clients, but a close reading indeed does not allow
<kchibisov>
event or request? You can request to create a new selection, but you won't receive a new selection(data_offer) event.
<kchibisov>
Thus it reads like you can set it, but not load it, even if you set yoursel.f
gusnan has joined #wayland
<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.
<kchibisov>
implicit copy for the user sounds like a mess.
slattann has quit [Quit: Leaving.]
<kchibisov>
UX wise.
<llyyr>
then you need to use ext-data-control
<zamundaaa[m]>
Fxzxmic: you're supposed to make data offers as the clipboare content changes, yes
<zamundaaa[m]>
Otherwise you circumvent clipboard managers for example
<Fxzxmic>
kchibisov: That's why I think there should be a permission control for users to proceed with explicit permission.
<kchibisov>
it's a compositor policy.
<kchibisov>
I'd also assume that you've tried storing to clipboard when you're unfocused, and it hasn't worked.
<Fxzxmic>
Yes, I tried.
<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.
<kchibisov>
theoretically if you set it once and then just update data you serve it should kind of work.
DodoGTA has quit [Remote host closed the connection]
<kchibisov>
And it's not a popup that you close, etc, you just have a regular app that always changes your clipboard?
Plasm0duck has quit [Ping timeout: 480 seconds]
Plasm0duck has joined #wayland
<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.
<kchibisov>
Then you can just have a hotkey to copy?
<kchibisov>
or button.
<kchibisov>
like every other program does.
<kchibisov>
like overwritting what user copied before sounds like a bad ux tbh.
<Fxzxmic>
The data is changing, that means the user still needs to manually click the button before going to paste.
<kchibisov>
it'll click once when they done input?
<selckin>
isn't there content negotiation on paste, can you not send the latest data there?
<Fxzxmic>
selckin: I don't know about this.
<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
DodoGTA has joined #wayland
<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.
<kchibisov>
Fxzxmic: you can change the content on the fly.
<zamundaaa[m]>
Fxzxmic: could you elaborate on what your application is?
<kchibisov>
it's just won't play nice with clipboard managers, but it's not like you can not dynamically change what you serve.
<kchibisov>
All you have to change is what you write to FD once user asks you to load clipboard.
<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.
<zamundaaa[m]>
Fxzxmic: that you've been saying
<zamundaaa[m]>
What is the application actually doing though?
<zamundaaa[m]>
From the user's perspective, not what you're trying to achieve on a low level
DodoGTA has left #wayland [#wayland]
DodoGTA has joined #wayland
<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.
<zamundaaa[m]>
I don't need a name, just a description
<Fxzxmic>
Leave for a while, sorry.
kode54 has joined #wayland
<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.
<kchibisov>
yeah, the only issue is when clipboard manager start messing with all of that.
rasterman has quit [Quit: Gettin' stinky!]
<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)
rasterman has joined #wayland
kts has joined #wayland
<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.
kts has quit [Ping timeout: 480 seconds]
<Fxzxmic>
gdk_clipboard_set_text(clipboard, text); This function always writes a new entry to the clipboard.
lsd|2 has joined #wayland
<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
<Consolatis>
so this is a GTK restriction, not a wayland one
<kchibisov>
yeah, toolkit issue.
<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?
<d_ed[m]>
lets back up to:
<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.
<d_ed[m]>
what's the program that would require constantly updating the clipboard
<Fxzxmic>
Data is changing and users need it to be up-to-date.
<Fxzxmic>
You can think of it as a sort of two-step authenticator, although there's a big gap.
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
Plasm0duck has quit [Quit: Konversation terminated!]
Plasm0duck has joined #wayland
<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.
lsd|2|2 has joined #wayland
<kchibisov>
your program writes clipboard data yourself when it asks for clipboard content.
<kchibisov>
so you can constantly change it.
lsd|2 has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
<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.
lsd|2 has quit []
<kchibisov>
it's gtk issue on what API you have.
<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.
<Consolatis>
the clipboard has no history, unless you are talking about some external application serving as a clipboard manager
lsd|2|2 has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
bodiccea has joined #wayland
bodiccea_ has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Quit: Konversation exit!]
bodiccea_ has joined #wayland
bodiccea has quit [Ping timeout: 480 seconds]
rgallaispou has left #wayland [#wayland]
bodiccea has joined #wayland
bodiccea_ has quit [Ping timeout: 480 seconds]
Plasm0duck has quit [Quit: Konversation terminated!]
Plasm0duck has joined #wayland
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
Plasm0duck has quit [Quit: Konversation terminated!]
Plasm0duck has joined #wayland
Plasm0duck has quit [Quit: Konversation terminated!]
Plasm0duck has joined #wayland
leon-anavi has quit [Remote host closed the connection]