ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
abeltramo589 has joined #wayland
abeltramo58 has quit [Read error: Connection reset by peer]
abeltramo589 is now known as abeltramo58
abeltramo58 has quit [Ping timeout: 480 seconds]
abeltramo58 has joined #wayland
abeltramo58 has quit [Ping timeout: 480 seconds]
abeltramo58 has joined #wayland
Mal_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
Mal_ has quit [Ping timeout: 480 seconds]
gspbirel5687340 has quit []
gspbirel5687340 has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
the_sea_peoples has quit [Quit: WeeChat 2.8]
the_sea_peoples has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
chiang has joined #wayland
Mal__ has joined #wayland
chiang has quit [Quit: chiang]
Mal__ has quit [Ping timeout: 480 seconds]
Arnavion has quit []
Company has joined #wayland
Mal__ has joined #wayland
mxz has quit [Quit: cya]
mxz has joined #wayland
Arnavion has joined #wayland
Arnavion has quit []
Arnavion has joined #wayland
Arnavion has quit []
Arnavion has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
kts has quit [Ping timeout: 480 seconds]
iomari892 has quit [Read error: Connection reset by peer]
sima has joined #wayland
Mal__ has quit [Ping timeout: 480 seconds]
Mal__ has joined #wayland
tzimmermann has joined #wayland
Mal__ has quit [Read error: Connection reset by peer]
<Company>
do Wayland compositors care if clients use RGBA vs BGRA image formats?
<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
<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."
<Company>
I was wondering what to do if renderers also support abgr8888 for example
<Company>
which one do I pick?
<dottedmag>
Indeed compositors giving hints which formats would be preferred if there is a choice would be useful.
<Company>
it might be the case that they are meant to be ordered by compositor preference
<Company>
that's why I'm wondering
<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.
robobub_ has quit []
<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 :))
<kennylevinsen>
Company: for shm, reading the buffer is slow regardless. You should use dmabuf if performance and preference is a concern
<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.
<RAOF>
Unless you're doing a swrast Vulkan swapchain?
<Company>
but I looked at that yesterday, that just loops over the dmabuf formats
<Company>
RAOF: the reason I was thinking about it was direct scanout
<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)
<Company>
but I'd want to avoid the compositor having to convert the wrong format from my fullscreen app
<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
<MrCooper>
if the compositor advertises a "bad" format in the first tranche, that's a compositor issue
<Company>
well, I'm picking from vkGetPhysicalDeviceSurfaceFormatsKHR() atm
<Company>
guess I need to be smarter about that then
<MrCooper>
or to put it more generally: check each tranche in turn, and if it has any usable formats, pick one of them
<pq>
I guess the question is how does that translate to using the Vulkan API?
<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.
Company has quit [Read error: Connection reset by peer]
rv1sr has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
ahartmetz has joined #wayland
floof58 has joined #wayland
fmuellner has joined #wayland
<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, ...
kts has joined #wayland
pochu has quit [Quit: leaving]
nerdopolis has joined #wayland
<pq>
wasn't scroll speed supposed to be the same as pointer motion speed with libinput?
<pq>
I'm not comparing to any other OS, I'm just comparing one vs. two finger motion.
<pq>
the scroll is fast enough that I don't even move my fingers, I just tilt them to scroll.
<pq>
unless I want to jump a few screenfuls
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
___nick___ has joined #wayland
<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
<kennylevinsen>
For that to hold true and maintain pointer movement == scroll movement, I assume both would need zero acceleration
<kennylevinsen>
Which might be weird for the pointer alone
<emersion>
i believe "natural scroll" is purely about the direction, nothing more
<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
<pq>
anyway, the two-finger scroll is too fast to be confortable for me
<pq>
but I manage because I don't use that laptop much
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
Satan2 has quit [Ping timeout: 480 seconds]
Satan2 has joined #wayland
Ampera has quit [Quit: Don't look at my quit message, steve30 has a better one anyways.]