ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
Company has joined #wayland
pnowack has quit [Quit: pnowack]
maxzor has joined #wayland
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
c7s has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
rv1sr has quit []
pieguy128 has quit [Ping timeout: 480 seconds]
columbarius has quit [Ping timeout: 480 seconds]
pieguy128 has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
pieguy128_ has joined #wayland
pieguy128 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
pavan_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
pavan_ has quit [Ping timeout: 480 seconds]
pavan has quit [Ping timeout: 480 seconds]
Company has quit [Ping timeout: 480 seconds]
shankaru has joined #wayland
Arnavion has quit [Quit: Arnavion]
maxzor has joined #wayland
Arnavion has joined #wayland
maxzor_ has joined #wayland
ecloud has quit [Ping timeout: 480 seconds]
ecloud has joined #wayland
erc_ has joined #wayland
erc has quit [Ping timeout: 480 seconds]
eroux has joined #wayland
danvet has joined #wayland
spstarr has joined #wayland
hardening has joined #wayland
jgrulich has joined #wayland
jgrulich has quit [Remote host closed the connection]
MajorBiscuit has joined #wayland
maxzor is now known as Guest503
maxzor_ is now known as maxzor
Company has joined #wayland
mort_6 has quit []
mort_6 has joined #wayland
shankaru has quit [Read error: Connection reset by peer]
jgrulich has joined #wayland
tzimmermann has joined #wayland
zubzub has quit [Ping timeout: 480 seconds]
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
Guest503 has quit []
jmabr has joined #wayland
rasterman has joined #wayland
pbc has joined #wayland
zubzub has joined #wayland
dcz_ has joined #wayland
xantoz has quit [Ping timeout: 480 seconds]
shankaru has joined #wayland
c7s has joined #wayland
pbc has quit [Ping timeout: 480 seconds]
pbc has joined #wayland
<pq>
JPEW, use a state machine that and triggers a redraw only after both conditions: frame callback done and new content available (the 20 ms timer). Which ever condition completes last will trigger redraw.
<pq>
-and
<pq>
At least as a starting point - the fundamental problem of having different content rate from monitor refresh rate is going to cause "jitter" anyway.
<JPEW>
pq: Thanks. I also thought about moving the "wait" for a frame callback until right before we commit the next frame instead of right after, basically allowing our code to render 1 frame ahead.... I realize this has some problems (e.g. if if your window is hidden when it unhides you get 1 frame of old content).
<JPEW>
But we have a pretty limited (embedded) use case, so I'm not to worried about that; are there perhaps some other problems with that idea that I didn't think about?
nerdopolis has joined #wayland
<pq>
JPEW, what do you mean with "wait"?
<pq>
a blocking wait?
<pq>
even though you "wait", you should still spin your event loop and process anything that arrives
<JPEW>
Oh, right, I forgot to mention that. We don't have the frame callback drive our render loop directly. If we want to pay attention to it we have to block
<JPEW>
its... annyoying
<pq>
kinda facepalm annoying
<MrCooper>
sounds really weird
<JPEW>
Ya, it's an old API (imaging the old blitting days before GPUs)
<pq>
not much different from SDL, EGL or mpv, perhaps?
<JPEW>
Ya, EGL with blocking eglSwapBuffers
<JPEW>
(pretty close anyway)
drunkcat has left #wayland [#wayland]
<pq>
there might be times when you want to re-draw even before a frame callback, like if you want to realize a resize ASAP.
<pq>
also frame callbacks might not come soon, if something obscures the window
<pq>
so hard-blocking on frame callbacks has many practical problems
<JPEW>
pq: Ya, right now we just use weston in fullscreen shell so we don't have to implement random $VENDOR DRM quirks
<JPEW>
so.... not a huge concern. We would have to do it differently on a real desktop shell
<JPEW>
eglSwapBuffers blocks though, so how does that work?
<JPEW>
(at least, I assume it blocks)
<MrCooper>
nothing to do with vendor DRM quirks, just the Wayland compositor not sending frame events while the surface isn't visible anywhere
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
I think Weston is going to postpone frame callbacks as long as the window is not at all visible one day, if it doesn't already.
<pq>
and it's nothing about DRM or vendor, it's just compositor behavior
<soreau>
in wayland, eglSwapBuffers blocks until next frame callback unless the swap interval is set to 0
<pq>
JPEW, personally I'd just set SwapInterval to zero always, and subscribe my own frame callbacks...
<JPEW>
Ya, sorry, that wasn't clear. Our use case for weston is to use the fullscreen shell to paper over vendor DRM quirks; IIRC in that _limited_ use case we don't need to worry about the window be obscured.
<JPEW>
But, I fully admit what we have would need to be redone if we wanted to run in e.g. a desktop shell
<pq>
yeah, at least if there is no other client
<JPEW>
IIRC fullscreen shell only lets you have one anyway
<pq>
sounds right - so it works as a consequence of somewhat unrelated design decisions :-)
<JPEW>
Ya, I'm not claiming it's great :)
<JPEW>
fullscreen shell is awesome for our purposes though :)
<pq>
interesting. Would you like to maintain fullscreen shell? :-)
<JPEW>
pq: ... err... I can barely maintain the other OSS stuff I work on; has it been having problems lately?
<pq>
I don't know really... I thought no-one used it :-D
radu242 has joined #wayland
<pq>
I suppose the greatest risk in the near future is it getting deleted, but since you're here, maybe we remember te retain it.
<JPEW>
pq: Ah. We use it for sure.... You can put me down as a person-of-interest at least
<pq>
Cool! Now if we just had anywhere to record that...
<JPEW>
Hmm.... ya, that can be problematic
<pq>
JPEW, well, with the feature deprecation policy in place, if you check in every stable Weston release, you'd see if it's in danger.
<JPEW>
k
<daniels>
JPEW: btw, you wouldn't have to do things differently on a real shell? you'd just need to replace your fullscreen_shell window with an xdg_surface+xdg_toplevel which was set to be fullscreen, and run on kiosk-shell instead
<JPEW>
daniels: Ya, it would still work, but it might have troubles with long blocks and out of date content if the window stopped getting frame callbackes because it was hidden
<daniels>
JPEW: right, but that's nothing to do with fullscreen-shell vs. xdg_surface or kiosk-shell - the decision on whether or not to send frame callbacks is made by the core
<daniels>
and if you run kiosk-shell then you have very similar semantics
<JPEW>
daniels: Are you saying we could also use xdg-shell with fullscreen and/or kiosk-shell because they will never consider the surface "hidden" (like fullscreen-shell)?
<daniels>
JPEW: whether or not a surface is 'hidden' is controlled by the core, and not by the shell per se
<daniels>
right now neither of them will stop sending frame callbacks - but when we do flip that switch in the core, it will effect all the shells alike
<daniels>
i.e. if your surface is occluded in fullscreen-shell, it'll stop receiving frame callbacks
<JPEW>
daniels: Ah, sure... but fullscreen doesn't have any way to hide a surface (since only one can be visible?)
jgrulich has quit [Ping timeout: 480 seconds]
c7s has joined #wayland
<daniels>
JPEW: kiosk-shell and fullscreen-shell do the exact same thing: when you create a new xdg_toplevel (kiosk-shell) or fullscreen_shell_surface, it makes it fullscreen and topmost
<daniels>
so either you have one toplevel surface, and it is forced to always be fullscreen and shown, or you have two toplevel surfaces, in which case only the latest is shown
radu242 has joined #wayland
robert_mader has joined #wayland
radu242 has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
maxzor has quit []
<robert_mader>
emersion: do you happen to already have experience with overlay plane support on AMD systems? Is the kernel support generally there? MrCooper mentioned some quirks. Just asking because I have the chance of getting a new setup and would like to work on that area :/
maxzor has joined #wayland
maxzor has quit [Remote host closed the connection]