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
nazarewk[m] has joined #wayland
hex[m]1 has joined #wayland
nerdopolis has joined #wayland
Moprius has quit [Quit: bye]
fmuellner has joined #wayland
columbarius has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
nyah has quit [Ping timeout: 480 seconds]
silverdev2482 has quit [Ping timeout: 480 seconds]
fmuellner has quit []
fmuellner has joined #wayland
silverdev2482 has joined #wayland
Brainium has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
zvarde1988 has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
zvarde198 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
slattann has joined #wayland
slattann has quit [Read error: Connection reset by peer]
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
manuel_ has joined #wayland
Company has quit [Quit: Leaving]
fmuellner has joined #wayland
naveenk2 has joined #wayland
jgrulich has joined #wayland
tzimmermann has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
zvarde19883 has joined #wayland
zvarde1988 has quit [Ping timeout: 480 seconds]
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
astlep has joined #wayland
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
manuel_ has quit [Ping timeout: 480 seconds]
ahartmetz has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
rv1sr has joined #wayland
eroux has quit [Remote host closed the connection]
rasterman has joined #wayland
eroux has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
hardening has joined #wayland
manuel_ has joined #wayland
naveenk2 has quit [Read error: Connection reset by peer]
fahien has joined #wayland
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
fmuellner has quit [Remote host closed the connection]
<LaserEyess>
oops, sorry, shoudl have explained. The main issue is that blocking on frame callbacks breaks a lot of software that people have 0 control over fixing
<emersion>
you mean X11 software?
<LaserEyess>
yes, or by extension any proprietary software that cannot be updated
<LaserEyess>
emersion: any video game played through proton/wine and hidden
<LaserEyess>
so it looks like there's a complicated set of problems that need to be figured out and solved before this can move forward
<emersion>
these use Mesa's WSI, and go through regular Xwayland
<emersion>
so nothing unfixable
<emersion>
but yeah we can't rewrite bad game loops
<LaserEyess>
right, and there are other programs that badly want some way to render separately to frame callbacks
<LaserEyess>
for example mpv
<emersion>
nothing stops you from rendering at any time you want
<LaserEyess>
I know the answer to that in particular is: "they should do it the Right Way™"
<LaserEyess>
right now mpv has complicated logic to figure out if it's hidden
<emersion>
at the protocol level at least
<emersion>
the wl_surface.frame event is provided as a way to throttle redraws
<emersion>
your particular issue is that Mesa's WSI blocks on frame callbacks
<emersion>
which can be disabled with the EGL interval?
<emersion>
but iirc setting that interval to 0 was difficult for mpv?
<LaserEyess>
I'm not sure about the details of that, I'd have to ask Dudemanguy
<LaserEyess>
I think the core issue is that mpv wants to render as efficiently as possible, which means using the EGL swap thing, but they don't want the rendering timing to be dependent on the compositor
<LaserEyess>
because in mpv's opinions they're in a much better position to decide when to render
<kennylevinsen>
not sure how big an issue it is for gameloops, based on the entire hatred for vsync. It's mainly normal applications that resorted to swap interval 1 for throttling.
<LaserEyess>
idk, this is beyond me, but back to the broken games that will never be fixed, I think surface suspension sounds like an incredible elegant fix
<LaserEyess>
or alternate-presentation timeing (which would bring other benefits like VRR intervals)
<LaserEyess>
but it seems to be stuck on what to do about sub-surfaces
<LaserEyess>
do I have this right, at the high level?
<kennylevinsen>
oh *hidden* games that do bonkers things, right. Wasn't thinking about those.
<emersion>
i'm not sure about the blocker. the sub-surface thing doesn't seem to block anything?
<LaserEyess>
and then after reading #266 and looking at !26 it seems to not be the easiest problem to solve
<emersion>
at any rate, that proposal is trying to solve all porblems at the same time, which makes it especially complicated to review
<LaserEyess>
right
<LaserEyess>
so that leads me into my next question: wayland-protocols seem to take a "get it right the first time because we'll have to support it for a long time" approach with a lot of these protocols
<LaserEyess>
hence !103 has a lot of iterations and deep discussion
<LaserEyess>
but !99 seems really, really simple
<emersion>
i am not sure !99 is what you're looking for
<emersion>
the suspension can fire 1min after the surface is invisible
<emersion>
or any amount of time, based on compositor policy
<emersion>
the suspension can be costly, because it asks the client to de-allocate buffers, so the compositor might want to debounce the suspension events
<kennylevinsen>
and I guess the way this "fixes" games is by allowing them to fake a vsync timer when they're in the background?
<LaserEyess>
it's not only compositor policy though, clients can choose how to interact with this
<LaserEyess>
and in particular mesa would figure this out for games
<kennylevinsen>
they can't choose what the compositor policy is though, so if the compositor can wait 1 min then they just have to deal with no frame callbacks *and* no suspend for 1 min. How long do the games in question have before they freak out about blocked swap buffer/anti-cheat/whatever?
<LaserEyess>
and costly is relative here, there are games that completely break
<emersion>
what you want this protocol to do is not what this protocol does, LaserEyess
<emersion>
game goes in the background
<emersion>
game doesn't know about it until 5min later
<emersion>
it = suspension
<LaserEyess>
ok, so what I want is this exact protocol, but with the stipulation that compositors must send these events "immediately"?
<LaserEyess>
if there was a compositor with the policy to do that, then surely this protocol *would* be what I want, no?
<LaserEyess>
I'm confused by the distinction here
<emersion>
what you want is a visibility event
<LaserEyess>
hm
Moprius has quit [Quit: bye]
<LaserEyess>
ok, so even !103 doesn't have this then
<LaserEyess>
it also doesn't seem to have a "resume" event
<LaserEyess>
oh, nevermind, if the event is sent again it means resume, should have read...
<kennylevinsen>
am I correct in that this is going to power a (hopefully non-default) backup timer in mesa for unblocking swap?
<kennylevinsen>
if so, considering that it will be ugly and non-default anyhow, why not just have some long bogus timer fallback?
<LaserEyess>
that's what mpv does
<LaserEyess>
but is that really proper to implement in mesa?
<LaserEyess>
even as a fallback?
<emersion>
xwayland has a 1s fallback timer, fwiw
<kennylevinsen>
well, a synethetic timer is wrong regardless, so I just wonder how much machinery we want to power something that is broken by design :/
<LaserEyess>
honestly the implementation details of this are beyond me, I'm afraid
<kennylevinsen>
as long as it is non-default, arguing over nuances in "broken" seems silly in my opinion :P
<LaserEyess>
I just know that the problem is, fundamentally: when things don't receive frame callbacks they can break
<LaserEyess>
I don't really even know why, but it's just a fact
<kennylevinsen>
ah, no - frame callbacks is purely wayland, so anything that breaks without frame callbacks is defective
<LaserEyess>
alright, clearly my terminology is bad here
<kennylevinsen>
but things relying on mesa WSI's swap buffer with an interval 1 - which roughly means "block if a frame was already submitted until next time vblank" - get rather upset that swap buffers can block indefinitely on wayland
<LaserEyess>
yes, that, whatever that mechanism is
<LaserEyess>
a lot of software is not designed to work like that, some of the software can be fixed, some cannot
<LaserEyess>
some don't want to fix it, they want alternate behavior for whatever reason
<kennylevinsen>
so the bug is either in clients making the assumption that it can't block, or mesa's WSI for allowing it to block
pac85 has joined #wayland
<LaserEyess>
probably a little of both
<LaserEyess>
idk how to solve this, it just looks to me like people have been trying to solve it and getting stuck somewhere
<LaserEyess>
I'm curious where exactly, beyond "it's a hard problem to solve while keeping backwards compatibility"
<pac85>
Doesn't vulkan allow to specify a timeout? How is that handled?
<kennylevinsen>
I would assume it's just lack of volunteer interest, with more interesting problems to solve.
<LaserEyess>
I'm also interested in !103, I see that as an interesting problem to solve, personally
Guest6943 has quit []
<LaserEyess>
but yes it's a big protocol and touches a lot of stuff and is probably super complicated to implement
DragoonAethis has joined #wayland
<LaserEyess>
I still think programs like mpv can make better decisions about things if they know that a) vrr is active, and b) what the bounds are
<LaserEyess>
mpv has a lot of machinery for ensuring audio/video sync as well as repeating/interpolating frames
<LaserEyess>
right now you can fake vrr "awareness" by just saying "don't care about display timing, just time it to audio and render frames whenever you want"
<LaserEyess>
it works surprisingly well, but you have to know when vrr is active for the surface, which mpv cannot know
<LaserEyess>
personally I just have a lua script that assumes vrr when fullscreened, and then does display-sync when the video is not fullscreen
<kennylevinsen>
yeah was about to say that even with VRR you'll need to deal with whatever display timings you get when there are other clients :P
<LaserEyess>
anyway, my ramblings aside, that also still seems to be blocked by how to get thigns to work with subsurfaces, and that somehow relates to #266 (maybe), so that part I'm curious about
<MrCooper>
LaserEyess: "mesa would figure this out for games", how could Mesa automagically figure out what's right for a particular game?
<kennylevinsen>
followed by MESA_THAT_DIDNT_HELP_TRY_SOMETHING_ELSE=1, which is followed by ...
<LaserEyess>
MrCooper: that's not what I meant, I meant an individual game would not have to figure this out or be patched, but rather mesa itself would be able to use that protocol to fix "all" games
<LaserEyess>
kennylevinsen: honestly I would put MESA_THIS_GAME_IS_BROKEN=1 in my env permanently...
<MrCooper>
LaserEyess: as for mpv, even if it gets VRR related information from the compositor, it'll still need to constantly measure the effective timings and adjust its rendering/presentation timing accordingly, just as now
<kennylevinsen>
while I would banish it to the shadow realm - I would not want this behavior to be default
<kennylevinsen>
(but acknowledge its necessity)
<LaserEyess>
games that Do The Right Thing™ wouldn't really be affected by this, only games that will crash/break will be
<LaserEyess>
though, maybe I'm not thinking this through, I'm not sure
<emersion>
i don't thing VRR needs to be such a special case
<emersion>
think*
<emersion>
kennylevinsen: mesa can ahev per-game settings via driconf, fwiw
<emersion>
already used to fix some games
<MrCooper>
for one thing, Mesa can't do anything with a Wayland protocol for apps running via Xwayland
<emersion>
indeed, and that's the common case
<kennylevinsen>
LaserEyess: for games that aren't broken, it's better that they freeze on swap buffer when hidden. This is far more power efficient.
<kennylevinsen>
it only makes sense to undo that behavior if the game can't handle it
jmdaemon has quit [Ping timeout: 480 seconds]
<kennylevinsen>
emersion: ah okay
<LaserEyess>
MrCooper: mpv can still make better decisions about how to render if it knows if vrr is active. You're correct that it still needs to do it's own timing and presentation properly, but it already has the capabilities to do that, it just needs more hints
<LaserEyess>
right now I give it a hint via my lua script, and mpv performs better because of it
<kennylevinsen>
well, it can make better decisions if it knows VRR is active, and is the only VRR client and thus can control the timing
<LaserEyess>
yes, correct
<emersion>
this is not true in the general case
<emersion>
even in fullscreen
<LaserEyess>
it may not be true in the general case but it is true for video players like mpv
<LaserEyess>
anyway we're talking about two separate things at this point
<MrCooper>
cursor updates and LFC are monkey wrenches messing up that simple world
<kennylevinsen>
I think emersion meant that the criteria isn't met in the general case for this to be true for mpv
<LaserEyess>
as for games being on Xwayland, that's true, but xwayland is the client here so mesa would give this suspension feedback to xwayland, no?
<kennylevinsen>
and that the case where mpv can benefit is an exception
<kennylevinsen>
LaserEyess: wrong way around, for X games, mesa's X wsi is a client of Xwayland which is a client of Wayland. Xwayland has to be the one pretending nothing has changed, as mesa doesn't know it's not on real x.
<MrCooper>
LaserEyess: and what would Xwayland do with it? It already has a fallback timer which fires if there's no frame event in 1 second
<emersion>
LaserEyess: what if a notification pops up?
<emersion>
over the video
<emersion>
what if there's a chat overlay?
<emersion>
and so on
<kennylevinsen>
X games: game -> egl -> mesa's EGL WSI for X -> xwayland -> wayland compositor, wayland games: game -> egl -> mesa's EGL WSI for Wayland -> wayland compositor
<LaserEyess>
alright, so what I'm getting from this is that games that aren't ported to native wayland, where their render loops get completely broken by blocking, are just completely broken on wayland and will be forever?
<LaserEyess>
what am I missing here? that can't be right
<LaserEyess>
emersion: better scenario: what if the mouse moves?
<LaserEyess>
yes I know it isn't perfect
<emersion>
only a few games break to my knowledge
<LaserEyess>
I'm not saying !103 is perfect, I'm saying a client knowing more about VRR is better
<kennylevinsen>
I think 103 was also about giving better information about latch timings
<emersion>
online games getting disconnected because of a timer was one case
<MrCooper>
LaserEyess: games which aren't ported to Wayland get Xwayland's 1s fallback timer; hidden games can fall back to 1 Hz even with Xorg, at least with some drivers
<kennylevinsen>
with the problem being that presentation feedback only tells you when it was presented, not when the buffer was latched by the compositor
<LaserEyess>
MrCooper: there are games that break because of this, this is how I started looking into this, because people I recommended wayland to had to switch back to xorg because software they used was broken
<emersion>
i don't think "knowing more about VRR" is necessarily a good thing, it depends how the client uses the info, and it seems in that case mpv would use that info badly
<emersion>
it all depends how the info is exposed and used
<LaserEyess>
how would mpv use it badly?
<emersion>
by assuming it completely controls the VRR screen, for instance
<MrCooper>
LaserEyess: I'm pointing out those games would break exactly the same on Xorg with some drivers
<kennylevinsen>
LaserEyess: With the workaround goggles on, maybe changing the 1Hz fallback timer to something faster would work
<kennylevinsen>
could maybe be combined with something gamescope-esque that configures that
<LaserEyess>
MrCooper: well my scenario is this: a game works properly on Xorg but not on wayland, the user blames wayland and in this case they are correct
<kennylevinsen>
it should be fast enough that games don't freak out, without being fast enough to not trip randomly
<LaserEyess>
emersion: mpv doesn't need to assume that and again I'm not sayin !103 is the perfect solution to communicating VRR status to a client
<MrCooper>
kennylevinsen: wasting energy for the vast majority of apps, to avoid issues with a tiny minority of broken apps? Sounds like a bad trade-off to me
<LaserEyess>
right now *my* lua script makes that assumption for *my* usecases with fullscreen mpv on sway, but obviously that's not ideal
<LaserEyess>
properly implementing this in mpv would certainly not be "fullscreen == VRR"
<MrCooper>
LaserEyess: you keep ignoring the part where the same thing can happen with Xorg as well :(
<kennylevinsen>
MrCooper: duh - I personally want that 1Hz timer to be 0Hz - but when I said gamescope-esque thing I meant a nested game compostor that could use its own Xwayland instance with faster fallback
<kennylevinsen>
or just a local hack on their own xwayland
<LaserEyess>
MrCooper: it does, and that makes people go back to windows
<LaserEyess>
in each scenario you are regressing
<MrCooper>
oh boy, now the goal posts have moved to another OS
<LaserEyess>
I don't want people to feel like "wayland isn't ready", but unfortunately if a popular game breaks on wayland, people think wayland isn't ready
<LaserEyess>
my goalposts are pretty simple: things that work on Xorg should transparently work on wayland
<LaserEyess>
if it's broken on wayland *and* xorg that's fine because wayland has feature parity :)
<kennylevinsen>
LaserEyess: We're already discussing multiple problems and PRs right now. Throwing "linux desktop isn't ready yet" onto the fire isn't very productive. :)
<kennylevinsen>
let's keep the discussion to "improve wayland and/or xwayland", not "make people change from other OS's"
<kennylevinsen>
(or retain them for that matter)
<LaserEyess>
well that's why I don't want to get into that conversation, the scope of this is simple: if software does not break on Xorg it should not break on wayland
<MrCooper>
99.9...% of X11 apps work perfectly with Xwayland, but it'll never be 100%
<kennylevinsen>
yes, and that's a fair-ish assumption.
<LaserEyess>
MrCooper: if the .1% is something that 50% of wayland users want to use though?
<LaserEyess>
(yes that's hyperbolic, but something like a popular game is a big deal)
<LaserEyess>
I think this was dark souls btw
nyah has joined #wayland
<swick>
frame scheduling and I missed it :(
<kennylevinsen>
it could be 0.1% of users, it could be 99% of users, we don't know so it's a rather pointless argument
<MrCooper>
LaserEyess: the only reason it didn't happen with Xorg is because the Xorg driver you tested with keeps *all* hidden apps running at full frame rate, which is arguably a bug
<kennylevinsen>
swick: you should've gotten a ping though :P
<swick>
was busy
<LaserEyess>
MrCooper: bugs that programs rely on become features :/
<kennylevinsen>
swick: tbf, it was a very light touch of the VRR topic in between a bunch of other topics
<dottedmag>
LaserEyess: Hyrum's Law
<swick>
soooo, the suspension protocol solves exactly the class of issues that the xwayland 1hz fallback timer also solves
<swick>
and we could implement a 1hz fallback timer in the vulkan wayland WSI as well
<swick>
nobody did that
<emersion>
i don't think people have been complaining about the vulkan wayland WSI today
<emersion>
it's strictly about Mesa's X11 WSI
<LaserEyess>
kennylevinsen: I am also interested in !103, originally though I brought it up because it implemented what !99 implemented
<swick>
emersion: wait, is anyone talking about x11 here?
<swick>
pretty sure we could do the same 1hz fallback timer in wayland EGL but I don't know because I try to stay away from GL
<LaserEyess>
swick: the only discussion about x11 is "this works on X11 but not on Xwayland"
<LaserEyess>
and that's it
<LaserEyess>
this = the game
<emersion>
games use X11, so
<swick>
I see, so we're talking about the cases where the fallback timer is not enough
<emersion>
i'm not sure at this point
silverdev2482 has quit [Ping timeout: 480 seconds]
<emersion>
some mpv (Mesa Wayland EGL WSI) issues were mentionned as well
<LaserEyess>
in this case the behavior is as follows: 1) game is hidden, 2) 1s fallback happens, 3) game thinks it's "idle" and disconnects the user
<LaserEyess>
emersion: ignore that then, mpv is just an example of a client I know the most about
<swick>
right, that's where the suspension protocol doesn't help either
<swick>
it would be completely valid for the compositor to not send the suspension event and throttle to 1hz itself
<swick>
and then you have the same problem again
<emersion>
i think this should just be a game workaround in mesa, enabled via driconf
<emersion>
(this = a faster timer)
<swick>
there is effectively two classes of problems: 1. apps which have a problem if they are blocked for too long (multiple seconds), and 2. apps which have a problem when they don't run at a constant frequency
<swick>
and the constant frequency stuff is just completely incompatible with waylands frame callback mechanism
<swick>
whereas the first problem can be solved with the 1hz fallback timer
<emersion>
LaserEyess: which game are you talking about specifically?
<LaserEyess>
let me double check
<kennylevinsen>
I wonder if these games just have a lower threshold for "blocked", and need e.g. 5 or 10Hz fallback...
<MrCooper>
games which require constant refresh rate will break with all Xorg drivers during DPMS off I think
<swick>
kennylevinsen: there are some which crap out of the frequency is variable in any way but there certainly will be some where the fallback timer frequency will always be too low
jgrulich has quit [Ping timeout: 480 seconds]
<LaserEyess>
emersion: regardless of what game it is, I think I have my answer: no surface suspension can't do anything more than the 1s fallback can
<LaserEyess>
oh well
<LaserEyess>
though, potentially for wayland native games it could work? idk
<LaserEyess>
not like those exist for the most part
<emersion>
there are no wayland native games ;)
<kennylevinsen>
if there were, they would also be written with wayland in mind so the problem wouldn't exist :P
<swick>
MrCooper: yeah, the point here is just that if we give clients enough tools they can implement their own constant frequency swapchain and e.g. proton will then fix those windows games
<i509VCB>
Some of the games using winit are though as winit implements a wayland backend. Although winit is somewhat designed around wayland being weird, but that still leaves egl/vulkan to do the right thing
<LaserEyess>
kennylevinsen: in talking with other people about this, their issue is that using an EGL swap interval of 1 only blocks on wayland, and that "every other platform" it doesn't
<emersion>
kennylevinsen: not necessarily: SDL, glfw, etc
<LaserEyess>
I am paraphrasing and I definitely don't understand what that means, but that was what I was told
<swick>
LaserEyess: the problem is that the people you're paraphrasing also don't understand what that means
<swick>
it is an insufficient problem description
<swick>
like I said, there is essentially the two classes of problems
<kennylevinsen>
emersion: I guess it depends on the definition of "wayland native"
<swick>
and solving one is easily done in the WSI/EGL and the other will require a lot of wayland protocol work
<emersion>
for me, it's "uses the Wayland protocol" :P
<emersion>
(directly, not via Xwayland)
<LaserEyess>
well, then any game that uses SDL is "wayland native" (though quite a few break when trying them with wayland...)
<i509VCB>
I'd assume "speaks Wayland protocol" is effectively wayland native
<LaserEyess>
I assume that measn their vendored SDL is broken
<LaserEyess>
not necessarily the game
zebrag has joined #wayland
<kchibisov>
The problem with waylands frame scheduling is that there's nothing like that on any other platform. So it's hard to tell those games to do the right thing since the libraries they are using are not exposing anything like that .
<emersion>
the web has something similar
<emersion>
requestAnimationFrame()
<kennylevinsen>
emersion: so indirectly through something else down the chain except if that thing is Xwayland? gotcha. :P
<kennylevinsen>
oh I hate requestAnimationFrame so much
<LaserEyess>
swick: WSI/EGL in this case would be handling the lack of frame callbacks more gracefully?
danvet has joined #wayland
<kchibisov>
yes and I think only winit has webasm platform. Not glfw.
<kchibisov>
And I'm sure most games targen desktop platforms,
<kchibisov>
target*
<emersion>
at any rate, nothing stops a wayland client from not using wl_surface.frame, and instead use a timer (even if that's a terrible choice)
<kennylevinsen>
LaserEyess: I think it would still be an interesting experiment to change the 1hz timer and see when the games work
<kchibisov>
And that's how it's done in most games, you have timer based rendering and vsync.
<kennylevinsen>
while a local hack, it would discover what is needed to make those games work
<LaserEyess>
kennylevinsen: interesting idea, I assume that is in no way configurable at runtime?
<kennylevinsen>
the final timer hack could be in mesa, or as I mentioned earlier maybe some gamescope thing with its own xwayland
<emersion>
gamescope should already be enough to "fix" the games
<emersion>
it has its own timer
<LaserEyess>
hm
<LaserEyess>
maybe I'll just tell my friend to use that
<swick>
LaserEyess: not sure what you mean with more gracefully, it would not trigger bugs in apps which need forward progress but not for apps which need a constant frequency
<kchibisov>
emersion: the problem is telling games to use method M just on Wayland, since my point is that you can't create anything like frame callbacks on other platforms just with the help of display server.
<kennylevinsen>
emersion: then... why are we not just telling people to use that
<emersion>
kchibisov: you can on X11 at least…
<kchibisov>
emersion: what should be used their?
<LaserEyess>
swick: all I know is this, a very limited niche example from a program I know well: mpv wants vsync, and they want to control their own timing. The problem is the vsync will block without a frame callback (if the surface is hidden, for example). Mpv works around this by a couple of constantly-tweaked hueristics, but it would really just like to know when to not render
<kchibisov>
I know that most applications(chromium) that do care about that are using the GL extension.
<emersion>
kchibisov: PresentCompleteNotify
<LaserEyess>
I think internally mpv implements something like the 1s fallback
<emersion>
tells you when a frame is presented on screen, should be enough to emulate wl_surface.frame
<LaserEyess>
but 1s is an eternity for audio timing so it does other things as well
<emersion>
but that's "owned" by the GL/Vulkan WSI in general
<emersion>
ie, if you use the GL/Vulkan WSI, you can't use that ext directly, you need a GL/Vulkan ext, which doesn't really exist
<swick>
LaserEyess: they should use the present timing protocol and use frame callbacks just to figure out if they should throttle or not
<swick>
mpv is an example if wanting to force the world to adapt to you rather than you adapting to the world
<LaserEyess>
mpv does use present-timing, I think that's part of the hueristic
<swick>
they have a design which works for windows and then constantly complain when another platform requires a different design
<LaserEyess>
mpv has to support no less than 4 OSes and no less than 5 different window systems
<swick>
so I generally don't care about what they say
<LaserEyess>
wayland is the only one where their rendering paradigm doesn't work
<kchibisov>
emersion: thx. I think you can't find it unless you know what you're looking for.
<LaserEyess>
¯\_(ツ)_/¯
<kennylevinsen>
LaserEyess: just a note: nothing in wayland blocks. Frame callbacks are hints, and you can submit stuff whenever and as fast as you'd like. The blocking often referred to is implemented in mesa's EGL WSI, as eglSwapBuffers with swap interval of 1 is *meant* to block (just not indefinitely)
<LaserEyess>
but it does block indefinitely
<swick>
what is idenfinitely anyway
<LaserEyess>
under certain circumstances
<LaserEyess>
swick: if the surface is hidden
<swick>
yeah, but eventually the surface is destroyed or shown, so it's not indefinite
<LaserEyess>
indefinite means for an undertermined amount of time
<LaserEyess>
I didn't say it blocked forever
<swick>
oh
<swick>
nvm then haha
<kennylevinsen>
point is: clients using wl_surface_attach/wl_surface_commit themselves do not block, so "wayland blocks" isn't true
danvet has quit [Ping timeout: 480 seconds]
<LaserEyess>
alright then, so maybe the mesa WSI/EGL stuff for wayland needs work
<kennylevinsen>
mesa egl wsi blocks on its own accord to implement a required behavior (in a new variation)
<LaserEyess>
this is now, once again, well beyond my knowledge on the topic :')
<kchibisov>
Since my experience is based on how browsers do implement the requestAnimationFrame. On Wayland they use frame callbacks, with X11 and Windows they use GL extension to compute the next frame based on the previos vblank, and on macOS they use DisplayLink api.
<kennylevinsen>
that's fair, but having the right assignment of blame is important - if it was wayland itself that blocked then it did have other consequences, e.g. there being no other way. :)
<kennylevinsen>
for native wayland clients, this is all optional after all
<kchibisov>
emersion: I guess to emulate frame callbacks you need to suppress the PresentNotify unless the user ask for a frame?
<emersion>
hm, what do you mean?
<LaserEyess>
well, when I say "wayland", I mean that when using a wayland compositor this behavior exists, whereas when using Xorg it does not
<LaserEyess>
yes, there's clearly a lot more going on, but still
<emersion>
kchibisov: how does the DisplayLink API work?
<LaserEyess>
and since I seemingly started a good discussion, I woudl like to ask questions about !103
<kennylevinsen>
that's probably a question for swick then :P
<LaserEyess>
in particular the fact that it combines the suspension event, as well as the tearing updates stuff, as well as improving on present-timing
<LaserEyess>
it seems like it's a very good protocol, but stalled on figuring out some hard issues
<kchibisov>
emersion: it tells you when the last frame was displayed.
<LaserEyess>
I've read the protocol and more importantly the discussions but I'm wondering if anyone has done further work on it behind the scenes, like the CM/HDR stuff is mostly worked on outside of w-p
<emersion>
kchibisov: so, kind of like wayland's presentation-time?
<kchibisov>
I think so, yes.
<kennylevinsen>
LaserEyess: the bug about when subsurfaces obscure the parent is manily a tricky definition question. All suggestions are strictly valid, someone needs to draw the line, and depending on where it is drawn some clients might need new protocols for convenience...
<kennylevinsen>
(some clients = very specifically firefox because of what I'd personally call borderilne abuse of gtk)
<kchibisov>
Yes.
<swick>
LaserEyess: short answer: no
<LaserEyess>
and the main problem there is that wl_surface.frame has no real concept of subsurfaces?
<kchibisov>
On how to use it I'd suggest to look into chromium.
<emersion>
"the system calls the selector on the target when the screen’s contents need to update"
<kennylevinsen>
LaserEyess: wl_surface.frame works perfectly fine with subsurfaces
<emersion>
sounds very similar to wl_surface.frame?
<kennylevinsen>
The problem is that when subsurfaces obscure their parent, their parent is no longer visible and thus no longer receive get frame callbacks.
<LaserEyess>
right...
<LaserEyess>
and there's no way to know if you're suspended
<kennylevinsen>
so now you need to subscribe from the subsurface itself, which is perfectly valid
<kchibisov>
emersion: actually yes.
<kennylevinsen>
but for something like firefox that is subsurfaces all the way down this is somewhat annoying
<swick>
there also is the whole (lack of) swapchain issue
<kennylevinsen>
and for subsurface tiles, if if part of your monitor is on a different display, tiles might (correctly) get frame callbacks at different times...
<LaserEyess>
(as an aside, another huge thing peopel say they won't switch to wayland for is the lack of tearing updates, even 1 frame of latency is unacceptable for a lot of gamers, so again !103 in my mind solves some real issues people ahve right now)
<swick>
gtg will read the backlog later
<kennylevinsen>
But the entire subsurface thing for firefox is a side-effect of trying to use Gtk to handle windows but not for content, so a real gtk surface with content exists *under* every firefox content-bearing surface. Every parent surface is obscured by default.
<kchibisov>
emersion: but I have no clue how to do something like that on Windows.
<kennylevinsen>
(IIRC, the underlying gtk surface even activately renders focus animation of its background like normal gtk apps while all this is happening, you just never see it.)
<kchibisov>
Though it means that I can add frame scheduling for like 4 platforms inside the winit directly, so the winit based games can use it.
<kennylevinsen>
(I think I tried getting rid of those subsurfaces at some point, but it didn't work as gtk rendered to the parent occasionally.)
<kchibisov>
I knew about macOs before, but forgot how it worked, and haven't known anything about X11, since I've used browsers as the source of truth for frame scheduling approaches and they use GL extension.
<kennylevinsen>
LaserEyess: so yeah, it's mostly a firefox issue, a question of whether we redefine how frame callbacks work or maybe make a protocol to help firefox.
<kennylevinsen>
all in all to work around firefox fighting against gtk
<LaserEyess>
so for !103, it's really just "make a choice and stick with it" for how subsurfaces should be handled
<kennylevinsen>
well that choice should be made in the subsurface issue in my opinion, and !103 should follow that for consistency
<LaserEyess>
also, if subsurfaces aren't part of the core protocol, can't you just update the protocol that defines those subsurfaces?
<kennylevinsen>
yes, but right now all surface types follow wl_surface's definition of surface frame callbacks
<LaserEyess>
ah, so special casing would be bad then
<LaserEyess>
or, hacky, I guess
<kennylevinsen>
yeah, it would be ugly
<LaserEyess>
alright, I guess that makes sense
<kennylevinsen>
and the current behavior is correct but inconvenient for firefox specifically (don't know if anyone else have this issue)
<LaserEyess>
is this why firefox always breaks on sway
<davidre>
subsurface are part of the core protocol (if you mean wayland.xml with that)
<kennylevinsen>
firefox break on sway?
<LaserEyess>
kennylevinsen: all the time, yes
<kennylevinsen>
I think the issue was actually about Mutter being more aggressive about throttling frame callbacks and so this broke on gnome :P
<LaserEyess>
ok so that's unrelated
<kennylevinsen>
idk, I use firefox all the time on sway, the only problem I tend to experience is that plugin popups sometimes get a little wierd
<LaserEyess>
yes, that's most of my issue as well
<LaserEyess>
menus and popups sometimes don't work in strange ways
<kennylevinsen>
I switched to my own compositor using wlr_scene recently-ish. Might get better when the wlr_scene sway PR gets in.
fahien has joined #wayland
<kennylevinsen>
it's either that or a recent nightly release that made it better, dunno and too lazy to bisect :)
<LaserEyess>
well I mean going back for a couple years now
<LaserEyess>
it goes back and forth, getting fixed in one version, breaking the next, fixed in the version after, etc.
<LaserEyess>
usually it just works
<kennylevinsen>
well, you can assign a lot of firefox's weird buggy behavior to fighting Gtk
<kennylevinsen>
even if it's not this specific subsurface frame callback issue, fighting gtk makes things rather annoying internally
<kennylevinsen>
a lot of weird races
<kennylevinsen>
but either a recent nightly or our wlr_scene made things better I think
<LaserEyess>
well I'm not using wlr_scene on sway so that can't be it
<LaserEyess>
but yes 103 has been pretty good so far
Guest6959 is now known as DemiMarie
<DemiMarie>
GTK appears to be extremely unfriendly to anyone who is doing mostly their own rendering.
<kennylevinsen>
gtk3 is not made to hand over complete surface control, no
<kennylevinsen>
it expects you to play ball and hand it content using its api's
<DemiMarie>
gtk4 is not made for that either, which I found very annoying when considering future ideas for Qubes OS.
<kennylevinsen>
but these hacks are not great, either get a change to gtk to allow this upstreamed or don't do it
<kennylevinsen>
i don't like chromium at all, but its windowing code is a heck of a lot prettier as a result of not trying to hack gui frameworks
<DemiMarie>
Does it just do everything itself?
<kennylevinsen>
yup, i thas an internal "toolkit" (ozone) for dealing with window management, but that's it
pac85 has quit [Read error: Connection reset by peer]
pac85 has joined #wayland
<DemiMarie>
What I want is a way to get a window with colorable and accessible client-side decorations.
<kennylevinsen>
that's why chromium never tries to look native
pac85 has quit [Read error: Connection reset by peer]
<DemiMarie>
ozone even supports rendering directly to a display, with no window system at all.
<DemiMarie>
on ChromiumOS, ozone is the window system
<ifreund>
really? where do their chromium wayland protocols come into play then?
<kennylevinsen>
they have a wayland compositor in there somewhere
<ifreund>
or are they how the ozone based compositor talks to the ozone based windows?
pac85 has joined #wayland
<MrCooper>
LaserEyess: it sounds like mpv may want to use eglSwapInterval 0 plus its own frame event handling to know when it should draw a new frame
<LaserEyess>
mpv wants to vsync, and I think that means eglSwapInterval 1
<emersion>
nope
<LaserEyess>
well then I have no idea
<emersion>
but mpv internals are old and have an expectation for eglSwapInterval = 1
<MrCooper>
the closest to "vsync" is waiting for the frame event before attaching a new buffer
<LaserEyess>
I am not the right person to ask about this because at this point I can only say what I've been told by other people
<MrCooper>
which eglSwapInterval 1 does internally, but in a way which doesn't suit mpv
<MrCooper>
so mpv can do it on its own
<LaserEyess>
what I have been told multiple times is that if mpv had some event that said "this surface is hidden", the wayland code could drop a lot of code
<MrCooper>
LaserEyess: "I can only say what I've been told by other people" isn't a great basis for a technical discussion :)
<LaserEyess>
sure, which is why I can't have a technical discussion about this
zvarde19883 has quit []
<DemiMarie>
The “correct” solution is for mpv to be changed to use non-blocking window system interfaces.
zvarde19883 has joined #wayland
<MrCooper>
what was the last n pages of scrollback supposed to be then?
<DemiMarie>
And to decouple render scheduling from the main loop
<LaserEyess>
MrCooper: me asking questions about the status of various protocols and if they are designed to fix problems I know particular applications have
<LaserEyess>
I do appreciate the technical answers, but I cannot provide any technical discussion on how mpv's render loop works
manuel_ has quit []
ybogdano has joined #wayland
lxsameer has joined #wayland
<lxsameer>
hey folks, is there anything like Xephyr for wayland to test my compositor ?
<lxsameer>
I'm running X at the moment
<kennylevinsen>
does your compositor use an library like wlroots?
<kennylevinsen>
if so, the compositor can on its own run nested under Wayland or X11. No Xephyr needed.
<lxsameer>
kennylevinsen: yes i'm planning to use wlroots
<kennylevinsen>
then just start your compositor from an existing x11 or wayland session and you'll get a window with a nested instance of your compositor.
<lxsameer>
kennylevinsen: is it going to interfere with my current wm?
<kennylevinsen>
there are no wm's under wayland, only compositors. so no.
<lxsameer>
kennylevinsen: thank you
<DemiMarie>
I wonder if anyone has ever made a compositor that handles rendering itself, while delegating window management to a plugin API.
<kennylevinsen>
river?
<kennylevinsen>
my own also delegates layout decisions to an external process, but it is somewhat inflexible on purpose.
<lxsameer>
That's what i'm going to do as well
<kennylevinsen>
lxsameer: see if the river protocols fit your need, then you can share some layout logic
<lxsameer>
kennylevinsen: cool I will. but i want to leave the layout management to Emacs, my compositor will be a native module for emacs
<kennylevinsen>
o.O
<lxsameer>
I'm aiming to do a simple version of exwm on wayland
<kennylevinsen>
I have no idea what that is, but good luck. :)
<lxsameer>
kennylevinsen: thanks friend, It seems like a exciting journey
<soreau>
DemiMarie: wayfire might fit into this category
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
<DemiMarie>
lxsameer: Interesting! Will emacs itself render using that compositor?
<DemiMarie>
I *strongly* recommend having your compositor run on a separate thread and communicate using message passing. Emacs will often block its main thread due to a combination of bad Lisp code and poorly designed functions such as `shell-command`. Having the compositor run on a separate thread means that this will not hang the whole display, and it also prevents emacs and the compositor from deadlocking against each other.
<lxsameer>
DemiMarie: yes, I'm going to create the compositor as a native module so it will expose elisp functions to emacs and allow it to render windows depending on the layout
<DemiMarie>
How do you plan on interacting with Emacs’s existing rendering code?
<lxsameer>
DemiMarie: yeah i'm aware of that issue with emacs, my original plan is to leave the multithreading of the compositor to itself rather than Emacs
<lxsameer>
DemiMarie: I'm not sure yet I have to run some experiments but recently emacs community merge a branch for a pure gtk support which is wayland friendly
<lxsameer>
I have to look into it, but i'm at the first square at the moment
<daniels>
DemiMarie: pretty much every compositor framework delegates window management to a plugin API
<DemiMarie>
<lxsameer> "Demi: I'm not sure yet I have to..." <- GTK does not like to run inside a compositor. If you can change that so that GTK can be used by a compositor, that would be amazing, because there will almost certainly be other users of that. As is, though, you will need to have emacs connect to your compositor over a socket.
<DemiMarie>
daniels: I meant a compositor *binary* that handles window management via plugins. Something like how it is done with X11, though obviously with lots of different details.
<DemiMarie>
Basically, a compositor that expects people will write window managers for it.
<lxsameer>
DemiMarie: hmmm I have to look at the code in Emacs thank for the great tip
<daniels>
DemiMarie: the weston binary literally does this
<DemiMarie>
daniels: Oh, interesting! I was not aware of that.
<daniels>
libweston is a library that you can write frontends (handling configuration + WM + etc etc) for. the binary called 'weston' does a bunch of this, and loads a plugin to very specifically handle window management and chrome. there are three such plugins in tree.
<DemiMarie>
lxsameer: You’re welcome! I also would not be surprised if there are nasty circular dependencies at startup, where emacs expects the compositor will be available before it loads your plugin. It might be simpler to have your compositor (or an existing one, such as River) communicate with your compositor over IPC>
<ifreund>
lxsameer: fwiw river probably isn't flexible for you to implement that using it's layout protocol yet. I do intend to move as much window management policy as possible out of the compositor process eventually though, exposing it over some kind of "window management" wayland protocol
<ifreund>
but I'm pretty busy with other parts of my life right now, so there isn't currently active work happening there
<lxsameer>
DemiMarie: I've thought of that, the issue with that approach for me is that If I have to restart my compositor then I have to restart Emacs as well which personally will be hard for me, I often run emacs for like 6 month and I usually have around 400 open buffers (don't judge me :P)
<kennylevinsen>
unfortunately the river layout protocol wasn't quite flexible enough for my clay "container"... things :<
<lxsameer>
DemiMarie: but it would be easy to ask emacs to initialize the compositor before anything else
<kennylevinsen>
(I had it working, but the race between a container going away and a layout demand being met bugged me too much)
<kennylevinsen>
s/race/delay/
<lxsameer>
ifreund: are you the author of river ?
<DemiMarie>
lxsameer: I’m less worried about emacs than I am about you not applying kernel patches 😆
caveman has quit [Quit: caveman]
<ifreund>
lxsameer: yes
caveman has joined #wayland
mclasen_ has quit [Ping timeout: 480 seconds]
<lxsameer>
DemiMarie: :)) good one, I use kexec for that
<lxsameer>
ifreund: oh cool, I have to thank you actually, I watched your video and inspired to create my own compositor with zig
<ifreund>
glad you enjoyed it, some parts are probably a bit outdated now I guess :D
<lxsameer>
ifreund: still a great talk, cheers
sozuba has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
AndroUser2 has joined #wayland
mbolhuis has joined #wayland
pac85 has quit [Read error: No route to host]
AndroUser2 has quit [Read error: Connection reset by peer]
ybogdano is now known as Guest7020
ybogdano has joined #wayland
Guest7020 has quit [Ping timeout: 480 seconds]
mbolhuis has quit [Ping timeout: 480 seconds]
AndroUser2 has joined #wayland
tzimmermann has quit [Quit: Leaving]
MajorBiscuit has quit [Ping timeout: 480 seconds]
ybogdano is now known as Guest7022
ybogdano has joined #wayland
Guest7022 has quit [Ping timeout: 480 seconds]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
nyah has quit [Quit: leaving]
AndroUser2 has quit [Remote host closed the connection]
AndroUser2 has joined #wayland
lxsameer has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
TestingPlant has joined #wayland
AndroUser2 has quit [Remote host closed the connection]
TestingPlant has quit [Remote host closed the connection]
TestingPlant has joined #wayland
lxsameer has joined #wayland
sozuba has quit [Quit: sozuba]
nerdopolis has quit [Ping timeout: 480 seconds]
vuanonym has joined #wayland
vuanonym has left #wayland [#wayland]
wahfato has quit []
MajorBiscuit has joined #wayland
AndroUser2 has joined #wayland
AndroUser2 has quit [Read error: Connection reset by peer]
AndroUser2 has joined #wayland
danvet has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
AndroUser2 has quit [Remote host closed the connection]
mclasen_ has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
AndroUser2 has joined #wayland
AndroUser2 is now known as pac85
lxsameer has quit [Ping timeout: 480 seconds]
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
ybogdano has joined #wayland
silverdev2482 has joined #wayland
mvlad has quit [Quit: Leaving]
nerdopolis has joined #wayland
rv1sr has quit []
<LaserEyess>
swick: since you said you'd browse the backlog later I guess I'll just give you more questions. W.r.t !103 and the VRR stuff, especially with what clients can do with it, would there be any interest in a VRR specific protocol that defines under what circumstances a target application would "drive" the display?
<LaserEyess>
basically when playing videos or games, some clients should be preferred as "driving" clients, and I think limiting it fullscreen limits some potentially valid usecases
<kennylevinsen>
hmm, but if you have mpv "drive" VRR in non-fullscreen, and you play a 24fps video, would the output then be stuck at 48Hz (closest multiple) for all other user interactions?
<kennylevinsen>
there's definitely some clients that do *not* need to drive VRR though, e.g. my text editor's blinking caret
<LaserEyess>
oh of course not, which is why this would need to be combined with content hints
<i509VCB>
assuming a 60hz display, yeah that would be the limit. Otherwise a more fortunate user with a 120hz display would be fine
<kennylevinsen>
16k 1kHz displays whem
<LaserEyess>
kennylevinsen: I think in a lot of circumstances people would choose 48 Hz no-judder over 60 Hz 3:2 pulldown
<kennylevinsen>
no need to ever synchronize content, you just submit whenever
<LaserEyess>
now, of course, there are better ways to handle video playback on mpv's side
<LaserEyess>
but if there was a vrr protocol mpv could define some minimum refresh rate on the client side, so in the 144 Hz case it could play content at 120 Hz for example, instead of doing 6:5 pulldown
<kennylevinsen>
uh I honestly beg to differ, i suspect the majority of users would find looking at sub-60Hz everything else to be worse than 3:2 pulldown... But this is too subjective.
<kennylevinsen>
yeah at higher frequencies it's an easier argument
<LaserEyess>
idk every smart TV in existence has a default frame interpolation thing that looks like garbage but people like it
<LaserEyess>
but then again they like it because it's smooth so maybe that's a point toward your argument...
<emersion>
instead of "driving" the display, i'd prefer an ext to provide enough context/info to let the compositor do the right thing
<LaserEyess>
oh that would work too
<emersion>
e.g. "my content is meant to be displayed at 24Hz"
<LaserEyess>
yes
<emersion>
then the compositor uses VRR if available to just do that
<LaserEyess>
mpv obviously has that information, that would be simple
<LaserEyess>
well, lets extend that to *video players* have that, for some reason I can't stop thinking about this from mpv's perspective
<LaserEyess>
that would also (maybe) solve the isuse of what happens if 2 videos are playing at the same time
<LaserEyess>
but I think that gets too complex too quickly
<LaserEyess>
going for the LCM is an option, but lol
<kennylevinsen>
Unpopular opinion: cinematic framerates are completly bogus, randomly made up back when film was expensive in a time where nobody even remotely agreed on framerates, and we only keep using it because we're used to it despite it being objectively worse.
* kennylevinsen
wants high refresh movies to come back
<LaserEyess>
that's objectively true, but it is an objective fact that there is still near infinite amounts of content that will forever be 24 fps
<LaserEyess>
so we're stuck
* kennylevinsen
has mild motion interpolation on because seeing credits move at 24fps makes him cringe
<kennylevinsen>
why does the bot not retrieve usernames correctly for issues? :/
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
TestingPlant has quit [Ping timeout: 480 seconds]
hardening has quit [Ping timeout: 480 seconds]
TestingPlant has joined #wayland
ybogdano has quit [Ping timeout: 480 seconds]
<emersion>
the GitLab API changed a few years back iirc
<emersion>
and whatever SardemFF7 uses hasn't been updated
MajorBiscuit has quit [Ping timeout: 480 seconds]
TestingPlant has quit [Remote host closed the connection]
TestingPlant has joined #wayland
<kennylevinsen>
it's nice to see there still being traction on the fractional scale proposal, and we actually have a lot of implementations now
<i509VCB>
I did mention that v120 won't exactly work for displays which have 1600 in some dimension
<i509VCB>
There is an ultrawide 3840x1600 monitor that exists
<i509VCB>
1600x900 as well
<kennylevinsen>
at what scale?
<kennylevinsen>
for reference, wl_fixed is 1/256 which can't communicate 10ths
<kennylevinsen>
i.e. 110%, 120%, 130%... except 150%
<i509VCB>
Oh so it describes a percentage
<kennylevinsen>
yes, it's the scaling factor
<kennylevinsen>
wl_fixed's 1/256 has plenty of resolution but the steps are really annoying and its original author disowns it :P
<kennylevinsen>
although I'm also kind of "ugh" over the entire re-inventing the wheel thing
<kennylevinsen>
but hey, if the guy who made wl_fixed says "don't use wl_fixed", what can I do :)
<swick>
LaserEyess: the point of that protocol is to let clients tell the compositor which frequency they want to run at to let the compositor decide on a frequency for the display
<swick>
and then correctly communicate the chosen frequency and phase (deadlines) to clients
<swick>
a text editor would probably just not say anything while a video player and a game would both choose something
<swick>
if a video player wants 25hz and a game wants 60hz you might get 50hz or 100hz
TestingPlant has quit [Ping timeout: 480 seconds]
<swick>
and clients continously adjust their target framerate so a game might not be able to sustain the 100hz and the compositor might then lower to 50hz
<swick>
the key here is a closed loop of feedback and giving the compositor enough information to make sensible decisions
<swick>
as well as giving clients enough information to schedule frames with low latency to the correct time (while leaving the trade-off to clients)
MajorBiscuit has joined #wayland
<LaserEyess>
yes, I agree with all of that
<LaserEyess>
I'd love to see it a reality one day :')
<LaserEyess>
the only other thing I would say is that personally i never want the cursor to drive the refresh rate
<LaserEyess>
nor things like notifications and whatnot
<LaserEyess>
if the cursor is the only thing on the screen (i.e. nothing that's a game or a video or some other animation), then sure it can do whatever
<LaserEyess>
but if you a fullscreen 48 Hz (2x 24 fps video) running it shouldn't make it jump to 60 and introduce judder
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
<tleydxdy>
we need dominate surface vs submissive surface
ybogdano has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]
pac85 has joined #wayland
pac85 has quit [Remote host closed the connection]