08:04 dubiousness: I think they'd be able to do what they want with a dbus-activated systemd unit
08:05 dubiousness: Registering it in a global context menu is a bit tricker
08:05 dubiousness: A reasonable question though, it is a very nice feature on Windows & macOS. Anecdotally something my parents have relied on in the past.
09:10 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
11:31 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.
11:31 emersion: do you know about WAYLAND_DEBUG?
11:39 wildwestrom[m]: I completely forgot about it! That gives me much more information.
11:41 pq: wildwestrom[m], https://wayland.freedesktop.org/extras.html has a few more.
11:43 wildwestrom[m]: Awesome Thank you!
13:49 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]
16:02 emersion: can someone help me convince these folks that using compositor-specific APIs to perform output modesets isn't a good thing to do?
16:02 emersion: https://github.com/xbmc/xbmc/issues/20614
16:10 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".
16:10 emersion: ;_;
16:11 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).
16:11 bl4ckb0ne:closes the tab
16:17 emersion: you didn't know that installing D-Bus will solve all your black screen issues?
16:17 kchibisov: Can one you put this dbus magic into early boot to avoid flickering as well?
16:17 kchibisov:runs.
16:18 emersion: thanks daniels
16:18 kchibisov: One could design exclusive fullscreen protocol to match their desire, I guess.
16:19 kchibisov: Though, hinting refresh rate could be not that bad either, but could be overly complex in compositors.
16:19 psykose: tbf there's like almost no point to use kodi with the non-gbm backends is there
16:19 psykose: for an actual like tv box setup
16:19 psykose: the extra compositor in the middle doesn't have any benefits for the usecase
16:20 kchibisov: maybe just _simpler code_.
16:20 kchibisov: since writing your own compositor is not that fun.
16:20 psykose: also going to gbm directly means not having to wait for the middle step to support HDR things :D
16:20 emersion: yeah… getting KMS right is not as easy as one may think…
16:20 psykose: it's not, but kodi has had it for a long time with a lot of users
16:21 psykose: i'd imagine it's pretty solid
16:21 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?
16:23 kchibisov: you still have a use case with regular video players.
16:24 soreau: or other games.. I think retroarch was discussed about the same thing a little while back, here
16:24 kchibisov: And sometimes you really want to change the refresh rate since the hardware is a bit special.
16:24 kchibisov: like I remember that on my projector I had to always lower the refresh rate on the output itself to get it smoother.
16:25 kchibisov: Or at least pick the one matching the video.
16:27 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?'
16:27 kchibisov: called zwp_exclusive_fullscreen_v1?
16:27 kchibisov: Because a separate protocol for this mess will probably make sense.
16:28 kchibisov: because you also want to know whether the mode actually got applied, etc.
16:29 soreau: or that one X dialog for clients.. 'do you want to keep this mode? will revert in 10 seconds'
16:29 soreau: in case it's black and you can't see the dialog, at least it doesn't stay black forever :P
16:29 kchibisov: I mean, one should try design thing like that, but it's really common in old games.
16:30 kchibisov: where they resize only by changing the entire mode of the display.
16:30 kchibisov: and because it's a _common functionality_ people will continunue to write code which modesets.
16:31 soreau: kchibisov: great, glad you're volunteering to write the extension
16:31 kchibisov: me? no.
16:31 soreau: heh
16:31 kchibisov: I have no use for exclusive fullscreen.
16:32 LaserEyess: I think exclusive fullscreen is bad and I think even microsoft doesn't even use it anymore
16:32 kchibisov: you can still use the API.
16:33 LaserEyess: instead, I would much rather people work on one of the 10000000000 open protocols for VRR and better presentation timing
16:33 kchibisov: win32 calls still work and still do exclusive fullscreen.
16:33 kchibisov: my projector can't do vrr.
16:33 LaserEyess: and you can use the win32 APIs to emulate windows xp, but I don't think that apps should use that
16:33 LaserEyess: kchibisov: you'd still benefit from better content timing
16:34 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.
16:34 soreau: LaserEyess: right but then where does that leave folks without VRR caps or if the client wants to change resolution?
16:34 ids1024: I guess more like how the Steam Deck does things. That's perhaps a more modern approach.
16:34 kchibisov: like idk, projectors are a bit weird.
16:34 LaserEyess: soreau: clients can request a resolution change and get a viewport
16:35 soreau: ids1024: yea I thought this too but there are other clients that also want these things too
16:35 LaserEyess: fuck arbitrary resolution changes imo
16:35 LaserEyess: one of the best things wayland prevents
16:35 LaserEyess: or, I mean, one of the best things wayland does is prevent it
16:35 kchibisov: If you have priviliged protocol for that it's not an issue.
16:35 LaserEyess: it's one of the worst things
16:36 kchibisov: there's already a priviliged protocol to change resolution.
16:36 LaserEyess: right but kodi is not such a client
16:36 daniels: emersion: no problem - didn't expect to see you turn into such a dbus enthusiast but here we are ;)
16:36 kchibisov: if I put it on my tv it can do whatever with that tv, I don't care.
16:36 kchibisov: the same with video player, if I do that, it can do whatever it wants, because I did that.
16:36 LaserEyess: strongly disagree, but most importantly so do the core wayland decs
16:36 LaserEyess: if kodi wants to do that they need to implement their own compositor
16:37 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
16:37 kchibisov: But I can't be bothered to modeset myself between every video I play.
16:37 soreau: LaserEyess: so BMF to those without VRR?
16:37 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
16:37 LaserEyess: soreau: VRR is not the only use case of commit-timing, refresh-cycle-info, etc. protocols under discussion
16:38 LaserEyess: there are literally 5 of them up deciding how to best communicate refresh info to clients to help them
16:38 soreau: daniels: so don't change res, just use whatever size and the compositor scales it?
16:38 vsyrjala: daniels: but i guess a specific refresh rate isn't something the client can ask for?
16:38 daniels: vsyrjala: not rn, no
16:38 daniels: soreau: yes, it scales it, or it changes the output mode temporarily, or whatever it decides is a good idea
16:38 kchibisov: in reality all compositors will put black content around and view in the middle.
16:39 LaserEyess: no they won't?
16:39 LaserEyess: they would use a viewport
16:39 kchibisov: without viewporter?
16:39 daniels: I'm not sure why 'without viewporter' is interesting?
16:39 daniels: I mean, if you arbitrarily remove the tools required to solve the problem, then the problem is harder to solve
16:39 daniels: but it's not clear why you would
16:39 LaserEyess: ^
16:40 kchibisov: I mean, people write cross platform toolkits and use exclusive fullscreen.
16:40 LaserEyess: and wayland maps that to a fullscreen surface?
16:40 kchibisov: Toolkit probably can use viewporter to emulate the behavior, but that's about it.
16:40 LaserEyess: that many compositors can and do make specific optimizations for?
16:41 daniels: if there are problems with viewporter which mean it needs to be improved, then sure, please suggest away
16:41 kchibisov: and if you don't have viewporter you're out of luck.
16:41 LaserEyess: but they do have viewporter...
16:41 daniels: yeah.
16:41 kchibisov: mine doesn't.
16:41 daniels: implement it then?
16:41 kchibisov: but it's not really an issue.
16:42 kchibisov: Like the only issue I see is that you can't emulate what exclusive fullscrene does.
16:42 LaserEyess: then implement viewporter as a change in resolution for your compositor
16:42 kchibisov: with all the things we have right now.
16:42 LaserEyess: if you control the stack, you do what you want
16:42 kchibisov: Because exclusive fullscreen changes refresh rate, color depth, resolution, etc.
16:43 daniels: colour depth is controlled by the client, as is resolution
16:43 daniels: we don't have refresh rate but we will do it
16:43 kchibisov: yeah, if you have refresh rate hint that will probably kind of work.
16:43 LaserEyess: and there are like 5 protocols that start to expose that information to the client
16:43 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
16:43 kchibisov: I was talking mostly about refresh rate.
16:44 kchibisov: soreau: was talking about resolution.
16:44 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 :/
16:44 kchibisov: kennylevinsen: on projects it's even more weird.
16:45 vsyrjala: kchibisov: just need 300hz panels and all will be well :)
16:45 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)
16:45 kchibisov: vsyrjala: you need to match refresh of the video.
16:45 kchibisov: like 30Hz doesn't solve anything, you need 23.995, 24.0, 30, 60, etc.
16:45 LaserEyess: soreau: you could theoretically implement viewport as a resolution change + a scale, for fullscreen stuff
16:45 kchibisov: and change dynamically between them.
16:45 vsyrjala: mean to reply to kennylevinsen soyy. 300hz is a nice integer multiple of 50 and 60
16:46 LaserEyess: but I doubt any compositor does that, because of the modeset issues already mentioned
16:46 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
16:47 kchibisov: I think that's partially true, since direct scanout wasn't a thing on windows for regular fullscreen.
16:47 kchibisov: but they changed that.
16:47 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...
16:47 LaserEyess: kchibisov: sure, and they also discourged exclusive fullscreen, those things are probably related
16:47 kchibisov: kennylevinsen: will cost like a year salary for some folks.
16:48 soreau: kennylevinsen: by the time that happens, there will be new technology that no one knows what to do with
16:48 LaserEyess: yeah but that also means a protocol to arbirarily change refresh rate also won't help in the future
16:50 soreau: monitors/tv's should just stop supporting multiple modes - just support one, and let the software figure it out
16:50 soreau: only one modeset per boot!
16:50 LaserEyess: yeah I agree, it's called VRR :)
16:51 soreau: my vrr cap monitors support like 20 modes...
16:52 LaserEyess: but it defaults to the fastest + VRR, no? that's the one people usually want
16:52 soreau: hm.. maybe we should default to VRR
16:52 vsyrjala: except when they care about power consumption ;)
16:52 LaserEyess: VRR helps with power consumption though
16:52 soreau: since it falls back gracefully
16:54 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
16:54 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
16:54 LaserEyess: like this https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/150
16:56 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
16:56 vsyrjala: there is no dyamic clocking in vrr
16:57 LaserEyess: why not?
16:57 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
16:57 vsyrjala: so it's the classic race to idle vs. not question. which is more optimal depends on many things
16:58 LaserEyess: for a 144 Hz, or even a 300 Hz display, they just have to ramp up faster than 1 ms
16:58 LaserEyess: surely that's possible
17:01 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.
17:05 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
17:09 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
17:38 soreau:wishes there were better timestamp formatting with WAYLAND_DEBUG
17:55 ManMower: what would you change about the current formatting?
17:56 ManMower: seems like a really easy thing to change if there's some better way...
21:02 countrysergei: bwidawsk: those leftovers being entire dog shit in/from human senses think they are someone to abuse me.
21:03 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.
21:04 countrysergei: protectorate abuser mind ill infected puppet.
23:05 diwoka__: nick diwoka
23:07 diwoka__: /msg NickServ RECOVER diwoka 137Darker!963
23:10 selckin: diwoka__: leaked your password if you didn't notice
23:11 diwoka: i notice
23:12 diwoka: thk you
23:12 diwoka: and impossible to delete
23:12 dubiousness: it happens, good chance to update it and ensure you don’t reuse it :)
23:28 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
23:32 diwoka: yeah i know
23:32 diwoka: you right
23:36 diwoka: i have one question
23:40 diwoka: i have issue with jetbrains-toolbox
23:40 diwoka: No X11 DISPLAY variable was set, <- this is the message
23:51 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)
23:53 Guest3076: ok ok sorry for my question