07:12wlb: weston Merge request !1464 merged \o/ (Add API to create color profile from parameters https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1464)
07:12wlb: weston/main: Pekka Paalanen * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/8288cead93f372f065bdc7884ac00a9ad6f82f15...2c44a4ea4a9b9d741148b698e4056b73351c7c3d
08:39wlb: weston Merge request !1547 opened by Pekka Paalanen (pq) gl-renderer: fix texcoord in shader desc https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1547
08:40wlb: weston Merge request !1548 opened by Pekka Paalanen (pq) color-lcms: print ICC profile class on error https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1548 [color-lcms plugin]
09:56wlb: weston/main: Pekka Paalanen * gl-renderer: fix texcoord in shader desc https://gitlab.freedesktop.org/wayland/weston/commit/2b6fe57e81af libweston/renderer-gl/gl-shaders.c
09:56wlb: weston Merge request !1547 merged \o/ (gl-renderer: fix texcoord in shader desc https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1547)
10:29wlb: weston Merge request !1549 opened by Pekka Paalanen (pq) frontend: remove useless if (section) https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1549 [Weston frontend]
11:58wlb: wayland-protocols/main: Simon Ser * members: trim trailing comma https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/903f85708e1b MEMBERS.md
11:58wlb: wayland-protocols Merge request !319 merged \o/ (members: trim trailing comma https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/319)
13:17mwhoosier: pq: Thought maybe I could catch you here rather than mess around on wayland-devel for a moment.
13:18pq: mwhoosier, very quickly at this time, I'm near my end of day. :-)
13:20mwhoosier: pq: Haha, okay. Should be quick! Just wanted to close out this topic about the restrictions on making updates to the KMS scene that a writeback connector is fed by. One (implied?) suggestion from the dri-devel people was to switch e.g. the DP-1 connector to a different CRTC while the writeback connector drains out its previous frame. (a) Is that even legal to bounce back and forth between two CRTCs repeatedly? (b) Would that lead to a modeset on each f
13:21pq: mwhoosier, your message was truncated for being too long. But yeah, re-routing connectors takes a modeset I believe, and you would still be touching the old CRTC because of taking the connector away from it.
13:22Calandracas: does color-lcms work for all backends? If I run weston as a nested wayland client (for example, as a kiosk shell within sway), would the colour pipeline still apply the appropriate transformations?
13:22mwhoosier: pq, Okay, thanks!
13:22pq: mwhoosier, I read the discussion, and while I don't remember my interpretation of that comment, I did not interpret it like you did.
13:23mwhoosier: pq: you mean Daniel Vetter's remark about using a different CRTC?
13:24pq: yeah
13:24pq: oh, I think it was about using another CRTC from the beginning, all the time
13:25pq: If you had enough planes, you could program two different CRTCs the same way, for different connectors.
13:25mwhoosier: I thought that my interpretation was probably wrong, so that's fine. I've never seen any DRM master code bounce around between CRTCs between frames, so it seems a longshot that's what Daniel was saying.
13:26pq: mwhoosier, yeah, I think it needs a modeset, and that ruins everything for a start.
13:26mwhoosier: Huh, I'm not immediately seeing why having two different connectors would help anyway. It's a specific physical output whose contents we would want to stream anyway.
13:27pq: Calandracas, umm... IIRC, yes
13:27mwhoosier: pq: Anyway, thanks for all the help on this one.
13:28pq: Calandracas, color-lcms is not specific for any backend itself. It's up to the frontend to configure output profiles and enable color management.
13:29pq: Calandracas, color-lcms does depend on GL-renderer and GL ES 3.0.
13:30pq: mwhoosier, I mean program two different CRTCs to produce the same image; one feeds the real connector, another feeds the writeback connector.
13:30pq: then they can update independently
13:30pq: writeback may still be low frame rate though
13:30mwhoosier: pq: Oh, okay. Fair. But that won't help with the secret use-case I talked about in the email, where some other virtualized OS is stuffing contents into the planes behind KMS's back.
13:31pq: indeed
13:31pq: dri-devel people didn't get that memo yet, I think :-)
13:31daniels: shhhh
13:31mwhoosier: No need to horrify them...
13:31mwhoosier: It's not as though I don't realize what a ghastly corporate engineering thing this is ;)
13:49Calandracas: pq, wow this is awesome. For some reason I didn't think of running applications like gimp or rawtherapee within weston as a nested wayland client, but this looks like it works very well
13:58pq: Calandracas, heh, as long as you don't want to show bigger than sRGB gamut. :-)
14:01pq: Calandracas, OTOH, if you can set up color management in the app, x11 style, that should be usable too, without Weston in between. The only assumption needed is that the desktop does not mangle pixels, or at least does not change how it mangles pixels.
14:02pq: The X11 style color management has always been possible in a Wayland-based DE, maybe sans VCGT.
14:04pq: When you use Weston's color management, it assumes all windows are sRGB when protocol says nothing else. And there is no app using the protocol yet, aside from weston-image in git main branch.
14:04pq: (Weston does not implement the parametric image description interfaces yet.)
14:05Calandracas: hum
14:05Calandracas: yeah I have a DCI-P3 monitor so would want to full gammut
14:06pq: then you need apps to tell Weston, when they are targeting full gamut - protocol is needed for that, in the Wayland color management style
14:07pq: in X11 style, you can make it just work for apps that do color management themselves, and all other apps will look too saturated.
14:09pq: When testing Weston from git, if you have PNG or JPEG with embedded ICC profiles, showing them with weston-image while setting a P3 ICC profile for the output in Weston, should make a nice demo.
14:10pq: unfortunately, that is the extent of the implementation we have in Weston so far
14:11wlb: weston/main: Derek Foreman * renderers: pull dmabuf initial setup out of attach https://gitlab.freedesktop.org/wayland/weston/commit/83b37c0ac469 libweston/ compositor.c libweston-internal.h renderer-gl/gl-renderer.c
14:11wlb: weston Merge request !1542 merged \o/ (compositor: Check buffer validity before attaching to renderer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1542)
14:11pq: Happy hacking, till tomorrow! .o/
16:48wlb: weston/main: Derek Foreman * clients/constraints: Fix up buffer handling https://gitlab.freedesktop.org/wayland/weston/commit/2819cb51c6c9 clients/constraints.c
16:48wlb: weston Merge request !1544 merged \o/ (clients/constraints: Fix up buffer handling https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1544)
16:56wlb: weston Merge request !1550 opened by Philipp Zabel (pH5) compositor: do not clear dmabuf pointer for busy buffers https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1550
23:36KarenTheDorf: So... there's the cursor shape protocol in staging. But there's no point in it if you have to support non-supporting compositors and implement a fallback to wayland-cursor or something? Am I missing anything?
23:42Nefsen402: The benefit of cursor shape is to have consistent size/style of the cursor
23:42Nefsen402: Compositors and clients may handle scaling differently and so the cursor may change sizes as the cursor changes from a compositor controlled one to a client one
23:43Nefsen402: Also, basically no client supported animated cursors
23:43Nefsen402: With cursor shape, as long as the compositor supports it, it will work
23:45KarenTheDorf: So I should probabally change to cursor shape where supported?
23:47KarenTheDorf: I go by XCURSOR_SIZE in the environment for the size? Is that not always correct? (I suppose it can't be, on multi-monitor setups with per-monitor scaling)
23:47Nefsen402: XCURSOR_SIZE afaik isn't even a stardard, it just sort of a thing clients started doing
23:47Nefsen402: and when you throw display scaling (hidpi) things get more complex
23:48Nefsen402: You should support the protocol if possible
23:48alice: i started using 1.5 scale and now i see like 3 separate cursor sizes... the only thing that gets it right is qt and things that support cursor-shape
23:49alice: definitely support if if you don't mind maintaining two paths :P
23:50Nefsen402: I added cursor shape here to fuzzel with build options to support older wayland protocol: https://codeberg.org/dnkl/fuzzel/pulls/251
23:50KarenTheDorf: Well, wayland is copying the most popular OS there with having 3 different sizes for everything depending how well applications support hidpi scaling.
23:50Nefsen402: it isn't a big deal at all
23:51KarenTheDorf: Supporting shape looks a lot simpler than wayland-cursor, it's just not ubiquitous support. I assume Mutter is not going to start supporting it since it's not a problem for GTK based apps.
23:51alice: there's an open pr for mutter actually
23:51alice: they probably will
23:52alice: and if mutter does gtk will probably support it as a client too
23:52Nefsen402: ofc mutter doesn't support it yet
23:52Nefsen402: Why am I surprised
23:54KarenTheDorf: Over on the vulkan discord, gnome users asking "How do I get (non-awful) window decorations on wayland" is a perrenial question.
23:55KarenTheDorf: Normally point them at libdecor now, or suggest just running on fullscreen if they are on GNOME and don't/can't use XWayland.
23:55Nefsen402: There's a solution for that: libdecor
23:55Nefsen402: But it's a client side thing
23:55KarenTheDorf: Indeed, I just said that :)
23:55Nefsen402: Indeed
23:56KarenTheDorf: 100% get why CSDs should be the default though, they are a lot nicer from a compositor's POV. I'm just not a compositor author.
23:57Nefsen402: There are a couple of advantages to purely SSDs like for tiling window managers