07:39ambasta[m]: Hi, I've been going through https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 Would compositors providing virtual resolutions to clients make more sense? i.e. clients request for a window with some value (or range of) for resolution and aspect ratio. Clients render what they like in this virtual window. Compositors can communicate updated resolutions/aspect ratios on resizing to the closest possible allowed
07:39ambasta[m]: values. When a window is resized to an aspect ratio beyond its supported range, transparent black bars could be used to avoid breakage. Is this a sensible approach or overly complicated/infeasible? The only issue I can think of is click detection (i.e. detecting which window/component was clicked, specially w/ transparent window contents)
07:53psykose: can't applications do that already with a subcompositor
07:57ambasta[m]: psykose: Well, if they can, then why is there an insistence on absolute positioning?
08:01psykose: because they want to open windows at absolute positions being multi-windowed applications
08:01psykose: what you're describing is "what if they rewrote their entire application to do this other thing", and in that case they could find a different way to approach it
08:01psykose: maybe i'm misreading what you mean mechanically
08:07psykose: i.e. it mostly sounds like https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247#note_2109638
08:08psykose: in the end it all boils down to "nobody wants to rewrite anything in their application, but they want absolute positions", and then it goes in a loop of "try this instead" -> "nobody would do that" -> ...
08:08psykose: i don't think there's a magic gotcha suggestion that gives absolute coords but actually doesn't and everyone is happy
08:10ambasta[m]: I still don't see why they want absolute positions. Even in a multi window app, they can open multiple windows in a larger virtual window with some supported resolution/aspect ratio range
08:11ambasta[m]: And then the user/compositor can decide where and how they want this multiwindow app to be positioned
08:12ambasta[m]: As for nobody would do that, maybe implementing a playground app to highlight how this could work might be sufficient?
08:12psykose: yes, and that "big window with things in it" is an embedded compositor and they would have to port to it, and nobody would do that
08:12ambasta[m]: I see
08:12ambasta[m]: Maybe a toolkit issue then
08:14ambasta[m]: But I think the desire for applications to specify absolute positions, even on a desktop is not right. At least coming as a TWM user, who wants to play games that don't force fullscreen and crash when I resize them
08:16ambasta[m]: In any case, thanks psykose
08:22psykose: yeah, it would be a toolkit issue in some sense
08:23psykose: that's touched on in the last link; nobody would change toolkits, but how would Qt suddenly allow this to be possible with minimal changes?
08:25ambasta[m]: I think the toolkit approach is feasible (start everything in a virtual window by default). But I am not a gui developer to actually forsee the details
08:26ambasta[m]: Or maybe, just start mutiple processes (one per window) and have them communicate w/ each other in a server/client model
08:27ambasta[m]: I think embedded/toolkit/multi-process are all addressed in the MR (and thanks to this discussion, now the MR responses make sense)
08:29pq: swick[m], you have access to ISO 22028-1? That Encoding Solutions is one of the few books I actually have.
08:37kennylevinsen: ambasta[m]: GIMP is a good example of an application that went from old-fashioned multi-window to single-window btw
08:37kennylevinsen: very much possible as is, and arguably quite the UX improvement...
08:37ambasta[m]: Yep, I was so happy when it came out
08:38ambasta[m]: Also, thank you for greetd
08:38kennylevinsen: glad you like it :)
08:39swick[m]: pq: eh, no, the summary paper of the standard
08:39pq: ah
08:40JEEB: I am sad ISO stopped N-Documents being accessible. they already had a setting per-document whether it was private or not :<
11:05wlb: weston Merge request !1366 opened by Michael Tretter (m.tretter) backend-pipewire: add support for rendering to DmaBufs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1366
11:36wlb: weston Merge request !879 closed (gl-renderer: FBO renderbuffer and DMA-BUF import)
11:45wlb: weston Merge request !1367 opened by Marius Vlad (mvlad) compositor/main: Lazy align the RDP output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1367
11:50wlb: weston/main: Philipp Zabel * ci, backend-vnc: update to Neat VNC 0.7.0 https://gitlab.freedesktop.org/wayland/weston/commit/8895b15f3dfc .gitlab-ci.yml .gitlab-ci/build-deps.sh libweston/backend-vnc/meson.build libweston/backend-vnc/vnc.c
11:50wlb: weston/main: Philipp Zabel * backend-vnc: Implement output resizing https://gitlab.freedesktop.org/wayland/weston/commit/690beab47561 libweston/backend-vnc/vnc.c
11:50wlb: weston/main: Philipp Zabel * compositor, backend-vnc: Allow to disable output resizing https://gitlab.freedesktop.org/wayland/weston/commit/d1df848d94a6 compositor/main.c include/libweston/backend-vnc.h libweston/backend-vnc/vnc.c
11:50wlb: weston/main: Philipp Zabel * man: Document VNC output section https://gitlab.freedesktop.org/wayland/weston/commit/46d3487abf4b man/weston-vnc.man
11:50wlb: weston Merge request !1051 merged \o/ (VNC output resizing https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1051)
12:20wlb: weston Issue #819 closed \o/ (Surfaces should be reassigned to another output when their drm output goes to sleep https://gitlab.freedesktop.org/wayland/weston/-/issues/819)
12:20wlb: weston Issue #818 closed \o/ (weston_surface_assign_output() should prefer primary-backend outputs as a tie-breaker https://gitlab.freedesktop.org/wayland/weston/-/issues/818)
12:20wlb: weston Issue #818 closed \o/ (weston_surface_assign_output() should prefer primary-backend outputs as a tie-breaker https://gitlab.freedesktop.org/wayland/weston/-/issues/818)
12:20wlb: weston Merge request !1363 merged \o/ (Try harder to keep an active primary output for surfaces https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1363)
12:20wlb: weston Issue #819 closed \o/ (Surfaces should be reassigned to another output when their drm output goes to sleep https://gitlab.freedesktop.org/wayland/weston/-/issues/819)
12:20wlb: weston/main: Derek Foreman * libweston: Consider output power state when selecting primary https://gitlab.freedesktop.org/wayland/weston/commit/d3fa809c55a6 libweston/compositor.c
12:20wlb: weston/main: Derek Foreman * libweston: Reconsider view primary output on output power change https://gitlab.freedesktop.org/wayland/weston/commit/305e954f76fa libweston/compositor.c
12:20wlb: weston/main: Derek Foreman * libweston: Prefer primary backend when assigning outputs to views https://gitlab.freedesktop.org/wayland/weston/commit/176a413ef0b6 include/libweston/libweston.h libweston/compositor.c
14:23wlb: weston Issue #821 opened by Michael Tretter (m.tretter) backend-drm: client view leaves remnant in rendered output after moving it to plane https://gitlab.freedesktop.org/wayland/weston/-/issues/821 [DRM/KMS backend]
14:54wlb: weston Merge request !1368 opened by Derek Foreman (derekf) libweston: fix output clamp helper https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1368 [Core compositor], [Input]
17:41wlb: weston Merge request !1369 opened by Derek Foreman (derekf) backend-drm: Fix visibility calculation https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1369 [Core compositor]
17:55wlb: wayland-protocols Merge request !248 opened by Derek Foreman (derekf) commit-timing-v1: Add new protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/248
18:38any1: For commit-timing-v1, will the compositor just hold onto buffers until they reach their presentation deadline?
18:39any1: What happens if a client submits buffers with timestamps far in the future? Do you just run out of vram? :)
18:40emersion: that's no different from a client allocating many buffers
18:40any1: Well, I suppos, but it's an easier mistake to make, I think
18:40emersion: or creating dmabuf buffers without committing them
18:42any1: This might be up to implementors, but shouldn't there be a reasonable limit for how many frames can be queued at a time?
18:42emersion:shrugs
18:42emersion: in general clients have a swapchain
18:42emersion: and the swapchain has a maximum number of buffers
18:43emersion: if anything, this is compositor policy, and something i wouldn't want to bother myself with in wlroots
18:43any1: hehe, I have no such limits in my swapchains. :)
18:44emersion: i would recommend you add such a limit, then
18:49any1: Anyway, it would be nice the have a protocol like that.
20:05wlb: wayland-protocols Issue #161 opened by i509VCB (i509VCB) ext protocols technically can't be rejected with nack https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/161
20:05bl4ckb0ne: oh no
20:06i509vcb:bringer of chaos and legalistic readings of rules
20:09vyivel: if ext could be nacked there would be no point to have it in the first place
20:10i509vcb: My question may be completely stupid, but it's a thing I guess should be asked
20:12wlb: wayland-protocols Issue #161 closed \o/ (ext protocols technically can't be rejected with nack https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/161)
20:20ManMower: any1: commit-timing-v1 doesn't provide a queue
20:23any1: If the compositor doesn't hold onto buffers until their pts passes, I don't really see the point.
20:23ManMower: commit-queue-v1 will be an MR sometime next week ;)
20:25ManMower: I just didn't think "protocol to add timestamps to pending commit state" and "protocol to make pending commit state a queue instead of a single entry" were things that must be in the same protocol
20:26ManMower: (and I think the previous attempts to timestamp have died in part because they overreached)
20:28any1: Smaller composable units are better than big things with knobs and dials
20:28ManMower: yeah
21:12wlb: wayland-protocols Merge request !249 opened by Matthias Klumpp (mak) Draft: Add xdg-alignment protocol for window-placement control https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/249
22:31wlb: weston Merge request !1370 opened by Leandro Ribeiro (leandrohrb) Do not represent stock sRGB color profile with NULL https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1370 [color-lcms plugin], [Colour management]