00:01KarenTheDorf: Is libdecor documented anywhere? Beyond just reading the header and/or examples?
00:01Nefsen402: Welcome to open source
00:01KarenTheDorf: I take it that's "Pull Requests are welcome" :D
00:01alice: usually are
00:02alice: unless it's the kernel and they start complaining that your sign-off is wrong :^)
00:03KarenTheDorf: *stares at the two bug reports they have open in ubuntu* I should learn myself driver develpment and fix all this UB in the radeon kernel driver.
00:04Nefsen402: For me, writing patches isn't the problem, it's finding reviewers
00:04Nefsen402: good like finding a reviewer for the radeon driver
00:05KarenTheDorf: "Just like use amdgpu", whoops, this laptops about a year too old, and my other laptop has a dead kb.
00:05Nefsen402: My old laptop had a first generation GCN chip in it and needs flags to use amdgpu
00:06Nefsen402: radeon didn't enable HW acceleration in the browser so it was a no-go
00:07KarenTheDorf: I should probabally actually fiddle. It's supposed to be dual graphics, but I only see one gpu reported.
00:07Nefsen402: Which laptop?
00:08Nefsen402: Some firmwares may hide secondary GPUs on non windows operating systems
00:08KarenTheDorf: It's reported in lspci
00:08Nefsen402: That's a different problem then
00:10KarenTheDorf: Hmm, the M chip is GCN1. I'm going to go find those flags to force AMDGPU for gen1 and see if it boots.
00:10KarenTheDorf: *gcn1
00:10Nefsen402: Other than some backlight issues I had with amdgpu that I found a workaround for amdgpu works much better
00:10Nefsen402: Vulkan works for everything I tried too
00:12KarenTheDorf: Yeah atm I'm stuck with llvmpipe
00:13KarenTheDorf: Laters, off to tinker.
00:34karenw: Nefsen402: It works! If I use X... *winces*
00:35Nefsen402: I used sway on all my devices including my old laptop
00:36KarenTheDorf: There's still UB in the amdgpu driver, a bunch of errors in dmesg that seem to be saying it can't get the gpu out of low power mode. Welp.
00:37Nefsen402: The way you're using the term UB doesn't make sense to me
00:38KarenTheDorf: Ubuntu seems to build the kernel with UBSAN enabled.
00:38KarenTheDorf: and it's flagging up out of bounds reads and stuff in dmesg
00:38Nefsen402: that might be completely normal
00:39Nefsen402: Out of bounds would trigger a page fault handler and that's how you implement stuff like swap
00:40alice: it would be pretty funny if kernel ubsan flagged stuff like that where it's intended
00:40alice: so i strongly doubt it
01:44RAOF: Out of bounds reads very rarely trigger a page fault handler, because they need to hit a page that's not mapped (which means they need to go 2K out of bounds, on average), whereas most out of bounds errors are off-by-one.
01:45RAOF: KUBSan is correctly triggering there, AFAICT.
03:36wlb: weston Merge request !1551 opened by Louis-Francis Ratté-Boulianne (lfrb) Add support for surface compression in simple-egl https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1551
07:10MrCooper: RAOF: does Ubuntu really enable UBSAN in production kernels though?
07:23davidre: MrCooper: I think so, I see ubsan messages from virtualbox kernel modules when shutting down
07:24davidre: i.e.... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/jNYwqJjqsAWWxkyINpnLRJdX>)
07:30MrCooper: wild
07:51RAOF: Yeah, we do. AFAIK it doesn't have false positives (at least, in the configuration we use), and has very little performance penalty.
07:54wlb: weston/main: Pekka Paalanen * color-lcms: print ICC profile class on error https://gitlab.freedesktop.org/wayland/weston/commit/c4a403b2a638 libweston/color-lcms/color-profile.c
07:54wlb: weston Merge request !1548 merged \o/ (color-lcms: print ICC profile class on error https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1548)
07:58pq: swick, are you actually here even when you're not?
08:36meltq[m]: if this assert `assert(buffer->pool->internal_refcount + buffer->pool->external_refcount);` in wl_shm_buffer_ref_pool fails, is the conclusion that the pool has been freed?
08:38pq: meltq[m], I would think so. I would expect ASan or Valgrind to likely flag use-after-free, too.
08:49wlb: weston/main: Jeffy Chen * renderer-gl: Support NV16 shm format https://gitlab.freedesktop.org/wayland/weston/commit/a073f93aba2b libweston/renderer-gl/gl-renderer.c tests/yuv-buffer-test.c
08:49wlb: weston/main: Jeffy Chen * gl-renderer: Support NV24 shm format https://gitlab.freedesktop.org/wayland/weston/commit/be43297679f6 libweston/renderer-gl/gl-renderer.c tests/yuv-buffer-test.c
08:49wlb: weston/main: Jeffy Chen * renderer-gl: Support more shm RGB formats https://gitlab.freedesktop.org/wayland/weston/commit/3b7cfdb56177 libweston/ pixel-formats.c pixel-formats.h renderer-gl/fragment.glsl renderer-gl/gl-renderer-internal.h renderer-gl/gl-renderer.c renderer-gl/gl-shaders.c
08:49wlb: weston Merge request !1430 merged \o/ (renderer-gl adding more SHM formats https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1430)
10:13swick[m]: pq: I'm here, yes
10:15pq: swick[m], oh, a for a few times I've wanted to say something, but didn't see you on the channel. Wonder what it was...
10:15wlb: weston Merge request !1433 closed (input: Fix losing focus during re-attaching keyboard)
10:16pq: swick[m], ah, the test images in https://www.color.org/version4html.xalter - the top-right one is actually using Input class embedded profile. That surprised me.
10:17pq: But I think I would still not want to add Input class as allowed in the protocol.
10:18swick[m]: ah, saw that one but I'm also not sure what no make of it
11:43pq: Weston and weston-image pass the https://displaycal.net/icc-color-management-test/ tests, as long as weston-image uses nearest-neighbor filtering.
12:49swick[m]: awesome!
14:16King_DuckZ: hey all, I'm implementing chroma key in weston and how can I pass user parameters to weston? for example say a float representing the moothness parameter
14:59wlb: weston Issue #920 opened by Nils K (septatrix) Segfault in `desktop_surface_removed` (of kiosk-shell) when client terminates abruptly https://gitlab.freedesktop.org/wayland/weston/-/issues/920
16:46mclasen: I'm looking around for a compositor that has the color management stuff for writing client code against it
16:46mclasen: looking at weston or kwin in rawhide, I don't find anything
17:30wlb: wayland Issue #472 opened by Dennis Lonoshchuk (laycookie) Attaching Null to the surface influences configuration. https://gitlab.freedesktop.org/wayland/wayland/-/issues/472
17:53zamundaaa[m]: mclasen: you need to set an env var to make it available
17:54mclasen: I learned that by now, thank
17:54mclasen: s
18:02wlb: wayland Issue #472 closed \o/ (Attaching Null to the surface influences configuration. https://gitlab.freedesktop.org/wayland/wayland/-/issues/472)
18:44emersion: pq, swick[m]: should we do a new libdisplay-info release now?
18:44emersion: or wait for more stuff?
18:59wlb: wayland-protocols/main: Simon Ser * governance: document review requirements https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/7d5a3a8b494a GOVERNANCE.md
18:59wlb: wayland-protocols Merge request !312 merged \o/ (governance: document review requirements https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/312)
19:07mclasen:marvels at the fact that there's zero overlap between the color-management protocol implementations in weston and kwin
19:25vyivel: ping on https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/219?
19:46emersion: not sure i will have time to look at this anytime soon
19:47vyivel: no rush
19:47emersion: PSA: i now have a full time job so will have a lot less time for Linux graphics stuff
19:49emersion: i still hope to have *some* time, for sure :P
19:55bl4ckb0ne: gz on the new job emersion
19:55emersion: ty!
19:55bl4ckb0ne: where is it? or do you prefer to keep it a secret
19:56KarenTheDorf: I don't have a job, by that logic I should spend more time on linux graphics stuff :D
19:57bl4ckb0ne: oh it's in your status update
21:27zamundaaa[m]: mclasen: Weston implementing the parametric bits is planned afaik. Depending on how things go with parametric-only in practice, *maybe* we'll implement the icc stuff at some point too
21:27mclasen: using such "everything is an option" protocols isn't very fun.
21:29emersion: for your purposes you can probably ignore the ICC stuff and require the parametric stuff, mclasen
21:30emersion: ICC stuff is for e.g. Krita
21:30zamundaaa[m]: Yeah. Any practical implementation of the ICC stuff can also do parametric
21:30mclasen: not really, and the parametric implementation in kwin is a bit too limited too
21:31zamundaaa[m]: What are you missing? Except the rendering intents we don't support yet of course
21:31zamundaaa[m]: ...which I should really add, it's pretty much trivial to do
21:31mclasen: why not support linear as a tf ?
21:33zamundaaa[m]: Because it wasn't necessary for anything so far, and KWin's internal "linear" means something else than the protocol does
21:34mclasen: the beauty of 'everything optional' protocols :)
21:34zamundaaa[m]: Once I put in the luminance stuff from Sebastian though, I can add that confusion free too
21:35zamundaaa[m]: mclasen: you can just require the features you need and bail out otherwise. Doesn't help you at this phase for testing ofc :)
21:35mclasen: yeah, sure