02:10 acsqdotme: what's the simplest way to change keyboard layouts for a wayland system?
02:12 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.
03:10 wlb: wayland Issue #426 opened by Eduardo Hopperdietzel (ehopperdietzel) Adding restrictions to global binding and resource creation. https://gitlab.freedesktop.org/wayland/wayland/-/issues/426
07:57 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
08:11 wlb: weston Merge request !1414 opened by FOREAL (Foreal) Foreal main patch 02812 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1414
09:04 daniels: acsqdotme: you’d have to check the dwl documentation
10:12 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.
10:13 pq: riteo, otherwise, good luck getting window state change from floating to maximized reliable and not crashy.
10:19 pq: riteo, doing anything other that *scheduling* a new draw from a frame callback sounds like a high risk to be a broken design.
11:18 pq: riteo, if you were talking about https://gitlab.freedesktop.org/libdecor/libdecor/-/blob/master/src/libdecor.h?ref_type=heads#L147-153 I wonder if that was misunderstood. It does not sound like "you must commit main surface now" but more like "maybe you want to make sure your main surface has an update scheduled, because the decor has pending updates that won't be visible otherwise".
11:19 pq: If you make multiple changes to the decorations in one go, you really should not commit your main surface more than once.
11:20 pq: jadahl, ^
11:23 pq: riteo, if you must draw at N Hz consistently, use a timer and ignore frame callbacks.
11:24 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.
11:24 pq: It's not necessary if you have a good reason to risk discarding the previous frame.
11:24 pq: It's not sufficient if you have nothing new to show.
11:25 pq: The very first frame of window being mapped needs to be drawn without a frame callback anyway.
11:27 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.
11:28 pq: If drawing is in separate thread from Wayland event handling, then just hand off a state structure to the drawing thread.
11:28 emersion: pq, i think mesa will stall if you try to render with a timer
11:29 pq: emersion, yup, so you set eglSwapInterval to zero.
11:29 emersion: hm, should be fine with swapinterval=0
11:29 pq: then Mesa will only stall for free buffers
11:31 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.
11:31 pq: queue internally, that is
11:33 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.
11:34 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.
11:36 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...
11:37 pq: or, a helper library shared with Mesa that does all the zwp_linux_dmabuf handling, so one would not need EGL Wayland platform
11:40 emersion: would be nice
18:57 DemiMarie: pq: does this mean that EGL and the Vulkan WSI are bad APIs?
19:40 kennylevinsen: DemiMarie: https://www.supergoodcode.com/wsi-was-a-mistake/
19:41 DemiMarie: kennylevinsen: I’m not saying you are wrong, but that isn’t really a helpful post :)
19:41 kennylevinsen: Anything else would just be unnecessary filler :P
19:43 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
19:44 kennylevinsen: Leave window management up to the surrounding platform code...
19:46 Ermine: Is the posy author from Intel?
19:48 kennylevinsen: Mike is at valve if his about section is to be trusted
20:09 wlb: wayland-protocols Merge request !265 opened by Simon Ser (emersion) xdg-decoration: add invalid_mode error https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/265 [xdg-decoration]
20:14 Ermine: Ah, thank you. I remember seeing him somewhere on irc (or in fdo gitlab), but my memories got corrupted
20:36 daniels: yeah, Mike is at Valve and working on Zink
20:36 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
20:37 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
20:38 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
20:38 daniels: the Vulkan dmabuf extensions do let you ignore WSI and roll your own if you want with little-to-no penalty, unlike EGL
20:40 emersion: thanks to WSI being this bad i can bring food to my table
20:41 emersion: daniels: hm, how is the Vulkan DMA-BUF ext different from the EGL one? to me they sound pretty similar?
20:41 emersion: well, modulo allocation which works correctly on Vulkan
20:41 emersion: on EGL you'd use GBM
20:42 emersion: but on both Vulkan and EGL, you need to do the linux-dmabuf protocol stuff yourself?
20:45 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)
20:46 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
20:46 emersion: :D
20:46 emersion: hm, right
20:53 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 :/
20:56 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
20:56 daniels: up to date with Vulkan's evolution
20:56 daniels: so like, the first couldn't happen, and the second did
20:57 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
20:57 kennylevinsen: But yeah, I know it's nothing new
20:57 kennylevinsen: yup
21:03 kchibisov: kennylevinsen: each vendor has their own wsi with its quirks because of how their drivers work.
21:04 kchibisov: like nvidia hooks into exit and tries to clean stuff, etc.
21:05 kchibisov: they also use wp_presentation, etc.
21:05 daniels: they should be using the protocols ManMower has been writing up to actually do FIFO properly :)
21:06 kchibisov: i mean, fifo is broken in mesa as well :p
21:06 kchibisov: I think the same with eglSwapInterval
21:06 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
21:07 kchibisov: And I should maintain wsi specific for nvidia, because they do and expect things differently?
21:07 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
21:07 ManMower: I took a shot at swapinterval too... https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26528
21:07 daniels: kchibisov: the new protocols literally exist to make FIFO not broken!
21:09 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
21:10 kchibisov: And then nvidia devs ask you to please run this command so our GPU don't die.
21:10 kchibisov: Like cross platform is a mess.
21:11 kchibisov: And if you do things differently on linux, we'll have each toolkit maintain their own wsi.
21:11 kchibisov: though, we have stuff like that in compositors already.
21:11 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
21:12 daniels: kennylevinsen: 'just' :)
21:12 kchibisov: wsi should work not only for waylan.d
21:12 kennylevinsen: daniels: I know I know, but I think it's good enough a simplification for *this* part of the discussion :P
21:12 daniels: kchibisov: literally the point of WSI is that it's not specific to Wayland
21:12 kchibisov: exactly, and you have a lot of mess in it.
21:12 kennylevinsen: kchibisov: the story is the same for other platforms: the WSI parts are dictated by the platform, not the driver.
21:13 kchibisov: e.g. xlib device init stuff, xpresent working _sometimes_ for _someone_.
21:13 kennylevinsen: a WSI does not need nvidia hacks, it needs macos/wayland/x11 hacks
21:13 kennylevinsen: it might *currently* have nvidia hacks because it exists in an nvidia user-space driver, because they can...
21:13 kchibisov: And then, obviously, I won't be using your standalone wsi impl.
21:14 kennylevinsen: and the need for a cross-platform implementation is not the same as need for putting it in mesa
21:14 kennylevinsen: A cross-platform "put a vulkan buffer on screen" library can exist externally just as well
21:15 kchibisov: I mean, sure, but there's no way anyone will invest their lifetime into maintaining this mess.
21:15 kennylevinsen: that's what they're doing right now, in mesa
21:15 kchibisov: or cooperate to write code.
21:15 kennylevinsen: I'm just saying it's in the wrong box
21:15 kchibisov: I mean with mesa it's at least in mesa.
21:16 kennylevinsen: yeah, my attitude is more that it should only be in mesa if it cannot exist externally at all
21:17 kchibisov: it would be nice to hook your wsi impl into mesa though.
21:17 daniels: I don't know what the alternative proposal is
21:18 emersion: i think kenny's point is that Vulkan/GL impls shouldn't be in the business of doing WSI
21:18 emersion: instead, libraries like glfw for instance could do it
21:18 emersion: since these do other WSI stuff anyways, like input
21:18 kchibisov: so we have a wsi in each toolkit and then mesa devs saying that we work only with wsi Y.
21:18 kchibisov: and if you don't work with wsi Y, we won't support you.
21:19 emersion: no, mesa works with DMA-BUFs
21:19 emersion: and is used only for submitting work to the GPU, not for presentation
21:19 kchibisov: So you want mesa work with only dmabufs and then you just pass them into mesa?
21:20 kchibisov: which you get _somehow_
21:20 kchibisov: Like I don't understand how are you supposed to do EGL platform stuff.
21:21 kchibisov: But I'm not experienced with doing dmabufs directly, I only touched mesa wsi a couple of times.
21:21 emersion: Vulkan can allocate DMA-BUFs, alternatively there is also GBM
21:22 emersion: either way, you import the DMA-BUF into Vulkan for drawing onto it
21:22 kchibisov: And what if I want to use something not using gbm?
21:22 emersion: and then use a WSI library to present it
21:22 emersion: something not using GBM?
21:23 kchibisov: I think llvmpipe is not using gbm?
21:23 kchibisov: Or it does use them?
21:23 emersion: there are extensions to import SHM buffers into Vulkan as well
21:23 kchibisov: I know that you can use dumb buffers with gbm, you can craete dmabuf for them though with libdrm.
21:23 kchibisov: what if I don't have vulkan?
21:23 kchibisov: my device doesn't support it.
21:24 emersion: there is a similar ext for EGL
21:24 kchibisov: ok, what to do with X?
21:24 kennylevinsen: kchibisov: for reference, the wlroots does not use WSI when rendering on X11 and Wayland backends. Works fine with gles and vulkan.
21:25 emersion: X isn't different from Wayland
21:25 kennylevinsen: and worked fine with llvmpipe, although we use a dedicated software renderer now because llvmpipe is slow
21:25 emersion: DRI3+Present gives you the same as Wayland's linux-dmabuf
21:25 kchibisov: Can nvidia even do DRI3?
21:25 emersion: i have no idea
21:26 kennylevinsen: those kinds of questions make me happy that I didn't get into the graphics stack until *after* I switched to Wayland
21:26 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
21:26 kchibisov: exactly.
21:26 kchibisov: and cross platform the only way that works is EGLSurface.
21:27 emersion: i don't think it's the only way that it could work
21:27 kchibisov: even in open source drivers, want partial present? Use EGSurface.
21:27 emersion: that's… unrelated?
21:27 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...
21:28 kchibisov: Yeah, the point of API to be cross platform.
21:28 emersion: what do you mean exactly by "partial present"?
21:28 emersion: damage?
21:28 kchibisov: emersion: EGL_KHR_partial_update.
21:28 emersion: right, that ext is pretty bad
21:28 kchibisov: I haven't found a way to do it without EGLSurface.
21:28 emersion: if we cared, we could have a better ext which doesn't depend on EGLSurface
21:29 emersion: i've started working on that until it turned out nobody could show that it brings a perf improvement
21:29 kchibisov: it only matters for GPUs without smart firmware iirc.
21:29 emersion: yeah, i paged these folks
21:30 kchibisov: I think it only possible with panfrost, but panfrost is nearly dead.
21:32 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.
21:43 DemiMarie: @_oftc_kchibisov:matrix.org: why does firmware help?
21:44 kchibisov: I think AGX doesn't need it and it has something similar on firmware level?
21:45 kchibisov: At least I was told someone messing with AGX a while ago about it when I asked them.
21:45 kchibisov: Because the end goal of this extension if I'm not mistaken is to communicate which tiles will get updated.
21:48 daniels: kchibisov: I don’t know why you think Panfrost is ‘nearly dead’, but it’s not even remotely true
21:48 kchibisov: daniels: panfrost advertises broken extension for like a year.
21:49 kchibisov: So I have regular reports from users that alacritty is broken because all text is black.
21:50 kchibisov: we even sent some patch ourselfves recently, because no one wanted to fix regression besides us, it semems.
21:50 daniels: kchibisov: link me the MR
21:50 kchibisov: be aware, we have no idea what we do.
21:51 daniels: it’s true that alacritty on Mali isn’t our primary focus, but there are multiple oceans between there and ‘nearly dead’
21:51 kchibisov: the point is different though.
21:51 kchibisov: we support pure GLES 2
21:51 kchibisov: so we work without any extensions.
21:52 kchibisov: but mesa says that it supports extension so we can take fast path, so we take it and then mesa asserts.
21:52 daniels: that’s fine. just post a link to the MR.
21:52 kchibisov: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26474
21:53 kchibisov: but the regression was in introduced in Feb 2023.
21:53 daniels: I think, reflexively, that it’s the wrong fix. can you please post a reproducer in there?
21:53 kchibisov: It has linked issue.
21:53 kchibisov: with repro, bisection, etc.
21:53 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)
21:54 kchibisov: Yeah, but it's a year and the lead maintainer who broke just said that they don't maintain, so won't fix.
21:54 kchibisov: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9487
21:54 kchibisov: That's the original issue.
21:55 daniels: nice, that works. will fix. thanks!
21:55 daniels: just hope you appreciate the gulf between ‘my issue wasn’t fixed’ and ‘is nearly dead’
21:55 kchibisov: Yeah, but it's just the feel I get.
21:56 kchibisov: Like it's not the only issue.
21:56 kchibisov: And not only my words.
21:56 kchibisov: There were issues (not related to alacritty) that was brought and somehow fixed, but with no reference to issue tracker, etc.
21:56 kchibisov: Like I have generally more luck with r300/i915, but they are like for _really old hardware_.
21:57 daniels: they don’t change, so they don’t break
21:57 kchibisov: I have a breakage on r300 like a month ago.
21:58 kchibisov: So they definitelly change.
21:58 kchibisov: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9918
21:59 kchibisov: The problem is not fixing regression, but the communication, mostly.
21:59 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
21:59 kchibisov: Since we offered to _fix ourselves if they can at least give a clue_.
21:59 emersion: daniels: yeah i've been wondering about other OSes as well
22:00 daniels: kchibisov: we have a lot to do, and alacritty users are not the majority of Mali users
22:00 kchibisov: I'm familiar with windows OpenGL wsi, it gives me nightmares.
22:00 kchibisov: daniels: it was not found in alacritty first though.
22:01 kchibisov: I'm pretty sure dual source blending is used even in firefox.
22:01 kchibisov: (at least their webrenderer uses it).
22:01 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.
22:01 kchibisov: Like if mesa can't fix they can hide extension.
22:01 daniels: kchibisov: Firefox works well on Mali
22:02 kchibisov: with webrenderer?
22:02 kchibisov: The issue is that it can't compile any dsb shader.
22:02 kchibisov: and webrenderer in firefox uses dsb.
22:02 daniels: yes, with webrenderer
22:02 kchibisov: maybe they don't try to enable it for gles.
22:03 kchibisov: Or they render into texture and then blend, but the point is that it's _assert_
22:03 emersion: daniels, there is at least https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VK_KHR_external_memory_win32.html
22:03 emersion: that should be enough to make a WSI lib and Vulkan work together
22:03 kchibisov: Like there's no even indication that something failed to complie.
22:03 emersion: even if everything is magic under-the-hood
22:04 daniels: emersion: yeah, but how do you allocate sensibly for your HWND?
22:04 emersion: hm
22:05 kchibisov: just fyi, wgl can load different OpenGL drivers based on window position, etc.
22:05 emersion: i mean, Vulkan
22:05 kchibisov: and widnow tpe.
22:05 kchibisov: So I guess they have something similar with Vulkan under the hood.
22:05 kchibisov: Maybe it's completely different though.
22:06 emersion: hm, this isn't going to work
22:09 emersion: oh great, IDXGISurface has actually nothing to do with what i think it does
22:12 kchibisov: daniels: what do you mean by mali users btw? because surely there're laptops with mali.
22:12 kchibisov: if you mean phone shells, then it was initially reproduced in mobile compositor env.
22:22 daniels: there are laptop Mali users, but they’re not the majority
22:22 kchibisov: And they are also not a phone users?
22:23 kchibisov: I mean, not a phone users running wayland compositors*
22:23 kchibisov: Like initially it was all with https://github.com/catacombing/catacomb
22:23 kchibisov: because top ui panel used DSB for rendering the text.
22:24 daniels: most phone users don’t run catacomb either …
22:25 kchibisov: that's true, but I'm sure some test should notice that shaders don't compile?
22:25 kchibisov: you don't even need fancy shader, you just need to put DSB extension in it.
22:26 kchibisov: I know that people usually don't use DSB when the GL is not 3.3.
22:26 daniels: it sounds like we need more Piglit coverage, sure
22:27 kchibisov: It's just mesa dev working on lima suggested us to do that in the past.
22:27 kchibisov: and ofc it works on lima :p