08:34 jadahl: pq: how does weston's icc client support deal with parsing client provided icc profiles?
09:00 pq: jadahl, feeding the data to LittleCMS 2 and hoping it doesn't do anything bad.
09:03 pq: jadahl, I wonder, if browsers do the same, then I would expect some hardening in LittleCMS 2, or someone fuzzing it. OTOH, maybe browsers rely on process isolation, so maybe not...
09:10 jadahl: pq: sounds scary (and it is what the mutter MR does too), but hard to say if "test parsing" in a sandboxed subprocess mitigates much, since one would have to eventually parse it in the compositor anyawy
09:11 pq: not necessarily
09:11 pq: if you feed both ICC profiles into the subprocess, let it compute the color transformation, and return it as a shaper + 3D LUT, I think it would be pretty safe.
09:14 jadahl: yea, that would be safe, but a bit of an overhead I guess
09:14 jadahl: depends on how often one need to do that, which I guess isn't very often hopefully
09:15 pq: the subprocess could maintain a cache of parsed ICC files
09:17 pq: seems there is some form of fuzzing going on somewhere: https://github.com/google/oss-fuzz/tree/master/projects/lcms - or was
09:17 jadahl: true, that could be done by anything. I don't imagine the ICC files plumbing would add that much, it'd be an fd passed around, more about the context switches doing I/O instead of just math when calculating luts
09:18 pq: somehow I doubt the context switch is much compared to the calculations from cached profiles
09:18 jadahl: are they (calculation) generally heavy?
09:19 jadahl: then maybe a "ICC LUT calculator" helper process is the way to go to avoid parsing untrusted complex data in the compositor
09:21 pq: I think the heaviness comes from how many LUT elements you have to produce. For computing one element, lcms needs to traverse through a linked list of "stages", each of which contains some elementary operation like a matrix, a lut, or a parametric curve.
09:22 pq: I don't know if that would be much faster if you had a pre-made buffer of all input tuples to feed in with a single call.
09:22 jadahl: would be interesting to see numbers, to know whether one would have to offload such a thing to a thread anyway
09:23 pq: yeah, I've never benchmarked that - have bigger gaps :-D
09:23 jadahl: hehe
09:23 jadahl: fair enough
09:24 pq: also the approach to ICC files and lcms in general is pretty... elaborate in Weston, and I still don't know if it's better or worse than the simple shaper + 3D LUT approach.
09:25 emersion: pq: is it simple to extract a shaper + 3D LUT from lcms?
09:26 emersion: shaper is 3x1D LUT right?
09:27 pq: It is simple to use LCMS to compute color values. Coming up with the shaper + 3D LUT takes some additional code, but LittleCMS helps with that, too.
09:27 pq: Let me see where Leandro's MR about that was...
09:29 emersion: right i already have the simple 3D LUT working
09:29 emersion: but grabbing a shaper in front seems tricky
09:33 pq: ah, it's not even a MR yet, just a draft patch
09:37 pq: Ok, maybe need to ask Leandro about that. The idea is documented in https://www.littlecms.com/ASICprelinerization_CGIV08.pdf .
09:38 pq: Essentially, the shaper is extracted from the original transformation by simply iterating through R=G=B=t for t=0.0 .. 1.0
09:39 emersion: ah, right, that one
09:39 emersion: hm
09:40 pq: then you compute the 3D LUT for the "remainder" of the original transformation, so that shaper + 3D LUT becomes equal to the original.
09:41 pq: IOW, 3D LUT = inverse shaper + original
09:42 emersion: seems like there's a bit more math/validation involved
09:42 pq: it also calls for a smoothing of the shaper
09:43 pq: IIRC, LittleCMS offers the smoothing implementation, which would be the most complicated part.
09:45 pq: I believe it's also important that shaper + inverse shaper = exactly identity, so rather than compute an inverse shaper LUT, I would reverse-evaluate the shaper instead.
09:46 emersion: i see
09:49 pq: The reverse evaluation is probably a binary search.
09:50 pq: maybe there are more efficient algorithms, but a binary search is simple to understand.
13:46 leandrohrb56: IIUC when playing with the shaper + 3DLUT on Weston, we were able to reduce the 3DLUT dimensions without loosing precision (on the test suite)
13:47 leandrohrb56: but it couldn't improve the precision
13:48 leandrohrb56: maybe on real world cases that would be different
13:48 pq: IIRC I had some reservations about those tests being fairly simple.
13:48 leandrohrb56: yes
13:49 pq: being able to reduce 3D LUT size is the point, it proves there are benefits to be had
14:00 leandrohrb56: nice, I'll work on this draft of shaper + 3DLUT and put in a MR
14:01 leandrohrb56: at the moment the code quality on this is horrible
14:23 DemiMarie: What is the advantage of giving Weston an ICC profile? Being able to offload to 3D LUTs?
14:23 DemiMarie: <pq> "being able to reduce 3D LUT size..." <- Why does one want a smaller LUT?
14:27 pq: DemiMarie, ICC profiles are the (printing) industry standard. They are used to describe displays as well, especially when profiled (measured) to produce predictable light.
14:28 pq: A Wayland compositor does not necessarily need to handle ICC profiles, but when it does, applications have it easier showing images with embedded ICC profiles.
14:29 DemiMarie: Is this because the application does not need to do the conversion itself?
14:29 pq: yes
14:30 pq: professional apps will still choose to do the conversion themselves, in order to control it in full detail, but doing so they can only target one monitor per window at a time.
14:31 DemiMarie: Ah
14:31 pq: for all other compositor outputs the compositor still needs to do an (additional) conversion
14:31 DemiMarie: Is this because compositors will not do as good a job as a professional app will?
14:32 JEEB: more like these apps and their users are more used to having the app have full control, so you just let them have it
14:32 pq: more like there are opnions and tastes of how things should be done
14:32 JEEB: :D
14:32 pq: yes, developers of those apps often believe that no-one else can get it Right(tm). :-)
14:33 pq: even if there was an objective definition of "right", which in many cases does not exist
14:34 pq: ...other compositor outputs could be e.g. RDP remote viewer or screencasting
14:34 pq: and screenshots, of course
14:35 feaneron: it's all about the attitude and confidence :)
14:35 pq: DemiMarie, smaller LUT would be less data, which is somewhat valuable in itself, but the major value is not having to explode the LUT size for more complicated transformations.
14:36 DemiMarie: pq: at what point does one give up and just use shaders?
14:36 zamundaaa[m]: Demi: this is about shaders
14:36 pq: DemiMarie, this *is* for shaders.
14:37 DemiMarie: I thought shaders did not use LUTs and used code instead.
14:37 zamundaaa[m]: ICC profiles contain LUTs
14:38 pq: ICC spec is too complicated (too many different elements and possible combinations) to implement in shaders as-is, so why bother when you can get reasonable precision with a comparably very simple code.
14:38 DemiMarie: Ah
14:38 DemiMarie: Thanks for explaining!
14:38 pq: that doesn't stop me from trying in Weston though :-P
14:39 pq: but in Weston, we choose to handle just few element types in limited combinations, and when that's not enough, Weston falls back to a 3D LUT.
14:40 pq: the fundamental problem with a plain 3D LUT is that you need N³ table elements.
14:41 pq: So if you need 1000 elements in one dimension in order to model a curve with sufficient precision, you'd need 1G elements in a 3D LUT
14:42 pq: if an element is 4 bytes which is practically the minimum viable...
14:43 pq: so, smaller LUTs are better in that they don't run out of memory
14:49 kennylevinsen: And if you’re unlucky enough to need one on both the input and output side of an output’s intermediate blending buffer… and might be using F16 for precision…
15:40 DemiMarie: pq: why is it too complex to implement in a shader? That seems like a job for a ICC → SPIR-V compiler, if that would be a reasonable option.
15:45 pq: if yo want to write such a compiler, go ahead
15:45 pq: if one wants to write such a compiler, they can go ahead :-)
15:48 pq: That might even be nice, but it's also much more work than a shaper + 3D LUT
15:49 Fxzxmic: Does wayland not allow an application to capture all keyboard input?
15:49 pq: Fxzxmic, correct.
15:50 Fxzxmic: But capturing all input from the keyboard is important for a remote desktop client.
15:51 pq: There are interfaces for that. Just not a Wayland interface free-for-all-apps.
15:51 feaneron: the Remote Desktop portal provides this functionaly on wayland
15:51 feaneron: it's not a wayland protocol or project though
15:52 Fxzxmic: Let me go find out.
15:54 feaneron: if you're an app developer, you can find the documentation page of this portal here: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.RemoteDesktop.html
15:55 kennylevinsen: Fxzxmic: why do think that is important? a remote desktop client only needs to receive input when focused, and there's a protocol for capturing focus (when granted)
15:55 kennylevinsen: (the portal that feaneron mentions is for making servers)
15:56 Fxzxmic: *there's a protocol for capturing focus* <- That's what I didn't know.
15:57 feaneron: maybe i didn't understand what you were looking after then
15:58 kennylevinsen: https://wayland.app/protocols/pointer-constraints-unstable-v1 <- this lets you able to hold the pointer within a region for stable interactions with e.g. VM console windows or remote desktop clients
15:59 kennylevinsen: you're not allow to steal focus you didn't already have, but it lets you implement the usual "pointer capture" feature of these clients so that the user doesn't accidentally leave a window while trying to trigger something at the edge of a remote screen
16:04 MrCooper: it sounded like they just want a keyboard grab, I know that exists but don't remember offhand which protocol has it
16:04 Fxzxmic: What I'm looking for is the ability to send all events from the keyboard to the remote server when the user is focused on a remote desktop window.
16:05 kennylevinsen: There's https://wayland.app/protocols/keyboard-shortcuts-inhibit-unstable-v1 to avoid local shortcuts from triggering (e.g., so that the super key doesn't get eaten locally but get forwarded)
16:05 Fxzxmic: The current e.g. Super key will be intercepted by the system and not sent to the server.
16:06 MrCooper: is that what e.g. gnome-boxes uses?
16:07 kennylevinsen: Fxzxmic: that's the latter protocol
16:07 Fxzxmic: Thanks all of you. I will check it.
16:17 MrCooper: Xwayland uses that, so should be good
16:18 ofourdan: gtk as well
16:22 DemiMarie:hopes that not too much will break without the protocol implemented (Qubes OS)
17:10 kennylevinsen: The shortcut protocol? Remote Desktop and vm consoles will be borked without it
17:11 kennylevinsen: It’ll work but be annoying in that stuff like the windows key for start menu might not work
19:23 outlander: how is the pixel unit defined in wayland?
19:29 soreau: that's a wide open question..
19:29 soreau: can you be more specific?
19:54 outlander: I mean it in the literal sense
19:54 outlander: soreau: ^
20:28 kennylevinsen: this has to be a trick question
20:47 DemiMarie: kennylevinsen: I don't think it is a trick question. It could be a question based on misunderstanding, though.
21:54 wlb: wayland-protocols/main: Heiko Becker * build: Raise required wayland-scanner version to 1.23.0 for tests https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/fe3d5448be6c meson.build
21:54 wlb: wayland-protocols Merge request !358 merged \o/ (build: Raise required wayland-scanner version to 1.23.0 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/358)
22:22 bwidawsk: Is there any protocol which would allow mirror mode to work in such a way that the client can be made aware of different refresh rates of the displays it is being presented on?
22:35 any1: The client can know when it is presented, but it does not know anything about the hardware
22:52 dviola: wow, this is getting hilarious: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1757
23:01 Ermine: well, if he wants to work on x11, why not?
23:01 kennylevinsen: if someone desperately wants to maintain it, I’m certainly not going to stopping them by warning them :P
23:02 kennylevinsen: but saying they’re “doing most of the work” is maybe a bit grand
23:03 dviola: yeah I just think it's funny, the way they respond
23:06 llyyr: they got themselves banned from the lkml for being a troll too
23:07 Ermine: it would be nice to highlight "doing most of the work" in the quote. I've interpreted the message in another way (but it can be a bug in my interpreter :))
23:07 dviola: llyyr: yes, I've seen that, with all the antivaxx stuff, etc
23:10 dviola: have they done any substantial work on X at all, or it's been mostly trivial fixes?
23:12 Ermine: from what got merged, it seems like trivial fixes
23:14 Ermine: (I've updated the xorg for $distro two months ago, so I had a chance to look at commit histories)
23:15 karl5fox: hi guys, could someone tell me how I can satisfy this requirement for using drm as a backend? "fatal: drm backend should be run using weston-launch binary, or your system should provide the logind D-Bus API"
23:15 dviola: Ermine: I see
23:16 karl5fox: I'm trying to use drm instead of the rdp-backend
23:16 Ermine: karl5fox: have you tried weston-launch binary?
23:17 karl5fox: I think I tried before with an unexpected respponse, but I will retry now to confirm :)
23:21 karl5fox: looks like the syntax is completely different and has to be run from a virtual terminal :/
23:23 kennylevinsen: karl5fox: with newer Weston you just start seatd as a daemon as root before launching Weston, or use seatd-launch -- weston (with seatd-launch having SUID)
23:23 kennylevinsen: For older Weston yeah you need weston-launch to be SUID and run that if you don’t have (e)logind installed and running (the default on systemd distros)
23:24 kennylevinsen: anywho, I’m off