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
immibis is now known as Guest506
immibis has joined #wayland
Guest506 has quit [Ping timeout: 480 seconds]
columbar1 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
silver has quit [Quit: One for all, all for One (2 Corinthians 5)]
silver has joined #wayland
nerdopolis has quit []
nerdopolis has joined #wayland
FLHerne_ has joined #wayland
FLHerne has quit [Read error: Connection reset by peer]
boistordu_ex has joined #wayland
<ishitatsuyuki>
if you use fractional scaling (125% etc) the advice is to not use any system facilities for that
<ishitatsuyuki>
unfortunately wayland fractional scaling is broken and you should use 100% scaling as the baseline and let the toolkit or application do the scaling through GDK_SCALE etc. or application settings
zebrag has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
zebrag has joined #wayland
zebrag has quit [Remote host closed the connection]
zebrag has joined #wayland
zebrag has quit [Remote host closed the connection]
emakar has quit [Remote host closed the connection]
dcz has joined #wayland
tzimmermann has joined #wayland
hardening has joined #wayland
jgrulich has joined #wayland
pnowack has joined #wayland
pnowack has quit [Remote host closed the connection]
pnowack has joined #wayland
ofourdan has quit [Quit: leaving]
ofourdan has joined #wayland
danvet has joined #wayland
pochu has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
audgirka has joined #wayland
kennylevinsen has quit [Remote host closed the connection]
kennylevinsen has joined #wayland
hegstal has joined #wayland
<pq>
psychon, an important question there is: what blocking Wayland roundtrips does Xwayland make? After all, the whole idea is to ensure that they can't deadlock.
<pq>
emersion, has anything actually changed wrt. that ^ in a long time?
<ofourdan>
there is one in drm lease
<ofourdan>
(not merged yet)
<emersion>
with a timeout
aleasto has joined #wayland
<ofourdan>
except that in the case of a deadlock I am not sure the callback timeoput will becalled, ever
<jadahl>
when does xwayland roundtrip when leasing?
<ofourdan>
to get the lease from the compositor
<pq>
did Xwayland ever use eglSwapBuffers() btw.?
<ofourdan>
ftr, I don't have irc history, so I don;t know what this is all qbout, I just replied the question "has anything actually changed wrt. that ^ in a long time?" because I remember drm lease did a busy loop waiting for the reply from the wayland compositor
<ofourdan>
pq: it does with eglstream
<jadahl>
ofourdan: it still does. thus it'll still dead lock if the compositor happens to do a sync request at that particular point in time, I suspect?
<ofourdan>
it stil ldoes, with a timeout, but as I mentioned I think a timeout might never be called in case of a deadlock
<pq>
ofourdan, so nothing to care about, good.
<jadahl>
yea, seems like it doesn't. xwl_screen_sync_events() needs a timeout parameter too
<ofourdan>
pq, it starts with your question, so that means there is no past context to your question then?
<pq>
jadahl, in general, what do you do after timing out through?
<pq>
ofourdan, yes there is, in a previous day
<jadahl>
pq: assume the lease failed or something?
<ofourdan>
ah, that's what I am missing
<jadahl>
ofourdan: xwl_sync_events(), is that blocking? otherwise I think that roundtrip is a non-polling busy loop?
<pq>
jadahl, I suppose, but then that would be flaky.
<pq>
jadahl, my point is, if there actually is a reasonable course of action after timing out, then would there also not be a way to handle things without blocking at all?
<pq>
if timing out should not have bad side-effects, then the complexity of handling the timeout is the same as not blocking in the first place, in a very general idea.
<jadahl>
pq: seems the internal randr API assumes it's a display server and drm master, i.e. can grant/deny synchronously, so one would have some how make that async, if that is even possible
<ofourdan>
jadahl: my point being looping on xwl_sync_events() will block X11 events/requests dispatching
<jadahl>
ofourdan: right, it will, but if its not polling and is a busy loop, it'll still timeout even without anything on the wayland socket
<pq>
jadahl, right, but that's what one needs do anyway to avoid random failures. So the trade-off question is, how often and how bad is it to randomly fail.
<jadahl>
i.e. it'll eat 100% cpu for a bit and then fail the lease
<ofourdan>
jadahl: but I am not sure thtimeout will be handled if we're never make it back to the Xserver main loop (or at least this is my suspiscion, I haven't actually tried)
<ofourdan>
should be easy to test for someone with all the bits inm place, just hack the compositor to not reply :)
<jadahl>
ofourdan: looks like rceate_lease() will just return BadValue after a second, and I guess that'll end us up on the main loop again
<ofourdan>
so it;s all good
<jadahl>
if you call 100% cpu busy loop good, I guess so
<ofourdan>
it's a busy loop, the code wa written like that
<ofourdan>
I mean, the discussion strated with deadlocks :)
<jadahl>
can x11 calls be async? i.e. can the randr x11 api function reply happen asynchronously?
<ofourdan>
the xserver can reply later, X11 is not synchronous
<jadahl>
or, what I'm really asking is, can the internal API be async?
<ofourdan>
is it?
<jadahl>
the ProcRRCreateLease() function looks pretty hard to async:ify
richbridger has quit [Ping timeout: 480 seconds]
richbridger has joined #wayland
<pq>
I think Xwayland could freeze the X11 client until it has a reply, I believe DIX has the framework for that?
<ofourdan>
no, the xserver cannot freeze the x11 cleints, but the x11 cleint won;t get its reply until the wayland compositor has replied with the current design
<ofourdan>
(well, at least, I don't see how the DIX could freze the client willingly)
<ofourdan>
if the client does an XSync() it will block until its gets its reply from the xserver
<pq>
I mean, something is used to implement... what that libX11 function again that grabs... XGrabServer()
<ofourdan>
but that's different, this is the client telling the Xserver that he wants to be the only client, blocking processign for all other clients
<pq>
yes, I know, but it still needs to freeze an arbitrary set of clients
<ofourdan>
what you mean is the client running synchronously waiting for the server
<pq>
here you just want to freeze that one client
<ofourdan>
this depends on hiow the request is implemented
<ofourdan>
maybe it's blocking, I dunno
<jadahl>
ofourdan: I can't find how one could implement a request non-blocking
<jadahl>
is it at all possible?
<ofourdan>
if it is, then the client will just block until it gets its reply from the xserver, which in turn will block until it gets its reply from the Wayland compositor
<pq>
ofourdan, yes, that's exactly what I'm saying.
<pq>
but xserver would not itself be completely blocked while that one X11 client is blocked
<ofourdan>
it would, from an X11 point of view, in the sense that it won;t process any other X11 request from any x11 client
<pq>
ofourdan, no, it would process all other X11 clients normally.
<ofourdan>
how? dispatch() isn;t called in that busy loop
<pq>
that's the whole point of doing a single-client freeze, and not a GrabServer
<MrCooper>
an X server can certainly freeze clients temporarily, DRI2 uses that
<jadahl>
ofourdan: so the X server can't handle two method calls (from two clients) async then?
<ofourdan>
I'm confused, we're talking about the xserver in general, or xwayland doing a busy loop on xwl_sync_events()
<ofourdan>
?
<jadahl>
ofourdan: what I'm talking about is whether we can make xwl_randr_create_lease() async (by making ProcRRCreateLease() async)
<jadahl>
so we don't introduce a dead lock prone code path to xwayland
<ofourdan>
that's two different things I reckon
<ofourdan>
you could have the calling X11 client blocked waiting on the reply, while having other clients being processed (andthat includes the X11 WM in there)
<MrCooper>
jadahl: each request is processed atomically in principle; however, the X server can defer processing a request to later and freeze the client in the meantime
<ofourdan>
that ^^
<jadahl>
MrCooper: can it do that after having looked at the request?
<MrCooper>
I think so
<ofourdan>
but what we have in the drm lease MR is blockign every x11 client
<jadahl>
that sounds like a X11 way of doing async :p
<MrCooper>
not 100% sure though
<jadahl>
we should probably see if that's possible, because that roundtrip sounds like a bad idea
<MrCooper>
looks like Xwayland already does something like this in xwl_dri3_open_client
<MrCooper>
glx/glxext.c:__glXDispatch calls ResetCurrentRequest, that looks like the current request can be rewound completely
<ofourdan>
you'd block that cleint until the compositor replies, while not blocking all x11 cliets
<jadahl>
sounds like exactly what we need
<jadahl>
ProcGrabServer() seems to have some "queue" of grabbers
<MrCooper>
yep, everything needed should be there AFAICT
<jadahl>
that uses the same thing
<jadahl>
now, can this be done inside rrCreateLease, or does the internal API needs to be changed
flacks has quit [Quit: Quitter]
flacks has joined #wayland
<MrCooper>
jadahl: I'd say the latter, currently ProcRRCreateLease either returns an error or completes the request after calling rrCreateLease
hegstal has quit [Remote host closed the connection]
hegstal has joined #wayland
aquijoule_ has joined #wayland
richbridger has quit [Remote host closed the connection]
dcz has quit [Ping timeout: 480 seconds]
gryffus has joined #wayland
<gryffus>
Lol i just discovered that wayland devs think, that user should not need/want to change resolution, is this true? What about gamers with old graphics, that need lower resolutions for higher framerate? One example for all... ?
<gryffus>
Can anyone please confirm if this is correct?
<pq>
gryffus, user can and should be able to change video modes at will. Generic Wayland clients should not.
<pq>
gryffus, so many people were upset at games messing up their desktops on X11 when arbitrary programs were able to change video modes and more. And they often did it against users' wish.
<emersion>
you probably already have one in your test suite?
<gryffus>
no dont get me wrong, i am not upset, i can use for gaming Xorg without problem (and continue doing so aas long as i want). I am jsut asking if this is really attitude of the devs, or if they just don't see use-cases when changing of resolution is helping
<pq>
gryffus, Lower resolution for games has been solved in Wayland by letting fullscreen games submit low-resolution images and not by forcing a video mode changes.
<gryffus>
So, i won't be able to change resolution (sorry for confusing resolution with video modes and whatever, my knowledge is not deep enough it seems) in game directly?
<gryffus>
what is difference between a "game" and a generic wayland client? Client is a window manager?
<pq>
emersion, alpha-blending-test contains also cases for the old "non-gamma" blending.
<gryffus>
"letting fullscreen games submit low-resolution images and not by forcing a video mode changes". - is this transparent? Or needs the game to implement this?
<gryffus>
FYI, i often kill EVERYthing, including window manager to boost my FPS highest as possible, i guess something like this won't be possible with wayland? Every MB of RAM matters to me
<gryffus>
I mean, if game submits lower resolution image/video, the desktop needs to upscale it again and that would cause significant overhead, no?
<ishitatsuyuki>
inefficient? yes. significant? no
<emersion>
KMS can scale buffers as well
<ishitatsuyuki>
it's better done in the display controller though], through an overlay plane or so
<ishitatsuyuki>
yeah basically what emersion said
<emersion>
it's pretty unlikely that killing the XWM will bring you any more FPS
<ishitatsuyuki>
I never felt necessary to kill anything on Linux to boost performance
audgirka has quit [Remote host closed the connection]
<ishitatsuyuki>
well maybe kill that Electron app but otherwise background behavior is much less problematic than Windows
<gryffus>
emersion: it does, it frees few tens of memory, and helps with fps "spikes"
<gryffus>
few tens of MB*
<emersion>
a good XWM should be completely idle when a game is active
<emersion>
in fullscreen
<gryffus>
KDM is not
<gryffus>
KWM sry
<gryffus>
I mean, KWin
<emersion>
i'm surprised you're using KDE if you want to save… dozens of bytes of RAM :P
<emersion>
a dedicated XWM just for games would make more sense IMHO
<gryffus>
emersion: i use KDE whistles when working, but i want the most FPS when i am gaming
<gryffus>
First i moved to "TWM" which boosted a few FPS.. Then i moved to starting the games via a xinit script, that only X and wine+game is running (and a kernel and systemD of course)
<gryffus>
I guess this is because of compositing in KDE? dunno the datails
<gryffus>
BTW plasma can be killed too
<gryffus>
but empty X is just faster (uses less RAM which the game can use)
<gryffus>
a guess my PC is just ancient now, but still, i would like to play with the original performance. And not to loose FPS each kernel / OS upgrade
<gryffus>
s/a guess/i guess
<gryffus>
And by what i read about wayland, it will bring performance loss, just as SystemD did... and BTRFS... and so on...
<emersion>
it depends
hegstal has quit [Remote host closed the connection]
<emersion>
pretty sure gamescope could do better than your X11 session
<gryffus>
and i was just really surprised when i read on internet, that wayland devs "think that user should not change his system resolution in app"
<gryffus>
gamescope?
<emersion>
clients are not users
<emersion>
gamescope is a wayland compositor, for gaming
<gryffus>
i asked before - client is the game? Or is client a window manager (or compositor in wayland universe)
<emersion>
the game is a Wayland or X11 client
<emersion>
clients can't mess with the resolution
<emersion>
users can configure output modes in their compositor
<gryffus>
So, do you think that game developers will remove option to set game resolution from games just because of wayland? Or is some hack in Wayland planned for this?
<emersion>
games can still submit buffers with a smaller size than the full resolution, as said above
<gryffus>
I see
<emersion>
and a compositor _could_ have the policy to change the mode depending on the game buffer size
<gryffus>
ok, will see how it plays with the benchmarks
<gryffus>
but guys, don't forget that every MB of video and/or system RAM matters, please :)
<gryffus>
especially with graphics
<gryffus>
wish you a good luck and fingers crossed for wayland! :)
<gryffus>
i will look at gamescope btw, even if i hate everything steam-related :D
<emersion>
gamescope uses vulkan, and works best on amd gpus
<gryffus>
nice
<gryffus>
maybe it's not the same BLOB with quadrillion of static and duplicated (with system) libraries as steam is :D (sorry if there is some steam dev)
<gryffus>
checking its github now
<emersion>
(just mentionning that in case your GPU cannot do vulkan)
<emersion>
it's fully open-source
<gryffus>
yeah i use Vulkan already for some
<gryffus>
gr8
<pq>
gryffus, every buffer matters, yeah, that's why a lot of people invest a lot of effort in making things "zero-copy".
<gryffus>
thats good imo :)
<pq>
gryffus, one of Wayland design principles was to let the compositor (display server) automatically use all the possible display hardware capabilities, rather than waiting for an app to decide to maybe use them (and mess up every other app running while at it).
<pq>
e.g. to scan out a low resolution frame from a game, you don't necessarily need to change video modes, the display controller can do the up-scaling for you. And without messing up your normal desktop layout.
<pq>
btw. GPU and display controller are different things, just to be clear.
<pq>
display controller is configured via KMS
<pq>
gryffus, however, being always composited, Wayland does have higher overhead compared to X11 without composition, when you have a desktop and multiple windows on it.
<MrCooper>
gryffus: changing resolution in games is working fine with Wayland, arguably better than it ever did with Xorg; consider trying things yourself before ranting based on something somebody wrote on the internet :)
<pq>
For fullscreen games, Wayland vs. X11 should be at least on par in performance. There is some background memory eaten thought because of the compositing design.
<pq>
swick, theoretically I guess no-one should be using those values, so maybe they could be deleted.
<gryffus>
pq: but up-scaling cost CPU cycles and RAMA
<gryffus>
*RAM
<pq>
gryffus, no, it does not when done by the display controller.
<gryffus>
MrCooper: since performance is almost the only thing i expect from graphical stack, i will stay on X for now until such "issues" are solved or until the performance is at least comparable with my minimal setup
<gryffus>
I like compositing when i work, but not when i play, i just not need it at all when playing
<gryffus>
Also, KWin has option for turning off compositing on fullscreen windows for a reason
<swick>
yes, because Xorg sucks
<MrCooper>
FWIW, background apps have less impact on fullscreen apps with Wayland than with X11 compositing
<gryffus>
pq: i see
<pq>
gryffus, turning off composition for fullscreen windows is something Wayland compostors are expected to do automatically. No need for the end user to poke at things.
<pq>
*compositors
<gryffus>
Well, i think i will just have to try it and compare myself
<gryffus>
agreed, there is much mis-information on the web
<pq>
yes, you do - but use an up-to-date distribution, please
<gryffus>
i have openSUSE Tumbleweed
<gryffus>
bleeding edge :P
<pq>
cool
<gryffus>
(on the machine i plan to test it)
<gryffus>
Ok, thanks everyone for your views and insights and mostly, for your time!
gryffus has quit [Quit: Leaving...]
aleasto has quit [Ping timeout: 480 seconds]
gryffus has joined #wayland
<gryffus>
Just one more question came to my mind. How does Wayland handle displays with broken / wrong edid info?
<pq>
gryffus, that is up to each Wayland compositor implementation to handle, Wayland says nothing about that.
<gryffus>
In past, this could be configured via manual modelines, but i expect modelines are not available in wayland?
<pq>
not a Wayland thing, but each compositor may or may not offer something equivalent
<gryffus>
Ok, so if i need a custom modeline, can a compositor implement that functionality?
<gryffus>
nice
dcz has joined #wayland
<gryffus>
I expect most will support something like that, since the number of broken EDID is still fairly large
dos11 is now known as dos1
<pq>
gryffus, I could suggest to find or craft a non-broken EDID file and set that up as an override with the kernel. That would then apply to all userspace and not just those display servers you configure manually.
<gryffus>
pq: yes, this is the correct procedure even with X, but not always possible (i do not remember the details, but i failed to do that when tried several years ago)
<gryffus>
But i might have been just lame
<pq>
I've never actually needed to do it myself, but I have forced a mode on kernel command line for a monitor that is unstable without reduced-blanking timings.
<gryffus>
Yeah i suspect that from when KMS was introduced, much more of this is on kernel rather than display server
<pq>
yes, the modelines are actually collected and validated in the kernel, and userspace looks at the kernel's list rather than parse EDID on its own.
<pq>
but KMS still allows totally custom modelines, too
<pq>
at least within hardware limits
<gryffus>
nice
<gryffus>
I think the situation with Wayland is much better than impression from it on web
<gryffus>
According to what you say
<swick>
is the seq value in presentation time/the MSC in X and GL actually a hardware counter or is the compositor the only source of truth for it?
<pq>
yeah, positive comments don't gather energy, it's all the negativity (true or false) that gets the hype
<pq>
swick, KMS has it, FWIW.
<pq>
swick, KMS pageflip event carry it, for example.
gryffus has quit [Remote host closed the connection]
<pq>
swick, I'm not sure if Xorg delivers that as-is, but I would assume it's the basis at least.
aquijoule_ has quit []
aquijoule_ has joined #wayland
aquijoule_ has quit [Remote host closed the connection]
<swick>
alright so a compositor should in general know the MSC targeted when it redraws