01:17 TimRex: Morning all. Quick question about wayland surface formats.. for any given surface returned by wl_compositor_create_surface(), how would I go about determining the pixel format for that surface?
01:20 TimRex: I'm encountering a scenario where eglChooseConfig() returns framebuffer configurations that are not valid for the native window surface
01:20 TimRex: That is.. eglCreateWindowSurface() fails with debug message indicating "Unsupported surfacetype/colorspace configuration"
01:21 TimRex: I can spin through the remaining configs until I get a match, but it would be nice to direct eglChooseConfig with something more precise based on the surface format provided by the compositor
09:25 wlb: weston Issue #881 closed \o/ (app_id and title are set after setting surface id https://gitlab.freedesktop.org/wayland/weston/-/issues/881)
10:18 wlb: wayland-protocols/main: Sebastian Wick * cursor-shape-v1: Does not advertises the list of supported cursors https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/aac8841f8298 staging/cursor-shape/cursor-shape-v1.xml
10:18 wlb: wayland-protocols Merge request !289 merged \o/ (cursor-shape-v1: Does not advertises the list of supported cursors https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/289)
11:07 wlb: wayland-protocols/main: Simon Ser * xdg-shell: recommend against drawing decorations when tiled https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/a5536f9a8cd7 stable/xdg-shell/xdg-shell.xml
11:07 wlb: wayland-protocols Merge request !257 merged \o/ (xdg-shell: recommend against drawing decorations when tiled https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/257)
11:23 WhyNotHugo: content-type-v1 has types (photo,video,game). Isn't "text" an obvious additional missing choice here?
11:24 emersion: it mirrors the HDMI spec, IIRC
11:24 emersion: if there is a use-case for another type, can be added
11:26 kennylevinsen: I guess for stuff like auto low-latency mode
11:26 pq: the xml mentions scaling modes, latency and image processing
11:28 pq: New types can be added if there is some idea what a compositor could do with it. If HDMI does not have a code point to forward the information to a TV, then what else could a compositor do?
11:29 wlb: weston/main: Pekka Paalanen * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/efec55cf62f798e6a4ec1fa7fc177be6720cf061...de8e3168f033e835e90a8571ec787ffbe171bd26
11:29 wlb: weston Merge request !1390 merged \o/ (Add support to some color curves in weston_color_curve https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1390)
12:05 zamundaaa[m]: WhyNotHugo: I mentioned that as a possibility in the MR adding it, but left it up for later
12:07 zamundaaa[m]: I wouldn't be opposed to having it fwiw
12:09 pq: I'm curious, how would you handle it?
12:11 zamundaaa[m]: There's two use cases I can think of
12:12 zamundaaa[m]: one is the feature that phones have, where they make e-book reader content aggressively follow the whitepoint of your surroundings
12:13 zamundaaa[m]: the other is picking an up/downscaling algorithm that works better for text. Might be quite niche, but when you mirror a display to a projector, not that niche perhaps
12:14 pq: Interesting.
12:14 pq: Would either need to assume a black&white or gray-scale image to work well?
12:15 zamundaaa[m]: For best results, probably
12:16 zamundaaa[m]: Text on a background image might be harder to process for the scaling algorithms. Then again, it's also harder to process for humans in general
12:17 pq: what about a code editor with colored syntax highlighting?
12:18 pq: Maybe the category shouldn't be "text" but "black&white text and art"?
12:18 pq: line art?
12:18 zamundaaa[m]: Colored syntax highlighting should work fine. I'm not an expert on text scaling, but I would assume it works mostly on contrast instead of just black and white
12:21 pq: alright
12:27 emersion: does anyone have an ICC profile at hand with a multiProcessElementsType?
12:31 pq: emersion, Weston test suite generates some very simple ones at runtime.
12:31 emersion: i'm looking specifically for the most complcated ones :P
12:31 emersion: complicated*
12:31 pq: I don't think there is an upper limit on complexity
12:32 pq: the number of MPE-type elements in a uint32_t
12:32 pq: *is
12:33 emersion: oh, sorry, i misunderstood
12:33 emersion: i thought you were saying that Weston had simple ICC files
12:34 pq: Weston test suite generates some very simple (2 elements) MPE-based ICC files at runtime.
12:34 emersion: cool, maybe i'll try to have a look at that then
12:34 pq: it uses LittleCMS for that
12:34 pq: build_lcms_clut_profile_output() is the one crafting them
12:35 pq: specifically one parametric curve set + one 3D LUT
12:39 pq: FYI, Marti and Graeme think that a shaper (per-channel 1D LUT) + 3D LUT should be enough for approximating any color transformation, if you optimize both together for the pipeline to approximate.
12:39 pq: Personally I'm not that optimistic.
12:39 emersion: ah, i was wondering about that
12:40 emersion: mstoeckl_: ^
12:40 emersion: pq, you think how many more elements would be needed?
12:40 pq: It depends on the transformation.
12:40 emersion: pq, is there an optimizer already?
12:41 pq: I don't have an optimizer for that.
12:41 pq: If your input space is optical, then a uniformly sampled 1D LUT might need far too many elements.
12:41 emersion: what is your plan for Weston?
12:42 pq: you can read our discussion in https://sourceforge.net/p/lcms/mailman/lcms-user/thread/20240315122239.3580e790%40eldfell/#msg58749089
12:43 pq: don't mind the BPC stuff in the beginning, the discussion departs soon enough
12:44 pq: Currently in Weston we let LittleCMS produce a cmsPipeline object, which is essentially a chain of mathematical operations (cmsStage). Then we have an optimizer that repeatedly combines adjacent matrices together, and does the same with curve sets when possible.
12:45 pq: Once nothing can be merged anymore, it attempts to fit the remaining pipeline into our fixed-function color-pipeline representation.
12:45 pq: That fixed-function color pipeline is roughly following KMS design, and has a GL-renderer implementation as well.
12:45 emersion: i see, what does the fixed ppelne look like?
12:46 emersion: LUT, matrix, LUT then?
12:46 pq: more or less, yeah, so far
12:46 pq: we use one such pipeline for input-to-blend transformation, and another for blend-to-output
12:47 pq: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/color.h?ref_type=heads#L245-276 is the pipeline definition.
12:48 pq: Marti and Greame argue, that this is all useless, and a 3x 1D LUT + 3D LUT is enough.
12:51 pq: I'm fairly sure that trying to model inverse PQ EOTF as a uniformly distributed 1D LUT is going to be futile, given our findings in https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/plots/index.md#transfer_function_lut1d_error_tapspy for the simple gamma 2.2 curve, and assuming that the PQ curve is even more difficult.
12:52 pq: Luckily inverse EOTF only appear in blend-to-output pipelines, and usually alone in there, so you could implement that separately analytically, and maybe, just maybe the LUT combination is enough for the input-to-blend side.
12:55 pq: There is that white paper from Marti Maria mentioned in the email thread, where he explains how to optimize the LUT combination.
12:59 pq: Anyway, best to read though the email thread, and make your own conclusions.
13:01 emersion: hm, thanks
13:01 pq: I guess the BPC discussion is a good note of the quirkyness of ICC handling. :-)
13:02 vaxry: hm, why is this hanging? https://github.com/hyprwm/Hyprland/issues/5123#issuecomment-2019311068
13:05 pq: vaxry, why is a KMS atomic commit ioctl hanging? A kernel bug or a GPU crash, probably.
13:05 emersion: this is the proprietary NVIDIA driver
13:05 emersion:stops looking
13:05 pq: oh, blame them then
13:06 vaxry: oh, havent even noticed
13:06 vaxry: my bad, sorry!
13:06 pq: it's definitely not userspace's fault in any case
13:06 vaxry: yeah I was weirded out by this
13:11 pq: Even if it was a FOSS driver, atomic commit getting permanently stuck is a kernel bug. On a GPU crash or other serious error it could take some timeout (seconds? a minute?) to return.
13:12 pq: (or faulty hardware as always)
13:15 WhyNotHugo: I mentioned the "text" variant content-type-v1 mostly thinking of eink displays.
13:24 kennylevinsen: WhyNotHugo: e-ink displays are pretty low-level, with the implementer controlling the exact waveforms used to set pixels and handle clearing. A controller could use different waveforms for text, but without a high-level standardized interface that's all extremely implementation-specific...
16:09 swick[m]: pq: so, I think I'm done with all the linting for now :P
16:10 swick[m]: was quite interesting and I would definitely add some of that stuff for new projects
16:11 swick[m]: let's see how good all of that is in practice though...