ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
karolherbst has quit [Ping timeout: 480 seconds]
karolherbst has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
andymandias has quit [Remote host closed the connection]
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Remote host closed the connection]
andymandias has joined #wayland
naveenk2 has joined #wayland
<tokyo4j>
ls
<tokyo4j>
sorry nvm
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<zzxyb[m]>
<emersion> "i believe this is a virtgpu bug" <- Yes, many compositor have workarounds.
rasterman has joined #wayland
feaneron has joined #wayland
<pq>
zzxyb[m], maybe it's related to Weston using a KMS cursor plane for *any* wl_surface and not just for cursors, so Weston does not set the KMS properties that promise "I'm using this only as a cursor".
<pq>
but I cannot see how that would affect y-flip
<pq>
DRM FB is a DRM FB, the orientation is always the same
<pq>
so maybe virtgpu or its host side do something differently based on "is it guaranteed to be a cursor image?"
<pq>
is virtgpu a rendering driver, or is a KMS driver as well?
<pq>
this would be about the KMS driver
<pq>
in virtualized systems it seems to be popular for the host side to "commandeer" the cursor plane and move it around by pointer motion itself instead of roundtripping into the guest window server which may cause lag.
<kennylevinsen>
I guess the cursor props in question would be HOTSPOT_X and HOTSPOT_Y. Would be easy to test what happens if wlroots didn't set those.
<pq>
that works fine as long as the cursor plane is not used for something else than cursor - which Weston will do
<kennylevinsen>
to see if that's the differentiator
<emersion>
iirc the bug existed before hotspot props
<MrCooper>
kennylevinsen: more likely not setting DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT, not setting the hotspot coordinates just leaves them at (0, 0)
<kennylevinsen>
ah yeah
<MrCooper>
though I guess not setting the former would just hide the cursor plane when it's relevant
<kennylevinsen>
zzxyb[m]: I think your hack patch just leaves the known plane formats for the cursor plane empty for drivers that do not support modifiers, such that all fb imports fail and the cursor ends up composited instead
<kennylevinsen>
which would "work"
kts has joined #wayland
<kennylevinsen>
I imagine the virtio-gpu kms driver offloads all composition to qemu on the host, which might offload it to e.g. spice/virt-manager/whatever clients, so I guess the issue could also be client-side there
rasterman has quit [Remote host closed the connection]
coldfeet has quit [Remote host closed the connection]
<wlb>
weston/main: Pekka Paalanen * tests: return status from each test definition https://gitlab.freedesktop.org/wayland/weston/commit/e57eb5b15df0 doc/sphinx/toc/test-suite.rst tests/alpha-blending-test.c tests/assert-test.c tests/bad-buffer-test.c tests/buffer-transforms-test.c tests/client-buffer-test.c tests/color-icc-output-test.c tests/color-lcms-optimizer-test.c tests/color-management-parametri
<orowith2os[m]>
YaLTeR, would you want to chime in a bit on that?
<orowith2os[m]>
I think I left a gap somewhere, so the compositor can't tell a window to just "not draw anything, trust me bro"
<orowith2os[m]>
which I'll have to resolve later, but I think niri would want that, right?
<YaLTeR[m]>
[@orowith2os:fedora.im](https://matrix.to/#/@orowith2os:fedora.im) haven't had a chance to take a look yet, but just to state one of my main concerns: if the resulting protocol isn't implemented by gtk 4 (and gtk 4 has some understandable opposition to xdg-deco v1), then it won't be very useful. I believe my main wants (signaling corner radius and asking to square corners) shouldn't be as controversial (notably, it is not about removing CSD,
<YaLTeR[m]>
in fact I want to keep it)
<YaLTeR[m]>
What you could call SSD in niri coexists just fine with CSD
qyliss has quit [Quit: bye]
qyliss has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
leon-anavi has quit [Quit: Leaving]
kts has quit [Quit: Konversation terminated!]
qyliss has quit [Quit: bye]
<orowith2os[m]>
YaLTeR: mmm, okay, I'll fix that then. I noticed some stuff that conflicts with what I would expect from an xdg-decoration v2 too.
<orowith2os[m]>
with me updating it to be more like a wm_capabilities thing, the whole "client must obey compositor" thing doesn't really apply anymore
<orowith2os[m]>
it's more like, "the client must not set any decorations that the compositor does not support"
qyliss has joined #wayland
<orowith2os[m]>
and a configure event is more a "this is what the WM prefers"
<YaLTeR[m]>
that's not really what i need in niri tbh. well maybe removing csd shadows but it's not a big deal
<YaLTeR[m]>
so probably want to tag someone else about that
<orowith2os[m]>
I have no_decorations, window_controls, and drop_shadow right now
<orowith2os[m]>
that should do the job
<orowith2os[m]>
I should probably add an event to say "the compositor prefers this mode", so that they don't rely on the configure event for that