ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
aknot has joined #wayland
spstarr has joined #wayland
spstarr has quit [Ping timeout: 480 seconds]
aknot has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
kenny has quit [Quit: WeeChat 4.1.1]
tristianc6704 has quit [Ping timeout: 480 seconds]
RAOF has quit [Read error: Connection reset by peer]
RAOF has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
bookworm has quit [Remote host closed the connection]
bookworm has joined #wayland
Guest9171 has quit [Remote host closed the connection]
narodnik1 has joined #wayland
narodnik has quit [Read error: Connection reset by peer]
<acsqdotme>
what's the simplest way to change keyboard layouts for a wayland system?
<acsqdotme>
I got dwl and foot to work so far, but it's a real pain having default qwerty, so I just stick in the tty ricing other stuff for my new system.
tristianc6704 has quit [Remote host closed the connection]
MrCooper_ has joined #wayland
MrCooper has quit [Read error: Connection reset by peer]
mvlad has quit [Remote host closed the connection]
tristianc6704 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mxz has quit [Quit: cya]
mxz has joined #wayland
Company has quit [Quit: Leaving]
kts has joined #wayland
sevz17 has quit [Quit: WeeChat 4.1.1]
kts_ has joined #wayland
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Leaving]
garnacho has joined #wayland
kts has joined #wayland
leon-anavi has joined #wayland
kts has quit [Quit: Konversation terminated!]
systwi has quit [Ping timeout: 480 seconds]
systwi has joined #wayland
sima has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
MrCooper_ is now known as MrCooper
rgallaispou has joined #wayland
<MrCooper>
riteo: ideally wl_surface_frame should be in the same commit which attaches the new buffer, otherwise the semantics of the frame event aren't well-defined
garnacho has quit [Remote host closed the connection]
mxz- has joined #wayland
yrlf has quit [Read error: Connection reset by peer]
mxz has quit [Read error: Connection reset by peer]
yrlf has joined #wayland
glennk has joined #wayland
garnacho has joined #wayland
fossdd_ is now known as fossdd
rv1sr has joined #wayland
yrlf is now known as Guest9497
yrlf has joined #wayland
Guest9497 has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
<daniels>
acsqdotme: you’d have to check the dwl documentation
qyliss has quit [Read error: Connection reset by peer]
neniagh has quit []
tzimmermann has joined #wayland
qyliss has joined #wayland
pochu_ is now known as pochu
maxzor has joined #wayland
tristianc6704 has quit []
suntory has joined #wayland
manuel_ has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
floof58 has quit [Ping timeout: 480 seconds]
slim has joined #wayland
floof58 has joined #wayland
<pq>
riteo, the Wayland intention is that you internally remember all the state you need to change, render based on that new state, and then emit the new state just before you call SwapBuffers or other wl_surface_commit equivalent.
<pq>
riteo, otherwise, good luck getting window state change from floating to maximized reliable and not crashy.
<pq>
riteo, doing anything other that *scheduling* a new draw from a frame callback sounds like a high risk to be a broken design.
<pq>
If you make multiple changes to the decorations in one go, you really should not commit your main surface more than once.
<pq>
jadahl, ^
maxzor has quit [Ping timeout: 480 seconds]
<pq>
riteo, if you must draw at N Hz consistently, use a timer and ignore frame callbacks.
<pq>
riteo, if you are ok to draw only when it's useful, then use frame callbacks, but mind that getting a frame callback is not a necessary nor a sufficient condition to draw.
<pq>
It's not necessary if you have a good reason to risk discarding the previous frame.
<pq>
It's not sufficient if you have nothing new to show.
<pq>
The very first frame of window being mapped needs to be drawn without a frame callback anyway.
aknot has joined #wayland
<pq>
riteo, the idea is that in Wayland event handlers you only accumulate state. You schedule a new frame to be drawn whenever you want to, and give a set of state with it to be drawn. When it's drawn and just before commit, you emit the state with Wayland requests.
<pq>
If drawing is in separate thread from Wayland event handling, then just hand off a state structure to the drawing thread.
<emersion>
pq, i think mesa will stall if you try to render with a timer
<pq>
emersion, yup, so you set eglSwapInterval to zero.
<emersion>
hm, should be fine with swapinterval=0
<pq>
then Mesa will only stall for free buffers
<pq>
riteo, all this is complicated enough that no simple rule of "always commit in ...." is good enough. You need a small state machine, plus an explicit representation of window state you can queue.
<pq>
queue internally, that is
<pq>
Doing Wayland requests straight from Wayland event handler callbacks is usually a bad idea, like sending ack_configure from xdg_surface.configure event handler.
<pq>
These are just the basics; if you are using EGL, then you get to be *really* careful with EGL calls in order to draw in the right size at the right time.
<pq>
maybe there should be a EGL Wayland-buffer platform that would hand out wl_buffers but still hide all the format modifier etc. negotiation...
<pq>
or, a helper library shared with Mesa that does all the zwp_linux_dmabuf handling, so one would not need EGL Wayland platform
qaqland is now known as Guest9516
Guest9516 has quit [Read error: Connection reset by peer]
<emersion>
would be nice
aknot has quit [Remote host closed the connection]
fmuellner has joined #wayland
nerdopolis has joined #wayland
maxzor has joined #wayland
Moprius has joined #wayland
maxzor has quit []
Brainium has joined #wayland
dos1 has quit [Ping timeout: 480 seconds]
dos1 has joined #wayland
kts has joined #wayland
Company has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest9529
kts has quit [Quit: Konversation terminated!]
fmuellner has quit []
fmuellner has joined #wayland
qyliss has quit [Quit: bye]
qyliss has joined #wayland
AnuthaDev has joined #wayland
fmuellner_ has joined #wayland
fmuellner has quit [Read error: Connection reset by peer]
fmuellner has joined #wayland
narodnik has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner_ has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has joined #wayland
Moprius has quit [Quit: bye]
lsd|2 has joined #wayland
leon has joined #wayland
kts has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
sevz has joined #wayland
tzimmermann has quit [Quit: Leaving]
manuel_ has quit [Ping timeout: 480 seconds]
fossdd has quit [Remote host closed the connection]
fossdd has joined #wayland
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
kts has quit [Quit: Konversation terminated!]
yshui` has quit []
i509vcb has joined #wayland
Moprius has joined #wayland
agd5f_ has joined #wayland
Brainium has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
AnuthaDev has quit [singleton.oftc.net coherence.oftc.net]
RAOF has quit [singleton.oftc.net coherence.oftc.net]
cwittlut has quit [singleton.oftc.net coherence.oftc.net]
AnuthaDev has joined #wayland
RAOF has joined #wayland
cwittlut has joined #wayland
AnuthaDev has quit []
privacy has quit [Quit: Leaving]
<DemiMarie>
pq: does this mean that EGL and the Vulkan WSI are bad APIs?
<DemiMarie>
kennylevinsen: I’m not saying you are wrong, but that isn’t really a helpful post :)
<kennylevinsen>
Anything else would just be unnecessary filler :P
<kennylevinsen>
But yeah, WSI makes for a world of pain with very little benefit. Implementing it is quirky and leads to a leaky abstraction where your gl/vulkan implementation drives *some* of your display connection but not all
<kennylevinsen>
Leave window management up to the surrounding platform code...
<Ermine>
Is the posy author from Intel?
<kennylevinsen>
Mike is at valve if his about section is to be trusted
leon has quit [Quit: Leaving]
leon-anavi has quit [Remote host closed the connection]
<Ermine>
Ah, thank you. I remember seeing him somewhere on irc (or in fdo gitlab), but my memories got corrupted
mvlad has quit [Remote host closed the connection]
<daniels>
yeah, Mike is at Valve and working on Zink
<daniels>
kennylevinsen: I think there is a good amount of benefit to WSI - not only will the average Vulkan client not necessarily get it right, but even if they do get it right for the time, that's not going to be the most optimal thing a few years down the line - containing the damage is good if you ask me
<daniels>
WSI is also fairly necessary given the existence of other, more encapsulated OSes, which don't have the same cross-vendor primitives of dmabuf/syncobj/modifiers/etc as we do
<daniels>
EGL is a horror show, but I mean, it's literally just s/GLX/EGL/, and from a time long before we even had dmabuf, so you can't expect too much really
<daniels>
the Vulkan dmabuf extensions do let you ignore WSI and roll your own if you want with little-to-no penalty, unlike EGL
<emersion>
thanks to WSI being this bad i can bring food to my table
<emersion>
daniels: hm, how is the Vulkan DMA-BUF ext different from the EGL one? to me they sound pretty similar?
<emersion>
well, modulo allocation which works correctly on Vulkan
<emersion>
on EGL you'd use GBM
<emersion>
but on both Vulkan and EGL, you need to do the linux-dmabuf protocol stuff yourself?
<daniels>
emersion: yeah, my answer to why Wayland is so terrible is that I'm either an idiot (didn't know any better) or a genius (like having a house and eating for the rest of my life)
<daniels>
emersion: it's not so much the allocation as the binding - with Vulkan you at least have the explicit transition between internal and external world, whereas with EGL all you have to go on is flushing FBO draws
<emersion>
:D
<emersion>
hm, right
<kennylevinsen>
daniels: that there is a need for convenient platform agnostic window management doesn't mean it had to be contained in mesa - especially as you still need the rest of the platform-specific cake for things to work :/
<daniels>
well, it would need to exist somewhere, and for Vulkan to be attractive it would need to be either an integral part of the various OS platforms (not going to happen on some other OSes at least), or if you aren't going for the OS-native-and-integral route then you'd need to at least keep it consistent with the surrounding API, and maintained by some kind of OS-neutral team who could ensure that it was coherent with Vulkan and kept
<daniels>
up to date with Vulkan's evolution
<daniels>
so like, the first couldn't happen, and the second did
<daniels>
but yeah, what I like is that you can go the external route if you know better (& will continue to know better for your client's lifetime), for little-to-no penalty
<kennylevinsen>
But yeah, I know it's nothing new
<kennylevinsen>
yup
<kchibisov>
kennylevinsen: each vendor has their own wsi with its quirks because of how their drivers work.
<kchibisov>
like nvidia hooks into exit and tries to clean stuff, etc.
<kchibisov>
they also use wp_presentation, etc.
<daniels>
they should be using the protocols ManMower has been writing up to actually do FIFO properly :)
<kchibisov>
i mean, fifo is broken in mesa as well :p
<kchibisov>
I think the same with eglSwapInterval
<kennylevinsen>
kchibisov: they're doing that exactly because of the WSI. Without, the driver just renders and you deal with wayland/X11/Cocoa/win32/whatever
<kchibisov>
And I should maintain wsi specific for nvidia, because they do and expect things differently?
<daniels>
there is definitely some latitude for vendor smarts - e.g. if you're Intel or AMD, you can have a separate buffer for compression metadata which you take advantage of when you're doing rendering to your imported buffer, then resolve it on transition back to the external world - but I don't think an atexit handler is integral to the way any particular vendor works
<daniels>
kchibisov: the new protocols literally exist to make FIFO not broken!
<kennylevinsen>
kchibisov: you wouldn't need anything nvidia-specific - you'd have a buffer and/or explicit sync to deal with, WSI is you talking normal wayland
<kchibisov>
And then nvidia devs ask you to please run this command so our GPU don't die.
<kchibisov>
Like cross platform is a mess.
<kchibisov>
And if you do things differently on linux, we'll have each toolkit maintain their own wsi.
<kchibisov>
though, we have stuff like that in compositors already.
<kennylevinsen>
I don't follow - ignoring daniels' (valid) point about being slightly smarter when the driver *does* own the WSI, an external wayland WSI is just wl_surface_attach/frame/commit
<daniels>
kennylevinsen: 'just' :)
<kchibisov>
wsi should work not only for waylan.d
<kennylevinsen>
daniels: I know I know, but I think it's good enough a simplification for *this* part of the discussion :P
<daniels>
kchibisov: literally the point of WSI is that it's not specific to Wayland
<kchibisov>
exactly, and you have a lot of mess in it.
<kennylevinsen>
kchibisov: the story is the same for other platforms: the WSI parts are dictated by the platform, not the driver.
<kchibisov>
e.g. xlib device init stuff, xpresent working _sometimes_ for _someone_.
<kennylevinsen>
a WSI does not need nvidia hacks, it needs macos/wayland/x11 hacks
<kennylevinsen>
it might *currently* have nvidia hacks because it exists in an nvidia user-space driver, because they can...
<kchibisov>
And then, obviously, I won't be using your standalone wsi impl.
<kennylevinsen>
and the need for a cross-platform implementation is not the same as need for putting it in mesa
<kennylevinsen>
A cross-platform "put a vulkan buffer on screen" library can exist externally just as well
<kchibisov>
I mean, sure, but there's no way anyone will invest their lifetime into maintaining this mess.
<kennylevinsen>
that's what they're doing right now, in mesa
<kchibisov>
or cooperate to write code.
<kennylevinsen>
I'm just saying it's in the wrong box
<kchibisov>
I mean with mesa it's at least in mesa.
<kennylevinsen>
yeah, my attitude is more that it should only be in mesa if it cannot exist externally at all
<kchibisov>
it would be nice to hook your wsi impl into mesa though.
<daniels>
I don't know what the alternative proposal is
<emersion>
i think kenny's point is that Vulkan/GL impls shouldn't be in the business of doing WSI
<emersion>
instead, libraries like glfw for instance could do it
<emersion>
since these do other WSI stuff anyways, like input
<kchibisov>
so we have a wsi in each toolkit and then mesa devs saying that we work only with wsi Y.
fmuellner has quit [Ping timeout: 480 seconds]
<kchibisov>
and if you don't work with wsi Y, we won't support you.
<emersion>
no, mesa works with DMA-BUFs
<emersion>
and is used only for submitting work to the GPU, not for presentation
<kchibisov>
So you want mesa work with only dmabufs and then you just pass them into mesa?
<kchibisov>
which you get _somehow_
<kchibisov>
Like I don't understand how are you supposed to do EGL platform stuff.
<kchibisov>
But I'm not experienced with doing dmabufs directly, I only touched mesa wsi a couple of times.
<emersion>
Vulkan can allocate DMA-BUFs, alternatively there is also GBM
<emersion>
either way, you import the DMA-BUF into Vulkan for drawing onto it
<kchibisov>
And what if I want to use something not using gbm?
<emersion>
and then use a WSI library to present it
<emersion>
something not using GBM?
<kchibisov>
I think llvmpipe is not using gbm?
<kchibisov>
Or it does use them?
<emersion>
there are extensions to import SHM buffers into Vulkan as well
<kchibisov>
I know that you can use dumb buffers with gbm, you can craete dmabuf for them though with libdrm.
<kchibisov>
what if I don't have vulkan?
<kchibisov>
my device doesn't support it.
<emersion>
there is a similar ext for EGL
<kchibisov>
ok, what to do with X?
<kennylevinsen>
kchibisov: for reference, the wlroots does not use WSI when rendering on X11 and Wayland backends. Works fine with gles and vulkan.
<emersion>
X isn't different from Wayland
<kennylevinsen>
and worked fine with llvmpipe, although we use a dedicated software renderer now because llvmpipe is slow
<emersion>
DRI3+Present gives you the same as Wayland's linux-dmabuf
<kchibisov>
Can nvidia even do DRI3?
<emersion>
i have no idea
<kennylevinsen>
those kinds of questions make me happy that I didn't get into the graphics stack until *after* I switched to Wayland
<emersion>
when it comes to closed-source drivers, a lot of times it requires going through EGLSurface, because the driver has its own special way of doing things instead of DMA-BUFs
<kchibisov>
exactly.
<kchibisov>
and cross platform the only way that works is EGLSurface.
<emersion>
i don't think it's the only way that it could work
<kchibisov>
even in open source drivers, want partial present? Use EGSurface.
<emersion>
that's… unrelated?
<kennylevinsen>
although back to the original discussion, that's not a technical limitation - it's because the WSI was put there in the first place...
<kchibisov>
Yeah, the point of API to be cross platform.
<emersion>
what do you mean exactly by "partial present"?
<emersion>
damage?
<kchibisov>
emersion: EGL_KHR_partial_update.
<emersion>
right, that ext is pretty bad
<kchibisov>
I haven't found a way to do it without EGLSurface.
<emersion>
if we cared, we could have a better ext which doesn't depend on EGLSurface
<emersion>
i've started working on that until it turned out nobody could show that it brings a perf improvement
<kchibisov>
it only matters for GPUs without smart firmware iirc.
<emersion>
yeah, i paged these folks
<kchibisov>
I think it only possible with panfrost, but panfrost is nearly dead.
<kchibisov>
anyway, I'm not against wsi being not in mesa, it just seems that there's very little resources to fix even mesa one.
tlwoerner_ has quit []
tlwoerner has joined #wayland
<DemiMarie>
@_oftc_kchibisov:matrix.org: why does firmware help?
<kchibisov>
I think AGX doesn't need it and it has something similar on firmware level?
<kchibisov>
At least I was told someone messing with AGX a while ago about it when I asked them.
<kchibisov>
Because the end goal of this extension if I'm not mistaken is to communicate which tiles will get updated.
Moprius_ has joined #wayland
<daniels>
kchibisov: I don’t know why you think Panfrost is ‘nearly dead’, but it’s not even remotely true
<kchibisov>
daniels: panfrost advertises broken extension for like a year.
<kchibisov>
So I have regular reports from users that alacritty is broken because all text is black.
<kchibisov>
we even sent some patch ourselfves recently, because no one wanted to fix regression besides us, it semems.
<daniels>
kchibisov: link me the MR
<kchibisov>
be aware, we have no idea what we do.
Moprius has quit [Ping timeout: 480 seconds]
<daniels>
it’s true that alacritty on Mali isn’t our primary focus, but there are multiple oceans between there and ‘nearly dead’
<kchibisov>
the point is different though.
<kchibisov>
we support pure GLES 2
<kchibisov>
so we work without any extensions.
<kchibisov>
but mesa says that it supports extension so we can take fast path, so we take it and then mesa asserts.
<daniels>
that’s fine. just post a link to the MR.
<kchibisov>
but the regression was in introduced in Feb 2023.
Brainium has quit [Ping timeout: 480 seconds]
<daniels>
I think, reflexively, that it’s the wrong fix. can you please post a reproducer in there?
<kchibisov>
It has linked issue.
<kchibisov>
with repro, bisection, etc.
<daniels>
(some will say that if something broke it a few months ago then it’s not dead, because if it was, there wouldn’t have been a change to break it)
<kchibisov>
Yeah, but it's a year and the lead maintainer who broke just said that they don't maintain, so won't fix.
<kchibisov>
The problem is not fixing regression, but the communication, mostly.
<daniels>
back to WSI, it makes sense for Linux in the current era, but not for other OSes (they don’t have anything close to the same primitives to expose), and also not for the era when WSI was created
<kchibisov>
Since we offered to _fix ourselves if they can at least give a clue_.
<emersion>
daniels: yeah i've been wondering about other OSes as well
<daniels>
kchibisov: we have a lot to do, and alacritty users are not the majority of Mali users
<kchibisov>
I'm familiar with windows OpenGL wsi, it gives me nightmares.
<kchibisov>
daniels: it was not found in alacritty first though.
<kchibisov>
I'm pretty sure dual source blending is used even in firefox.
sima has quit [Ping timeout: 480 seconds]
<kchibisov>
(at least their webrenderer uses it).
<daniels>
emersion: nothing even like modifiers. even formats are more of a vague concept than something concrete. a lot a lot a lot of under-the-hood mystery.
<kchibisov>
Like if mesa can't fix they can hide extension.
<daniels>
kchibisov: Firefox works well on Mali
<kchibisov>
with webrenderer?
<kchibisov>
The issue is that it can't compile any dsb shader.
<kchibisov>
and webrenderer in firefox uses dsb.
<daniels>
yes, with webrenderer
<kchibisov>
maybe they don't try to enable it for gles.
<kchibisov>
Or they render into texture and then blend, but the point is that it's _assert_