ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
julio7359 has joined #wayland
Brainium has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
kenny has quit [Quit: WeeChat 4.2.1]
kenny has joined #wayland
navirc has quit [Quit: WeeChat 4.1.2]
aknot has joined #wayland
tyzef has joined #wayland
aknot has quit [Ping timeout: 480 seconds]
tyzef has quit [Quit: WeeChat 3.8]
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
garnacho has quit [Ping timeout: 480 seconds]
zxrom has quit [Quit: Leaving]
aknot has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
aknot has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
vincejv has quit [Quit: Bye bye! Leaving for now...]
<wildwestrom[m]>
How do y'all usually debug Wayland issues? I'm having so much trouble finding where to set breakpoints in order to know what's causing the bug.
<emersion>
do you know about WAYLAND_DEBUG?
glennk has quit [Ping timeout: 480 seconds]
<wildwestrom[m]>
I completely forgot about it! That gives me much more information.
<ManMower>
I got to the 2 year old comment that said "I'm not asking to fix this properly, I just want wlroots to be X11".
<emersion>
;_;
<bl4ckb0ne>
> In case of DBus, the "black screen" problem you mentioned is probably easy solvable as it's backed by Polkit (if that problem exists at all).
* bl4ckb0ne
closes the tab
<emersion>
you didn't know that installing D-Bus will solve all your black screen issues?
<kchibisov>
Can one you put this dbus magic into early boot to avoid flickering as well?
* kchibisov
runs.
<emersion>
thanks daniels
<kchibisov>
One could design exclusive fullscreen protocol to match their desire, I guess.
mripard has quit [Quit: mripard]
<kchibisov>
Though, hinting refresh rate could be not that bad either, but could be overly complex in compositors.
<psykose>
tbf there's like almost no point to use kodi with the non-gbm backends is there
<psykose>
for an actual like tv box setup
<psykose>
the extra compositor in the middle doesn't have any benefits for the usecase
<kchibisov>
maybe just _simpler code_.
<kchibisov>
since writing your own compositor is not that fun.
<psykose>
also going to gbm directly means not having to wait for the middle step to support HDR things :D
<emersion>
yeah… getting KMS right is not as easy as one may think…
<psykose>
it's not, but kodi has had it for a long time with a lot of users
<psykose>
i'd imagine it's pretty solid
<ManMower>
I think kodi can launch external things like games/emulators, so having a desktop hidden underneath could be beneficial even in the set top case?
<kchibisov>
you still have a use case with regular video players.
<soreau>
or other games.. I think retroarch was discussed about the same thing a little while back, here
<kchibisov>
And sometimes you really want to change the refresh rate since the hardware is a bit special.
<kchibisov>
like I remember that on my projector I had to always lower the refresh rate on the output itself to get it smoother.
<kchibisov>
Or at least pick the one matching the video.
kts has quit [Ping timeout: 480 seconds]
<soreau>
maybe there can be a protocol, where the client says 'hey, change the mode' and then the compositor asks the user with a dialog or whatever 'hey, client wants to switch mode. do you want to do this?'
<kchibisov>
called zwp_exclusive_fullscreen_v1?
<kchibisov>
Because a separate protocol for this mess will probably make sense.
<kchibisov>
because you also want to know whether the mode actually got applied, etc.
<soreau>
or that one X dialog for clients.. 'do you want to keep this mode? will revert in 10 seconds'
<soreau>
in case it's black and you can't see the dialog, at least it doesn't stay black forever :P
<kchibisov>
I mean, one should try design thing like that, but it's really common in old games.
<kchibisov>
where they resize only by changing the entire mode of the display.
<kchibisov>
and because it's a _common functionality_ people will continunue to write code which modesets.
<soreau>
kchibisov: great, glad you're volunteering to write the extension
<kchibisov>
me? no.
<soreau>
heh
<kchibisov>
I have no use for exclusive fullscreen.
<LaserEyess>
I think exclusive fullscreen is bad and I think even microsoft doesn't even use it anymore
<kchibisov>
you can still use the API.
<LaserEyess>
instead, I would much rather people work on one of the 10000000000 open protocols for VRR and better presentation timing
<kchibisov>
win32 calls still work and still do exclusive fullscreen.
<kchibisov>
my projector can't do vrr.
<LaserEyess>
and you can use the win32 APIs to emulate windows xp, but I don't think that apps should use that
<LaserEyess>
kchibisov: you'd still benefit from better content timing
<ids1024>
"I think kodi can launch external things like games/emulators" - probably the best solution there would be for Kodi to be a Wayland compositor itself. Though also not a *simple* thing.
<soreau>
LaserEyess: right but then where does that leave folks without VRR caps or if the client wants to change resolution?
<ids1024>
I guess more like how the Steam Deck does things. That's perhaps a more modern approach.
<kchibisov>
like idk, projectors are a bit weird.
<LaserEyess>
soreau: clients can request a resolution change and get a viewport
<soreau>
ids1024: yea I thought this too but there are other clients that also want these things too
<LaserEyess>
one of the best things wayland prevents
<LaserEyess>
or, I mean, one of the best things wayland does is prevent it
<kchibisov>
If you have priviliged protocol for that it's not an issue.
<LaserEyess>
it's one of the worst things
julio7359 has joined #wayland
<kchibisov>
there's already a priviliged protocol to change resolution.
<LaserEyess>
right but kodi is not such a client
<daniels>
emersion: no problem - didn't expect to see you turn into such a dbus enthusiast but here we are ;)
<kchibisov>
if I put it on my tv it can do whatever with that tv, I don't care.
<kchibisov>
the same with video player, if I do that, it can do whatever it wants, because I did that.
<LaserEyess>
strongly disagree, but most importantly so do the core wayland decs
<LaserEyess>
if kodi wants to do that they need to implement their own compositor
<daniels>
soreau: we don't need a mode-switch extension, because the fullscreen protocols have been designed to allow clients to present fullscreen content at a different resolution
<kchibisov>
But I can't be bothered to modeset myself between every video I play.
<soreau>
LaserEyess: so BMF to those without VRR?
<daniels>
the compositor doesn't need to ask the client 'hey do you want me to resize or do you want weird stuff to happen'; it can decide what the right thing is to do and ... do it
<LaserEyess>
soreau: VRR is not the only use case of commit-timing, refresh-cycle-info, etc. protocols under discussion
<LaserEyess>
there are literally 5 of them up deciding how to best communicate refresh info to clients to help them
<soreau>
daniels: so don't change res, just use whatever size and the compositor scales it?
<vsyrjala>
daniels: but i guess a specific refresh rate isn't something the client can ask for?
<daniels>
vsyrjala: not rn, no
<daniels>
soreau: yes, it scales it, or it changes the output mode temporarily, or whatever it decides is a good idea
<kchibisov>
in reality all compositors will put black content around and view in the middle.
<LaserEyess>
no they won't?
<LaserEyess>
they would use a viewport
<kchibisov>
without viewporter?
<daniels>
I'm not sure why 'without viewporter' is interesting?
<daniels>
I mean, if you arbitrarily remove the tools required to solve the problem, then the problem is harder to solve
<daniels>
but it's not clear why you would
<LaserEyess>
^
<kchibisov>
I mean, people write cross platform toolkits and use exclusive fullscreen.
<LaserEyess>
and wayland maps that to a fullscreen surface?
<kchibisov>
Toolkit probably can use viewporter to emulate the behavior, but that's about it.
<LaserEyess>
that many compositors can and do make specific optimizations for?
<daniels>
if there are problems with viewporter which mean it needs to be improved, then sure, please suggest away
<kchibisov>
and if you don't have viewporter you're out of luck.
<LaserEyess>
but they do have viewporter...
<daniels>
yeah.
<kchibisov>
mine doesn't.
<daniels>
implement it then?
<kchibisov>
but it's not really an issue.
<kchibisov>
Like the only issue I see is that you can't emulate what exclusive fullscrene does.
<LaserEyess>
then implement viewporter as a change in resolution for your compositor
<kchibisov>
with all the things we have right now.
<LaserEyess>
if you control the stack, you do what you want
<kchibisov>
Because exclusive fullscreen changes refresh rate, color depth, resolution, etc.
<daniels>
colour depth is controlled by the client, as is resolution
<daniels>
we don't have refresh rate but we will do it
<kchibisov>
yeah, if you have refresh rate hint that will probably kind of work.
<LaserEyess>
and there are like 5 protocols that start to expose that information to the client
<daniels>
I just don't understand how 'we can't do different resolutions without the protocol designed to allow different resolutions' is an interesting discussion
<kchibisov>
I was talking mostly about refresh rate.
<kchibisov>
soreau: was talking about resolution.
<kennylevinsen>
For current TVs, VRR tends to cause weird game modes to trigger. On the other hand, on current TV, changing refresh rate causes a multi-second blackout. They have automatic 3:2 pulldown detection and adjustment, but 50fps at 60hz is awful. Currenr status quo sucks :/
<kchibisov>
kennylevinsen: on projects it's even more weird.
<vsyrjala>
kchibisov: just need 300hz panels and all will be well :)
<soreau>
<daniels> soreau: yes, it scales it, or it changes the output mode temporarily, or whatever it decides is a good idea <-- are there any compositors that change the mode temporarily? regardless, seems like they'd be better off with their own compositor instead of trying to convince all the compositors to do what they want (because everyone knows that's impossible)
<kchibisov>
vsyrjala: you need to match refresh of the video.
<kchibisov>
like 30Hz doesn't solve anything, you need 23.995, 24.0, 30, 60, etc.
<LaserEyess>
soreau: you could theoretically implement viewport as a resolution change + a scale, for fullscreen stuff
<kchibisov>
and change dynamically between them.
<vsyrjala>
mean to reply to kennylevinsen soyy. 300hz is a nice integer multiple of 50 and 60
<LaserEyess>
but I doubt any compositor does that, because of the modeset issues already mentioned
<LaserEyess>
and anyway, for modern stuff, exclusive fullscreen isn't used to change resolution, it's used to get exclusive access to the screen for latency optimizations
<kchibisov>
I think that's partially true, since direct scanout wasn't a thing on windows for regular fullscreen.
<kchibisov>
but they changed that.
<kennylevinsen>
TVs also aren't good at mapped SDR content in HDR modes. Fun things like zone dimming backlight flicker. It's honestly all a mess. Perfect HDR VRR, one day...
<LaserEyess>
kchibisov: sure, and they also discourged exclusive fullscreen, those things are probably related
<kchibisov>
kennylevinsen: will cost like a year salary for some folks.
<soreau>
kennylevinsen: by the time that happens, there will be new technology that no one knows what to do with
<LaserEyess>
yeah but that also means a protocol to arbirarily change refresh rate also won't help in the future
<soreau>
monitors/tv's should just stop supporting multiple modes - just support one, and let the software figure it out
<soreau>
only one modeset per boot!
<LaserEyess>
yeah I agree, it's called VRR :)
<soreau>
my vrr cap monitors support like 20 modes...
<LaserEyess>
but it defaults to the fastest + VRR, no? that's the one people usually want
<soreau>
hm.. maybe we should default to VRR
<vsyrjala>
except when they care about power consumption ;)
<LaserEyess>
VRR helps with power consumption though
<soreau>
since it falls back gracefully
<LaserEyess>
and what's really more important here is what the actual content needs, which is why instead of a give-me-a-refresh-rate-I-want protocol, wayland needs more protocols that let the compositor and client exchange hints about content and intent
<vsyrjala>
it still needs all the display logic to be clocked at the highest frequency. which also potentially means higher voltages, higher memory/fabric clocks/etc
<LaserEyess>
vsyrjala: dynamic clocking is a thing and if TV manufacturers haven't figured it out despite all the other power saving stuff they put into their products then they just suck
<vsyrjala>
there is no dyamic clocking in vrr
<LaserEyess>
why not?
<vsyrjala>
well, some clocks may be turned off while not in use. but the clock rate while its doing its thing is fixed to the max defined by the display timings
<vsyrjala>
so it's the classic race to idle vs. not question. which is more optimal depends on many things
<LaserEyess>
for a 144 Hz, or even a 300 Hz display, they just have to ramp up faster than 1 ms
<LaserEyess>
surely that's possible
cmichael has quit [Quit: Leaving]
<kennylevinsen>
It's also not quite that simple. Most TVs have quite noticable amount of post processing that depends on a particular, fixed refresh rate. VRR removes the need for pulldown removal, but there's still 24p anti-judder (displays with very fast response can make 24p an unwatchable slideshow) and dimming zone control. The latter in particular seems Very Bad in low latency or VRR modes.
<kennylevinsen>
The solutions that TV manufacturers have come up with so far is Quick Media Switching to allow changing *fixed* refresh rate without blackouts (*very* new), which gives you an idea of the kind of bandaids they're applying
leon-anavi has quit [Quit: Leaving]
<vsyrjala>
LaserEyess: we're not talking about psr here. while the display is active a lot of things remain active 100% of the time. only really the memory fetch can get a bigger reprieve during vblank
rasterman has joined #wayland
garnacho has quit [Quit: garnacho]
julio7359 has quit [Ping timeout: 480 seconds]
* soreau
wishes there were better timestamp formatting with WAYLAND_DEBUG
tyzef has joined #wayland
julio7359 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
glennk has quit [Ping timeout: 480 seconds]
<ManMower>
what would you change about the current formatting?
<ManMower>
seems like a really easy thing to change if there's some better way...
junaid has quit [Remote host closed the connection]
tyzef has quit [Quit: WeeChat 3.8]
Brainium has quit [Quit: Konversation terminated!]
privacy has quit [Quit: Leaving]
countrysergei has joined #wayland
<countrysergei>
bwidawsk: those leftovers being entire dog shit in/from human senses think they are someone to abuse me.
<countrysergei>
Ermine: gets to deliver his ass to abusers i rather think, not to even get close to me with his hitmen when i do not want, but just bitch slapped to deliver his ass for little bit of anal.
<countrysergei>
protectorate abuser mind ill infected puppet.
___nick___ has quit [Ping timeout: 480 seconds]
countrysergei has quit [Remote host closed the connection]
countrysergei has joined #wayland
tyzef has joined #wayland
rv1sr has quit []
flom84 has joined #wayland
mvlad has quit [Remote host closed the connection]
Brainium has joined #wayland
rgallaispou1 has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
flom84 has quit [Ping timeout: 480 seconds]
calcul0n has quit [Ping timeout: 480 seconds]
diwoka__ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
<selckin>
diwoka__: leaked your password if you didn't notice
diwoka__ is now known as diwoka
<diwoka>
i notice
<diwoka>
thk you
<diwoka>
and impossible to delete
<dubiousness>
it happens, good chance to update it and ensure you don’t reuse it :)
NepNep[m] has quit [Quit: Reconnecting]
NepNep[m] has joined #wayland
NepNep[m] is now known as nep_nep
nep_nep has quit []
nep_nep has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
nep_nep has quit []
nep_nep has joined #wayland
fossdd has joined #wayland
<danieldg>
you should never assume a delete works anyway in a public chat, so IRC being unable to delete is actually better as it avoids the false sense of security
<diwoka>
yeah i know
<diwoka>
you right
diwoka is now known as Guest3074
jal has left #wayland [#wayland]
glennk has quit [Ping timeout: 480 seconds]
Guest3074 has quit [Quit: Page closed]
diwoka has joined #wayland
<diwoka>
i have one question
aknot has joined #wayland
<diwoka>
i have issue with jetbrains-toolbox
<diwoka>
No X11 DISPLAY variable was set, <- this is the message
verify has joined #wayland
diwoka is now known as Guest3076
countrysergei has quit [Remote host closed the connection]
aknot has quit [Ping timeout: 480 seconds]
<Consolatis>
diwoka: Guest3076: sounds pretty self-explanatory to me. Either your env got somehow reset while starting jetbrains-toolbox or your compositor isn't supporting (/ compiled with) xwayland. In any case this seems unrelated to the wayland protocol, please consider asking in your compositor channel instead (if one exists)