ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Company has quit [Quit: Leaving]
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
d4n13L has joined #wayland
lsd|2 has quit []
sevz has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest1978
nerdopolis has quit [Ping timeout: 480 seconds]
Guest1954 has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
carlos_ has quit [Ping timeout: 480 seconds]
dri-logger has joined #wayland
dri-logg1r has quit [Ping timeout: 480 seconds]
glisse has quit [Ping timeout: 480 seconds]
glisse has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
anarsoul|2 has quit [Read error: No route to host]
anarsoul has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
tent405 has joined #wayland
sima has joined #wayland
ohmltb^ has joined #wayland
tent405 has quit [Quit: tent405]
tent405 has joined #wayland
tzimmermann has joined #wayland
gspbirel568734088670613 has joined #wayland
gspbirel56873408867061 has quit [Ping timeout: 480 seconds]
sevz has quit [Quit: WeeChat 4.0.4]
iomari892 has joined #wayland
periontus has joined #wayland
periontus has quit [Quit: Leaving]
rasterman has joined #wayland
carlos_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
rgallaispou has quit [Quit: Leaving.]
Leopold_ has joined #wayland
rgallaispou has joined #wayland
crazybyte has quit [Quit: Ping timeout (120 seconds)]
<kchibisov>
I'm not a mesa developer, I don't remember the details here.
mblenc has joined #wayland
krishbin has joined #wayland
<pq>
If there is no back buffer yet, you can simply set the new size, and when a back buffer is next allocated, it'll be that size.
<pq>
If there is a back buffer already, it cannot replaced for another size, so the size cannot change before the current back buffer has been swapped.
<kchibisov>
Ah, and the size will be updated on the functions which could result in latching, such as make_current.
<pq>
a back buffer is chosen at the first call that needs a back buffer; it could be a draw call, query of buffer_age, etc.
<kchibisov>
yeah.
<kchibisov>
I guess if it doesn't go immidiatelly it's a working indicator?
<kchibisov>
It's nice that it mentions fatal issues which we got today.
<kchibisov>
But from the behavior used to prevent them.
<kchibisov>
(not in that mail, in other ones in this thread)
<kennylevinsen>
not a fix for mesa WSI issues, but using wp_viewporter instead of buffer scale makes scale mismatch into an imperfect render instead of a protocol error
<kchibisov>
kennylevinsen: yeah, I said that in the past.
<kchibisov>
I just getting pinged about this issue from time to time.
<kchibisov>
And from time to time i try to dig a bit.
<kchibisov>
surely I can set viewporter to the target size and workaround the issue all together.
<kchibisov>
(I guess)
<pq>
It's not even a Mesa WSI issue even, the WSI behavior is completely deterministic wrt. to the calls made to Mesa. The root of the problem is that the toolkit cannot require nor ensure when and how Mesa is called.
<kchibisov>
Though, wsi is bugged wrt context current stuff.
<kchibisov>
because there's no explanation to it.
<pq>
ah, yeah, that's another thing
<kchibisov>
Like I gave 2 examples in the past where it's clearly a bug.
<kchibisov>
which I implemented in alacritty.
<kchibisov>
Like even if you look at them it doesn't make any sense, but they prevent all the latching.
<kchibisov>
It's like "before you create a new window, uncurrent the active context on the current thread, otherwise you'll latch it".
<kchibisov>
kennylevinsen: the main issue here, is that users need to develop heuristics to apply the state.
Guest1978 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest2022
mblenc has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
paulk-bis has quit []
paulk has joined #wayland
<kennylevinsen>
yeah, I'm not a fan of graphics APIs that interact with the window system... It splits responsibility of window state across multiple components (mesa and its user)
kts has joined #wayland
<kennylevinsen>
rendering to buffers and having the client (or their toolkit) attach them in their (unavailable) platforms-specific window bits is a cleaner separation of responsibilities
<kennylevinsen>
s/unavailable/unavoidable/
<pq>
EGLDevice platform for the win?
<pq>
and maybe a library to help handling all the dmabuf protocol and modifier feedbaack
nerdopolis has joined #wayland
<emersion>
you just invented wlroots backends :P
<kennylevinsen>
indeed :D
ShapeShifter499 has joined #wayland
<pq>
yay \o/
kts_ has joined #wayland
<kennylevinsen>
but to sell this to kchibisov we'd also need to have a means to get this running on windows, macos and x11 :P
<kennylevinsen>
I doubt we'll add a win32 backend to wlroots anytime soon
<kchibisov>
kennylevinsen: I mean, I can use vulkan without such issues.
<kchibisov>
it doesn't have to work across all the platforms, it just should be something that could be reliable.
<kchibisov>
The EGLDevice platform will solve the out standing issue with languages hard depending on libwayland because of mesa.
<pq>
EGLDevice platform solves the issue of fighting a WSI, right?
<pq>
as in, you get to reinvent it yourself so it does what you need
kts has quit [Ping timeout: 480 seconds]
<kchibisov>
yeah, we considered doing something like that.
<kchibisov>
but it requires resources.
<emersion>
pq, EGLDevice doesn't mean you don't get an EGLSurface
<emersion>
you can create an EGLDisplay bound to wl_display and an EGLDevice
<emersion>
i think you mean surfaceless, rather than EGLDevice
<pq>
isn't EGLDevice an independent EGL platform?
<emersion>
hm, right
<emersion>
and if you use it, you don't get an EGLSurface that can work with Wayland
<pq>
but yes, I am bit confused how you get scanout-able dmabuf out of an EGLDevice platform
<emersion>
you allocate via GBM
<pq>
or not even scanout-able
<emersion>
you can allocate via FBO if you'd like, but then it's not good for Wayland
<pq>
ah, still GBM for allocation, even though not using EGL GBM platform.
<emersion>
yes
<emersion>
Vulkan is a bit different in this regard, there is enough Vulkan API to allocate proper buffers for Wayland
<emersion>
(but not necessarily scanout)
rv1sr has joined #wayland
kts_ has quit []
<bl4ckb0ne>
> <kennylevinsen> rendering to buffers and having the client (or their toolkit) attach them in their (unavailable) platforms-specific window bits is a cleaner separation of responsibilities