01:21orowith2os[m]: https://github.com/flightlessmango/MangoHud/pull/1093
04:43i509vcb: orowith2os[m]: wayland-rs has a full rust mode but you'll have to reinvent gl and vulkan wsi to avoid pulling in libwayland
04:48ids1024: https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt says the call can fail due to driver restrictions in pitch and offset. `zwp_linux_dmabuf_feedback_v1::main_device` says "Clients need to create buffers that the main device can import and read from, otherwise creating the dmabuf wl_buffer will fail (see the wp_linux_buffer_params.create and create_immed
04:48ids1024: requests for details)."
04:48ids1024: Does it follow that `create_immed` may produce a protocol error for an offset or stride that is valid but not supported by the `main_device`, without any way for the client to know this restriction through the protocol?
06:05emersion: yes
06:05emersion: or any other driver-specific reason really
11:06WhyNotHugo: Is it possible to run XWayland with a nested X11 window manager?
11:07WhyNotHugo: This is mostly theoritical curiosity, but if someone wanted to use X11, could they do it entirely in a nested session (with something like cage)?
11:07emersion: yes
11:10WhyNotHugo: Oh, I guess that the main details here is not to run it with -rootless
13:10MrCooper: ids1024: an LD_PRELOAD based keylogger doesn't break any security boundary; in contrast, an X based one can log all input any other client receives
13:58orowith2os[m]: jadahl: fwiw are you interested in landing some support for `GtkSettings:gtk-application-prefer-dark-theme` in the GTK libdecor plugin?
13:58orowith2os[m]: I need to look at the whole process so it's set only when it needs to be (system is dark mode) but seems like something to have
14:14jadahl: orowith2os[m]: why not
14:21orowith2os[m]: jadahl: alrighty, gonna research it a bit :)
14:45iomari891: greetings, can I safely use bindfs to mount a folder as /var?
14:48iomari891: wrong channel. sorry
14:57ids1024: emersion: That does seem like an issue with create_immed. Unless you specifically know what the main device can import, there would be no way to safely use it without getting a protocol error. (With `create` you can handle this, but Mesa's EGL and WSI code seems to only use create_immed currently.)
14:58emersion: that's an issue with a single GPU as well
15:02i509vcb: If import can fail due to reasons the driver or application can't predict, I don't see a reason to even have create_immed
15:07ids1024: Yeah, it shouldn't be possible to get a protocol error for something the client can't foresee and avoid. Though it's also a bit odd that `create_immed` says it may produce a protocol on failure, or may send a `failed` event.
15:08emersion: there is no "failed" event in this case
15:17ids1024: "Upon import failure, either of the following may happen, as seen fit by the implementation: - the client is terminated with one of the following fatal protocol errors: - INCOMPLETE, INVALID_FORMAT, INVALID_DIMENSIONS, OUT_OF_BOUNDS, in case of argument errors such as mismatch between the number of planes and the format, bad format, non-positive width or height, or bad offset or
15:17ids1024: stride. - INVALID_WL_BUFFER, in case the cause for failure is unknown or plaform specific. - the server creates an invalid wl_buffer, marks it as failed and sends a 'failed' event to the client. The result of using this invalid wl_buffer as an argument in any request by the client is defined by the compositor implementation."
15:18ids1024: So `create_immed` is documented to send a protocol error, OR send `failed` and have the wl_buffer behave in future requests in an implementation defined manner.
15:19ids1024: Oh, I guess the formatting there is kind of broken reading it on wayland.app
15:22ids1024: The grouping here is clearer in the XML, but it still suggests that `failed` could be sent, instead of a protocol error, and doesn't specify that should only happen for certain types of errors. So that is a possible behavior here as defined by the spec.
15:29emersion: there is no way to send the failed event in the create_immed path
15:29emersion: create_immed doesn't create the object where the failed event is sent
15:30ids1024: Failed is an event on the `zwp_linux_buffer_params_v1`
15:30emersion: ah, right
15:30emersion: i thought it was separate
15:31i509vcb: I'd probably err towards import on the server being 100% fallible
15:40ids1024: If it fails, there's no obvious way for the client to know what will (other than trying different parameters that tend to be better supported), but it could at least fall back to `wl_shm`, which should always work. But currently mesa and Nvidia's egl-wayland just use create_immed.
15:57emersion: the real solution is buffer constraints
19:06bl4ckb0ne: is somebody already in charge to do next week's governance meeting?
19:23jadahl: bl4ckb0ne: last one we thought there would be an inputfd one so didn't assigned anyone to schedule a next one
19:30bl4ckb0ne: yeah i messed up last time
19:30bl4ckb0ne: there was one already scheduled
19:31bl4ckb0ne: ill take care of it then
19:31bl4ckb0ne: and try not to put the admin link this time
19:41manuels: hey guys i have another niche case. i want my launcher to be able to paste text into the frontmost window. like open launcher, select snippet or some other text source and paste it.
19:42manuels: i guess wayland is not that straight forward in this case, but is it possible?
19:43manuels: but somehow is has to be possible right, i mean the launcher basically acts as an input method. what do i have to do to achieve such a thing?
21:23akik: hi, i'm using Xwayland in wsl 2 (windows) to start it up for :1. the problem is i can't find where the X1 socket is. i can see that it exists somewhere https://termbin.com/onyu
21:32akik: (/tmp/.X11-unix/X0 exists but that's the wsl 2 default)
21:34akik: the https://termbin.com/onyu output is from lsof ran in wsl 2
23:48Ermine: X1 should be in the same place as X0, shouldn't it?
23:49orowith2os[m]: Any X11 sockets are basically required to be in /tmp.X11-unix
23:49orowith2os[m]: well, you can also go over the network, but that's another topic, and less performant
23:50orowith2os[m]: but that location is hardcoded, and it's a real pain, especially for us Flatpak folks; see https://github.com/flathub/org.freedesktop.Platform.VulkanLayer.gamescope/issues/6 for an example resulting from it