ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
overholts has quit [Quit: Ping timeout (120 seconds)]
zzag has quit [Read error: Network is unreachable]
overholts has joined #wayland
zzag has joined #wayland
fluix has quit [Read error: Network is unreachable]
fluix has joined #wayland
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #wayland
kts has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
privacy has quit [Quit: Leaving]
bim9262 has joined #wayland
Brainium has quit [Remote host closed the connection]
co1umbarius has joined #wayland
kts has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
maxzor has quit [Remote host closed the connection]
<pq>
kchibisov, you can see multiple wl_seat and wl_output globals. Each global refers to a different underlying thing, but since an output is an output, all outputs use the wl_output interface each.
<pq>
Globals are things, interfaces are APIs, and wl_proxies are instances of an interface referring to a thing.
<kchibisov>
pq: could, but I'm not quite sure how I end up binding the display.
<kchibisov>
but in the code we reliably remove outputs.
<pq>
kchibisov, this is issue 10.
<kchibisov>
so it's a kwin bug?
<kchibisov>
I read that you need to send things in the near same time in 10.
<pq>
Originally it is a protocol mis-design, making clients vulnerable to global removal races, and losing that race trigger the error here.
<kchibisov>
but given that I got add/remove as a 2 consequative events won't it be fine?
<pq>
It has been solved by adding API (links in the issue) to send the global removal event first, and then much later actually destroying the global, to give time for clients to handle the removal. This is something the compositor needs to implement.
<kchibisov>
Hm, I think I get the issue is that it's removed on kwin side.
<pq>
between global_remove event and actual removal, a client binding to the removed global would still work.
<pq>
yes, this is something only kwin can fix
rukusza has quit [Remote host closed the connection]
<pq>
Also, it's curious how within the same millisecond, the compositor manages to advertise a wl_output, remove it, and advertise another wl_output.
<pq>
that hints to some kind of software design problem, bcause no-one can unplug and re-plug a monitor within a millisecond. Even connector load detect cannot work that fast, right?
<emersion>
there are a bunch of cases where something like this can happen
<emersion>
docks, flaky connectors, suspend/resume with different screens
manuel_ has joined #wayland
<pq>
would dock and flaky connectors really do it within a millisecond?
<emersion>
i don't know
<emersion>
maybe also changing a setting in the screen config
<pq>
from the log, it seems the wl_output lives about 50 microseconds
rukusza has joined #wayland
<emersion>
maybe this happens when the output is disabled, but output config is managed by another program?
<emersion>
(would be better to wait for the external program before doing anything with the output, in that case)
<pq>
maybe - I'd call that a software design problem, this is just teasing clients
<kchibisov>
it's a KDE virtual desktop thing.
<pq>
ok
<pq>
in any case, issue 10 needs a compositor workaround, and that would stop your app from crashing
<pq>
regardless of how many and how fast the compositor is adding and removing wl_outputs
<kchibisov>
it also send a configure with 8K x 8K while doing so....
manuel1985 has quit [Ping timeout: 480 seconds]
<pq>
:-p
<pq>
kchibisov, in the client, do you drain the Wayland events before actually doing the window changes? Or was this not possible because of library API design?
bim9262 has quit [Ping timeout: 480 seconds]
<kchibisov>
it could be wayland-rs? Or maybe mesa drained a bit.
<pq>
I mean, draining would be good, so the last window configure you see is not the 8k one
<kchibisov>
but I don't remember it batching.
bim9262 has joined #wayland
<pq>
as in, you don't needlessly draw an 8k window, only to see in the next event that that was outdated
<kchibisov>
I think we read all.
<pq>
cool
<pq>
just an aside :-)
Company has joined #wayland
<kchibisov>
I know that winit itself batches.
<kchibisov>
so you won't see this thing with winit.
<kchibisov>
oh, I got what you've meant with batching. a toolkit side batching. yes, we do it, but I plan on moving it into users side.
maxzor has joined #wayland
bindu has joined #wayland
fmuellner has joined #wayland
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
Moprius has quit [Quit: bye]
nerdopolis has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
cmichael has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Remote host closed the connection]
bim9262 has joined #wayland
nerdopolis has joined #wayland
<zamundaaa[m]>
<pq> "in any case, issue 10 needs a..." <- We have that workaround. KWin waits for 5s before deleting globals that were removed
<emersion>
5s sounds a bit risky under heavy load
<zamundaaa[m]>
<kchibisov> "it's a KDE virtual desktop thing..." <- KWin doesn't do anything with wl_outputs when it comes to virtual desktops
<pq>
well, the protocol log shows everything happening in one millisecond. An old version of kwin, perhaps?
<zamundaaa[m]>
Would have to be very old
<kchibisov>
zamundaaa: you could check the issue I've linked.
<zamundaaa[m]>
Isn't the debug printing on the client side? These timestamps aren't necessarily real time if the client can't keep up, right?
<zamundaaa[m]>
kchibisov: it's 5.27.9, that's the latest version
<kchibisov>
zamundaaa: well...
<kchibisov>
it's all client side log, but the size to 8K res is also really weird.
<zamundaaa[m]>
True
<kchibisov>
maybe they have some weird plugin, idk, I just got pinged because my toolkit got involved.
kts has joined #wayland
<zamundaaa[m]>
Oh, the 8k thing is the stupid placeholder output
<kchibisov>
A kind of big placeholder.
<pq>
good point about timestamps
<kchibisov>
yeah, but I'm pretty sure client can keep-up into 5 seconds?
<pq>
maybe the app contains code that blocked it for 10 seconds
<kchibisov>
Hm.
<zamundaaa[m]>
kchibisov: yes, to not resize clients to be smaller than they were on a real output. It's a relic from the past and can def be made smaller now
<pq>
like weird plugin
<zamundaaa[m]>
The placeholder gets created when all real outputs get hotunplugged fyi, so "normal desktop usage" can't trigger this to happen
<kchibisov>
Regular KDE desktop usage with changing virtual desktops or minimizing and restoring
<kchibisov>
from the issue.
<kchibisov>
Though, I usually don't trust users...
<emersion>
zamundaaa[m]: do you really need to advertise a placeholder wl_output?
<kchibisov>
And their logs from app don't have timestamps.
<zamundaaa[m]>
emersion: we don't do that. The wl_output is from a real output
<pq>
...maybe the app uses eglSwapInterval=1 or equivalent, and ended up stuck in eglSwapBuffers or equivalent while the user was virt-desktop-switched away?
<kchibisov>
pq: I think it actually does so.
<kchibisov>
because it was a released version of neovide.
<kchibisov>
And they moved to frame callbacks only on master.
<emersion>
zamundaaa[m]: ah i see, the placeholder output is only "leaking" throughthe 8K configure event
<kchibisov>
Hm, I guess I need a full log.
<zamundaaa[m]>
emersion: yeah
<kchibisov>
1GB wayland debug log compressed to 3M with zip, impressive.
bim9262 has quit [Ping timeout: 480 seconds]
<kchibisov>
Well, the issue I raised about timestamps in libwayland sort of shown itself.
<kchibisov>
Since I have no idea how to read them.
<pq>
they are the dispatch time
<pq>
I wouldn't have remembered the units though without you asking.
<kchibisov>
The problem is that it's not really monotonic
<kchibisov>
pq: given that WAYLAND_DEBUG uses realtime and does u64 -> u32 via cutting it could probably do a thing like that?
bim9262 has joined #wayland
vyivel has left #wayland [#wayland]
vyivel has joined #wayland
<kchibisov>
there're a lot of cases like that in the log though.
<pq>
but 3535002.325 is 12.7 minutes before wraparound
<pq>
maybe anything really did not happen for ~ 14 minutes
<kchibisov>
maybe.
<kchibisov>
They also have 3535002 -> 71665 -> 112210
<kchibisov>
And that code was in _mesa_
<kchibisov>
where it manipulates with buffers in swap_buffers.
<kchibisov>
(the said place is easy to find from the bottom of the log).
<pq>
eglSwapBuffers could easily be blocked for 14 minutes waiting for a frame callback, if the compositor so decides
<pq>
e.g. during virtual desktop switched away
Brainium has joined #wayland
<kchibisov>
Yeah, it could still be the case, I've asked whether they do on the same thread as event loop, but I remember that they don't.
<kchibisov>
At least it's not the case with what they do now.
<pq>
maybe their threads are sync'd somehow
<kchibisov>
yeah, I'll just continue to poke them.
ErrorNoI1ternet has joined #wayland
kts has quit [Quit: Konversation terminated!]
ErrorNoInternet has quit [Ping timeout: 480 seconds]
<kchibisov>
pq: apparently they never used a thread, and they indeed block on vsync.
bim9262 has quit [Ping timeout: 480 seconds]
<kchibisov>
they used thread on some separate branches, and maintainer sort of _forgot_ about what they had in a particular versios.n
<pq>
heh
<pq>
well, that can explain everything
<kchibisov>
zamundaaa[m]: sounds like it's not your bug :p but user still haven't done hotplugs from their words.
<kchibisov>
yeah, mesa blocking here is an issue.
<kchibisov>
It should probably send frame callbacks when output change happens, because otherwise it'll crash all the games using vsync.
<pq>
no, that's part of a much bigger debate
<kchibisov>
Like I know that there was a surface suspension stuff.
<kchibisov>
but mesa can't really use it.
<pq>
yeah, that's part of the debate
<kchibisov>
yeah, but I'm pretty sure mesa will still block in the end of the day.
<kchibisov>
unless it somehow starts communicating that _I'll block for likely indefinite time_.
bim9262 has joined #wayland
<pq>
IMO, using frame callbacks for eglSwapBuffers throttling was a mistake, though no better mechanism existed. There would need to be a new mechanism that ticks at "refresh" rate somehow regardless of window visibility or even mappedness.
<kchibisov>
Sounds like wp_presentation could kind of work.
<pq>
how to make that also power efficient is another question
<pq>
no, presentation is very much about being visible
<kchibisov>
Can't you estimate how much to block based on that?
<kchibisov>
like chrome uses it for its requestAnimationFrame.
<pq>
I think this would need something new, like some of the vblank timing update extensions.
<pq>
you can estimate, yeah, but the more time passes, the more it drifts
<pq>
you would need the first presentation to succeed to initialize
<pq>
and you would want to sync the timer somehow to actual presentation when the window is visible
<zamundaaa[m]>
kchibisov: well, hotplugs from a user perspective and hotplugs from the compositor perspective aren't necessarily the same
<kchibisov>
pq: I guess doing something stupid as subscribing to vsync event could sort of solve it.
<zamundaaa[m]>
Random displays trigger "hotplugs" when they go to standby
<pq>
kchibisov, part of it at least, yeah
<pq>
for me, turning a DisplayPort monitor off is the same as unplug from hardware perspective
kts has joined #wayland
<kchibisov>
tbf, I'm more concerned about other mesa issue with latching buffer, but I kind of not have time to try fix myself.
kts has quit []
<kchibisov>
Though, a perfect size of 960x480 for initial buffer could kind of save us.
rv1sr has quit []
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
kts has joined #wayland
neniagh_ has joined #wayland
neniagh has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
r00tobo has quit [Remote host closed the connection]
r00tobo has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
<Company>
random question of the day: If I zwp_linux_buffer_params_v1::create() twice with the same dmabuf fd, what's supposed to happen?
<Company>
do I get 2 wl_buffers for the same dmabuf?
<emersion>
yes
<emersion>
that's a perfectly fine thing to do
<emersion>
need to be careful around buffer re-use and such
<emersion>
if any of these is held by the compositor you can't write to the buffer
<Company>
that's not the issue actually
<Company>
I have a static image here while offload-testing and it flickers when resizing the window - and GTK just creates a new wl_buffer every time things move
<Company>
and I suspect mutter is confused about getting a new wl_buffer with the same dmabuf
<Company>
it doesn't flicker in weston
lsd|2 has joined #wayland
rederick29 has quit [Remote host closed the connection]