ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
RAOF has quit [Remote host closed the connection]
sevz has joined #wayland
RAOF has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
carlos_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
nerdopolis has joined #wayland
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #wayland
RAOF has quit [Remote host closed the connection]
chris- has quit [Quit: Hosted by www.ZNCHost.com]
chris_ has joined #wayland
RAOF has joined #wayland
tzimmermann has joined #wayland
sevz has quit [Quit: WeeChat 4.0.4]
sima has joined #wayland
PopLamina has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
PopLamina has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
caveman has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
<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?
mblenc1 has quit [Ping timeout: 480 seconds]
caveman has joined #wayland
<kennylevinsen> Net147: that's because the output buffer you composite to is still 800x480
<kennylevinsen> So there's nothing past the edge
<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.
<Net147> kennylevinsen: any suggestion where I can modify the buffer dimensions to fix it?
tent405 has quit [Quit: tent405]
Dami_Lu has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
Dami_Lu has joined #wayland
<kennylevinsen> hmm on second thought, that matrix is probably used during composite and should be sufficient...
<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
<kennylevinsen> maybe overwriting weston_output_update_matrix
<Net147> moving assignment of output->width from weston_view_set_output into weston_output_enable worked
<Net147> thanks!
<Net147> actually, spoke to soon. didn't work
mblenc has quit [Ping timeout: 480 seconds]
<Net147> putting it in weston_output_enable is too late so it doesn't do anything
<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().
caveman has quit [Ping timeout: 480 seconds]
<pq> you can set output->width,height there, and that should then propagate to everything else that is derived from logical output size.
rasterman has joined #wayland
<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.
<pq> Net147, ^
<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
<Net147> pq: that seems to work
<pq> cool
<kennylevinsen> pq to the rescue, my caffeine blood levels are not yet at operational levels :)
<pq> kennylevinsen, I'm surprised you know weston insides that well :-)
<pq> Net147, things to verify (if they apply to you): input coordinates, damage regions, direct scanout of client buffers
<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.
<Net147> pq: input co-ordinates seem fine
knolle has quit [Quit: .]
mblenc has joined #wayland
<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.
<Net147> pq: I am using weston 12.0.2
<pq> good
<Net147> pq: running Chromium from another system using waypipe and SSH to display locally
sima has joined #wayland
kts has joined #wayland
Leopold___ has quit [Remote host closed the connection]
<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?
Leopold_ has joined #wayland
<pq> zzag, the resize will pend until after eglSwapBuffers and needing a buffer the next time.
<zzag> okay thanks
<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.
<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
mblenc1 has joined #wayland
<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();
opotin65 has joined #wayland
mblenc has quit [Read error: No route to host]
<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.
<pq> but I don't know what actually happens today
mblenc has joined #wayland
<pq> and the X11 legacy in the spec probably allows size to change even mid-rendering for all I know
<jadahl> pq: yes, thats what I meant
<jadahl> in the above example, the draw() would have to use the size from the query, not from the resize
<pq> ok, I understood the opposit
<jadahl> if query was a draw call, it'd be the same, the size would be locked to what was before the resize
<jadahl> zzag: fwiw, there was a bug in wayland-egl (nvidia) where the resize was always postponed until after the next eglSwapBuffers()
carlos_ has joined #wayland
<jadahl> it reproduced with both qt and gtk
mblenc1 has quit [Ping timeout: 480 seconds]
<pq> The most predictable point to resize is immediately *before* the previous frame's SwapBuffers, but that might be difficult to arrange.
<jadahl> I'd say the most easily reasoned about and predictable result is doing it *after* SwapBuffers()
<jadahl> it'd raise fewer eyebrows and the risk of any draw calls or querying sneaking in is minimal
<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
<pq> if you do it after swap, what guarantees do you have that something did not already query buffer_age or something?
<pq> *immediately* after swap is fine, too
<pq> but if you swap, do something else "harmless", and then resize, it's much more difficult to be sure it always works
<pq> and if a toolkit allows running user code in between, it's nearly impossible to guarantee
caveman has joined #wayland
<zzag> jadahl: okay, that's what I see. sometimes SwapBuffers() commits a buffer with new size rather than the one you started at MakeCurrent()
cmichael has joined #wayland
knolle has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit []
kts has joined #wayland
iomari891 has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
cstub has joined #wayland
<wlb> wayland Merge request !334 closed (Draft: server: Add support to fetch the process name of wayland clients)
mvlad has joined #wayland
fmuellner has joined #wayland
mblenc1 has quit [Quit: Quit]
mblenc has joined #wayland
kts has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
ukiran has joined #wayland
rv1sr has joined #wayland
mblenc has quit [Quit: Lost terminal]
lbia has joined #wayland
Moprius has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Remote host closed the connection]
Moprius has quit [Quit: bye]
fmuellner has joined #wayland
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
andyrtr_ has joined #wayland
andyrtr- has joined #wayland
andyrtr| has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
ukiran1 has joined #wayland
andyrtr has joined #wayland
andyrtr_ has quit [Ping timeout: 480 seconds]
andyrtr_ has joined #wayland
andyrtr- has quit [Ping timeout: 480 seconds]
ukiran has quit [Ping timeout: 480 seconds]
andyrtr| has quit [Ping timeout: 480 seconds]
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
Company has joined #wayland
nerdopolis has joined #wayland
kts has joined #wayland
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
nerdopolis has quit [Ping timeout: 480 seconds]
andyrtr_ has joined #wayland
kts_ has joined #wayland
andyrtr- has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
andyrtr has joined #wayland
andyrtr_ has quit [Ping timeout: 480 seconds]
andyrtr_ has joined #wayland
kts_ has quit []
andyrtr- has quit [Ping timeout: 480 seconds]
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ has quit [Ping timeout: 480 seconds]
andyrtr has joined #wayland
andyrtr_ has joined #wayland
ukiran1 has quit [Read error: Connection reset by peer]
<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
<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)
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
kts has joined #wayland
kts has quit []
danshick_ has quit [Remote host closed the connection]
danshick has joined #wayland
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
cstub2 has joined #wayland
cstub has quit [Read error: Connection reset by peer]
andyrtr has joined #wayland
andyrtr_ has quit [Ping timeout: 480 seconds]
<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
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
<i509vcb> although if such a content type selection were possible then there would need to be feedback that scanout possibly failed
<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?
iomari891 has quit [Ping timeout: 480 seconds]
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
andyrtr has quit [Remote host closed the connection]
andyrtr has joined #wayland
tzimmermann has quit [Quit: Leaving]
<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)
<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)
<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
<wlb> weston Merge request !1039 closed (kiosk-shell: Respect xdg surface relationships when activating surfaces.)
<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
<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)
cstub2 has quit [Remote host closed the connection]
knolle has quit [Quit: .]
knolle has joined #wayland
junaid has joined #wayland
cmichael has quit [Quit: Leaving]
Kerr has joined #wayland
m5zs7k has joined #wayland
jkl has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
cstub has joined #wayland
Kerr has quit [Quit: Bye.]
<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
<orowith2os[m]> anything that might fit into there I can look at?
<kennylevinsen> no, clients do not get to have that degree of control
<kennylevinsen> Scan-out is purely compositor decision when possible, and dmabuf hints tell you what graphical configuration it prefers
<kennylevinsen> It might think another client is more important to scan-out for example
gspbirel568734088670613144876 has joined #wayland
gspbirel56873408867061314487 has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
rederick29 has joined #wayland
mvlad has quit [Ping timeout: 480 seconds]
bindu has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
kts has joined #wayland
rv1sr has quit []
mvlad has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
lbia has quit [Remote host closed the connection]
lbia has joined #wayland
nerdopolis has joined #wayland
Kerr has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
cstub has quit []
kts has quit [Quit: Leaving]
jtbx has joined #wayland
slim has joined #wayland