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
ewrvvvvvvvvvvvvvvvvvvvvvvvvvvd has quit [Remote host closed the connection]
hardening has joined #wayland
dcz_ has joined #wayland
jgrulich has joined #wayland
maxzor has quit [Remote host closed the connection]
maxzor has joined #wayland
pnowack has joined #wayland
gusnan has quit [Ping timeout: 480 seconds]
maxzor is now known as Guest10119
maxzor_ is now known as maxzor
gusnan has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
eroux has joined #wayland
maxzor_ has joined #wayland
eroux has quit [Ping timeout: 480 seconds]
<pq>
soreau, no, the user must not be part of video or input groups on a typical systemd using distribution. It's not necessary when things work correctly.
maxzor has quit [Ping timeout: 480 seconds]
<pq>
luckily the one asking in this case was not having systemd
luc4 has joined #wayland
eroux has joined #wayland
___nick___ has joined #wayland
<pq>
MrCooper, of course, but what I explained is what presentation-time was designed for and nothing more (like dynamic client-side scheduling).
eroux has quit []
<pq>
Now that people want more, presentation-time is not enough.
psykose has left #wayland [#wayland]
<MrCooper>
my point is that no protocol could completely shield clients which may need the full GPU capacity available from making a prediction when the next compositor deadline will be (only a working crystal ball could ;)
<MrCooper>
since the compositor itself can only know it when the previous frame has completed, which is too late for such clients to start working on the next one
<MrCooper>
I guess "may only know it" is more accurate, for compositors doing dynamic frame scheduling
<jadahl>
with a just-before-deadline based compositor kms commit approach, and a currently being unredirected surface, and if the compositor knows how to fast-forward the client buffer to the kms state, one could allow clients to post just before the deadline in best case scenarios
<jadahl>
but once it becomes redirected thus part of the compositors compositing pipeline, that deadline would not be applicable
caveman has joined #wayland
agners has joined #wayland
pochu has joined #wayland
resonious has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
<swick>
if the presentation deadline is jumping around a lot there is no way for clients to reliably hit the deadline anyway no matter what heuristic they use
___nick___ has joined #wayland
<swick>
but at least with a slowly changing presentation deadline and clients being aware of previous deadlines they can choose between minimizing latency and potentially missing the deadline
<swick>
doesn't really matter if the change of the presentation deadline is a result of VRR or compositing
mvlad has joined #wayland
rasterman has joined #wayland
cvmn has joined #wayland
qyliss has quit [Quit: bye]
<dottedmag>
I wonder if clients could cooperate by telling compositor "I'm quite static, don't bother refreshing the screen all the time", and on VRR with all-static clients it'd result in 1) no scheduled refreshes; 2) any submitted buffer being rushed to the display. With a fallback to timed refresh if any active clients are detected.
<dottedmag>
However "clients cooperate" does not sound very promising in the real world...
qyliss has joined #wayland
qyliss has quit []
qyliss has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
maxzor__ has joined #wayland
Guest10119 has quit [Remote host closed the connection]
<zamundaaa[m]>
Clients don't need to tell the compositor that, they just need to not submit buffers
hasebastian[m] has joined #wayland
<ishitatsuyuki>
they need to indicate whether they intend to submit a frame or not, otherwise compositors would think the client is lagging when it's just not trying to update and delay refresh as such
<SardemFF7>
why would it think it’s lagging? not sending a new buffer is perfectly valid O_o
<ishitatsuyuki>
on Windows this is typically done with a heuristic that only apps using DirectX/GL/VK are subject to FreeSync
<ishitatsuyuki>
SardemFF7: it should not, but with the current protocol there's no way to differentiate
<SardemFF7>
ok, same question but different: why would it matter that it’s lagging? what is the use case enabled by knowing that?
<ishitatsuyuki>
one thing that would be easy to notice is cursor updates
<ishitatsuyuki>
if you wait for an application that doesn't update then cursor updates would run at 48Hz (lowest refresh rate) instead of 144Hz (highest refresh rate)
<SardemFF7>
so you mean a high level “client not responding” concept?
<ishitatsuyuki>
huh?
<SardemFF7>
my bad, I didn’t get what you mean at all
<SardemFF7>
if the cursor changes or move, the compositor is perfectly free to do so at 144Hz, isn’t it?
<ishitatsuyuki>
then it breaks VRR?
<SardemFF7>
no?
<ishitatsuyuki>
how do you know if the application is running at 130Hz or is simply static?
<ishitatsuyuki>
you need a heuristic or a protocol
<SardemFF7>
it doesn’t matter because the application is independent from the cursor? and if it’s not, it means the application is in charge of the cursor (using the pointer constraint or whatever it’s named protocol)
<ishitatsuyuki>
you can't run the monitor at 144Hz and 130Hz at the same time
<SardemFF7>
you run it at 144Hz because the cursor needs that, and you just happen to see 14 frames of the application twice because … it didn’t change in between anyway
<ishitatsuyuki>
that's not called VRR
<ishitatsuyuki>
the refresh rate is literally fixed in your description
<SardemFF7>
it is because if you don’t move the cursor with a 130Hz application… you’ll get 130Hz
<ishitatsuyuki>
I guess that's a workable tradeoff, but VRR implementations I've seen doesn't work like that in practice
cousinofthor[m] has joined #wayland
ewryyyyyyyyyyyyyyyyyyyyyyyyyyd has joined #wayland
<kennylevinsen>
ishitatsuyuki: that is still VRR, it's just not Window's implementation
<kennylevinsen>
Capping the cursor would probably help a lot of use-cases though
<ishitatsuyuki>
I prefer having a VRR "master" with everything else following its refresh rate but not sure if it works for Linux
<kennylevinsen>
but it doesn't matter if a client isn't rendering becuase it doesn't have new content, or becuase it's being slow - the compositor needs to do the same work on next frame regardless. Maybe you meant a way to entirely opt-out of "VRR-like" behavior by not having such an application drive pageflips?
<kennylevinsen>
that would be fragile as the compositor would need to anticipate if no other client updated either and do a fallback composition before the upper VRR limit in case nothing else drove the pageflip
<ishitatsuyuki>
fair
<kennylevinsen>
but maybe that's needed, idk - don't have a VRR-capable machine myself
<ishitatsuyuki>
> it doesn't matter if a client isn't rendering becuase it doesn't have new content, or becuase it's being slow
<ishitatsuyuki>
if you refresh on every possible update (including cursor), yes. otherwise, it does matter because if you refresh at t+1/144 time, then you won't be able to perform the next refresh on, say, t+1/130 time
gryffus has joined #wayland
<kennylevinsen>
that also doesn't matter - if something needed to refresh at 1/114, delaying to 1/130 would be a degradation. Then we get into the priority/"opt-out" to say something matters enough to delay other things.
<ishitatsuyuki>
I see what you say
ivyl has quit [Quit: issued !quit command]
ivyl has joined #wayland
<MrCooper>
FWIW, the compositor or kernel driver could also have the display refresh at a multiple of the application frame rate, to allow the cursor to move more smoothly; this is already done in some cases when the frame rate drops below the minimum refresh rate (called LFC for Low Framerate Compensation)
<ishitatsuyuki>
it's tricky to expand this beyond cases where LFC would kick in because the compositor cannot predict the next present time accurately and it can end up delaying presentation unnecessarily
<kennylevinsen>
I do imagine that a lot of use-cases solve themselves by being fullscreen applications on a single surface with no "real" cursor (games)
<kennylevinsen>
the main question is how to gain something from VRR for regular desktop usescases
<kennylevinsen>
and no one wants to see a 30Hz cursor movement on a 144Hz monitor :P
<ishitatsuyuki>
right now, only video playback probably
<ishitatsuyuki>
there are possible creative use cases I think
<kennylevinsen>
Video playback is a good example of where you probably don't want screen refresh to follow the content exactly, but you'd probably want 2x or 3x video rate for windowed content
<MrCooper>
doras is blocking VRR support in mutter on the cursor issue, and does have a point there
<kennylevinsen>
we have VRR in sway, but from what I can tell people are complaining about the cursor issue there as some monitors/drivers handle the jerk to max refresh poorly. I imagine it works fine when there isn't a cursor moving around.
<kennylevinsen>
I think there was a proposal to rate limit the cursor or otherwise "exclude" it
rubo_[m] has joined #wayland
gryffus has quit [Remote host closed the connection]
<MrCooper>
the other side of that coin is the cursor moving at the minimum refresh rate (which is pretty painful) while the application doesn't update / isn't keeping up
<MrCooper>
so a solution needs to allow the cursor to move smoothly at all times, while not messing up the refresh rate (too much) for the application
<MrCooper>
which is pretty difficult to achieve for the compositor, especially with the current atomic KMS API
<MrCooper>
arguably the best solution would be an atomic KMS API extension which allows the compositor to update the cursor independently from other planes, and the kernel driver doing (the equivalent of) LFC to make it all work well together
<swick>
I don't think that's really necessary
<swick>
a "don't present earlier than $TIMESTAMP" in the atomic API should be sufficient
<swick>
and it's more generally useful
<MrCooper>
the problem is there's currently no way to queue separate commits for the cursor and other planes which will be applied in the same refresh cycle; it's either cursor only or everything together
saumon has quit [Ping timeout: 480 seconds]
<swick>
yeah, okay, but that's the lack of amending commits
<swick>
you could then change the cursor directly after the previous scanout or whenever you receive input with a no-earlier-than timestamp and if the client commits you amend that commit
<MrCooper>
amending commits alone doesn't solve it either, since a cursor update shouldn't always trigger a new refresh cycle ASAP (and the cursor plane is fundamentally the same as any other plane in the API), but an application buffer update should
<swick>
right, that's where the no-earlier-than timestamp comes in
<MrCooper>
so instead or in addition, some mechanism is needed for distinguish between the two cases
<MrCooper>
no-earlier isn't quite right for this either, there isn't really any time limit, cursor updates just shouldn't mess up the refresh rate for the application
<MrCooper>
we discussed this in great detail here or on another channel at the end of last year
<swick>
setting no-earlier to the greatest possible next refresh gives you exactly that
<swick>
however it also allows you to define a lowest refresh rate for the cursor
<swick>
and you can do the LFC trick in user space
<swick>
but I can see why you would want to have an explicit value for "whenever the greatest possible next refresh is"
<MrCooper>
yeah, this would preclude the kernel driver from doing LFC transparently
<LaserEyess>
09:54 < kennylevinsen> and no one wants to see a 30Hz cursor movement on a 144Hz monitor :P
<LaserEyess>
fwiw, I disagree, as a user I assume that the cursor is secondary to any other content I have on the screen
<LaserEyess>
and yes my monitors/drivers are among the set that will just jerk the refresh rate from 48 Hz to 120 Hz upon the cursor moving once
<LaserEyess>
or more realistically, from 72 Hz to 120 Hz when watching 24 fps video content fullscreen, very annoying
rasterman has quit [Quit: Gettin' stinky!]
<MrCooper>
LaserEyess: that really sounds like you've never tried to move a cursor at 30 Hz :)
<LaserEyess>
I didn't say it should always be at 30 Hz, but the cursor should not be the driver for refresh rate over a video game, a web browser, or a video
<LaserEyess>
if I have a 144 Hz monitor and firefox is playing a youtube video at 60 fps, I don't want the cursor movement to make it change how the video is being presented
<MrCooper>
the cursor could trivially update at 120 Hz in that case
<MrCooper>
which I find noticeably smoother than 60
<MrCooper>
(on the Samsung G9, even the 240 Hz line on blur busters looks significantly smoother than the 120 Hz one :)
<LaserEyess>
yeah that could be one way to do it, personally I think I am not particularly caring what the cursor is doing if I have a video on one monitor
<LaserEyess>
if the cursor is on another monitor this is no issue since each updates individually
<LaserEyess>
I just never want it to interfere with how the video is rendering
<MrCooper>
sure
<MrCooper>
we're discussing how to get something better than either cursor always pushing to maximum refresh rate or falling back to the minimum one
<LaserEyess>
ah, I didn't get to that point in my scrollback
bodiccea has quit [Read error: Connection reset by peer]
bodiccea has joined #wayland
Narrat has joined #wayland
moa has quit [Ping timeout: 480 seconds]
bluebugs has joined #wayland
rasterman has joined #wayland
radu242 has joined #wayland
pochu has quit [Quit: leaving]
jgrulich has quit [Ping timeout: 480 seconds]
ewryyyyyyyyyyyyyyyyyyyyyyyyyyd has quit [Remote host closed the connection]
sychill has quit [Ping timeout: 480 seconds]
boistordu has joined #wayland
pnowack has quit [Quit: pnowack]
fmuellner has quit [Ping timeout: 480 seconds]
boistordu has quit [Remote host closed the connection]
d42 has quit [Ping timeout: 480 seconds]
<doras>
MrCooper: I rebased my Mutter VRR branch on master locally. I still need to test it in games, but it generally seems to work in VRR scenarios. The event dispatch rate issue is solved, so hopefully FPS games won't stutter anymore. It probably requires some design review, and maybe deeper refactoring, but it should work pretty well otherwise.
pnowack has joined #wayland
<doras>
The cursor issue is present, obviously. It's annoying. I set a minimum refresh rate of 30Hz when cursor or other updates are pending, and you're right, cursor updates at 30Hz are a pretty bad experience.
<doras>
Setting the minimum update rate to the minimum refresh rate, which may be a bit higher on some monitors (48Hz-ish), will effectively break LFC when th cursor is moving due to atomic KMS's limitations.
boistordu has joined #wayland
<doras>
So it's quite an unfortunate degradation in the atomic API compared to legacy KMS. We have no good options here, only a handful of bad ones.
boistordu has quit []
___nick___ has quit [Ping timeout: 480 seconds]
boistordu has joined #wayland
mvlad has quit [Remote host closed the connection]
fmuellner has joined #wayland
cphealy has quit [Remote host closed the connection]