ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
riverdc has quit []
<moses>
does this work
<moses>
yay ok I think it does. didn't understand how to register my nick but I believe I just figured it out
<moses>
anybody here work on KWin/Wayland? I'm trying to track down an issue where Wayland DRM leases don't quite work properly on multi gpu
<moses>
on that line, the first time around it finds my Valve Index connected to my dGPU, the second time it dispatches ?something? to my iGPU and ends up waiting forever
<moses>
right now I just have a hack to only run wl_display_dispatch for my dGPU device, but that's not the right way of doing things. It works perfectly in Sway
<moses>
note that I don't know all that much about wayland; just trying to communicate the symptoms I'm seeing
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
<soreau>
moses: are you saying this 'comp_window_direct_wayland' client works in sway but not in kwin?
<moses>
It works perfectly in Sway, and only works in kwin with workarounds that I don't want to upstream, yes
<soreau>
maybe kwin doesn't call 'done' for the second gpu for whatever reason, and this means that dev->done never gets set to true for it, so it waits forever
<moses>
yeah I've been toying with alternate theories related to the 'done' event
<moses>
I actually don't think it gets to the second GPU now, instead the 'done' event doesn't get sent or gets sent too late, *then* it hangs on calling wl_display_dispatch a second time?
<moses>
am very unsure
<moses>
it hangs on calling wl_display_dispatch a second time _on the same device_*
<moses>
am happy to see zamundaaa in here, I think they wrote the KWin DRM leasing stuff
<moses>
I really don't know anything about Wayland; I just work on computer vision for VR and want this bit to work well
saina has joined #wayland
saina has quit []
<moses>
I don't really understand why `wl_display_dispatch` would hang here
<moses>
it sure seems to be doing that tho
<soreau>
one thing you can do is run the client with WAYLAND_DEBUG set in sway and kwin, and compare the outputs
<moses>
ooh yeah that was another thing I needed to ask: how do I start kwin/KDE Plasma (I don't quite know the difference yet - I just want the whole thing) from tty?
<moses>
I know how to do it for sway, it's just `sway`
<soreau>
ask in kwin channel
<soreau>
WAYLAND_DEBUG=1 ./client
<moses>
could you link me to the kwin channel?
<soreau>
no, I don't know where it is
<moses>
okay I think I found it, thanks
caveman has joined #wayland
<moses>
i need to come back to this when I'm less tired. I think that kwin never calls done on our `wp_drm_lease_device_v1` for some reason, then hangs monado when it tries to wl_display_dispatch again
<moses>
weird
<soreau>
moses: to be clear, you only need to run the client (monado) with WAYLAND_DEBUG=1, not the compositor.. redirect the output to file for comparison, once under sway and again under kwin
<soreau>
this will tell you what's happening on the wire (socket) between compositor and client
<soreau>
moses: it looks like sway log has wp_drm_lease_device_v1@4.connector and then wp_drm_lease_device_v1@4.done (and same for 5) but kwin calls wp_drm_lease_device_v1@4.connector but never calls done (same for 5)
<soreau>
so I'd ask kwin folks why you're not getting the done event or maybe it's been fixed in a more recent version of kwin than you're using
<moses>
I'm on arch but no idea what their release cycle is like. I'll look at getting a version of kwin with that patch in
<moses>
thanks for helping me :D
adarshgm has quit [Ping timeout: 480 seconds]
maxzor_ has quit [Ping timeout: 480 seconds]
bookworm has quit [Read error: Connection reset by peer]
bookworm has joined #wayland
caveman has quit [Remote host closed the connection]
jgrulich has joined #wayland
dcz has joined #wayland
Dami_Lu has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
CodeSpelunker has joined #wayland
CodeSpelunker has quit [Quit: CodeSpelunker]
Dami_Lu has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
Dami_Lu has joined #wayland
shankaru1 has quit [Remote host closed the connection]
manuel1985 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
shankaru1 has joined #wayland
rgallaispou has joined #wayland
<zubzub>
does the (latest) nvidia driver support importing dmabuffers with a linear modifier?
mbalmer has joined #wayland
fahien has joined #wayland
manuel1985 has joined #wayland
ppascher has joined #wayland
fahien has quit [Remote host closed the connection]
fahien has joined #wayland
cool110_ has quit [Remote host closed the connection]
mvlad has joined #wayland
cool110 has joined #wayland
pochu has joined #wayland
MajorBiscuit has joined #wayland
<zubzub>
09:13 < zubzub> does the (latest) nvidia driver support importing dmabuffers with a linear modifier?
<zubzub>
the qbq being can I get a working eglimage from a nvidia dmabuffer using linux dmabuffer protocol?
fmuellner has joined #wayland
fahien has quit [Ping timeout: 480 seconds]
adarshgm has joined #wayland
<zamundaaa[m]>
moses: the fix will be in 5.25.3, which will be released tomorrow
<pq>
zamundaaa[m], is the withdrawal function relevant to moses' problem, though?
<zamundaaa[m]>
Ah. Thanks for making me look again, there is a device->done event missing completely
nerdopolis has joined #wayland
mclasen has joined #wayland
fahien has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.5]
<zubzub>
11:22 < zubzub> the qbq being can I get a working eglimage from a nvidia dmabuffer using linux dmabuffer protocol?
MajorBiscuit has joined #wayland
<zubzub>
answering my own question: it can export it but not import it unless you map it to cuda memory first and some other ceremonies
mclasen_ has joined #wayland
<moses>
zamundaaa[m]: awesome, thanks! if you want me to try to build kwin from source I will, but will need some help. couldn't figure out what the "ECM" dep was
mclasen has quit [Ping timeout: 480 seconds]
<moses>
otherwise I'll just wait for everything to roll through to my distro :D
<davidre>
moses: extra-cmake-modules
<moses>
thank you!
adarshgm has quit [Ping timeout: 480 seconds]
Company has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
manuel1985 has quit [Ping timeout: 480 seconds]
Numocha has joined #wayland
<Numocha>
I recently discovered wio. It was just like what I had been looking for, a stacking WL compositor inspired by Plan 9 from Bell Labs. And then I learned the project got abandonned D:
<tleydxdy>
adopt it!
<bl4ckb0ne>
it not abandonned, it waiting to be forked and continued
MrCooper has quit [Remote host closed the connection]
<Numocha>
bl4ckb0ne: Do you have any idea if there are any forks at the moment? I have a hard time gathering info on it. It seems like such a cool idea
<Numocha>
Though I tried to build it and it didn't work, might have to try again the last version
<bl4ckb0ne>
ive seen one one codeberg which is also abandonned
mvlad has quit [Remote host closed the connection]
manuel1985 has joined #wayland
ids1024 has joined #wayland
staceee has quit [Remote host closed the connection]
staceee has joined #wayland
saina has joined #wayland
saina has quit [Read error: Connection reset by peer]
<ids1024>
The documentation for Wayland doesn't seem to define what types are nullable. Are nullable arrays a thing in the protocol? `wl_closure_marshal` has a test for `!arg.nullable && args[i].a == NULL`, but it looks like `wl_connection_demarshal()` would never produce a null array.
fmuellner has joined #wayland
<ids1024>
`TEST(connection_marshal_nullables)` does test marshalling for `?a`. Don't see a test for demarshalling that.
<ids1024>
Does `?a` make sense in terms of the wire format? I guess a non-nullable array could have length 0, and that wouldn't be distinguishable from "null" in the wire protocol? Unlike `?s`, since a non-null string has to be nul-terminated.
<ifreund>
ids1024: see is_nullable_type in wayland-scanner's source code
<ifreund>
strings, objects and arrays are nullable
<ids1024>
Ah, I hadn't seen that part. That should be mentioned in the documentation too. But am I missing something, or is `wl_connection_demarshal` not actually ever outputting a null array? In `case 's'` it sets `closure->args[i].s` to `NULL` if `length == 0` and `arg.nullable`, but `case 'a'` doesn't seem to have logic like that.
<ids1024>
(I've noticed wayland-rs, which provides a libwayland backend and a pure Rust implementation of the wire protocol, isn't correctly handling nullable strings. So I want to see if nullable arrays also need to be fixed, and how to marshal/unmarshal that.)
<ifreund>
hmm, looks like on the write end NULL array arguments are handled just like strings by writing just a 0 length to the buffer but on the read end a zero length array is returned instead of NULL
<ifreund>
seems like an oversight to me. do any real-world protocols actually use nullable arrays?
manuel1985 has quit [Ping timeout: 480 seconds]
<ids1024>
None that I can see, looking in wayland, wayland-protocols, and wlr-protocols.
<ids1024>
If that's the case, it should probably reject `?a` as a valid type. If there's no way to represent it in the wire protocol that isn't the same as a zero-length non-null array.
<ifreund>
ids1024: the same can be said for strings though...
<ifreund>
oh wait, those have the 0 terminator so zero length is different from NULL on the wire
<ifreund>
yeah I agree that wayland scanner should reject nullable arrays then