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...]
julio7359 has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
Company has quit [Quit: Leaving]
eroc1990 has quit [Quit: The Lounge - https://thelounge.chat]
eroc1990 has joined #wayland
sima has joined #wayland
Kerr has quit [Remote host closed the connection]
qaqland_ has joined #wayland
calcul0n has joined #wayland
qaqland has quit [Ping timeout: 480 seconds]
tyzef has joined #wayland
vincejv has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
kts has joined #wayland
junaid has joined #wayland
Kerr has joined #wayland
tzimmermann has joined #wayland
kts has quit [Quit: Leaving]
floof58 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
glennk has joined #wayland
floof58 has joined #wayland
tyzef has quit [Ping timeout: 480 seconds]
junaid_ has joined #wayland
Kerr_ has joined #wayland
Kerr has quit [Ping timeout: 480 seconds]
junaid_ has quit []
Kerr_ has quit [Remote host closed the connection]
qaqland_ is now known as qaqland
slim has joined #wayland
<dubiousness> I think they'd be able to do what they want with a dbus-activated systemd unit
<dubiousness> Registering it in a global context menu is a bit tricker
<dubiousness> A reasonable question though, it is a very nice feature on Windows & macOS. Anecdotally something my parents have relied on in the past.
rv1sr has joined #wayland
rgallaispou has joined #wayland
tzimmermann has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
kts has joined #wayland
mripard has joined #wayland
peelz has quit [Quit: ZNC 1.8.2 - https://znc.in]
peelz has joined #wayland
mvlad has joined #wayland
junaid has quit [Remote host closed the connection]
<wlb> wayland-protocols Merge request !281 opened by Sebastian Wick (swick) xdg-shell: add missing enum attribute to set_constraint_adjustment https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/281
kts has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
cmichael has joined #wayland
leon-anavi has joined #wayland
mbalmer has quit [Ping timeout: 480 seconds]
mbalmer has joined #wayland
guru_ has quit [Ping timeout: 480 seconds]
cmichael has quit [Quit: Leaving]
zxrom has joined #wayland
cmichael has joined #wayland
<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.
<pq> wildwestrom[m], https://wayland.freedesktop.org/extras.html has a few more.
<wildwestrom[m]> Awesome Thank you!
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
rasterman has joined #wayland
Company has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
kts has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
sgm has quit [Remote host closed the connection]
bittin has quit [Ping timeout: 480 seconds]
bindu_ has joined #wayland
sgm has joined #wayland
bindu has quit [Remote host closed the connection]
luna has joined #wayland
<wlb> weston Merge request !1455 opened by Pekka Paalanen (pq) Color manager cleanups https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1455 [color-lcms plugin], [Colour management]
nerdopolis has joined #wayland
navi has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
privacy has joined #wayland
fmuellner has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
Guest2935 has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit []
cool110 has joined #wayland
cool110 is now known as Guest3015
Guru_DE has joined #wayland
kts has joined #wayland
tzimmermann has quit [Remote host closed the connection]
<emersion> can someone help me convince these folks that using compositor-specific APIs to perform output modesets isn't a good thing to do?
lsd|2 has joined #wayland
<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> fuck arbitrary resolution changes imo
<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...
Brainium has joined #wayland
garnacho has joined #wayland
glennk has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
junaid has joined #wayland
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
Lyude has quit [Quit: Bouncer restarting]
Lyude has joined #wayland
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!]
sima has quit [Ping timeout: 480 seconds]
privacy has joined #wayland
<diwoka__> nick diwoka
<diwoka__> /msg NickServ RECOVER diwoka 137Darker!963
diwoka__ has left #wayland [#wayland]
diwoka__ has joined #wayland
<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)
<Guest3076> ok ok sorry for my question
kenny has quit [Quit: WeeChat 4.2.1]
Guest3076 is now known as diwoka