08:04wlb: weston Merge request !1375 opened by Marius Vlad (mvlad) libweston: Ignore subsurface offsets https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1375 [Core compositor]
08:06wlb: weston Issue #824 closed \o/ ([imx8mp]Weston-rdp screen share issue https://gitlab.freedesktop.org/wayland/weston/-/issues/824)
08:25wlb: wayland Merge request !347 opened by Kirill Primak (vyivel) protocol: improve wl_subsurface.{set_position,place_above} description https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/347
08:31wlb: wayland Merge request !348 opened by Hongfei Shang (checkmode) scanner: extern struct should use protected visibility https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/348
09:00wlb: weston Issue #832 opened by Himanshu Bhavani (himanshu.d) VNC on imx8 https://gitlab.freedesktop.org/wayland/weston/-/issues/832
11:54emersion: note, gitlab is semi-borked atm, i wouldn't recommend posting/writing anything, might get lost
13:20wlb: weston Merge request !1376 opened by Derek Foreman (derekf) xwm: Fix accidental resizing of windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1376 [XWayland]
13:43wlb: wayland Merge request !348 closed (scanner: extern struct should use protected visibility)
13:49emersion: zamundaaa[m]: so, just fyi, i made this thing https://gitlab.freedesktop.org/emersion/libicc
14:08pq: emersion, I'm curious, how will it be different from LittleCMS 2? What made you start on that?
14:09emersion: lower level, raw access to ICC
14:10emersion: less features, simpler
14:10pq: even lower?
14:11emersion: i mean, currently you need to write LCMS plugins and other hacks
14:12pq: true
14:12pq: but starting from scratch seems... a lot, if just for that reason
14:14emersion: i don't think it's that much work, for my purposes
14:14pq: Interesting to see how that works out.
14:17emersion: i already have everything i need for v2
14:20zamundaaa[m]: emersion: I don't think I can adopt that this short before the Plasma 6 feature freeze, but I am interested in using it later on
14:20zamundaaa[m]: Especially if we can add some higher level APIs too, like getting the effective primaries + whitepoint of a display profile, or inverting curves
14:21wlb: wayland Merge request !349 opened by Hongfei Shang (checkmode) scanner: export interface should use protected visibility https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/349
14:21emersion: yup, makes sense
14:47pq: inverting LUT curves can be tricky for precision; Weston does do that today with LCMS, but I'm not sure how far that carries. Parametric curves are better anyway, if available.
14:49pq: a Display class profile can (and for measured monitors, does) include a 3D LUT, which means trying to extract primaries is probably going to hurt, assuming the user has a reason to use a measured profile.
14:50zamundaaa[m]: The profile always contains primaries directly too, even if it has a 3D lut
14:50pq: but are they supposed to be used *instead*?
14:51pq: are you still going to use the 3D LUT?
14:52pq: ICC profiles seem to be able to contain multiple levels of information, where more sophisticated CMMs would use the more precise information.
14:54zamundaaa[m]: The spec is pretty clear about that: Use BToD tags if available, BToA if not, and the primaries if that isn't available either
14:54pq: right
14:54zamundaaa[m]: In the current KWin impl I'm using the primaries for the blending color space; the 3D lut from the ICC profile gets applied post-blending
14:55pq: interesting
14:56pq: our Weston approach is to take a Display profile as an opaque box, and approximate a linearization of that to produce the blending space.
14:57pq: Graeme Gill suggested this, as the blending space does not need to be too precisely anything specific, as long as it is light-linear enough.
14:58pq: and as long as the linearization can be undone precisely enough, which may be of question in Weston at the moment.
14:58pq: exactly because representing the inverse of a LUT as a LUT is prone to problems
15:04pq: Maybe Weston should attempt fitting a power function to the recovered linearization LUT in order to improve roundtrip precision...
15:06pq: use the curve in both directions
15:06Consolatis: Small question about xdg-shell: There is a xdg_surface.set_window_geometry() request defined. It is used by a (Qt) client which then later gets a configure request from the compositor, ACKs the request, updates its viewporter and buffer size but does *not* update the window_geometry. Is that a client bug and how should compositors reacts to this, keep using the outdated geometry (so we ignore drop shadows and friends) or just update it manually ba
15:06Consolatis: sed on the new viewporter / buffer sizes?
15:08vyivel: you are supposed to ignore drop shadows and friends
15:08vyivel: window_geometry is the geometry without that
15:10Consolatis: vyivel: I am aware of that. The question is what should happen if a client does not keep it in sync with size changes
15:10vyivel: report a bug to the client i presume
15:11Consolatis: so it *is* a client bug then
15:11vyivel: probably; what program is this?
15:11Consolatis: random ones, all Qt based
15:12Consolatis: it also doesn't seem to happen all the time so there might be some race condition within Qt itself that sometimes prevents sending the new window_geometry
15:12vyivel: sounds like it
15:13vyivel: generally if the buffer is resized the window geometry should be updated as well so yeah a qt bug i assume
15:14Consolatis: for now we'll likely just add a workaround and check if the reported extents of the surface match those of our configure request and if yes use those instead of the window geometry. Feels pretty hacky though.
16:03wlb: weston Merge request !1377 opened by Derek Foreman (derekf) xwm: Fix accidental resizing of windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1377 [XWayland]
17:13wlb: weston Merge request !1378 opened by Marius Vlad (mvlad) backend-x11: Move back-end removal to the destroy function https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1378 [Nested X11 backend]
18:24DemiMarie: @_oftc_Consolatis:matrix.org: have you reported the bug to Qt itself?
18:53Consolatis: I'd reply with a "no" but.. well. matrix bridge ¯\_(ツ)_/¯
20:07Riolku: Hi! What's the difference between wl_shm.format abgr16161616 and abgr16161616f
20:08emersion: one is unsigned, other is float
20:08bwidawsk: Is there a valid case where https://wayland.app/protocols/wayland#wl_shm_pool:request:create_buffer:arg:offset can be negative?
20:08Riolku: 16 bit float?
20:10bwidawsk: I do not see an error for such a thing, so I assume it's valid
20:13emersion: or fixed point? i don't remember
20:13emersion: bwidawsk: i don't think it's valid. i think the error is invalid_size?
20:13bwidawsk: just format/stride afaict
20:13bwidawsk: well, maybe wayland.app isn't up to date
20:14bwidawsk: hmm, nope, seems up to date there
20:14bwidawsk: oh
20:15bwidawsk: invalid_stride is "size of stride"
20:15bwidawsk: okay
20:59Company: Riolku: 16bit float aka half-float
21:00Company: Riolku: https://en.wikipedia.org/wiki/Half-precision_floating-point_format
23:46Riolku: interesting ty