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]
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
<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]
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]