ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
garnacho has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
privacy has joined #wayland
coldfeet has quit [Remote host closed the connection]
gryffus has quit [Read error: Connection reset by peer]
feaneron has joined #wayland
feaneron has quit [Remote host closed the connection]
gryffus_ has quit []
garnacho has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
privacy has joined #wayland
lbia has quit [Remote host closed the connection]
lbia has joined #wayland
kts has joined #wayland
rasterman has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Narrat has quit []
kts has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
kts has joined #wayland
mclasen has joined #wayland
lbia_ has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Company has joined #wayland
riteo_ is now known as riteo
rv1sr has quit [Ping timeout: 480 seconds]
pbsds has joined #wayland
kts has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
bodiccea has quit [Remote host closed the connection]
bodiccea has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
kts has joined #wayland
garnacho has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
aktaboot has joined #wayland
<aktaboot>
o/
<aktaboot>
I've been encountering an error with wayland, might be a driver issue..
<aktaboot>
wl_drm@52: error 0: wl_drm.create_prime_buffer is not implemented
<aktaboot>
I am really unsure where I should dig deeper to understand the error, or where to report it
<aktaboot>
any help is appreciated :)
<emersion>
which compositor?
<ids1024_>
aktaboot: What driver is that with? And what compositor?
<emersion>
which client?
<emersion>
wlroots intentionally doesn't support this request
<emersion>
because it uses legacy/insecure GEM names
<emersion>
iirc
<emersion>
hm
<emersion>
might be a different request, seeing "prime" in the name...
<ids1024_>
For the most part, drivers/clients should now be using the dmabuf protocol instead of wl_drm. Though things like AMDVLK seem to still rely on it.
<aktaboot>
amdgpu driver, I'm using plasma with kwin
<aktaboot>
emersion: what do you mean by client ? wayland client ?
<emersion>
cc zzag
<emersion>
I mean, which app?
<aktaboot>
happened with two applications, one is using rust iced for graphics,and changing the iced backend to software rendering make it work
<ids1024_>
So is this just all applications using AMDVLK on kwin? Including something like vkcube-wayland?
<aktaboot>
the other one is using egui for rust aswell: zed-editor
<emersion>
OK, so it's GL or vulkan wsi. are you using Mesa or amdvlk?
<aktaboot>
how can I check
<emersion>
hm
<emersion>
eglinfo maybe
<aktaboot>
EGL vendor is Mesa
<emersion>
well that's weird
<emersion>
which version of mesa?
<aktaboot>
this might be a driver issue, since very few seem to encounter it
<aktaboot>
or a platform issue
<aktaboot>
that's the thing, I'm really unsure where to report it even ...
<aktaboot>
oh sorry I missed the question
<aktaboot>
Mesa 24.0.5
<aktaboot>
OpenGL 4.6
<ids1024_>
I don't know about egui, but Iced should default to using Vulkan if available.
<ids1024_>
So I'd check vulkaninfo too.
<aktaboot>
sure, anything to check for in particular
<emersion>
the driver name I'd say
<aktaboot>
I couldn't find any of RADV, AMDVLK in vulkaninfo output
<alice>
well you can try install the mesa vulkan drivers instead, idk how that's done on your distro
<ids1024_>
That's what I thought, since RADV shouldn't be using that wl_drm call unless its an old version or the compositor doesn't support the dmabuf protocol.
<aktaboot>
mesa vulkan drivers = radv ?
<alice>
yea
<aktaboot>
thanks!
<alice>
usually named something like mesa-vulkan in distro packages
<HildarThedorf>
Hello, is this the right place to ask a question about the xdg-shell protocol?
<vyivel>
yes
<emersion>
zzag: wlroots used to do the same, but we don't enable wl_drm by default anymore
<HildarThedorf>
How am I supposed to interpret the following sequence of xdg shell events: xdg_toplevel.configure_bounds(750, 550), xdg_toplevel.configure(0,0,...), xdg_surface.configure(), xdg_toplevel.configure(800,600,...), xdg_surface.configure(). This to me seems to be asking me to resize my surface to a size that violates the configure_bounds I was given?
<vyivel>
a compositor shouldn't really send this tbh, but i'd use the 800x600 size
<HildarThedorf>
That's what kwin is sending me when I switch to fullscreen. >.>
<zamundaaa[m]>
HildarThedorf: configure bounds is the maximum recommended size for when you create a window without special states
<zamundaaa[m]>
It's not a size limit, and the fullscreen size is expected to be different
<zamundaaa[m]>
In most cases the configure bounds is the size a maximized window would have, so the screen size minus panels and decorations
<vyivel>
ah so those are two separate configures
<HildarThedorf>
Yeah, that's indeed what it is, the size of my screen minus the taskbar on the left side, and (if enabled) server-side decorations at the top.
<HildarThedorf>
Should I 'forget' any state sent from the previous configure sequence? Or is the configure_bounds still 'alid' but overruled by the explicit size in toplevel.configure?
<HildarThedorf>
*valid
<vyivel>
it applies to the 0,0 case aka "pick the size yourself", if you're sent a specific size just use that