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
<LaserEyess>
swick: I'm curous, what are the chances of a scenario such as surface-suspension being merged to staging, and your present-timing being debated and refined for all the time it needs, and then being merged to staging and superceding surface-suspension?
<LaserEyess>
I ask because surface-suspension on it's own seems really useful to a lot of clients, right now
<LaserEyess>
it's a good stop-gap measure for a more comprehensive solution like yours
<LaserEyess>
why wouldn't such a simple fix be implemented on mesa's side?
<LaserEyess>
I assume it's against some spec?
<swick>
pretty sure it would get merged if you wrote a patch
<swick>
just nobody cares enough to write that patch apparently
<LaserEyess>
that's also only vulkan, so you'd need to do the same for opengl, right?
<swick>
EGL, yes
<JPEW>
emersion: Removing the `goto fail` doesn't seem to resolve the problem
<JPEW>
emersion: Weirdly, if I run `weston-simple-dmabuf-egl -d /dev/dri/card0` for a little bit and then `-d /dev/dri/renderD128` the latter runs for a little while, but eventually crashes weston
<emersion>
JPEW: have you removed the assert too?
<JPEW>
I think so
<emersion>
what happens exactly?
Erandir has quit []
<JPEW>
emersion: If I run `weston-simple-dmabuf-egl` on a fresh power cycle, I get this immediately and nothing crashes:
<JPEW>
emersion: doh. Hang on, I may not have actually uploaded the new mesa :)
<emersion>
:P
Erandir has joined #wayland
spstarr has joined #wayland
<JPEW>
emersion: Ok, that patch works. I still get the warning message in weston, but it does render
<JPEW>
It looks like the warning message could possibly be removed?
<emersion>
JPEW: lynxeye's MR i linked earlier removes it
<emersion>
JPEW: can you submit your patches? :)
<JPEW>
emersion: Indeed
<emersion>
glad it works!
<emersion>
in the future the compositor should be sending the render node to clients
<emersion>
so it's better to fix mesa than to require clients to open the primary node
<emersion>
(primary nodes in general shouldn't be opened by clients)
<JPEW>
emersion: Well, in this case the client is using the render node, it just doesn't match the primary node
<emersion>
yup
<emersion>
because of that split display/render architecture
<JPEW>
emersion: Ya. Is that fairly unique to raspberry pi?
<emersion>
nah, it's common in many Arm SoCs
<emersion>
but the software wasn't originally written with these assumptions
<emersion>
so kmsro/renderonly is a (fragile) attempt in mesa to sidestep the issue
<JPEW>
emersion: Ah; is there something thats support to replace kmsro eventually?
<emersion>
we've been talking about allowing compositors to better match the display device and the render device
<emersion>
but we quickly hit issues with buffer allocations
<emersion>
the compositor needs to allocate scanout-capable buffers, but the render device doesn't know how to do it
<emersion>
so a whole new solution needs to be plumbed first to allow allocations to work correctly
<emersion>
(the allocation issue is more general than just this Arm issue)
<emersion>
kmsro works by asking the display device to allocate sometimes via dumb buffers (!) sometimes via something else, then import that into the render device
<emersion>
all of that is pretty much driver specific and not good to put into a generic compositor