07:29 Net147: I am trying to modify weston to have area of twice the screen width (1600 pixels) and scale it to half (800 pixels) when displaying on 800x480 screen - https://pastebin.com/8JhDwTyW. however, it seems to crop off any content on the right half of the area available. any ideas?
07:35 kennylevinsen: Net147: that's because the output buffer you composite to is still 800x480
07:36 kennylevinsen: So there's nothing past the edge
07:37 Net147: kennylevinsen: the DRM output is 800x480. the co-ordinate system is 1600x480 and I adjust the output matrix to scale by 0.5 along x.
07:37 Net147: kennylevinsen: any suggestion where I can modify the buffer dimensions to fix it?
07:45 kennylevinsen: hmm on second thought, that matrix is probably used during composite and should be sufficient...
07:49 kennylevinsen: you probably do this where the output is set up, e.g. weston_output_enable or similar, and make sure nothing else is messing with your matrix
07:50 kennylevinsen: maybe overwriting weston_output_update_matrix
07:52 Net147: moving assignment of output->width from weston_view_set_output into weston_output_enable worked
07:52 Net147: thanks!
07:58 Net147: actually, spoke to soon. didn't work
07:59 Net147: putting it in weston_output_enable is too late so it doesn't do anything
08:01 pq: there are many points inside weston_output_enable(), and it needs to be set at the right point. That's why I recommended modifying weston_output_transform_scale_init().
08:05 pq: you can set output->width,height there, and that should then propagate to everything else that is derived from logical output size.
08:06 pq: the idea is to have logical output size 1600x480, and the framebuffer size and video mode 800x480. Then the output matrices to achieve the down-scaling directly during composition.
08:07 pq: Net147, ^
08:07 Net147: pq: okay what I did is set output->width at end of weston_output_transform_scale_init, then I put the weston_matrix_scale by 0.5 along x in weston_output_update_matrix right before the invert
08:07 Net147: pq: that seems to work
08:07 pq: cool
08:08 kennylevinsen: pq to the rescue, my caffeine blood levels are not yet at operational levels :)
08:08 pq: kennylevinsen, I'm surprised you know weston insides that well :-)
08:11 pq: Net147, things to verify (if they apply to you): input coordinates, damage regions, direct scanout of client buffers
08:12 pq: if any of those is broken and you're not yet using the latest Weston release, an upgrade could be worth it, or even testing with the git main branch version.
08:13 Net147: pq: input co-ordinates seem fine
08:14 pq: in the recent past (months, years, I forget) there has been an effort to unify and consolidate all calculations related to this kind of scaling, so it's possible an old Weston would need more changes.
08:14 Net147: pq: I am using weston 12.0.2
08:14 pq: good
08:15 Net147: pq: running Chromium from another system using waypipe and SSH to display locally
08:40 zzag: daniels: what is expected to happen if wl_egl_resize() is called while painting to that window? is the window going to be resized immediately or on the eglMakeCurrent() or something?
08:41 pq: zzag, the resize will pend until after eglSwapBuffers and needing a buffer the next time.
08:42 zzag: okay thanks
08:43 pq: I do hear that eglMakeCurrent may unnecessarily latch the new size in, meaning that you have to swap buffers again before you are able to realize a new size again.
08:44 pq: but that's only when the current size is modifiable, that is, between a swap buffers and needing a buffer the first time after swap
08:46 jadahl: pq: zzag: the resize will happen either at the next time a buffer is actually needed (e.g. when querying the size or queuing a draw call). the size might be up to date already the next eglSwapBuffer() but could also be the next if one did QuerySize();resize();draw();SwapBuffers();
08:49 pq: to me it would be logical if querying EGLSurface size would lock the size for the current frame. Just like querying buffer_age determines the buffer and size.
08:49 pq: but I don't know what actually happens today
08:49 pq: and the X11 legacy in the spec probably allows size to change even mid-rendering for all I know
08:50 jadahl: pq: yes, thats what I meant
08:50 jadahl: in the above example, the draw() would have to use the size from the query, not from the resize
08:50 pq: ok, I understood the opposit
08:50 jadahl: if query was a draw call, it'd be the same, the size would be locked to what was before the resize
08:52 jadahl: zzag: fwiw, there was a bug in wayland-egl (nvidia) where the resize was always postponed until after the next eglSwapBuffers()
08:52 jadahl: it reproduced with both qt and gtk
08:54 pq: The most predictable point to resize is immediately *before* the previous frame's SwapBuffers, but that might be difficult to arrange.
08:56 jadahl: I'd say the most easily reasoned about and predictable result is doing it *after* SwapBuffers()
08:56 jadahl: it'd raise fewer eyebrows and the risk of any draw calls or querying sneaking in is minimal
08:57 jadahl: IIRC in gtk we resize whenever, but only ever do draw calls and querying in a single dispatch without any resize allowed in the middle
08:58 pq: if you do it after swap, what guarantees do you have that something did not already query buffer_age or something?
08:59 pq: *immediately* after swap is fine, too
09:01 pq: but if you swap, do something else "harmless", and then resize, it's much more difficult to be sure it always works
09:01 pq: and if a toolkit allows running user code in between, it's nearly impossible to guarantee
09:18 zzag: jadahl: okay, that's what I see. sometimes SwapBuffers() commits a buffer with new size rather than the one you started at MakeCurrent()
10:08 wlb: wayland Merge request !334 closed (Draft: server: Add support to fetch the process name of wayland clients)
13:45 wlb: weston/main: Loïc Yhuel * libweston: Do not include private headers in shell-utils.h https://gitlab.freedesktop.org/wayland/weston/commit/c00ef0a5ce00 include/libweston/shell-utils.h libweston/shell-utils/shell-utils.c
13:45 wlb: weston Merge request !1354 merged \o/ (libweston: Do not include private headers in shell-utils.h https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1354)
14:38 i509vcb: orowith2os[m]: Technically there might be cases where a surface MUST be directly scanned out, but that's more DRM related (not direct rendering) and probably not something the Wayland members themselves would want to support
14:40 i509vcb: although if such a content type selection were possible then there would need to be feedback that scanout possibly failed
14:45 i509vcb: For a compositor implementation, if the serial overflows a naive implementation of checking of a configure was acked using >= would fail. I'm guessing the compositor would need to either ensure no more than u32::MAX - 1 configures exist at once or maintain an internal overflow counter?
15:25 wlb: weston Issue #805 closed \o/ (Segfault in weston_desktop_surface_get_maximized in desktop-shell during output resize https://gitlab.freedesktop.org/wayland/weston/-/issues/805)
15:25 wlb: weston Merge request !1348 merged \o/ (desktop-shell: Don't process surfaces under destruction during output resize https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1348)
15:25 wlb: weston/main: Alexandros Frantzis * desktop-shell: Don't process surfaces under destruction during output resize https://gitlab.freedesktop.org/wayland/weston/commit/7dcde16f22f1 desktop-shell/shell.c
15:27 wlb: weston Merge request !1039 closed (kiosk-shell: Respect xdg surface relationships when activating surfaces.)
15:36 wlb: weston/main: Loïc Yhuel * gl-renderer: Do not attach the first buffer twice https://gitlab.freedesktop.org/wayland/weston/commit/623646bbfda7 libweston/renderer-gl/gl-renderer.c
15:36 wlb: weston Merge request !1353 merged \o/ (gl-renderer: Do not attach the first buffer twice https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1353)
18:40 orowith2os[m]: i509vcb: the requirements and "might be" are making me think there aren't any cases where direct scanout is a complete must-have
18:40 orowith2os[m]: anything that might fit into there I can look at?
18:42 kennylevinsen: no, clients do not get to have that degree of control
18:43 kennylevinsen: Scan-out is purely compositor decision when possible, and dmabuf hints tell you what graphical configuration it prefers
18:43 kennylevinsen: It might think another client is more important to scan-out for example