04:27 wlb: weston Issue #833 opened by Rob Kramer (teegee) Dual screen https://gitlab.freedesktop.org/wayland/weston/-/issues/833
07:34 swick[m]: Company: scaling is tricky because the position in the color pipeline matters in kms so right now undefined is as good as it gets
09:48 pq: swick[m], yes, I very much intend to finish color-and-hdr!35
10:42 wlb: wayland Issue #416 opened by Simon Ser (emersion) Document that wayland-scanner generated code should not be versionned https://gitlab.freedesktop.org/wayland/wayland/-/issues/416 [Documentation]
11:17 wlb: wayland Merge request !349 closed (scanner: export interface should use protected visibility)
11:23 pq: heh, interesting to use Rust syntax highlighting for a gdb stack trace in Gitlab :-)
11:34 pq: oh my, I can resolve threads in Gitlab issues now!
12:50 WhyNotHugo: From an end-user perspective, is there a different between maximised and fullscreen? Or are the differences merely implementation details?
12:51 emersion: might want to draw decorations when maximized but not fullscreen
12:52 kennylevinsen: And maximized does not necessarily fill the screen
12:52 WhyNotHugo: kennylevinsen: maximised is limited by the size in set_max_size?
12:53 emersion: the interactions are not super clear
12:53 wlb: wayland-protocols Merge request !259 opened by Olivier Fourdan (ofourdan) Draft: (Re)move Xwayland related protocols https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/259
12:53 emersion: set_max_size is a hint that the window may not like being maximized
12:53 emersion: but the compositor can still put the window in that state afaiu
12:55 kennylevinsen: maximized could be some size chosen by the compositor for a "large" window - imagine an ultrawide monitor, where most apps make no sense in fullscreen
12:56 kennylevinsen: yeah min_size and max_size are worded rather weakly right now...
12:57 WhyNotHugo: I guess that set_max_size could also be taken as a hint that the window doesn't like to be fullscreened?
12:58 emersion: not necessarily -- the client can pick whatever size it wants in fullscreen mode
12:58 WhyNotHugo: True. Weird, but true :P
12:58 WhyNotHugo: So maximised is something like "largest preferred size", not really fullscreen.
12:59 kennylevinsen: yes, and not exclusive like fullscreen requires
13:00 zamundaaa[m]: Fullscreen doesn't require exclusivity either
13:00 emersion: right, some compositors might have weird fullscreen modes
13:01 emersion: like covering all outputs, or covering just part of an output
13:03 WhyNotHugo: I see that my confusion was not unjustified.
13:03 kennylevinsen: hmm? the spec states that if the surface does not cover the entire wl_output, the compositor will fill the rest, and that the compositor will ensure nothing else is visible through transparency
13:03 kennylevinsen: doesnt' cover the multi-output fullscreen case, but it's arguably a mistake to mention wl_output's here in the first place...
13:05 pq: What's an output if not wl_output?
13:05 kennylevinsen: if your fullscreen spans multiple outputs
13:06 zamundaaa[m]: I was more referring to the fact that you can have windows on top of the fullscreen window. Or a fullscreen window only spanning one tile
13:06 pq: No, I mean in general. If you write a spec for fullscreen, how do you define an "output"?
13:07 kennylevinsen: zamundaaa: one tile would conflict with the specific mention of output
13:07 WhyNotHugo: The way the spec is worded, it would seem that "fullscreen" covers 100% of a single output. If you have a 2x2 grid of monitors tiled together, fullscreen will only cover one.
13:08 ascent12: That assumes that output = monitor, which isn't something Wayland says
13:08 pq: WhyNotHugo, IMO that depends on how the monitor grid is exposed, as a single output or four outputs. (wl_outputs?)
13:08 ascent12: The vagueness gives compositors a lot of flexibility to do neat/werid things
13:08 zamundaaa[m]: what the spec says and what compositors do in practice aren't necessarily the same things
13:09 WhyNotHugo: Outputs have a make and model. It kidna leads you to think that 1 monitor is 1 output. Does any compositor currently allow configuring a grid of monitors as a single output?
13:10 pq: WhyNotHugo, wl_output has a make and model. "Output" might be something else, which we are trying to find out here. :-)
13:11 WhyNotHugo: xdg_toplevel::set_fullscreen explicitly says 'wl_output' anyway.
13:11 pq: besides, wl_output is one of the oldest interface still existing, and has met lots of critique.
13:11 kennylevinsen: pq: Hmm, I'd probably try to avoid it to not explicitly rule out e.g. the fullscreen-to-tile case zamundaaa mentions. Maybe "expanded to fill exclusively fill a larger area" rather than say output? idk
13:12 WhyNotHugo: kennylevinsen: A compositor can expose the entire grid of outputs as a virtual output (e.g.: another wl_output instance). It can then be passed as an argument to set_fullscreen without API changes.
13:12 pq: most of the events in wl_output probably should not exist
13:12 kennylevinsen: indeed
13:13 pq: WhyNotHugo, good point.
13:13 kennylevinsen: the argument to set_fullscreen is not particularly useful, as the app won't understand the grid - but yes, there could be arbitrary even overlapping outputs
13:14 pq: there are some technical details like the monitors in the grid should all be gen-locked if presentation-time is intended to be accurate
13:14 WhyNotHugo: kennylevinsen: That's the whole point: the grid is opaque to the client and looks like just one single big output (which is the intent).
13:15 zamundaaa[m]: WhyNotHugo: that doesn't work for any other case though. Exposing a wl_output per tile sounds like it might cause lots of fun issues
13:16 pq: might? Maybe. Hard to come up with an example, though.
13:17 pq: I think the protocol development has been quite good recently to move away from wl_outputs in general.
13:18 WhyNotHugo: I think recent protocol development reflects a lot of lessons learnt from the initial ones (I say this as a form of praise).
13:18 MrCooper: WhyNotHugo: hmm, I wonder if Xwayland could cope with such a virtual output though :/
13:19 WhyNotHugo: Oh, yeah, if that tiled-output spans monitors connected to different GPUs then I can see how several things would quickly become a problem.
13:25 zamundaaa[m]: That would not be a problem at all, as the compositor is the one handling multi gpu, not Xwayland
13:26 wlb: weston Issue #834 opened by Himanshu Bhavani (himanshu.d) Weston dual screen issue at imx8 https://gitlab.freedesktop.org/wayland/weston/-/issues/834
13:53 kennylevinsen: WhyNotHugo: when wl_output is entirely arbitrary it also erases all meaning of a wl_output reference - the client cannot make sense of being entered on 12 different overlapping outputs, nor can it select one meaningfully
13:54 kennylevinsen: we're just bending the definition of the object to get around the fact that it's needed, and in that case it would be nicer if it just wasn't needed in the first place
13:54 kennylevinsen: but it's what we're stuck with for now so oh well :P
13:55 WhyNotHugo: Formerly, clients needed output::enter to figure out a scale. With the new scaling protocols, do regular clients actually need to deal with outputs at all?
13:56 emersion: some clients still use subpixel
13:57 kennylevinsen:shakes fist at subpixel rendering
13:57 emersion: some toolkits insist on exposing the output layout in their API
14:18 Company: GTK wants to know the likely scale
14:18 Company: so it can create resources before creating surfaces
14:19 Company: ie in gtk_init()
14:20 Company: and when initializing resources from a UI file, which happens before allocation of surfaces
14:20 Company: and we use the scale of the first output for that
14:21 kennylevinsen: wouldn't picking the largest scale be better than first scale?
14:21 Company: dunno
14:21 d_ed[m]: even then you have an int -> fractional problem
14:22 Company: GTK3 used to pick the scale of the primary output
14:22 Company: but Wayland doesn't have that
14:22 Company: GTK's APIs are all ints
14:22 Company: so that number is either 1 or 2
14:23 kennylevinsen: yeah, have to wait for gtk5 for fractional scale
14:23 Company: o_O
14:23 Company: or you just use 4.12
14:24 Company: the bigger problem is that the whole asset infrastructure - ie icons - uses PNGs
14:25 Company: and so far nobody has volunteered to make it do all the caching and whatnot with fractions
14:25 Company: and figure out what scales to save PNGs at because loading SVGs is slow
14:25 Company: don't want inkscape or gimp to take twice as long to start just because it's scaling SVGs
14:26 kennylevinsen: if you're spending time scaling svgs something is wrong :P
14:26 kennylevinsen: drawing svgs or scaling pngs however...
14:27 Company: yeah
14:28 Company: I want the artist community to agree on a scalable format for icons
14:28 Company: but the artist community is not a fan of scalable formats anyway, they want their lines to be pixel-perfect
14:28 Company: so there's been lots of friction and burnout with people trying to push things
14:29 kennylevinsen:can't wait for resolutions to get high enough that pixel perfect becomes irrelevant
14:29 Company: plus, there's no free tools other than inkscape really
14:30 Company: and SVG is this huge format and nobody has a fast and well-maintained renderer for a subset that everyone can agree on
14:30 Company: plus, so far with Gnome just doing 1x or 2x, you could just pre-render all the assets
14:30 kennylevinsen: not sure what state pathfinder is in, but yeah - could maybe use a less xml-ey overhaul
14:31 Company: you don't want to throw pathfinder at your icons 60 times per ssecond
14:31 Company: and if you're caching anyway, you can probably render things with a slow SVG renderer
14:32 Company: minus the startup issue
14:32 kennylevinsen: you also presumably don't decode pngs from disk 60 times per second, so either way you'd rasterize to a buffer and go from there
14:32 kennylevinsen: why do it slow if you can do it fast
14:32 Company: (GTK3 color-converts pngs 60 times per seconds)
14:33 Company: (because PNGs are GdkPixbufs and those are unpremultiplied RGBA and cairo wants premultiplied BGRA)
14:33 Company: (don't tell anyone)
14:33 Company: actually, GTK3 doesn't do it 60 times per second, it's not that fast
14:35 d_ed[m]: FWIW, we (qt/kde) have a relatively slow SVG renderer with a runtime png cache so we can do things natively at the right scale and it's fine
14:35 Company: d_ed[m]: we probably could, too, if anyone wanted to improve the existing asset pipeline - but I'd rather get a better asset pipeline
14:36 Company: the font pipeline deals with this scaling stuff way better for example
14:38 Company: kennylevinsen: side note: GTK is planning to add something like pathfinder to its renderer, too
14:39 Company: kennylevinsen: https://blog.gtk.org/2023/09/19/paths-in-gtk/
14:39 Company: it's part of all the rendering stuff I'm doing atm - but people find more and more fun things to do, so now I get to look at dmabufs, too
14:40 Company: new unified renderer for Vulkan/GL that can do fractional scaling, dmabufs, HDR, paths
14:41 wlb: wayland Issue #417 opened by daniel kramer (dan1119999111) Black screen after inactivity stays black forever - can't get back to the desktop https://gitlab.freedesktop.org/wayland/wayland/-/issues/417
14:52 wlb: weston Issue #829 closed \o/ (wl_surface.offset interaction with subsurfaces https://gitlab.freedesktop.org/wayland/weston/-/issues/829)
14:52 wlb: weston Merge request !1375 merged \o/ (libweston: Ignore subsurface offsets https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1375)
14:52 wlb: weston/main: Marius Vlad * libweston: Ignore subsurface offsets https://gitlab.freedesktop.org/wayland/weston/commit/d18fd64a158a include/libweston/libweston.h libweston/compositor.c
14:54 wlb: wayland Issue #417 closed \o/ (Black screen after inactivity stays black forever - can't get back to the desktop https://gitlab.freedesktop.org/wayland/wayland/-/issues/417)
15:27 lordmzte: Hello and sorry if I'm asking in the wrong place: Is it possible to create a `zwlr_layer_surface` using the `zwlr-layer-shell-unstable-v1` protocol that spans all outputs? I'd like to create a desktop background application that spans all monitors. Thanks!
15:28 emersion: no, you need to create one per output
15:28 YaLTeR[m]: I think you need a surface per output
15:29 lordmzte: Alright, thanks!
16:13 kchibisov: When wl_compositor@v6 is being used should client still fallback to output scale when the compositor doesn't ever send `prefered_buffer_scale`? I'd assume no, and client should use this event or assume 1?
16:14 vyivel: i'd assume scale 1
16:14 emersion: yeah, scale 1
16:14 emersion: iirc the protocol says so
16:20 kchibisov: emersion: it doesn't.
16:21 kchibisov: But clients shouldn't fallback to output based scaling, right?
16:21 kchibisov: The protocol doesn't say so, but probably should.
16:21 emersion: hm, it was discussed in GitLab
16:22 kchibisov: 🤔
16:22 emersion: but yeah apparently not in the protocol
16:22 emersion: clients shouldn';t fallback no
16:22 kchibisov: yeah, exactly.
16:22 kchibisov: I just got asked "why do you think that they shouldn't".
16:22 kchibisov: I can't just reply that there's no way anyone meant to do fallbacks...
16:23 YaLTeR[m]: It's not obvious when you haven't followed the discussion
16:23 kchibisov: YaLTeR[m]: you should just feel the wayland over the years.
16:25 YaLTeR[m]: If I let too much wayland into my veins, I'll be unable to use google maps as I'll lose my global positioning
16:25 drakulix[m]: that one hurt.
16:26 MrCooper: lol
16:29 wlb: wayland Merge request !351 opened by Simon Ser (emersion) util: simplify wl_fixed_from_double() https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/351 [IPC library]
17:04 wlb: wayland Merge request !352 opened by Kirill Chibisov (kchibisov) protocol: clarify defaults with wl_compositor@v6 https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/352
17:45 wlb: wayland-protocols Merge request !260 opened by Lucas Berthou (berlu) Adding protected_content value in content-type enum to cover protected content use-case. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/260
19:49 wlb: wayland-protocols Merge request !260 closed (Draft: Adding protected_content value in content-type enum)
20:42 anarsoul: daniels: emersion: jadahl: pq: can you please set +MR modes on this channel?
20:42 emersion: why?
20:43 emersion: +R is very aggressive
20:43 emersion: especially when OFTC doesn't support SASL
20:43 emersion: the channel is secret
20:43 anarsoul: emersion: I'm tired of spammers spamming in PM
20:44 emersion: this channel is secret, so if they spam you, it's probably not via #wayland
20:45 emersion: you should get in touch with the OFTC admins
20:45 anarsoul: I'm pretty sure they are aware
20:46 emersion: maybe. but if everybody thinks this way…
20:46 anarsoul: can you at least set +M?
20:48 emersion: that wouldn't help
20:49 anarsoul: OK, at least I tried :)