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
sozuba has joined #wayland
Moprius has joined #wayland
Moprius has quit []
smallville7123 has joined #wayland
mokee has quit []
mokee has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
cool110_ has quit [Ping timeout: 480 seconds]
bluebugs has joined #wayland
moa has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
smallville7123 has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
sozuba has quit [Ping timeout: 480 seconds]
smallville7123 has joined #wayland
king has quit []
jgrulich has joined #wayland
rv1sr has joined #wayland
<tleydxdy>
hmm I'm trying to figure out how to have an "multiseat" setup with two users, apparently linux's vt system is single user so my idea of having the two monitor be different vt and just have the two user start their compositor on each is bust
<tleydxdy>
as for input devices I'm planning to have devices plugged into one of the usb hubs be assigned to the second user via udev, maybe that also won't work?
<pq>
Compy_, you need to enforce the z-ordering in your special window manager of your Wayland compositor. That's very doable, since I understsand you are designing a predefined system (not a desktop).
<pq>
tleydxdy, Linux VT system enforeces that only one VT is ever active at a time, on the hardcoded seat "seat0". Other seats cannot have VTs (or their problems).
<tleydxdy>
pq: yes my original message already said seem like vt is not gonna work
<pq>
tleydxdy, DRM device, udev and logind achitecture are designed so that you assing a whole DRM device to a specific seat, so if you want multiple seats, you need one DRM-device per seat.
<tleydxdy>
but that's not what I'm after
<pq>
however, DRM leasing could offer a way otherwise
<pq>
the problem is integrating DRM leases with the seat management system
<tleydxdy>
that's interesting because I could have say two container share a drm node
<tleydxdy>
and they can run their own compositor independently
<pq>
you need one entity that is the DRM master on the one DRM device, which creates and hands over DRM leases per CRTC+connector.
<pq>
the problem with DRM leasing is that the different compositors are not aware of each other, but the DRM device still has global resource limits in hardware.
<pq>
for example, if one compositor picks a very demanding output setup (resolution, pixel format and modifier, refresh rate), it is possible the other compositors cannot even light up their outputs.
<pq>
if you can manually configure each compositors, that shouldn't be a problem
<tleydxdy>
yeah I can imagine multiseat would require quite a bit of manual config
<tleydxdy>
but it's weird that it doesn't seem to be possible at all currently
<tleydxdy>
all I could find are info from like 10 years ago
<pq>
maybe, maybe not - it can work by pluggin in more gfx cards already, and how popular is multiseat anyway
<tleydxdy>
the reason I'm trying this is I want to setup my machine so me and my so can use it at the same time
<pq>
sure
<tleydxdy>
e.g. we'd have two desks and the computer in between
<tleydxdy>
hw is so expensive these days
<pq>
that would be really nice, yeah
<pq>
many people have two gfx cards already while use essentially just one: the embedded unused one, and the discrete for gaming
<pq>
tleydxdy, would gaming simultaneously be a use case for you?
<tleydxdy>
yes, but we won't play really demanding game together, and running two games on a gpu would be a really really cool project
<tleydxdy>
right now if I want to add another gpu I will need to upgrade the whole mb too
<tleydxdy>
say as a hack the second compositor runs with wayland backend, and the first compositor is configured to put it on a specified display, would that work as a workaround?
<pq>
it could, yeah
<pq>
In that architecture, the parent compositor could also just give a DRM lease out. How to get input devices is another question.
<tleydxdy>
the way I'm reading loginctl manpage seem like even though by default drm devices are needed to create a seat, it's not strictly required
<tleydxdy>
I would also need to let the second user have access to the first user's wayland socket somehow, err
<pq>
perhaps, I'm not sure. In that architecture, the problem is plumbing the output somehow.
<pq>
well, you have two different possible architectures there:
<pq>
- the secondary compositor runs with a Wayland backend, which means it needs to connect to the primary compositor and the primary compositor needs to know to dedicate a set of input devices for secondary, and one output.
<pq>
- the seconsary compositor runs a DRM backend, so it somehow needs to get a DRM lease from the primary compositor, and it can open all the secondary seat input devices itself (perhaps with udev rules to give static access)
<tleydxdy>
right I think I was thinking the second compositor runs wayland backend for display and libinput backend for input
<tleydxdy>
so it have a seat that only has input devicea
<tleydxdy>
no output
<pq>
I wonder if any compositor actually allows such a mix-up in backends. It would be contrary to fundamental design.
<tleydxdy>
on wlroots it's already like that for drm+libinput right?
Leopold has quit [Remote host closed the connection]
<tleydxdy>
so basically replacing drm with "send frame to this socket"
<pq>
no, because it's drm+libinput, not wayland+libinput
<tleydxdy>
right, I would need to hack some compositors
<pq>
wayland+libinput normally does not make "sense" because a nested compositor needs to get its regular input from the parent compositor.
<pq>
yup, I think you need to hack something in any case
<pq>
maybe that AGL case from Gitlab is the closest to a solution
<tleydxdy>
but it seem like something I can do at wlroots layer and don't need to touch the actual compositor itself
<pq>
perhaps
<tleydxdy>
agl?
<pq>
that gitlab issue I linked to?
<pq>
AGL is Automotive Grade Linux
<pq>
it seems they have patches for exactly this, and someone was testing them out
<pq>
for weston, though
<tleydxdy>
cool, I'll look into that
<JEEB>
I recall tizen ivi also having some weston multiseat back in ye olden days. possibly then picked up by AGL
Leopold_ has joined #wayland
gschwind has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<kennylevinsen>
tleydxdy: it's not just for security that you cannot share a drm node - you can't have two processes be DRM master, controlling and sending stuff to outputs at the same time.
<kennylevinsen>
I assume your container test only forwards a render node, which is the "lighter" node shared by all applications needing to use the GPU to draw stuff...
<tleydxdy>
I forwarded both card0 and renderD128
<tleydxdy>
but yeah they didn't drive any outputs
<tleydxdy>
it's a headless conpositor
kts has quit []
<kennylevinsen>
yeah it's just using it as a render node then
<tleydxdy>
I need to learn more about this drm lease thing
<tleydxdy>
is it basically to split one drm node into one for each display connector?
audgirka has joined #wayland
<kennylevinsen>
a drm master has access to a bunch of drm resources, like the drm connectors. the lease protocol and kernel infrastructure allows the compositor to borrow a connector to another process.
<kennylevinsen>
bl4ckb0ne's kmscube dms lease demo might be the simplest example
<kennylevinsen>
but in your case you need a compositor that borrows out *all* it's resources - normally they only let you use non-desktop (e.g., VR ) headset outputs.
<kennylevinsen>
(alternatively you could have a "system compositor" setup that lets you run two sub-compositors with seat-aware input routing and window management)
<tleydxdy>
yeah ideally something that let me assign leased nodes to seats?
<tleydxdy>
so I have a system daemon that's the drm master
<tleydxdy>
and have the seat own a leased node each
kts has joined #wayland
kts has quit []
kts has joined #wayland
kts has quit [Remote host closed the connection]
zxd has quit []
kts has joined #wayland
<pq>
tleydxdy, DRM leasing does not create device nodes. It only creates an open DRM device fd.
<pq>
That's the big problem with trying to hack in leases to existing seat management: leased devices do not exist as nodes that could be tagged. Instead they are open file descriptors that need to be passed via some IPC from lessor to lessee, and they could be revoked at any time, so the lessee needs to cope with losing and re-getting one.
fmuellner has joined #wayland
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #wayland
<kennylevinsen>
well, the server handing out drm leases for every connector could also hand out the input fds, and thus handle configuration for seat management however one would like
<kennylevinsen>
doesn't have to revolve around udev tagging
<pq>
exactly
<pq>
what I mean is, you cannot just hack things a little and have logind do the right thing.
<pq>
either logind needs to start handing out DRM leases, or you need replace logind completely, most likely
<pq>
a job for seatd?
fmuellner has quit [Ping timeout: 480 seconds]
<kennylevinsen>
if the leased connector appeared similar to the master node, a modified seatd could do the job - but I assume the client needs to be aware that it's getting something other than a master?
<pq>
no, it's essentially a new master file description
<tleydxdy>
the hypothetical drm master system daemon could create some "file" that is backed by the fd I think?
<pq>
with the caveat that it can get revoked
<pq>
tleydxdy, fd do not work like that.
<kennylevinsen>
so if the lease is just a new, restricted master file description, then one could modify seatd to hand out leases without the seat client knowing about it...
<pq>
kennylevinsen, right, and often tell beforehand they are going to do it. Should fit nicely.
<pq>
kennylevinsen, possibly, yeah
<pq>
the fd has DRM master status, but it only exposes the leased subset of the device resources
<pq>
kennylevinsen, one thing I'm not sure about is what happens with connector hotplug events.
<tleydxdy>
my guess is the lease would just get revoked?
<pq>
the lessor could do that, but I somehow doubt it's useful
<pq>
maybe all compositors see everyone's hotplug events
<kennylevinsen>
yeah, they should just fail when they tried to act on other people's hotplug events
<kennylevinsen>
which shouldn't matter
<pq>
after all, a hotplug event is pretty much "hey, something changed, re-check your DRM resources"
<pq>
and the DRM resource list simply does not have the other compositors' things
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
<davidre>
And here are wayland developers of other clients/toolkits
<c0a3hr>
it's over wayland lost X won
Moprius has quit [Quit: bye]
<davidre>
please stop trolling
<pq>
c0a3hr, if you are trying to pick a fight, please go somewhere else.
<pq>
if you want someone here to read that post and comment about it, this is not the way to ask that.
luc4 has quit [Ping timeout: 480 seconds]
lbia1 has quit []
lbia has joined #wayland
Lumpio- has joined #wayland
c0a3hr has quit []
Lumpio__ has quit [Ping timeout: 480 seconds]
<repetitivestrain>
please stop trolling
<repetitivestrain>
wayland and X both have their places
<ebassi>
repetitivestrain: They left and have been quieted
<kennylevinsen>
also, troll handling 101: they feed off responses and wither when ignored
<ebassi>
In any case, dudemanguy is just salty because gtk is going to get a file selection dialog with an icon view, and it's going to make his custom patched package on arch obsolete, so now he's going after wayland
* ebassi
runs
<kennylevinsen>
so no need to use valuable oxygen on them...
<repetitivestrain>
ebassi: that's pretty good news but off topic here, i would like the new dialog
<vsyrjala>
oxygen is abundant on earth :P
<kennylevinsen>
hmm, that blog post seems to be entirely about mpv issues ("doing things differently than other platforms is bad") and a lot of false equivalence fallacies ("eglSwapInterval >1 is broken, therefore EGL support is immature"), so eh. :/
<kennylevinsen>
vsyrjala: not if we had to entertain every troll :D
<LaserEyess>
it's because he's the main wayland developer for mpv and has struggled a lot with trying to get wayland to work well with mpv's rendering loop
smallville7123 has quit [Quit: Konversation terminated!]
<kennylevinsen>
yeah, that would entitle one to a lot of frustration
kts has quit [Quit: Leaving]
<zzag>
that's a poor allocation of resources tbf. you could direct all the time that you've spent writing a blog post towards something more useful. anyway, I'm personally get annoyed by comments such as "wayland is not ready, use x11, don't use wayland;" they don't help at all and they won't change the mind of compositor developers. hating for the sake of hating imho
<zzag>
it's also foolish to assume that wayland will cover ALL x features and provide more; x has existed for more than 30 years for god's sake
<LaserEyess>
I know him decently well, and I know (somewhat) the issues mpv has with wayland, it boils down to mpv wanting to use frame callbacks to efficiently render, but its internal rendering loop is very advanced and sacrificing it (or modifying it) to work with wayland's frame callbacks would sacrifice a lot of features
<LaserEyess>
hence the hack with a timeout to discover if the window is hidden
<LaserEyess>
something liek surface-suspension would handle this very well, and let mpv drop a few hacks and hueristics
<pq>
should a video player use frame callbacks to begin with? particularly if presentation-time extension is available?
jmdaemon has quit [Ping timeout: 480 seconds]
<LaserEyess>
I don't know
<LaserEyess>
to be honest, I do not understand the details 100%, nor do I particularly understand wayland's frame callback model
<pq>
that's more of a research question than something for IRC :-)
<kennylevinsen>
for content not at display refresh rate, probably not
<kennylevinsen>
pq: indeed
<LaserEyess>
well, mpv has a bunch of things like --video-sync and --interpolation that do work at display refresh-rate
<pq>
good point
<LaserEyess>
and to be honest, mpv's current wayland code works *very* well for reducing jitter and syncing with the display
<LaserEyess>
sub-ms variability for hitting vblank times
<daniels>
pq: boxerab has in fact made mpv use presentation-time for its rendering loop
<LaserEyess>
when running in a special context, yes
<kennylevinsen>
swick have repeatedly pointed out that presentation feedback doesn't really tell when you need to submit a frame to get a certain presentation delay, rather just telling you what you ended up with - maybe that also plays into it.
<daniels>
yeah, nor does it allow you to get ahead by targeting particular refresh cycles, because it's only backward-informative rather than forward-targeting
<pq>
this is a video player with pre-recorded content, it should know what it wants to present at any point in the future :-)
<pq>
so the lack of deadline information should not be an issue at all
<kennylevinsen>
Unless it wants to interpolate at mismatched refresh rates or something
<kennylevinsen>
Hmm nah should also be fine
<pq>
you still know what you want to show at any point in the future, unlike games
<repetitivestrain>
tbh i would like a protocol to apply a commit at a given msc or ust on a user specified crtc, at least when the surface is subject to direct scanout
<LaserEyess>
despite his rather scathing blog post, he woudl still be generally receptive to solutions to the frame callback stalling issue that aren't "simply re-write mpv's internal rendering loop"
<LaserEyess>
ideally most of it is fixed by something like surface-suspension, though
<LaserEyess>
ideally from mpv's perspective, I mean*
<kennylevinsen>
Something like surface suspend or surface hide info doesn't seem unacceptable to have...
<kennylevinsen>
Or just having the surface exit the output
<kennylevinsen>
Maybe that would be better - surface suspend seems more like a "clean up your resources, you are unwanted. all your memory are belong to us" kind of ordeal...
<pq>
I think using frame callbacks for SwapInterval was probably a mistake.
<Compy_>
pq: Thanks for the feedback! Yeah, these would be the only 2 apps running on this system, so not a generic desktop setup. I'm using Weston currently as the compositor. I'll look into enforcing the z-ordering at that level.
<tleydxdy>
what even is swapinterval supposed to mean. is it tied to the display?
<tleydxdy>
like inherently
<tleydxdy>
ig in other words what's "a video frame"?
kts has quit [Quit: Leaving]
nerdopolis has joined #wayland
<pq>
tleydxdy, think of fixed frequency refresh rate and direct scanout. One interval is one scanout cycle, and they never stop or pause.
gschwind has quit [Quit: Leaving]
<tleydxdy>
so it's only well defined for exclusive fullscreen?
<repetitivestrain>
tleydxdy: in other words a swap interval of 1 means the swap will happen 1 msc after the last swap, and 2 means it will happen 2 mscs after
<pq>
I wouldn't say so, scanout cycles happen all the time regardless of what you display.
<pq>
msc = media stream counter, IOW a refresh cycle counter
<pq>
IOW a timer
<tleydxdy>
but if say it's a window, then it could span or get mirrored to multiple displays
<tleydxdy>
how would this work then
<pq>
that concept likely didn't exist when swapinterval was defined, or it was ignored
<pq>
so, just pick any CRTC for it
<repetitivestrain>
tleydxdy: the compositor picks a crtc to synchronize with
<pq>
better if that CRTC is actually displaying even a part of the window in question
<tleydxdy>
it predates moving window across displays?
<repetitivestrain>
they could behave differently, but i don't know of a compositor that does anything other than picking 1 crtc to sync with
<repetitivestrain>
even if the surface straddles multiple crtcs
<tleydxdy>
I'm asking in terms of like egl or vulkan spec
<pq>
tleydxdy, possibly. I mean, being able to drag a window from monitor to another is a pretty new invention in X11 time scale.
<tleydxdy>
what do they say about what this interval mean
<tleydxdy>
is it implementation defined?
<tleydxdy>
in that case using frame callback is perfectly valid right?
<pq>
no, frame callbacks can stop. scanout cycles cannot. It doesn't matter what the specs say much, because that's what apps expect, because until Wayland that's how it has always worked.
<vsyrjala>
iirc xorg picks the crtc that contains the largest chunk of the window
<tleydxdy>
okay, so as a defacto spec, it's a timer that fires at an regular interval
<tleydxdy>
that's all
<pq>
pretty much
<pq>
I bet EGL was heavily influenced by its predecessor GLX.
<repetitivestrain>
vsyrjala: that depends on the video driver, modesetting does what you said, yes
<tleydxdy>
so in theory the swapinterval implementation can just have their own timer
<repetitivestrain>
i don't remember what nvidia's ddx or the rest of the xf86-video-foo do
<repetitivestrain>
tleydxdy: yes
<tleydxdy>
and only uses whatever hints compositor gives as like a clock synchronization mechanism
<repetitivestrain>
you could probably get the necessary info to do it right off wp_presentation
<tleydxdy>
so it's not really "blocking"
<repetitivestrain>
but i haven't looked at wp_presentation in detail yet
<vsyrjala>
repetitivestrain: iirc intel ddx does the same. although maybe there was some extra heuristic wrt favoring the primary crtc. dunno if modesetting has that or not
<repetitivestrain>
repetitivestrain: nope, modesetting just tries to find the crtc with the biggest overlap with the window
<tleydxdy>
so why is swapinterval implementations using frame callbacks if it is indeed problematic?
<pq>
tleydxdy, because frame callback was the only relevant thing that existed at the time when EGL Wayland platform was invented.
<tleydxdy>
if the application prints frames on a regular interval, e.g. games, video players
<vsyrjala>
repetitivestrain: looks like it does use the primary crtc as a tie breaker
<tleydxdy>
what's the harm in just ignoring frame callbacks?
<daniels>
if you ignore frame callbacks, then you pointlessly burn resources (battery, thermal, the Amazon, etc) by spamming the compositor with frames which will never be rendered
<pq>
tleydxdy, it varies from none to omg-my-laptop-battery.
<tleydxdy>
but that's an optimization thing right?
<daniels>
but that's also what you're doing when you're still sending frames at a compositor which is no longer sending you frame events
<daniels>
tleydxdy: depends on your view of 'optimisation'. careless background tabs in Chrome can lower my laptop battery life from 8 hours to <2h.
<tleydxdy>
using frame callback to optimize, sure
<pq>
I think in modern world optimizing power consumption is more than "just optimization".
<daniels>
which isn't 'oh it would be nice if this was a little faster', it's 'I can't use this thing for what I need to'
kts has joined #wayland
<tleydxdy>
to phrase another way, why does it "rely" on frame callbacks
<pq>
it? the eglSwapInterval implementation?
<tleydxdy>
yeah or vulkan present modes
<daniels>
because they have to?
<pq>
purely historical reasons - no-one bothered to replace it with something better yet.
<tleydxdy>
so this > okay, so as a defacto spec, it's a timer that fires at an regular interval
<tleydxdy>
is not true
<daniels>
eglSwapInterval(1) is defined such that while (true) { glDrawArrays(); eglSwapBuffers(); } will pace itself to deliver 1 frame per refresh cycle
<pq>
applications do expect exactly that ^ behavior, whether it's good or not.
<zamundaaa[m]>
tleydxdy: it isn't exactly true in the context of Wayland, but it is true in what applications expect
tanty has quit [Remote host closed the connection]
<tleydxdy>
okay emm
<tleydxdy>
so swapinterval is tied to the refresh cycle whatever that means
<pq>
and when I say replace the swapinterval implementation, I mean replacing the frame callback waiting with a literal timer.
<tleydxdy>
and frame event is not tied to the refresh cycle
tanty has joined #wayland
<tleydxdy>
so why tie the two together
<pq>
frame event is higher level concept than a refresh cycle
<pq>
tleydxdy, historical reasons.
<tleydxdy>
and if swapinterval has to happen on a regualr interval
<zamundaaa[m]>
tleydxdy: in practice it is tied to the refresh rate
<tleydxdy>
it can't be used to stop rendering to save battery
<daniels>
the EGL core spec doesn't define behaviour for when windows are fully occluded
<tleydxdy>
so i'm not sure how this two even get mixed in the first place
<daniels>
you're off into the land of platform-defined things there, and yes, precluding completely-invisible apps from pointlessly burning GPU resources was seen as a feature at the time
<daniels>
whether or not it's still seen that way is up for debate
<daniels>
(on Xorg, your app will get throttled down to a 1Hz gate through SwapBuffers, which is also a completely valid thing to do)
<tleydxdy>
I see two things here right? 1. app wants to know when the monitor is refreshed -> swap interval. 2. app wants to know when to draw and when not to draw to save battery/perf -> frame callback
<tleydxdy>
those two seem completely unrelated
<pq>
tleydxdy, right.
<pq>
when EGL Wayland platform was invented, the only thing that had any relation to refresh cycle was the frame callback. And it seemed to have other good properties as Daniel mentioned above.
<tleydxdy>
if say we "rename" frame callback to "keep drawing" callback for the mental model, it would make more sense to me
<tleydxdy>
and have some other way to tell the apps when an particular monitor refreshes
<pq>
unfortunately, no-one ever tests any program completely off-screen, so even if they did test on an OS where swaps stop happening, they never saw it.
<daniels>
tleydxdy: knowing exactly when a particular monitor refreshes is a) provided by the presentation-time interface, and also b) irrelevant for almost every usecase
<daniels>
presentation-time gets used when it's useful: knowing when pixels became photos, so you can use that to sync against your audio clock and do lipsync properly
<tleydxdy>
so you are saying 1. and 2. from my previous message are the same thing
<daniels>
for any other purpose, it's not a relevant detail and is mostly misleading, because it doesn't tell you (as a client) when to get your clients out
<daniels>
*get your buffers out
<daniels>
there are several different and often orthogonal usecases, which are pretty hard to reduce further than what's already been said here
<daniels>
for clients which don't have a strong opinion about when exactly to draw, but are happy to accept the compositor's opinion on when is 'good', that's the frame callback
<daniels>
for apps which additionally need to correlate pixels-to-photons with other things, that's presentation-time
<tleydxdy>
right so presentation time does not solve either 1 or 2
<tleydxdy>
it solves some other problem 3
<daniels>
yes
<tleydxdy>
and problem 2 have a solution namely frame callback
<tleydxdy>
what's the solution for 1?
<daniels>
1 is the wrong question
<daniels>
what actual root-cause problem leads you to wanting to know at which point your display device begins its own refresh cycle?
<tleydxdy>
what about "1. know/have a way to present on the next refresh cycle of a particular monitor"
<daniels>
that's closer to a useful formation, but still has some assumptions that you're 1:1 with that particular monitor's underlying refresh cycle
<daniels>
assuming you would, there's an MR in wayland-protocols for a protocol which allows forward targeting of particular refresh cycles
<tleydxdy>
okay, would that protocol solve the swapinterval problem? i.e. is the swapinterval problem same as problem 1?
<daniels>
which is often very useful in its own right, but doesn't solve mpv's apparent problem of 'I want to be able to push frames at the compositor at the display's refresh interval no matter what, even if they will never be displayed, and even if there is no refresh interval because the display's been turned off'
<daniels>
what do you mean by 'the SwapInterval problem'?
<tleydxdy>
i.e. the 1 second fallback, all that
<tleydxdy>
if say the application could access the refresh info of monitors, then it won't need to rely on frame callback and confuse problem 1 with problem 2
<daniels>
if you've determined it is an absolute hard requirement for eglSwapBuffers to make forward progress at something resembling 60Hz absolutely all the time no matter what (and this is not objectively an improvement), then the client implementation can already just tick through on its own timer, without spamming the compositors with buffers it'll never use
<tleydxdy>
be it "when do I need to submit frames to catch the next refresh" or "when did the monitor last refresh"
<tleydxdy>
neither of this two are solved by frame callback it seems
<zamundaaa[m]>
tleydxdy: the monitors refresh rate is not necessarily constant
<tleydxdy>
yes of course
<tleydxdy>
which is why my original question is "what even is swapinterval supposed to mean. is it tied to the display?"
<tleydxdy>
like what does this interval even mean
<pq>
VRR did not exist when swap interval was invented
<tleydxdy>
my understanding after all the above is that swapinterval is a way for apps to "catch the next refresh"
<tleydxdy>
I get that if apps are sloppy it might still miss
<pq>
The problem is, apps are not using a timer, because swap interval has always implicitly provided that timer by blocking eglSwapBuffers calls. Even better, it has synchronized to the refresh cycle, meaning the app gets a constant latency.
<pq>
It used to be that a fixed rate timer, swap interval, and refresh cycle were all equivalent. Now that they are not equivalent anymore, we cannot know which one an application was interested in.
<tleydxdy>
here's some other thing I don't understand
<tleydxdy>
some games seem to have a way to know when they are backgrounded
<tleydxdy>
is that something that's used to stop drawing?
<daniels>
pq: (you're right about EGL's origins fwiw. it's GLX with a regex)
zebrag has joined #wayland
<zamundaaa[m]>
tleydxdy: if you mean by "when they are backgrounded", that they're pausing the game when you click out of it, they're just reacting to losing window focus
<pq>
tleydxdy, one would hope it is. I also don't know how they would find that out on Wayland.
<pq>
oh yeah, of course :-D
hardening has joined #wayland
<tleydxdy>
so I guess a complete solution would be something like this? the swap interval thing unblocks in accordance with a particular monitor's refresh cycle, this is done via some sort of protocol, if it did not receive an frame callback in a while, it stops tracking the monitor's refresh cycle (ideally completely but in practice with a 1 second cycle), when frame callback resume it resume tracking a particular monitor's refresh cycle
<pq>
kind of, yeah
<tleydxdy>
do this call pull double duty? it both schedules the buffer to be presented at the next n'th refresh, and it blocks before that happens so app don't draw too much?
<pq>
yes
<tleydxdy>
so there need to be some other protocol that does the first part too
<pq>
usually it block waiting for the previous frame to be presented rather than the new frame
<pq>
um, I assumed we are talking about eglSwapBuffers()
<tleydxdy>
yeah I was calling the previous frame the current frame and the next frame the new frame xd
eroc1990 is now known as Guest33
eroc1990 has joined #wayland
<tleydxdy>
ah I get what you mean
<tleydxdy>
yeah
<pq>
... I also recall Mesa is getting the option to the blocking for current frame too, because people want lower latency at the risk of missing the next update
<tleydxdy>
either way there's 3 problem and need 3 protocols, one of them is frame callback for the power saving thing but the other two are not there yet
Guest33 has quit [Ping timeout: 480 seconds]
<pq>
definitely conflated problems, since in the old days they were not different :-)
<tleydxdy>
yeah definitly feel weird since the power saving is solved before the other two
audgirka has quit [Remote host closed the connection]
xiaoyaobing has joined #wayland
xiaoyaobing has quit []
<MrCooper>
daniels: "knowing when pixels became photos" is a cute typo :)
<MrCooper>
pq: FWIW, the new Mesa option is "block SwapBuffers until the next buffer is available", not (necessarily) "block for current frame"
<daniels>
ManMower: haha
<daniels>
*MrCooper
<pq>
ah!
<MrCooper>
pq: one issue currently is that a video player which doesn't want to attach a new buffer for every display refresh cycle can't know reliably when it should attach the next buffer
<MrCooper>
hmm, or maybe presentation-time could at least help for this, assuming the feedback from that works as intended with nothing else in the same surface commit
<ManMower>
I guess you can just ask for another frame callback if you don't have anything new to present when you get one?
king has joined #wayland
<ManMower>
just look at how toytoolkit applications do animated cursors. :) (no, don't)
<ManMower>
but iirc they'll either ask for a frame callback if the next update is "soon", or set a timerfd if it's a long way off
<MrCooper>
I wouldn't rely on frame callbacks for that, we've had a long discussion about that on GitLab
<MrCooper>
but presentation-time feedback could work
<ManMower>
isn't presentation-time feedback by definition too late? or will you just always target 1 frame behind?
<MrCooper>
I didn't say "use presentation-time feedback as the starting point" :), just as a reference for the client's scheduling
<MrCooper>
(note that frame callbacks are fundamentally the same though; by definition, a frame callback marks the point after which attaching a new buffer will not affect the next display refresh cycle)
<ManMower>
with weston's repaint window, I don't think that's strictly true
qyliss has quit [Quit: bye]
<MrCooper>
that would violate the protocol spec, if the client attached a buffer between the last vertical blank period and the frame callback
<ManMower>
would it?
<ManMower>
in the proto doc for frame, "if the client commits an update earlier than that, it is likely that some updates will not make it to the display, ..."
<ManMower>
doesn't sound strictly illegal
<ManMower>
just inefficient
qyliss has joined #wayland
<MrCooper>
it conversely means "attaching after frame callback will never replace a previously attached buffer before it is displayed"
<ManMower>
no, it doesn't
<ManMower>
like, if you attach before the frame callback but after the vsync, then attach again after the frame callback, you can get a "discarded" feedback event
maxzor has joined #wayland
<MrCooper>
no such thing for frame callbacks, you're thinking of presentation-time
<ManMower>
I'm saying if you're using both you could instrument this.
<MrCooper>
it doesn't change the frame callback semantics though
<ManMower>
where is that documented?
<MrCooper>
you quoted the spec above
<ManMower>
"likely" is a fuzzy word
<ManMower>
and on weston, you can absolutely commit before and after frame within a single vsync interval
<ManMower>
attaching after presentation feedback tells you you've been presented would never replace, because that's when your pixels have become light. but the frame callback could be anywhere within the refresh interval.
<ManMower>
(would never replace an undisplayed buffer)
floof58 is now known as Guest39
floof58 has joined #wayland
sozuba has joined #wayland
Guest39 has quit [Ping timeout: 480 seconds]
sozuba has quit [Quit: sozuba]
<MrCooper>
ManMower: so you're saying weston sends frame callbacks at some earlier point in the display refresh cycle, then processes additional client requests, then composites the next frame at some later point in the display refresh cycle?
jryans has quit [Write error: connection closed]
MatrixTravelerbot[m]1 has quit [Write error: connection closed]
edrex[m] has quit [Write error: connection closed]
furyishere[m] has quit [Write error: connection closed]
Naruto[m] has quit [Write error: connection closed]
deknos82[m] has quit [Write error: connection closed]
Guest4154 has quit [Write error: connection closed]
frytaped[m] has quit [Write error: connection closed]
jasyuiop[m] has quit [Write error: connection closed]
cb5r[m] has quit [Write error: connection closed]
niecoinny[m] has quit [Write error: connection closed]
Florian[m]1 has quit [Write error: connection closed]
hasebastian[m] has quit [Write error: connection closed]
DrNick has quit [Write error: connection closed]
tleydxdy has quit [Write error: connection closed]
Max[m]12345 has quit [Write error: connection closed]
Levans has quit [Write error: connection closed]
hariselldon[m] has quit [Write error: connection closed]
xerpi[m] has quit [Write error: connection closed]
Mershl[m] has quit [Write error: connection closed]
gnustomp[m] has quit [Write error: connection closed]
RAOF has quit [Write error: connection closed]
pac85[m] has quit [Write error: connection closed]
Sumera[m] has quit [Write error: connection closed]
cmeissl[m] has quit [Write error: connection closed]
hch12907 has quit [Write error: connection closed]
ujineli[m] has quit [Write error: connection closed]
bdaase[m] has quit [Write error: connection closed]
apol[m] has quit [Write error: connection closed]
ongy[m] has quit [Write error: connection closed]
ozwald1[m] has quit [Write error: connection closed]
pitsch[m] has quit [Write error: connection closed]
danburd[m] has quit [Write error: connection closed]
rails[m] has quit [Write error: connection closed]
[old]freshgumbubbles[m] has quit [Write error: connection closed]
JosExpsito[m] has quit [Write error: connection closed]
GeorgesStavracasfeaneron[m] has quit [Write error: connection closed]
doras has quit [Write error: connection closed]
teh1[m] has quit [Write error: connection closed]
Ryhon[m] has quit [Write error: connection closed]
rubo_[m] has quit [Write error: connection closed]
RomanGilg[m] has quit [Write error: connection closed]
Kelseyjgilbert[m] has quit [Write error: connection closed]
ambasta[m] has quit [Write error: connection closed]
japchae[m] has quit [Write error: connection closed]
FbioPacheco[m] has quit [Write error: connection closed]
hex[m]1 has quit [Write error: connection closed]
ammen99[m] has quit [Write error: connection closed]
ehfd[m] has quit [Write error: connection closed]
FellFromTheSky[m] has quit [Write error: connection closed]
diamondburned[m] has quit [Write error: connection closed]
Joanna[m] has quit [Write error: connection closed]
q234rty[m][m] has quit [Write error: connection closed]
vchernin[m] has quit [Write error: connection closed]
underpantsgnome[m] has quit [Write error: connection closed]
psydroid[m] has quit [Write error: connection closed]
bluepenquin has quit [Write error: connection closed]
anomalous_creator[m] has quit [Write error: connection closed]
Nova[m] has quit [Write error: connection closed]
toggleton[m] has quit [Write error: connection closed]
DemiMarie has quit [Write error: connection closed]
nielsdg has quit [Write error: connection closed]
Nico has quit [Write error: connection closed]
nazarewk[m] has quit [Write error: connection closed]
junglerobba[m] has quit [Write error: connection closed]
Guest4168 has quit [Write error: connection closed]
unix-supremacist[m] has quit [Write error: connection closed]
arichardson[m] has quit [Write error: connection closed]
inkbottle[m] has quit [Write error: connection closed]
tzx[m] has quit [Write error: connection closed]
varlad[m] has quit [Write error: connection closed]
smasher_tati[m] has quit [Write error: connection closed]
Bran[m] has quit [Write error: connection closed]
emilio[m]1 has quit [Write error: connection closed]
davidre has quit [Write error: connection closed]
d_ed[m] has quit [Write error: connection closed]
cousinofthor[m] has quit [Write error: connection closed]
botiapa[m] has quit [Write error: connection closed]
AndrewAylett[m] has quit [Write error: connection closed]
ttancos[m] has quit [Write error: connection closed]
marcusbritanicus[m] has quit [Write error: connection closed]
zamundaaa[m] has quit [Write error: connection closed]
ahmadraniri[m] has quit [Write error: connection closed]
yshui` has quit [Write error: connection closed]
heftig has quit [Write error: connection closed]
ki[m] has quit [Write error: connection closed]
YaLTeR[m] has quit [Write error: connection closed]
BilalElmoussaoui[m] has quit [Write error: connection closed]
windowsxp[m] has quit [Write error: connection closed]
zaibon[m] has quit [Write error: connection closed]
qaq[m] has quit [Write error: connection closed]
q234rty[envs][m] has quit [Write error: connection closed]
Poly[m] has quit [Write error: connection closed]
Max[m]1234 has quit [Write error: connection closed]
Shimmy[m] has quit [Write error: connection closed]
jmariondev[m] has quit [Write error: connection closed]
GrahamPerrin[m] has quit [Write error: connection closed]
j-james[m] has quit [Write error: connection closed]
drakulix[m] has quit [Write error: connection closed]
Guest4176 has quit [Write error: connection closed]
robertmader[m] has quit [Write error: connection closed]
i509VCB has quit [Write error: connection closed]
halfline[m] has quit [Write error: connection closed]
mvlad has quit [Remote host closed the connection]
king has quit []
DemiMarie has joined #wayland
ambasta[m] has joined #wayland
ammen99[m] has joined #wayland
AndrewAylett[m] has joined #wayland
anomalous_creator[m] has joined #wayland
apol[m] has joined #wayland
arichardson[m] has joined #wayland
bdaase[m] has joined #wayland
BilalElmoussaoui[m] has joined #wayland
bluepqnuin has joined #wayland
botiapa[m] has joined #wayland
Naruto[m] has joined #wayland
RAOF has joined #wayland
cb5r[m] has joined #wayland
cmeissl[m] has joined #wayland
cousinofthor[m] has joined #wayland
d_ed[m] has joined #wayland
danburd[m] has joined #wayland
davidre has joined #wayland
Nico has joined #wayland
DemiMarieObenour[m] has joined #wayland
deknos82[m] has joined #wayland
diamondburned[m] has joined #wayland
Guest49 has joined #wayland
doras has joined #wayland
drakulix[m] has joined #wayland
edrex[m] has joined #wayland
ehfd[m] has joined #wayland
emilio[m] has joined #wayland
GeorgesStavracasfeaneron[m] has joined #wayland
FbioPacheco[m] has joined #wayland
Joanna[m] has joined #wayland
FellFromTheSky[m] has joined #wayland
[old]freshgumbubbles[m] has joined #wayland
frytaped[m] has joined #wayland
furyishere[m] has joined #wayland
gnustomp[m] has joined #wayland
Guest69 has joined #wayland
GrahamPerrin[m] has joined #wayland
halfline[m] has joined #wayland
hariselldon[m] has joined #wayland
hasebastian[m] has joined #wayland
hch12907 has joined #wayland
Bran[m] has joined #wayland
Florian[m]1 has joined #wayland
heftig has joined #wayland
Guest87 has joined #wayland
hex[m]1 has joined #wayland
i509VCB has joined #wayland
inkbottle[m] has joined #wayland
j-james[m] has joined #wayland
japchae[m] has joined #wayland
jasyuiop[m] has joined #wayland
Kelseyjgilbert[m] has joined #wayland
jmariondev[m] has joined #wayland
junglerobba[m] has joined #wayland
JosExpsito[m] has joined #wayland
jryans has joined #wayland
Levans has joined #wayland
marcusbritanicus[m] has joined #wayland
MaxbackNov2nd[m] has joined #wayland
Mershl[m] has joined #wayland
Max[m]123 has joined #wayland
nazarewk[m] has joined #wayland
niecoinny[m] has joined #wayland
nielsdg has joined #wayland
ongy[m] has joined #wayland
teh1[m] has joined #wayland
ozwald1[m] has joined #wayland
pac85[m] has joined #wayland
pitsch[m] has joined #wayland
Poly[m] has joined #wayland
psydroid[m] has joined #wayland
q234rty[envs][m] has joined #wayland
q234rty[m][m] has joined #wayland
qaq[m] has joined #wayland
rails[m] has joined #wayland
robertmader[m] has joined #wayland
DemiMarie is now known as Guest92
RomanGilg[m] has joined #wayland
rubo_[m] has joined #wayland
Ryhon[m] has joined #wayland
smasher_tati[m] has joined #wayland
Sumera[m] has joined #wayland
Nova[m] has joined #wayland
Shimmy[m] has joined #wayland
underpantsgnome[m] has joined #wayland
tleydxdy has joined #wayland
toggleton[m] has joined #wayland
ttancos[m] has joined #wayland
tzx[m] has joined #wayland
ki[m] has joined #wayland
ujineli[m] has joined #wayland
unix-supremacist[m] has joined #wayland
varlad[m] has joined #wayland
vchernin[m] has joined #wayland
MatrixTravelerbot[m]1 has joined #wayland
windowsxp[m] has joined #wayland
xerpi[m] has joined #wayland
YaLTeR[m] has joined #wayland
yshui` has joined #wayland
zaibon[m] has joined #wayland
zamundaaa[m] has joined #wayland
Guest49 is now known as DrNick
gschwind has joined #wayland
tzimmermann has quit [Quit: Leaving]
dcz_ has quit [Ping timeout: 480 seconds]
king has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mokee has quit [Remote host closed the connection]
jmdaemon has joined #wayland
fmuellner has joined #wayland
gschwind has quit [Quit: Leaving]
rv1sr has quit []
Narrat has quit []
floof58 is now known as Guest106
floof58 has joined #wayland
Guest106 has quit [Ping timeout: 480 seconds]
hardening has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
<daniels>
fwiw if someone wants to do something useful, adapting https://gitlab.freedesktop.org/freedesktop/mr-label-maker to be able to take multiple project arguments and monitor them all, as well as adding wayland/weston regexes, would be great