06:12 Company: do Wayland compositors care if clients use RGBA vs BGRA image formats?
06:13 Company: I'm currently reviewing the code that picks the format to create a Vulkan swapchain with and I'm wondering how to decide which one to pick
06:16 orowith2os: Company "All renderers should support argb8888 and xrgb8888 but any other formats are optional and may not be supported by the particular renderer in use."
06:16 orowith2os: nabbed from https://wayland.app/protocols/wayland#wl_shm:enum:format
06:17 orowith2os: probably what you're looking for?
06:18 Company: I was wondering what to do if renderers also support abgr8888 for example
06:18 Company: which one do I pick?
06:27 dottedmag: Indeed compositors giving hints which formats would be preferred if there is a choice would be useful.
06:29 Company: it might be the case that they are meant to be ordered by compositor preference
06:29 Company: that's why I'm wondering
06:34 rahl: Sadly, according to whot, my issue is with the kernel. I still don't fully understand that, given that the touchpad is known to work in certain situations.
06:42 rahl: Ok, so even though void is rolling release, it's nott bleeding edge, so the main kernel version is a bit behind. I will be checking something more up to date - and see if that fixes things (while maybe giving me other issues :))
06:47 kennylevinsen: Company: for shm, reading the buffer is slow regardless. You should use dmabuf if performance and preference is a concern
06:48 RAOF: By and large I don't think it matters? Also, since you're doing Vulkan it'll be a driver preference rather than a compositor preference? That tends to be below the level that compositors care. We just care that we can sample from it, and the driver promises that we can.
06:49 RAOF: Unless you're doing a swrast Vulkan swapchain?
06:57 emersion: linux-dmabuf has preference tranches
07:49 Company: kennylevinsen: this was about Vulkan - https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkGetPhysicalDeviceSurfaceFormatsKHR.html to be exact
07:50 Company: but I looked at that yesterday, that just loops over the dmabuf formats
07:57 Company: RAOF: the reason I was thinking about it was direct scanout
07:58 Company: if the compositor composites from it, it may support more formats than the scanout engine (I wouldn't klnow though, I'm an app dev not a driver dev)
07:59 RAOF: Company: Ah, yes. In that case you want to be looking for [dmabuf-feedback](https://wayland.app/protocols/linux-dmabuf-unstable-v1#zwp_linux_dmabuf_feedback_v1)
07:59 Company: but I'd want to avoid the compositor having to convert the wrong format from my fullscreen app
08:00 MrCooper: Company: zwp_linux_dmabuf_v1 v4 also has scanout tranches, but really the client should just pick a format from the first tranche, which is the highest priority one
08:00 MrCooper: if the compositor advertises a "bad" format in the first tranche, that's a compositor issue
08:00 Company: well, I'm picking from vkGetPhysicalDeviceSurfaceFormatsKHR() atm
08:01 Company: guess I need to be smarter about that then
08:08 MrCooper: or to put it more generally: check each tranche in turn, and if it has any usable formats, pick one of them
09:50 pq: I guess the question is how does that translate to using the Vulkan API?
09:52 pq: whoever complained that touchpad scrolling is too fast; Yes, it is. On Fedora 38 GNOME, scrolling is significant faster with two-finger gesture than pointer motion with one finger. I just never thought about it.
11:45 kennylevinsen: pq: would be interesting to compare to macos and windows - maybe scroll is fast, maybe cursor is slow, maybe acceleration of the two is different when it should not be, ...
12:38 pq: wasn't scroll speed supposed to be the same as pointer motion speed with libinput?
12:39 pq: I'm not comparing to any other OS, I'm just comparing one vs. two finger motion.
12:40 pq: the scroll is fast enough that I don't even move my fingers, I just tilt them to scroll.
12:41 pq: unless I want to jump a few screenfuls
13:01 kennylevinsen: I do not now if that was the intention. "Natural scroll" might imply a perceived direct linkage between input and response that disallows any acceleration - otherwise the page "slips", breaking the illusion
13:02 kennylevinsen: For that to hold true and maintain pointer movement == scroll movement, I assume both would need zero acceleration
13:02 kennylevinsen: Which might be weird for the pointer alone
13:03 emersion: i believe "natural scroll" is purely about the direction, nothing more
13:04 kennylevinsen: in libinput, sure, but the concept also comes with inertial scroll and other things that are meant to make it feel like the content is physically under your fingers and reacting as such
13:06 pq: anyway, the two-finger scroll is too fast to be confortable for me
13:06 pq: but I manage because I don't use that laptop much