03:39 <tokyo4j> whot: why does libinput "accumulate" hi-res mouse scrolls? M705 mouse reports 15,15,15,15,15,30,15 (120 in total) scroll events at evdev layer, but libinput reports them as 60,15,30 (105 in total). So we have difficulty in reliably executing a mouse binding for exact one scroll click.

04:22 <whot> tokyo4j: user complaints about flaky scroll wheels, so that heuristic was a way to work around that. This was fixed in https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1261 and https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1258, merged a few h ago

04:24 <whot> tokyo4j: current code still has some accumulation but it's now two clicks, i.e. in your case it's 30 (not 60) to start and for mice with low res multipliers there is no accumulation (because it's unlikely to have inadvertant scrolls anyway)

04:33 <whot> tokyo4j: still trying to figure out if *any* devices are actually affected by flaky scroll wheels or just the MX Master 3 series (or at least some of those...) but once the wheel is hi-res enough it's hard to be sure what is flakyness and what is just finger movement

06:25 <tokyo4j> whot: OK, thanks for your explanation. I installed libinput-git from AUR and now the reported scroll events are 15,15,15,15,15,30 (105 in total). I personally expect the scroll events from evdev (including the last 15-degree scroll) to be just passed through to the compositor immediately, at least with M705 mouse, but I'm not following the context of debouncing issue and don't know what's the best solution.

08:12 <whot> tokyo4j: it's one of the many cases where there is no single correct answer because it depends on the mouse, the user and the interactions themselves. but it's basically the same as the de-jittering of the touchpad movement that we already have, the key is finding out what the magic line is where the least number of users is unhappy

08:42 <wlb> weston Issue #1035 opened by Lukas Wuergler (lukix42) Can't install `weston` because missing dependencies (Rocky 10) https://gitlab.freedesktop.org/wayland/weston/-/issues/1035

09:04 <wlb> weston Issue #1035 closed \o/ (Can't install `weston` because missing dependencies (Rocky 10) https://gitlab.freedesktop.org/wayland/weston/-/issues/1035)

09:33 <riteo> Hi people. I'm looking at the docs and it says "For efficiency purposes, the IDs are densely packed in the sense that the ID N will not be used until N-1 has been used.". I mostly understand this but one thing is not clear: do the newly "reused" IDs have to be sequential, that is, do I need to necessarily pick e.g. from a freelist the lowest ID possible or is any free ID fair game?

09:36 <riteo> rn I have an implementation that picks whatever free ID it can find, without ordeering them, and libwayland doesn't seem to complain but I wonder if that's actually spec compliant

09:43 <kennylevinsen> riteo: "ID N will not be used until N-1 has been used" - if you pick, say, object ID 5 while object ID 4 is available, then you have violated that rule

09:43 <riteo> aight

09:43 <riteo> so I need a sorted free list

09:44 <riteo> I initially scanned the buffer as a PoC but that's obviously pretty bad

09:45 <riteo> ty for the clarification!

09:45 <kennylevinsen> you could do some tricks like storing the first known gap index and only scan if that fails or something

09:49 <riteo> mhhh

09:50 <riteo> I guess that a sorted freelist would be more elegant though, wouldn't it?

09:50 <riteo> I'm really not that experienced when it comes to data structures

09:52 <kennylevinsen> a freelist with ranges would be fine, so you start with just 1 entry covering all IDs, and only add new entries to deal with gaps

09:53 <riteo> aight

09:53 <riteo> I'll see what I can do

09:58 <kennylevinsen> if one had to be pedantic, a freelist could be provoked to create N/2 entries by an evil client allocating all IDs and destroying every second one, but oh well

09:59 <riteo> i mean isn't this like, inevitable by design

09:59 <riteo> that's technically correct, if you do this checkerboard thing you get a big object buffer

10:00 <riteo> oh you mean like, the free list also consumes a lot of memory

10:01 <kennylevinsen> "a lot" being somewhat limited by you only needing to store roughly two uint16's

10:29 <ifreund> riteo: fwiw, libwayland stores its freelist without using extra space with some pointer bit hacking

10:30 <ifreund> see the map_entry union and is_free()/get_data() functions

10:31 <ifreund> the free list is essentially a linked list of slots where each free slot stores the index of the next free slot

10:31 <ifreund> in the same memory used to store the data pointers for slots that are not free

10:34 <riteo> oh that's interesting

10:35 <riteo> I'm currently very tired so I'm having some trouble figuring it all out (and I'm also a super newb in data structures) so I'll try to whip up something in the future

10:35 <riteo> I'm pretty sure that it's going to be hard to do worse than straight up scanning the buffer lol

12:13 <wlb> wayland-protocols Merge request !425 opened by Anselm Schüler (schuelermine) Remove disclaimer about testing phase from staging/fifo/fifo-v1.xml https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/425

12:41 <wlb> wayland-protocols Merge request !425 closed (Remove disclaimer about testing phase from staging/fifo/fifo-v1.xml)

14:51 <wlb> wayland-protocols Merge request !426 opened by DorotaC (dcz) Typos and clarifications for experimental input method https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/426

15:15 <dcz> I'd be thankful for anyone who wants to spare a look at the above MR

15:25 <wlb> wayland-protocols Merge request !427 opened by DorotaC (dcz) Draft: input method: simpler keyboard handling https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/427

15:35 <dcz> I'm not going to ask for reviews of the above, but I'd like for someone to raise awareness about the experimental process

15:35 <dcz> namely, it's not clear what I should do to get my update merged in... https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/407#note_2994643

19:16 <pq> kennylevinsen, I don't think libwayland itself works like that. I guess "has been used" means has *ever* been used. It's only to stop clients from causing a massive allocation the compositor by choosing a huge new ID.

19:17 <pq> kennylevinsen, IIRC, libwayland's wl_map only uses a simple unordered free list.

19:17 <pq> riteo, ^

19:18 <riteo> yea it's somewhat ambiguous

19:18 <riteo> (btw watch out I'm chaning my nick)

19:18 <riteo> libwayland definitely doesn't complain

19:19 <riteo> but since I'm working on the embedding compositor thing I'd really rather not get some very careful compositor to complain and redo the whole allocation approach

19:19 <riteo> although tbf if libwayland uses an unordered free list... I guess I'm safe?

19:19 <riteo> that'd definitely let me avoid a huge headache

19:20 <kennylevinsen> pq: Yeah there's some issues in the phrasing - I don't think "has *ever* been used" is a meaningful restriction, or even true to the description of dense packing

19:21 <kennylevinsen> I mean, requiring an ID to never be larger than the historically largest + 1 is a thing, but that's not dense packing

19:21 <pq> kennylevinsen, it's not really dense packing. It only cares that the array is enlarged only if it is all in use.

19:21 <kennylevinsen> ("For efficiency purposes, the IDs are densely packed in the sense that the ID N will not be used until N-1 has been used. This ordering is not merely a guideline, but a strict requirement")

19:22 <dery> (just changed my nick as I said)

19:22 <kennylevinsen> Hmm if we only want to mean that a new object ID must not be more than 1 larger than the previous largest ID, then we should rephrase that :/

19:23 <dery> that would make things a lot simpler and more efficient imo

19:23 <pq> yeah, you can confirm it in the wl_map code

19:23 <dery> rn the Godot PooledList actually uses two arrays, like, whole contiguous blocks things

19:23 <dery> and otherwise I'd have to switch to a linked list and sort stuff

19:23 <kennylevinsen> I was looking around for our checks and was failing to find anything other than the wl_map_insert_at check

19:24 <pq> kennylevinsen, that sounds like it.

19:24 <pq> so, I was wrong too

19:24 <pq> I guess?

19:26 <kennylevinsen> wl_map_insert_at fails only if the length of the array is shorter than the index, so indeed it enforces only allowing a single call to wl_array_add (historical maximum length + 1)

19:26 <pq> no need for the array to be full to enlarge, as long as the need is just +1

19:30 <wlb> weston Issue #1036 opened by Devanshi Bansal (devanshi_bansal) Color Distortion in NV12 Buffers Due to Shader Mismatch https://gitlab.freedesktop.org/wayland/weston/-/issues/1036

19:33 <dery> soo I guess I'm fine as is?

19:34 <kennylevinsen> to satisfy the libwayland definition, as long as any object you create is not more than +1 of any previous object, yeah

19:34 <kennylevinsen> we should reword the docs to clarify this

19:34 <dery> so lets say the buffer is 10 big, and there are holes from 2-8. If i were to create, say an object with id 8 I would still be fine right?

19:35 <dery> because the pooledlist implementation in godot uses basically reverse free order for regaining slots

19:35 <kennylevinsen> if the buffer is 10 big, any number <= 11 is safe by the libwayland definition

19:35 <dery> Aight

19:35 <dery> so I'm safe, technically

19:35 <dery> and I suppose that this was the original meaning of the definition in the documentation?

19:36 <dery> I really hope nothing enforces the stricter interpretation

19:41 <kennylevinsen> that's why we should fix the documentation :/

19:44 <dery> aight aight

19:44 <dery> just making sure