00:49 ErrorNoInternet: zamundaaa[m]: KWIN_DRM_DEVICES does seem to work! i set the first device as my nvidia GPU and my second as the intel gpu (otherwise it would lock up my display and keyboard). kwin_wayland looks like its running on my nvidia gpu, not 100% sure if its real though
10:05 ifreund: the protocol doesn't state explicitly whether compositors are required to send a wl_keyboard.keymap event before the first wl_keyboard.enter event
10:05 ifreund: is this in fact required or not?
10:07 emersion: IMHO keymap should be sent on keyboard object creation always
10:13 pq: ...if a keymap exists to begin with
10:15 emersion: we have NO_KEYMAP
10:15 pq: what fd do you send?
10:15 emersion: unfortunately FDs are not nullable so you need to send a /dev/null or something
10:15 pq: right
10:17 ifreund: Either way, it would be good to document this in the protocol
12:18 Company: robertmader[m]: you're aware that mutter's YUV stuff is busted on AMD because of the stride issue?
12:19 robertmader[m]: Company: shouldn't be the case for anything produced by VA-API
12:19 robertmader[m]: But yeah, for cameras it's difficult.
12:19 Company: I had thought you importing as RGB would work around it
12:24 robertmader[m]: Nah, AMD really wants to have stuff aligned. Annoying - but IMO video playback is also way more interesting. I wonder if we can either make the AMD devs add some workaround for dmabufs from sysmem - or if the stride should somehow be negotiable (via pipewire) and if v4l2 could produce stuff accordingly.
12:29 Company: robertmader[m]: the conclusion last time was that everybody should just allocate at strides of 256 by default
12:29 Company: robertmader[m]: but I didn't talk to v4l people about that idea
12:29 robertmader[m]: <robertmader[m]> "Nah, AMD really wants to have..." <- I mean - I can see that they want the stride if the buffer comes from the same GPU/driver. But if they have to move the buffer to vram anyway, why not add padding themselves somehow?
12:30 pq: what do you know, Dr. Charles Poynton is on Mastodon.
12:33 Company: robertmader[m]: I don't think mapping memory works that way?
12:35 robertmader[m]: AFAIK dmabufs are some kind of magic where kernel drivers move things around - which is why it's easy to get wrong / super slow.
12:37 Company: it's mostly easy to get wrong because nobody talks to anyone else
12:37 pq: dmabuf are explicitly not like that, for that very reason
12:37 Company: and there's no best practices
12:39 daniels: well, with dmabufs you can move the underlying storage, but you can't mutate the data - padding out stride to a different alignment definitely counts as mutation
12:40 daniels: as soon as you do that, you have a different copy of the data, so it's very much not dmabuf
12:40 pq: The original dmabuf idea was to share the handle with all involved devices first, and only afterward trigger the actual allocation. But then turned out that everyone just allocate first and export a handle second.
12:40 Company: that's also hard to pass through the stack
12:41 pq: yes, I believe convience was a very big reason to not do the original plan.
12:41 Company: because suddenly the compositor needs to talk to the app so it can tell pipewire to make them all share the involved devices
12:42 pq: daniels, who is "you" there?
12:43 Company: another thing I suspect dmabuf is suffering from today is that people on embedded stuff all make their devices compatible
12:43 pq: maybe the exported can move the data before anyone has imported the dmabuf?
12:43 pq: *exporter
12:43 Company: because it's easy - you know what devices are in the soc and can hack the drivers
12:44 daniels: pq: correct, I believe it's valid for storage to be moved when no-one else has an active attach
12:44 Company: but the desktop stack with its random device combinations hasn't used dmabufs much
12:44 pq: daniels, doesn't that mean that if AMD is importing something allocated by someone else, it cannot move it to make it compatible with AMD hw?
12:45 daniels: pq: I think you're right to say that
12:45 Company: everyone dup()s the fds at least
12:45 daniels: though iirc there is a move callback you can use? or maybe that was just TTM-internal and not usable for dmabufs generically
12:45 pq: unless maybe if the exporter already dropped all references to it? preventing re-use
12:46 pq: daniels, moving is a heavy operation. Would that really be semantically ok to do on dmabuf import?
12:48 daniels: \_o_/
12:48 pq: I aasumed not.
12:48 emersion: i would really really like a way to check whether an import will cause a move or not
12:49 Company: A move is certainly better than not importing
12:49 emersion: because right now it's… import into KMS, do a test commit, that fails -- too late, time already been spent on moving stuff around needlessly
12:50 pq: yeah, sometimes even a fallback might be better than a move, I imagine
12:52 pq: maybe the move forbids re-use because the source device loses usability, or maybe that case would simply refuse to move
12:52 kennylevinsen: reminds me of the need for being able to do a test commit with a buffer before it is allocated (to try modifiers)...
12:53 kennylevinsen: (vaguely related to "test a buffer without doing an import")
12:54 emersion: yeah that too…
12:54 emersion: if only someone was paid to solve all problems in FOSS
12:55 kennylevinsen:stares at emersion
12:55 kennylevinsen: :D
12:55 emersion:stares at the wall behind
12:55 kennylevinsen: one person is enough, right? Not that much open source code out there to fix
12:55 emersion: it's mainly AMD headers anyways
12:56 kennylevinsen: hah, true
13:10 daniels: emersion: … without creating new problems?
13:11 emersion: i don't know what you're talking about
13:11 emersion: the fact that v3d/vc4 is totally not my fault and i don't know anything about it
13:11 emersion: is broken is*
13:33 MrCooper: robertmader[m]: the drivers can't know when they'd need to copy from the dma-buf to their shadow copy, so they'd have to either pessimize that or risk glitches
13:35 MrCooper: Company: dma-buf is the central mechanism for hardware acceleration on any non-ancient Linux desktop; presumably you mean specifically for inter-device sharing, which isn't the main use case for dma-buf
13:35 Company: MrCooper: I also specifically mean same device but different software stack
13:36 Company: va-api vs GL vs Vulkan vs qemu isn't without problems either
13:37 daniels: MrCooper: systems with three separate codec/GPU/display devices would violently disagree with you
13:37 Company: even high0level things like GL handing me DRM_MODIFIER_INVALID and Vulkan not allowing that
13:38 MrCooper: daniels: didn't say there were no other use cases
13:38 MrCooper: but the main one is surely passing dma-bufs for the same device between different processes
13:39 Company: like, I have 4 use cases here, and only one of them seems to work with another one working if I do the right thing
13:39 Company: and 3 use cases are same device
13:39 Company: screencasting, webcam, qemu and video decode
13:40 daniels: MrCooper: it came out of a Linaro F2F in 2012 (?), so it was hardly a random afterthought …
13:40 Company: screencasting works, webcam is the stride thing, qemu is busted and video decoding gets stuck in GStreamer somewhere
13:40 MrCooper: to be clear, I mean main as in "most often used"
13:41 Company: I have the feeling on desktop, dmabuf is almost exclusively wl_buffer until pretty recently when video decode started happening
13:42 Company: on embedded, it's a lot more wild what people are doing
13:42 Company: there are some weird GStreamer pipelines with single-usecase elements
13:43 Company: that shuffle video between webcams, video decode/encode, and display systems
13:45 daniels: MrCooper: if you’re counting by number of devices, then same-device is a very very significant minority
13:45 daniels: *insignificant
16:01 pq: The saga "wtf sRGB" continues...
16:02 pq: The thing I learnt today is that apparently people *can* see the difference.
16:03 MrCooper: the difference between what and what?
17:03 Vanfanel: Hello. I am trying to implement pointer constraints in the CAGE compositor, but if I include "wlr_pointer_constraints_v1.h", I get an error abut "pointer-constraints-unstable-v1-protocol.h" being missing. Where is that "pointer-constraints-unstable-v1-protocol.h" file supposed to come from?
17:05 emersion: Vanfanel: i'd suggest asking in #wlroots on Libera
17:07 Vanfanel: emersion: Ok, I will do that, thanks!
21:08 JPEW: We are looking at adding support to the fullscreen shell for a background image (sort of like the desktop shell). Assuming this is even possible, would weston upstream accept this? It would really help with some usability complaints we've had while using weston
21:08 JPEW: And I hate not upstreaming things first :)
21:10 emersion: doesn't weston already support fullscreen-shell?
21:10 emersion: why do you want fullscreen-shell, and not desktop shell?
21:11 JPEW: emersion: Sorry perhaps not clear, we are using the fullscreen shell as is, we want to add support for a background image to it
21:11 JPEW: We kinda have to use fullscreen shell because it's an embedded device with multiple monitor support and we need precise control over what gets displayed on what monitor
21:12 daniels: JPEW: we’re using Weston’s kiosk mode for that these days, with xdg-shell for clients
21:13 JPEW: daniels: Ya, I've been told to look at that; we're still on some older weston(s) and we have some pretty strict requirements so IDK if kiosk would work (need to look though)
21:13 daniels: that’s much more actively maintained, and makes the clients less weird :) it does also have support for background colours, and directing specific surfaces to specific outputs
21:14 daniels: but yeah, if there’s something missing we could look at it
21:16 JPEW: Ya, it's on our TODO list to look at kiosk shell... I don't think we can get rid of fullscreen shell yet though. I was mostly check to see if we did add support for a background image to the fullscreen shell it wouldn't get outright rejected for some reason :)
21:32 daniels: JPEW: hmm, it is deprecated and scheduled for removal at the next point it stands in the way of some other useful work … but a patch against 8.x wouldn’t apply anyway
21:32 JPEW: Oh.... well.... that's not good :/
23:09 JoshuaAshton: pq: I am guessing you mean the difference between sRGB with piecewise EOTF and Gamma 2.2 as EOTF?