06:59ofourdan: DodoGTA: Xwayland is an xserver, it handles x11 fonts like like any other xservers, using font paths "xset fp" - for example, here, 'xlsfonts | wc -l' gives 2188 fonts.
07:00ofourdan: (it doesn't use the xorg.conf though, so if you had any font paths set there, you'd have to add them using xset)
07:27kode54: I have significantly more font pollution in my system
07:27kode54: that wc -l gives 8010 here
07:27ofourdan: well, definitely more than 4 ;-)
07:28kode54: fun thing I ran into recently too
07:28kode54: I needed an xorg-fonts-misc package
07:29kode54: to run hasciicam in GUI mode, that is
07:29kode54: turns out that package uses aalib, and I didn't see the optional dependencies of aalib to make its x11 backend display properly
08:26DodoGTA: kode54: Even after I install one of those xorg-fonts packages, the font count doesn't change in xfontsel (and probably xlsfonts too)
08:58wlb: weston Merge request !1399 closed (compositor: fix crash when repaint fails with pending presentation feedback)
08:58wlb: weston Merge request !1572 opened by Daniel Stone (daniels) repaint: Requeue presentation feedback on failed repaint https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1572 [Core compositor]
10:29kode54: DodoGTA: are you missing fontconfig?
10:29DodoGTA: kode54: I'm definitely not (otherwise my DE would probably be unusable)
10:35MrCooper: fontconfig doesn't affect the X protocol font handling, it's more or less a client-side replacement
10:59kode54: ah
10:59kode54: so I don't know what would cause X to be missing font config
12:22ofourdan: DodoGTA: are those fonts you installed listed in the font path as used by teh xserver (xset q)?
12:24ofourdan: installign the fonts is not enough, the font path need to be knownto the xserver - Some distributions add symlinks in /etc/X11/fontpath.d/ but those might end up being filtered out and ignored.
12:27soreau: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/meson_options.txt?ref_type=heads#L27-L29
14:33wlb: wayland Issue #480 opened by Demi Marie Obenour (DemiMarie) Document the expected format of the text in description tags https://gitlab.freedesktop.org/wayland/wayland/-/issues/480
14:45wlb: weston/main: Derek Foreman * rdp-backend: Fix more scale that should be current_scale https://gitlab.freedesktop.org/wayland/weston/commit/b56d887e3474 libweston/backend-rdp/ rdp.c rdpdisp.c
14:45wlb: weston Merge request !1571 merged \o/ (rdp-backend: Fix more scale that should be current_scale https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1571)
14:57wlb: weston/main: Daniel Stone * view: Move psf_flags from weston_view to weston_paint_node https://gitlab.freedesktop.org/wayland/weston/commit/f5074f261aa8 include/libweston/libweston.h libweston/backend-drm/state-propose.c libweston/compositor.c libweston/libweston-internal.h
14:57wlb: weston/main: Daniel Stone * repaint: Requeue presentation feedback on failed repaint https://gitlab.freedesktop.org/wayland/weston/commit/3b7ef70d3ab4 libweston/compositor.c
14:57wlb: weston Merge request !1572 merged \o/ (repaint: Requeue presentation feedback on failed repaint https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1572)
16:05wlb: weston Merge request !1573 opened by Derek Foreman (derekf) rdp: Align nsc_compose_message content https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1573 [RDP backend]
16:45wlb: weston Merge request !1574 opened by Derek Foreman (derekf) libweston: Remove output->scale https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1574 [Core compositor], [Headless backend], [libweston API], [Nested Wayland backend], [Nested X11 backend]
17:17wlb: weston Merge request !1575 opened by Derek Foreman (derekf) xwm: Fix input regions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1575 [XWayland]
17:38Company: zamundaaa: there's various GTK branches of the protocol, too - but it's all wip and nobody has actually run a full app => gtk => any compositor => kernel => monitor setup yet
17:38Company:not commenting on the issue because it doesn't load
17:41zamundaaa[m]: great, added it to the list
17:41zamundaaa[m]: And yeah it takes absolute ages to load sometimes
17:42Company: I have flaky internet atm
17:42Company: that surely contributes
17:42zamundaaa[m]: Maybe, but it also takes like 10s just to load the preview of my edited comment
17:43zamundaaa[m]: freedesktop gitlab seems to be generally slow today, and the 600 comment MR is always slow on its own
17:44Company: I talked about this with mclasen yesterday
17:45Company: my plan with GTK is to slowly truck on with adding features, but not sue how much we expose with the September Gnome release
17:45mclasen: here is what I have so far: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7444
17:45Company: and then we switch to linear compositing early after
17:46Company: so I'd like to see some common implementations appear in time for F42
17:48Company: or 25.04 Ubuntu
17:48Company: or whatever people use to time things
17:49zamundaaa[m]: I'd like a much faster timeline fwiw
17:50zamundaaa[m]: Ideally to have the protocol merged before Plasma 6.2, which releases in October if I have the release schedule correct
17:53Company:has no horse in this race
17:53Company: I'll take what is there and work with it, and don't care if it's merged or not
17:54mclasen: zamundaaa[m]: it would be really nice to have to the protocols merged
17:55Company: the biggest thing I want is implementations I can test against, and even better conformance tests
17:55Company: if a merged protocol helps with that, I'm all for it
17:58zamundaaa[m]: It should mostly help get a lot of app developers interested in implementing it
17:58Company: I have no idea how that's even supposed to work
17:58zamundaaa[m]: Because right now that seems to be quite limited, because they expect an API to be there in the system before implementing it, which doesn't work with Wayland
17:59Company: like, the apps that want to use it are somewhat limited
17:59Company: and a bunch of them wait on toolkits
18:00zamundaaa[m]: There aren't many apps that really depend on it, but they're one of the last major complaints about Wayland
18:02Company: how does that work with Qt?
18:02Company: Does Qt have an API in the core, or does the rendering engine ship one? Or does that go in KDE?
18:04Company: mostly because in core would mea it's pretty restricted and how the protocol evolves doesnt matter too much for app dev - and if it's outside, the APIs are way more undefined and dependent on the Wayland protocol probably
18:05Company: also, do you know of any browsers doing work about this?
18:06Company: feaneron: Do you know if webkit-gtk is doing any work on color management integration?
18:06zamundaaa[m]: Krita has some custom stuff for color management
18:07Company: yeah, I was expecting that - Krita is used in places where people care a lot about that stuff
18:08zamundaaa[m]: What Qt has itself for color management is still very limited afaik, I'm not super up to date if there's any efforts to change that
18:08zamundaaa[m]: On the browser side, Chromium implements a really old snapshot of the protocol
18:09zamundaaa[m]: Getting it to actually make use of it on normal Linux is something I tried but failed badly at
18:09Company: hehe
18:11Company: what's actually needed is some sort of collaborative environment where people implement in their apps what other people need to test their apps - which is where it's always been fallen apart
18:11Company: because the stack is so deep that at least one component is always acting up
18:11zamundaaa[m]: For Firefox last I heard there's at least interest in playing HDR videos, but idk if anything has actually happened about it
18:12Company: and it's demotivating trying to make something happen in experimental branches of other people's code that one isn't familiar with
18:12Company: and then people go do other stuff
18:13zamundaaa[m]: Yeah. And you need someone with Wayland, color management and app knowledge to then review the thing if you do write it
18:14Company: plus there's at least 3 competing groups with different ideas about how everything should work
18:15Company: movie people, games people and oldschool icc profile people
18:17Company: it's even kinda the case with the Wayland protocol - where Weston and KWin have an entirely different featureset, and the only thing they both can do is sRGB more or less
18:18Company: other question: GTK wants to do linear compositing
18:19Company: so that we produce visually identically output on sdr and hdr modes
18:19Company: but that means we end up with a linear buffer in the end
18:20Company: and then how do we hand that off to Kwin?
18:20Company: do you like linear buffers? Will we need to run a transfer function over it?
18:20zamundaaa[m]: You can use the linear transfer function with the new luminance requests Sebastian just added
18:21Company: how would this look on the kwin side in an ideal world?
18:21Company: the apps produce what kind of data and how do you turn that into the final image to send to the hardware
18:22Company: ?
18:22Company: assuming HDR hardware here
18:22zamundaaa[m]: It depends
18:23zamundaaa[m]: In Plasma 6.1, if direct scanout isn't possible, the color data is converted to a linear version of the output colorspace, and that's written to a shadow buffer
18:24zamundaaa[m]: After compositing, another shader pass converts from that to PQ in a 10bpc buffer, and that gets passed to KMS
18:24Company: you use 16bit float for the intermediate buffers?
18:25zamundaaa[m]: Yes
18:25Company: "output colorspace" - is that hardware dependent, or does that essentially mean rec2020 linear?
18:25zamundaaa[m]: In git master / 6.2, it does blending in a gamma 2.2 variant of the output colorspace. It either does the same as in 6.1, just with a 10bpc buffer, or it doesn't use a shadow buffer at all
18:26zamundaaa[m]: With HDR, that is rec.2020 linear
18:27Company: do you do the blending in the gamme colorspace? or do you use GL_SRGB do have gamma buffers but blend in linear?
18:28Company: I guess that only works in 8bpc
18:28zamundaaa[m]: Blending is in the gamma 2.2 colorspace. There's no GL_SRGB for 10bpc or for EGLImage in general
18:29Company: EGLImage has a flag for that I thought?
18:29Company: I saw some extension while googling about it
18:30zamundaaa[m]: There is an extension, but I thought it wasn't implemented in Mesa
18:30Company: that might be
18:31Company: for GTK, it's available for the target side, so I'm fine
18:32Company: so I can send you linear rec2020 from GTK and you're gonna be reasonably happy
18:32Company: as float16
18:32zamundaaa[m]: Yes
18:33Company: btw: do you have linear srgb supported?
18:33Company: it's excellent for testing, that's why I'm asking
18:33zamundaaa[m]: I don't think 6.1 supports the linear transfer function
18:34zamundaaa[m]: But 6.2 will
18:34Company: that's good enough for me
18:34zamundaaa[m]: If you want to offload blending in linear space though, that might be problematic. At least not until we switch to Vulkan and/or implement blend shaders in OpenGL
18:35Company: the thing I'm worried about there, but those aren't critical atm, are our offloading stuff
18:35Company: and if the compositor does scaling
18:36Company: but we support fractional scale, so there should be no scaling happening
18:36Company: for offloaded videos it might though
18:37Company: most apps are opaque, so that's not an issue either
18:37Company: and if shadows are blended wrong, I can live with that
18:37zamundaaa[m]: With fractional scale v1, supporting it doesn't mean anything for subsurfaces
18:38Company: yeah, but I'll either assume subsurfaces work fine or not use them until they do
18:39Company: the tricky part is the hole punching part
18:40Company: this case: https://blog.gtk.org/files/2023/11/bbb-below.png
18:40Company: because that often has a lot of transparent parts
18:40Company: like the overlays being semi-transparent black and such
18:41Company: but we can disable that mode if it looks too bad
18:42Company: then you get no offloading while controls are visible - so what
18:42Company: the important version is https://blog.gtk.org/files/2023/11/bbb-above.png - and that doesn't do blending because the video is opaque and square
18:43Company: that reminds me
18:43Company: can kms do linear blending of planes?
18:44Company: because it doesn't buy us anything if we offload blending to the compositor, if the compositor can't send it on to kms
18:49zamundaaa[m]: It depends on the compositor and on the hardware
18:49zamundaaa[m]: With current KMS APIs in general though, no
18:50Company: somore fun work to do there, too
18:50zamundaaa[m]: Lots of fun work has already happened
18:51zamundaaa[m]: There's a branch with an API for per plane color pipelines, with support for Intel and AMD GPUs
18:52zamundaaa[m]: KWin git master has most of the infrastructure for that in place, with only some minor changes being needed for it to make use of that
18:52Company: oh, that's quite a lot closer to reality than I had expected
18:54zamundaaa[m]: That reminds me though that I should finish up that stuff and post it on dri-devel. Afaik having real world userspace for the API is the main blocker for getting it into the kernel
18:55zamundaaa[m]: The biggest remaining missing piece for offloading at this point is imo overlay and underlay support in compositors
18:55Company: that's the same chicken-and-egg game as with the Wayland protocol
18:57zamundaaa[m]: Nah, on the compositor side offloading a whole window is also worth it
18:57zamundaaa[m]: And the color pipeline stuff is useful for the post blending CRTC properties too
18:58zamundaaa[m]: The code to glue the infrastructure to different drm properties in the end is the easy part :D
19:04Company: I was more thinking of the apps not starting to use an API that's not in the kernel
19:04Company: and the kernel not adding an API that no app isusing
19:07zamundaaa[m]: Yeah it's pretty similar in that regard
19:08Company: the graphics offloading stuff in GTK was a similar thing - needed GStreamer patches, various gstreamer plugins, GTK, and video players
19:08Company: without rmader running from one project to the next and filing issues and MRs, that would not have happened as quickly
19:11Company: that said, it's still not really done - the big apps still haven't switched and various smaller drivers/compositors still have issues
20:41feaneron: Company: webkit has internal plumbing for color management, but that's disabled on linux
20:42feaneron: Company: it's all in the internal, non-gtk part of webkit anyway. we'll need some sort of api somewhere, somehow, to enable it
20:43Company: yeah, you're gonna end up with a buffer that's not srgb and then need to tell gtk/wayland about it on gtk/wpe probably
20:44Company: which would require looking at the new protocol (for wpe)
21:09JPEW: I notices that weston pins the wl_region version to 1, is this for the same reason as wl_callback, just not documented as such?
21:10emersion: it shouldn't, it should be tied to wl_compositor version
21:10JPEW: It's not
21:11JPEW: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/compositor.c?ref_type=heads#L5105
21:14kennylevinsen: JPEW: wl_region is only created from wl_compositor::create_region, so the concern described in wl_callback (more than one factory) does not apply
21:18kennylevinsen: JPEW: weston also isn't really "pinning" anything, it's just specifying that it's version 1, which is the only version available
21:19JPEW: kennylevinsen: Fair, but if there was some change to wl_region, it would be e.g. version 6?
21:20JPEW: (6 be being the next wl_compositor version)
21:21kennylevinsen: maybe, but given the scope of wl_region I doubt that will happen
21:22kennylevinsen: and versioning hypothetical changes isn't a hobby of mine :P
21:23JPEW: kennylevinsen: Sure, just checking. Maybe I just missed the documentation that describes how object versioning works, but that particular piece of code is a little confusing