03:09whot: regarding repeat: the kernel does key repeat (with a value of 2), that's what you'll see when you look at the event node with e.g. libinput record. The repeat delay/rate is configurable via an ioctl, and all that is the key repeat you'd see on a vt
03:12whot: XKB has its own key repeat which the server is doing, decades ago we had some issues with the kernel repeat keys interfering with XKB repeat keys resulting in "pulsing" repeats where you'd get aa aaaaa a aaaaa depending how the rates interfered with each other. in 2008 the evdev driver stated filtering all kernel repeat events and thus forcing XKB repeat only (XKB was made mandatory
03:12whot: a few xserver releases before)
03:12whot: XKB also has a per-key repeat setting so you can set some keys to repeat and others not
03:13whot: libinput does the same as the evdev driver, it filters all kernel repeats, so you won't see any of those in libinput debug-events
03:14whot: which all makes sense on a local setup where any delay between HW and processing would be a bug :)
09:51wlb: weston Merge request !1463 opened by Marius Vlad (mvlad) Deprecate fullscreen shell and screen-share module https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1463 [Clients], [Fullscreen-shell], [Nested Wayland backend], [screen-share]
09:52wlb: weston Merge request !1463 opened by Marius Vlad (mvlad) Deprecate fullscreen shell and screen-share module https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1463 [Clients], [Fullscreen-shell], [Nested Wayland backend], [screen-share]
09:52wlb: weston Merge request !1463 opened by Marius Vlad (mvlad) Deprecate fullscreen shell and screen-share module https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1463 [Clients], [Fullscreen-shell], [Nested Wayland backend], [screen-share]
09:53wlb: weston Merge request !1463 opened by Marius Vlad (mvlad) Deprecate fullscreen shell and screen-share module https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1463 [Clients], [Fullscreen-shell], [Nested Wayland backend], [screen-share]
10:22wlb: weston Merge request !1463 opened by Marius Vlad (mvlad) Deprecate fullscreen shell and screen-share module https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1463 [Clients], [Fullscreen-shell], [Nested Wayland backend], [screen-share]
10:30daniels: I think mvlad may have opened an MR, but I'm not sure
10:30mvlad: yeah ^^ see bot message
10:31mvlad: CI pipeline is building now
10:31mvlad: oh there's been some gitlab update
10:32mvlad: seems everything is there
10:38daniels: mvlad: that was a joke :)
10:38mvlad: ah, geez, okay :p
11:19pq: mvlad, FYI, there was 5 annoucements from wlb that you opened that one MR, 4 of them before you joined.
11:19mvlad: ha, I see.
11:19pq: likely due to gitlab upgrades, I guess
11:26emersion: mvlad is using the same marketing techniques as rich russian bankers claiming they want to wire me some inheritance
11:27pq: wlb is
11:43emersion: MrCooper: hm so i'm confused, i'm reading the discussions from this again: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_2194398
11:44emersion: point (3) is the exact contrary of an earlier discussion we had
11:45emersion: i originally had an error for set_*_point called twice between commits, and you and swick[m] argued that it shouldn't be a protocol error for consistency with the rest of the protocols
11:45emersion: s/called/sent/
11:45MrCooper: point 3 isn't about that
11:45wlb: weston/main: Leandro Ribeiro * color-noop: avoid assert hit in cmnoop_destroy() https://gitlab.freedesktop.org/wayland/weston/commit/6da5b8a5a52e libweston/color-noop.c shared/weston-assert.h
11:46wlb: weston Merge request !1462 merged \o/ (Avoid assert hit in cmnoop_destroy() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1462)
11:46emersion: ah, ok, then i misunderstand
11:46emersion: "The request to set the acquire & release points wasn't used since the last commit."
11:46emersion: what does that mean then?
11:47MrCooper: it's about the client attaching a buffer to an explicit-sync surface, but not setting acquire & release points in the same commit
11:47emersion: oh
11:47emersion: the sentence before the list is key here
11:47MrCooper: yep :)
11:48daniels: yeah, my reading was indeed that you were required to call for every commit where you also had a new attach
11:51emersion: daniels, what do you mean exactly here? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90#note_2280862
11:51emersion: gitlab is sooo sloooow :(
11:52emersion: daniels, do you mean that pending state may not be discarded by the compositor?
11:52pq: I've been thinking of trying bichon again...
11:52daniels: emersion: yeah, that the compositor may take the acquire point into account and may set the release point
11:52daniels: or it may not
11:52emersion: hm, that'd be surprising i think
11:53daniels: just seems like it makes it easier for implementations rather than a guarantee that it _will_ be discarded
11:53emersion: it would be like implicitly committing pending state
11:53daniels: would it?
11:53daniels: oh, iswym
11:53daniels: hmm
11:53emersion: the compositor should completely ignore the pending state as long as there's no commit
11:53daniels: yeah, I guess I'm thinking it would just be easier than reaching into pending state you've already stored away and undoing it
11:54emersion: i guess i'm not really seeing how this could help in the implementation
11:54daniels: right, but I mean, in the case where you have surface.attach(); sync.set_acquire_point(); sync.destroy(); commit(); then you'd have to go into your surface pending state and remove the acquire point
11:54daniels: whereas with a 'may' you could either leave the acquire point in the pending state or clear it out, as you pleased
11:54emersion: daniels, same if you set_acquire_point() twice
11:55daniels: true true
11:55emersion: you need to "unset" the previous point either way
11:55emersion: ah, i see…
11:55daniels: I don't feel strongly about it, just seemed like an easy win which could help implementations and probably no issue for clients as it's a pretty nonsensical thing to do anyway
11:55emersion: it comes from the fact you have a monolithic surface state struct i suppose
11:55emersion: with All Of The State
11:55daniels: right, rather than something composed by addons
11:56daniels: which might change, let's see
11:56daniels: amazingly, this is one of the things which is not complicated by subsurfaces :P
11:57emersion: yeah, no judgment here, the addon stuff adds some substantial complexity
11:59daniels: tbf I have a branch where I steal wlr_addon, just keep forgetting to push it
12:16emersion:has finally reached the "whatever you say i don't really care anymore" mindset on this MR :P
12:21daniels: haha
12:40wlb: weston Issue #879 opened by Pekka Paalanen (pq) Follow-up from "Speed up tests runtime": reduce HIGHEST_OUTPUT_REFRESH usage https://gitlab.freedesktop.org/wayland/weston/-/issues/879 [Testing]
14:00wlb: weston Merge request !1464 opened by Leandro Ribeiro (leandrohrb) Draft: Add API to create color profile from parameters https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1464 [Colour management], [libweston API]
14:29Eighth_Doctor: daniels: hey it was great to meet you at fosdem :)
14:29Eighth_Doctor: sadly didn't get the opportunity to talk about all the things
14:31wlb: weston/main: Pekka Paalanen * 5 commits https://gitlab.freedesktop.org/wayland/weston/compare/6da5b8a5a52efc8434fb83e1f43eb6da9c97dcc7...31a9a4831fcb4558e0321303d7cf188619ad2646
14:31wlb: weston Issue #682 closed \o/ (Cut Your Test Runtime In Half With This One Weird Trick https://gitlab.freedesktop.org/wayland/weston/-/issues/682)
14:31wlb: weston Merge request !1405 merged \o/ (Speed up tests runtime https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1405)
14:33daniels: Eighth_Doctor: you too :)
14:34Eighth_Doctor:is poking all his known consumers of fullscreen shell to switch to kiosk shell
14:34Eighth_Doctor: I'm also now co-maintainer of Weston in Fedora :P
14:35Eighth_Doctor: hmm maybe I should file a bug about weston not being compatible with freerdp3
14:41daniels: orly?
14:42daniels: I swear they only smashed their API to bits like last week
14:44Eighth_Doctor: I'm trying to get rid of freerdp2 in Fedora before Fedora 40 GA
14:44Eighth_Doctor: I have a terrible feeling I won't be able to, but I can at least try
14:47daniels: frdp3 isn't packaged in Debian/Ubuntu, so we'd either have to fork the backend or shed support for those distros ...
14:48Eighth_Doctor: oof
14:49daniels: not in Yocto either
14:49Eighth_Doctor: ....
14:49Eighth_Doctor: am I the first?!
14:50Eighth_Doctor: Yocto doesn't count though
14:50Eighth_Doctor: since that would be uplifted/added with a new Weston release anyway
14:51daniels: 3.0.0 says 'The API should now be considered stable and only minor changes (if at all) will happen from this point on, so every project using FreeRDP can check compatibility with upcoming 3.0'; 3.3.0 released just now breaks the API. sweet.
14:51Eighth_Doctor: wait, seriously?!
14:51daniels: y
14:51daniels: well, they say 'some [...] inconvenient API functions were fixed on the way', which I'm going to assume is an API break
14:52Eighth_Doctor:facepalms
14:52daniels: as for Yocto, there are a lot of downstreams who don't necessarily follow the very latest Yocto but do update versions of other things - and there's no Yocto packaging at all for 3.x, soooo
14:56Eighth_Doctor: it looks like the API changes in 3.3.0 are related to winpr for supporting images in clipboards
14:56Eighth_Doctor: at least I don't see anything else significant
14:58daniels: seems like they're all fairly benign and probably backwards-compatible with 3.0 use
14:59Eighth_Doctor: yeah
14:59Eighth_Doctor: which makes me feel better about updating to 3.3.0 in fedora 40+ just now 😅
15:00Eighth_Doctor: alright, so now the upcoming version of sddm will no longer depend on fullscreen shell! https://github.com/sddm/sddm/commit/dfc3bdb6510a12a6435e8cdb0bf151aa83aa51d5
15:06daniels: woot!
15:49amosbird: whot: Hello! I have been using Thinkpad X1E Gen 3 with Archlinux + X + libinput for more than two years. Everything works just fine except that 3-finger gesture intermittenlty fails. Usually it stops working right after carrying on some 4-finger gesture. The only way to make 3-finger gesture work again is to trigger another 4-finger gesture.
15:50amosbird: Someday I updated my kernel with https://github.com/torvalds/linux/commit/7984b43542070f5888546d95b48003c4a8af7c0f. After this update, the name of my touchpad becomes "Synaptics TM3625-010" instead of "SynPS/2 Synaptics TouchPad". Since then the touchpad became quite laggy during movement. Surprisingly, all multi-finger gestures work perfectly!
15:50amosbird: I'm aware that setting psmouse.synaptics_intertouch=0 in kernel cmdline will make it back to SynPS/2, but the 3-finger gesture issue will regress. Is there a way to have either "TM3625-010" get smooth movement or "SynPS/2" with healthy 3-finger gesture?
17:28wlb: wayland-protocols Issue #179 opened by Xaver Hugl (Zamundaaa) Output selection for games https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/179
17:42wlb: weston Merge request !1465 opened by Leandro Ribeiro (leandrohrb) Create/destroy color profile id generator in a safe point https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1465
19:48bwidawsk: AFAICT, xdg_toplevel::configure should (for the current version anyway) specify negative values for width and height are disallowed - or is there something I'm missing?
20:15bwidawsk: I'm also confused about xdg configure/ack. ack_configure wants a serial, but it seems like there is a sequence of events which would result in toplevel.configure being sent without a surface.configure, and then what serial would you use
20:19emersion: no, a xdg_toplevel configure is always followed by xdg_surface.configure
20:19emersion: clients should buffer what they receive in xdg_toplevel.configure
20:19emersion: and apply to on xdg_surface.configure
20:19emersion: it*
20:19emersion: apply as in act on
21:16bwidawsk: emersion: so basically until get_popup or get_toplevel, hang on to the last surface configure, yes?
21:17emersion: I don't understand
21:18bwidawsk: If a client does get_xdg_surface; commit, a configure event should be sent
21:19bwidawsk: then the client does get_toplevel, a toplevel configure event would be sent
21:19bwidawsk: agree so far?
21:24bwidawsk: emersion: ^^
21:28bwidawsk: or would it go, get_toplevel(); commit(); // get both configure events?
21:34vyivel: bwidawsk: get_{toplevel,popup} is sent at most once for a given xdg_surface
21:34vyivel: before that, xdg_surface has no associated xdg surface role object
21:34bwidawsk: vyivel: yeah, it's the configure event I'm interested in here
21:34vyivel: iirc you're not even allowed to commit in this state
21:34vyivel: yeah so
21:35bwidawsk: which, with no role?
21:35vyivel: xdg_surface.configure marks the end of a configure sequence
21:35vyivel: which can consist of multiple events
21:35vyivel: e.g. xdg_toplevel.configure, zxdg_toplevel_decoration_v1.configure, xdg_surface.configure
21:35vyivel: the client must treated the above sequence as an atomic configuration request
21:36vyivel: what are you trying to do btw?
21:37bwidawsk: vyivel: test suite
21:37vyivel: aha
21:38bwidawsk: vyivel: so indeed, surface.configure marks the end of a configure and that does answer the question, it *does* seem you can end up with multiple configure sequences though for toplevel/popup and surfaces that build on top of these
21:38bwidawsk: however, they all end with surface.configure
21:38bwidawsk: thanks
21:39bwidawsk: I think this should be reworded though if the intention is the sequence is all configure events
21:39bwidawsk: `The configure event marks the end of a configure sequence. A configure sequence is a set of one or more events configuring the state of the xdg_surface, including the final xdg_surface.configure event.`
21:39vyivel: wdym?
21:39vyivel: seems pretty clear to me
21:39bwidawsk: the events configure the state of something higher level perhaps than an xdg_surface
21:39bwidawsk: ie. toplevel in an simple example
21:40bwidawsk: or if you look at some other external protocols
21:40vyivel: "the state of the xdg_surface and associated objects" maybe then, idk
21:40vyivel: xdg_surface by itself isn't very useful so some other, actually useful, object is implied there