06:34emersion: ity: sure, can be abstracted away by libraries, e.g. like toolkits do or even GL/Vulkan. but at the Wayland protocol level, it still needs to be dmabufs and can't be abstracted
07:32ity: emersion: I don't understand why at the protocol level it has to be dmabufs, what is the difference between passing dmabufs directly and having a library that translates to dmabufs on Linux ?
07:33emersion: the protocol is not code, it's a communication mechanism like HTTP
08:35wlb: wayland Issue #477 closed \o/ (Crash when playing games and using a screen recorder/streaming https://gitlab.freedesktop.org/wayland/wayland/-/issues/477)
09:06Helmholtz: Can I ask a libinput question? Is it possible to enable BOTH edge and twofinger scroll for a touchpad that is using libinput driver?
14:33wlb: wayland Issue #478 opened by Kirill Primak (vyivel) scanner: C keywords aren't escaped https://gitlab.freedesktop.org/wayland/wayland/-/issues/478
16:49wlb: wayland Merge request !402 opened by Simon Ser (emersion) scanner: fix validator for bitfields https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/402
17:22deathmist1: hey, I've got a Minisforum V3 AMD tablet which seems to exhibit a libinput bug(?): with the keyboard case attached the tablet volume keys work as expected but if I remove it (same if I boot without it attached). /dev/input/event0 always seems to provide events if I cat it. debug-events example: https://paste.c-net.org/rt2sghudiqoz
17:23deathmist1: s/but/but not/
17:28kennylevinsen: deathmist1: you can try to monitor event0 with evtest
17:28kennylevinsen: that will show you what events come out of the kernel for that device
17:29kennylevinsen: better than cat'ing it :)
17:39deathmist1: kennylevinsen: looks as expected https://paste.c-net.org/9xllvnd4unhz
17:53deathmist1: ok I went through all keys on the keyboard and have a theory: the volume keys are part of the same event device as the detachable keyboard (partially) so libinput never considers it "active" even if volume keys are still present on-device without the keyboard case attached. the only thing shared with the keyboard case seems to be LED_CAPSL for the caps lock LED seemingly. this even
17:53deathmist1: also wasn't visible in debug-events fwiw
17:57deathmist1: https://wayland.freedesktop.org/libinput/doc/latest/switches.html#tablet-mode-switch-handling "When the device switches to tablet mode, the touchpad and internal keyboard are disabled", I guess I'd have to make it ignore doing this for event0 since it's also used for the volume keys?
18:04deathmist1: with "libinput debug-events --verbose" I indeed see "event0 - tablet-mode: suspending device" https://gitlab.freedesktop.org/libinput/libinput/-/blob/1.26.1/src/evdev-fallback.c#L1333-1337, looks like there's no way to avoid this for a specific device even as a quirk currently?
18:10kennylevinsen: deathmist1: There's "QUIRK_MODEL_TABLET_MODE_NO_SUSPEND"
18:11kennylevinsen: `ModelTabletModeNoSuspend`, example here: https://gitlab.freedesktop.org/libinput/libinput/-/blob/main/quirks/30-vendor-microsoft.quirks
18:31deathmist1: kennylevinsen: thanks, I got it working, guess I'll send a PR :)
18:31deathmist1: or rather MR but yea
18:44wlb: wayland Issue #479 opened by John Fairbairn (JohnFairbairn) Reaper Window Won't Open Full Size Using Wayland on Debian 12 - KDE Plasma https://gitlab.freedesktop.org/wayland/wayland/-/issues/479
18:52wlb: wayland Issue #479 closed \o/ (Reaper Window Won't Open Full Size Using Wayland on Debian 12 - KDE Plasma https://gitlab.freedesktop.org/wayland/wayland/-/issues/479)
18:59vyivel: i wonder if issue reporters at least try to read the issue template or just delete it immediately
19:19deathmist1: ennylevinsen: https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1026
19:32deathmist1: um, kennylevinsen: not sure how the k got lost. thanks again for the pointers!
19:34kennylevinsen: You’re welcome
20:16ity: emersion: I don't understand why the protocol would have to be code for an abstraction to exist ? Like, dmabuf is already an abstraction on top of GPU-specific buffer handling, which then utilizes the kernel API (which is most likely utilized through libgbm). The same kind of argument could be made for not using dmabuf and instead having a custom protocol for Intel's buffer handling,
20:16ity: AMD's buffer handling, NVIDIA's buffer handling, Lima's buffer handling... Thankfully the kernel at least abstracts that, but it's still an API, and most importantly *code* that ties them together.
20:17emersion: i mean, nothing stops you from writing a spec for cross-platform buffer sharing
20:18emersion: but getting it working on multiple platforms, accepted and merged there, etc etc, is just going to be… a challenge
20:18emersion: and that's an understatement
20:19emersion: i personally don't even think it would be desirable
20:19ity: Indeed, however I am asking whether there is room for adoption, or whether major projects (like Mesa) have already decided they will only support linux-dmabuf. I could make an MR for Mesa, however I'd rather know what is the sentiment around it before doing all of the work just to realize it has already been decided to not support non-Linux DRM platforms.
20:19ity: Why do you think it would not e desirable?
20:20emersion:recalls about EGLStreams
20:20emersion: because it just makes a whole lot of things more difficult or impossible
20:23emersion: sorry, don't have more free time to discuss about this
20:23ity: What for example ? Afaik the problem with EGLStreams was that it was a small-in-scope API, rather than something inherent to not being Linux-dependent. I would for sure be interested in hearing the exact reasons why EGLStreams was bad outside of _it's not GBM/dmabuf_, though, I tried to search for any detailed description but could not find anything outside of _it's bad for
20:23ity: unspecified reasons_
20:23ity: Ah, that's alright, thanks for your time ^^
20:30kennylevinsen: ity: If you have a particular idea of uniting linux-dmabuf with <something else>, maybe try to draw up the practical details of the proposal to have something real to discuss
20:31kennylevinsen: however, I feel that your are somewhat missing that whatever it is, you need both 1. compositor support, 2. a protocol to exchange the implementation-specific details, 3. client support wherever buffer management is required
20:33kennylevinsen: e.g., in linux-dmabuf the compositor gives you information about format selection for different devices and use-cases, which your client and its gl/vulkan driver uses to allocate and later export images
21:05ity: kennylevinsen: I am aware I will need protocol support, client support, and server support. Right now I am simply querying whether a decision has been made to stick to dmabuf; whether a proposal would be welcome at all. Mostly wondering about Mesa here, if Mesa agrees the rest should follow somewhat easily.
21:17kennylevinsen: it's not a mesa decision, it's a community one, and there's no push-back on linux-dmabuf to my knowledge, nor do I see any reason for it - the burden of supporting something else is primarily in the server and client toolkits, and so linux-dmabuf - the protocol - ends up being quite a small part of the puzzle
21:20kennylevinsen: whether a generic encapsulation is viable will require details of the other systems you have in mind
21:20kennylevinsen: and such encapsulation also has the side-effect of tying the systems together to some extend, which might negate all benefit
21:29ity: So, it's likely that there will be push-back against a more generic protocol ? The reason why I am asking before having anything concrete yet is to evaluate whether, after solving the technical issues, I will also have to deal with immense pushback just because it's change. I understand the concerns of issues that might arise, but we don't know yet whether they will; That is why I am
21:29ity: asking whether it will be rejected on the basis of changing something and adding maintanence burden to replace that works for the majority of users in order to allow Wayland to run on non-Linux DRM systems (which are certainly a minority) alone, rather than any fundamental, solvable issues within the solution itself. I am ofc willing to write & send patches to major projects in order
21:29ity: to lessen the work required, but I need to know whether they will be even open to the idea in the first place.
21:31kennylevinsen: I simply cannot imagine that any discussion can start without anything concrete: i.e., a concrete platform needing support that does not fit the dmabuf/drm ideas and what thta support requires, and a concrete idea for how a "generic" solution would somehow substitute linux-dmabuf and support both those platforms in a way that would be better for adoption than a new protocol for the new system
21:38kennylevinsen: (without such concrete examples, what you need is too blurry, and whether e.g. a generic protocol makes any difference in solving the problem whatsoever cannot be said.)
22:10ity: Ah, I see, but given something concrete, a discussion can start, right ? Which is what I am asking about mostly, whether a proper technical discussion about it can be had if the ideas are mergable into a new protocol but not into dmabuf.