02:25 jess: hi
02:26 psykose: hi
03:17 vaxry: hi
04:00 YaLTeR[m]: hi
04:13 lockywolf: YaLTeR[m]: hello
07:00 klaasvakie: Hi, I'm dealing with an issue with a USB barcode scanner that presents as a USB keyboard. When I scan a specific barcode I get the correct symbols with "evtest /dev/input/eventX", when I am in xorg, I get those correctly mapped and in the correct order when checking with "xev", but in wayland the keycodes sometimes arrive out of order when checking with "libinput debug-event --show-keycodes"
07:02 klaasvakie: Specifically, I am seeing SHIFT-L releases arriving early. I can reliably reproduce this. This is also architecture independent (manifests on ARM and x86_64). All machines running stock Gnome on ubuntu 22.04
07:03 klaasvakie: Is the information above enough to submit a bug report to https://gitlab.freedesktop.org/libinput/libinput/issues/new or is there something else I should check first?
07:04 klaasvakie: I can also include dumps from "evtest", "xev", and "libinput debug-event"
07:11 kennylevinsen: klaasvakie: libinput debug-events is reading directly from evdev, not through wayland
07:13 klaasvakie: weird, because "evtest" and "libinput debug-events" give me a different scancode order
07:13 kennylevinsen: wev is available as a wayland-native xev equivalent, although xev also works when Xwayland is present
07:13 klaasvakie: found a issue on the libinput gitlab here: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5890#note_1674831
07:14 klaasvakie: "wev" produces no output for me
07:14 kennylevinsen: You must focus its window
07:15 klaasvakie: pkill ibus fixes the problem for me
07:18 kennylevinsen: Peculiar. I am unfamiliar with ibus. Regardless, libinput doesn't speak to Wayland. It's the library that Wayland compositors themselves use to manage evdev inputs, and its debug tools open evdev directly.
07:20 klaasvakie: looks like a fix was merged for gnome 45
07:20 klaasvakie: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044
07:23 kennylevinsen: That MR changes how Mutter reacts to events from libinput, it won't change anything if libinput or the evdev device was mistaken. Likewise, if this was the issue, the libinput debug tool wouldn't have shown it...
07:24 klaasvakie: yeah sorry - I'm not familiar with the internals of exactly how all the components fit together - first time going down this rabbithole
07:44 kennylevinsen: klaasvakie: try running evtest and libinout debug-events simultaneously
07:56 klaasvakie: logs from a simultaneous capture here:
07:56 klaasvakie: https://pastebin.com/BhMBBwKZ
07:57 klaasvakie: you can see the KEY_LEFTSHIFT (42) released arriving out of order on line 57 in the libinput trace
08:01 kennylevinsen: Looks the same to me between libinput and evtest - shift press, g press, shift release, g release. Although I'm on a phone screen right now.
08:01 kennylevinsen: Line 196 is the same evtest event
08:02 klaasvakie: yeah - I agree with you
08:02 klaasvakie: The trace from both is also the same after a "pkill ibus"
08:03 klaasvakie: so I think the issue is happening elsewhere
08:19 kennylevinsen: klaasvakie: which Wayland server?
08:20 davidre: I find it curious that evdev would send differnt events when using Xorg?
08:21 MrCooper: presumably that was a misunderstanding, the issue seems between ibus and the compositor?
08:31 klaasvakie: MrCooper is correct - it was a misunderstanding, sorry for the noise
08:32 klaasvakie: the traces from libinput dump-events and evtest are identical between xorg and wayland, and with/without ibus killed
08:34 klaasvakie: I'm not sure how I came to the previous conclusion, I could've sworn I saw different stuff earlier, but alas.
08:35 davidre: No worries
08:51 pq: bwidawsk, an arbitrary time out of my hat, that I think should be long enough even on a heavily loaded CI machine without stalling CI failure too much.
09:17 wlb: weston/main: Jordan Williams * meson: Add missing dependencies on egl https://gitlab.freedesktop.org/wayland/weston/commit/2e6c58fb37ea libweston/backend-headless/meson.build libweston/backend-pipewire/meson.build libweston/backend-wayland/meson.build libweston/meson.build meson.build shared/meson.build
09:17 wlb: weston Merge request !1479 merged \o/ (meson: Add missing dependencies on egl https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1479)
10:41 wlb: wayland-protocols Merge request !289 opened by Sebastian Wick (swick) cursor-shape-v1: Does not advertises the list of supported cursors https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/289
11:01 zzag_: jadahl: is there anything that we could to bump https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6212#note_2055560 ? GTK applications are not exclusive to GNOME Shell, they run on other desktop environments too. GTK not willing to commit to wayland protocols that are important to desktop environments other than GNOME Shell is deeply disappointing...
11:01 zzag_: another example is xdg-decoration-v1
11:03 emersion: oh :(
11:03 emersion: "Get it into mutter, then we'll look at it"
11:03 emersion: pretty disappointing indeed
11:03 jadahl: I don't know why mclasen has that opinion, I disagree
11:03 emersion: mclasen often has… opnionated opnions let's say…
11:03 jadahl: no idea the state of xdg-decoration though, I think I've reviewed a couple of iterations of some MR or two
11:03 davidre: > I will say that I don't think this protocol fits very well into Wayland, and I would be happier if mutter did not accept it.
11:03 davidre: ....
11:04 jadahl: opinienated opinion :P
11:04 kennylevinsen: the best kind of opinion
11:05 jadahl: fwiw, I wouldn't block any mutter implementation, but not very high prio for me personally to implement
11:09 d_ed[m]: <jadahl> "I don't know why mclasen has..." <- Can you override him on this MR?
11:11 kennylevinsen: well, maybe not *override*, just share a second opinion perhaps
11:12 d_ed[m]: I mean override. This is beyond rude. I have a lot of Gnome specific patches in Qt that I do to be a good citizen. This is beyond rude.
11:12 d_ed[m]: * I mean override. This is beyond rude. I have a lot of Gnome specific patches in Qt that I do to be a good citizen.
11:14 kennylevinsen: yeah, but convincing them of the benefits of a friendlier standpoint might be preferable for future cooperation, if possible.
11:17 kennylevinsen: otherwise, the next such MR will end up equally difficult, if not harder. It's not sustainable to have to take their family hostage every time, too cumbersome. :)
11:17 jadahl: going around "overriding" people is a rather antisocial behavior, not going to do that
11:19 kennylevinsen: d_ed[m]: minor nit: editing a message to remove duplicate sentances has the ironic side-effect of sending the whole message again on IRC. :D
11:19 d_ed[m]: jadahl: Sorry, I don't mean to take it out on you
11:21 kennylevinsen: your personal opinion whatever that may be would of course still be appreciated as input on the MR
11:22 zzag_: absolutely! ^
11:27 Consolatis: I would have thought that cursor shape would actually be great for gnome as it provides the option for a unified cursor theme controlled by the compositor for all applications that support the protocol
11:28 Consolatis: rather than hoping that applications use whatever is configured within the gnome environment / gtk theme
13:30 Company: random question of the day: do subsurfaces work for cursor surfaces?
13:30 pq: nothing says they don't, but they probably don't, except in Weston
13:31 Company: I was wondering how many things would fall apart and keep working if GTK aded a widget cursor
13:31 emersion: should work in wlroots, but yeah, i wouldn't rely on it
13:32 pq: what's a widget cursor?
13:32 Company: setting any GtkWidget as the cursor
13:32 emersion: cursor with an arbitrary widget tree in it i suppose?
13:32 Company: yeah
13:33 Company: which would mean you could put offloaded videos into it
13:33 emersion: you're going to have fun with X11 aha
13:33 Company: dnd icons work with X11
13:33 Company: and those are widgets
13:33 pq: nothing in Wayland stops you from doing so
13:33 emersion: but cursors in X11 are a completely separate thing?
13:34 Company: but I think that's just manually repositioning an XWindow to the pointer location?
13:34 emersion: like… you basically need to get a pixel array, and then send that to the X11 server
13:34 Company: sure, but we can just hide the cursor and put an override-redirect XWindow there
13:34 emersion: and the window follows the cursor manually?
13:34 Company: no, we'd have to make it do that
13:35 emersion: interesting, although it will lag behind
13:35 Company: that's expected with X11
13:36 Company: though our cursors have the ability to claim they're unsupported and then they use the fallback
13:36 Company: so the more realistic solution is that nobody implements it and waits for patches
13:37 Company: I think once the small desktops have switched to Wayland, GTK4's X11 backend is pretty dead
13:38 YaLTeR[m]: who is pushing gtk 4 x11 nowadays even?
13:38 Company: nvidia users
13:38 YaLTeR[m]: understandable
13:40 YaLTeR[m]: fwiw I'm gonna guess cursor with subsurfaces will work on Smithay too, modulo maybe the usual "nobody ran this code path before" fixes
13:40 Company: there's also the LTS distros, but I don't think they use GTK4 much
13:40 Company: so I expect GTK3 X11 to receive more attention than GTK4 X11
13:42 YaLTeR[m]: One problem with the cursor is it goes into the cursor plane and that one's a dumb buffer, so you need to download from GPU to CPU
13:42 Company: current GTK only allows textures anyway
13:42 jadahl: Company: LTS distros use apps from e.g. flathub, so yes they might get new gtk4s
13:43 Company: jadahl: that's gonna explode sooner or later though - both because nobody maintains the X11 codepaths and because flatpak doesn't want to keep the X11 codepaths open
13:44 emersion: i use a GPU buffer for the cursor plane in wlroots
13:45 Company: I don't think widget cursors are that interesting
13:45 Company: unlike for dnd cursors - because being able to drag a widget is a neat feature
13:46 Company: it's rare that apps want to do fancy things with regular cursors
13:46 Company: exception as always: VMs
13:47 jadahl: Company: I mean Wayland
13:47 pq: YaLTeR[m], do you mean Smithay does per-plane partial compositions with GPU?
13:49 YaLTeR[m]: pq: I meant that if a cursor is a video then there might be performance issues involved
13:50 pq: and sub-surfaces?
13:50 YaLTeR[m]: Pretty sure smithay doesn't do per-plane partial compositions, it just picks the topmost cursor surface for the cursor plane probably
13:51 YaLTeR[m]: So if that happens to be a video subsurface then that's going into the dumb buffer
13:51 Company: YaLTeR[m]: how does that work with dnd?
13:51 Company: like, dnd has 2 surfaces already - the pointer from the compositor and the drag icon from the app
13:51 pq: sub-surface cannot be a cursor surface by definition, those are conflicting roles. Unless you mean something else?
13:52 YaLTeR[m]: Company: the API is that the compositor marks elements in the render tree as "cursor" or "something else" and if there's an element marked as cursor at the top then smithay will try offloading it into the cursor plane
13:52 YaLTeR[m]: Element means one wayland buffer
13:52 Company: so during dnd only half of the cursor ends up in the cursor plane?
13:53 pq: Company, what's "cursor"?
13:53 Company: pq: the thing that moves when you move the mouse
13:54 YaLTeR[m]: Company: if the compositor marks dnd as cursor, and if the cursor is next to a different monitor in such a way that only the dnd surface shows on that monitor but not the cursor, then that dnd buffer will be on that monitor's cursor plane
13:54 YaLTeR[m]: otherwise only the cursor yes
13:54 pq: so if I drag a window, the window is part of the cursor?
13:54 Company: YaLTeR[m]: that sounds like a wild corner case to go wrong :D
13:55 YaLTeR[m]: Company: i test all the corner cases :p
13:55 YaLTeR[m]: although here you might call it an edge case
13:56 Company: pq: that's an interesting question - though I think the dragged window doesn't follow the cursor exactly, so people don't associate it
13:56 pq: there's a wl_surface with the cursor role, and I guess there is also a wl_surface with the DnD icon role?
13:56 Company: pq: and it requires an active button press
13:57 Company: but I don't think many people realize that the dnd icon is 2 different surfaces
13:57 pq: Company, in Weston the window will move in lock-step with the cursor, because Weston does not implement a special fast-path for cursor surface motion only. So it depends.
13:57 Company: I think we had bugs to let people get of the stupid arrow when dragging things
13:58 YaLTeR[m]: in my compositor dnd never goes into the cursor plane because my app puts videos into dnd and i don't want the slow
13:58 Company: hahahaha
13:58 Company: tuned for the apps that matter!
14:00 pq: The same in Weston, only one wl_surface can go to the KMS cursor plane. Weston does not do partial composition yet, so that's all it can do.
14:01 YaLTeR[m]: yeah, no partial composition in smithay either i think, so in 99.99% of cases you'll have pointer on top anyway
15:59 robert_mader: Hi! I'm currently playing with an optimization for certain GL/Vulkan clients that would replace a surfaces buffer with a single_pixel one. The intention is to let the compositor know that a surface is e.g. completely black (even though the next frame could be a GL/Vulkan one again), so they can skip a hardware plane in KMS.
15:59 robert_mader: My question now is: if I replace the surface buffer *after* GL/VK commited their (also completely black) buffer - can anyone of you think of negative side-effects? From my understanding, all what would happen is: the compositor releases the GL/VK buffer earlier than otherwise - and the presentation info would be off. Apart from that - are there any assumptions in the Mesa EGL/VK platforms assuming that no other buffer may e
15:59 robert_mader: hed to a surface "owned" by EGL/Vulkan?
16:00 robert_mader: I made an experiment for GTK and so far it seems to work surprisingly well (https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7057)
16:01 robert_mader: p.s.: the use-case is when there's a subsurface with e.g. YUV content on top of the surface used/owned by EGL/VK
16:01 emersion: i think ideally you'd completely skip GL/Vulkan in that case and won't bother to render at all
16:02 emersion: the problem with "replacing" is that it's not atomic
16:02 emersion: vulkan renders + commits a buffer, then you attach another buffer and commit again
16:02 emersion: i suppose it's not a super big deal if the buffers are identical…
16:03 emersion: but it's a bit weird
16:04 emersion: (the compositor might process the first commit, then wait an indefinite amount of time, then process the second commit)
16:04 emersion: (potentially blocking the first commit on a GPU fence)
16:04 robert_mader: The idea is to keep using the surface you usually use for rendering - e.g. the GTKs main surface - without having the extra-complexity of another subsurface.
16:04 emersion: right but you can attach+commit without calling vulkan?
16:04 emersion: on the same surface used by vulkan
16:04 robert_mader: Why not?
16:05 robert_mader: As long as I have a pointer to the wl_surface - I can attach buffers.
16:05 emersion: sorry, not sure i'm following :P
16:05 emersion: yes
16:05 emersion: what i mean is that… currently you do eglSwapBuffers() and then wl_surface_attach()+wl_surface_commit(), right?
16:06 robert_mader: right
16:06 emersion: why not skip the eglSwapBuffers()?
16:06 robert_mader: Mainly to keep things like buffer-age etc in tact.
16:07 emersion: since it's the same buffer contents conceptually, i think it doesn't matter?
16:07 robert_mader: Or generally to not touch anything on the renderer side - but to keep things as a backend-level optimization.
16:09 robert_mader: The main idea was to not change the EGL/Vulkan flow - but just do something behind their back. The overhead from the additional commit shouldn't matter here, as it only happens once when e.g. entering fullscreen while playing a video or so.
16:11 emersion: right, so the behind-the-back thing is not something do every frame, but rather once in a blue moon
16:12 emersion: i think it's fine, but not 100% perfect ;)
16:12 emersion: in general having extraneous wl_surface.commit in-between is a red flag
16:13 emersion: but shouldn't matter very much here
16:13 robert_mader: Well, we already do that in Firefox...
16:13 MrCooper: robert_mader: only thing that comes to mind offhand is it might interact badly with https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256 (the FIFO protocol)
16:14 emersion: oh please don't tell me about firefox 😭
16:21 robert_mader: Well, and generally EGL/Vulkan have to live with all kind of other surface state changes without a buffer swap.
16:22 robert_mader: MrCooper: thanks! Even though from a short look it's not obvious to me that it would be problematic - at least for the use-case in mind.
16:25 emersion: robert_mader: if FIFO is used, one vblank will show the GL buffer, and the next vblank will show the single-pixel one
16:25 emersion: in general, if you want to transition to something else, it'll have extra latency
16:26 robert_mader: Ah I see - yeah, that'd be unfortunate.
16:28 emersion: i think the conclusion is that if you can guarantee that the codepath is only ever triggered for the use-case you describe, it's probably fine
16:28 emersion: but if it's a more generic thing, it'll probably cause issues sooner or later
16:35 kennylevinsen: robert_mader: at least for the vsyncsource thing, my old dream was to replace it with a "FrameSource" that cooperated a bit more with rendering to avoid its own commits
16:37 robert_mader: kennylevinsen: Yeah, I remember...just so much work and little support/interest from Moz people :/
16:37 kennylevinsen: indeed, and each such task is quite a huge project...
16:40 kennylevinsen: robert_mader: btw, there's still no plans to move away from gtk3 or avoid using gtk's toplevel handling right?
16:43 robert_mader: No, AFAIK not. Even though the use of GTK features slowly continues to drop, making a new Wayland only backend more and more realistic IMO.
16:53 kennylevinsen: I recently had a small compositor multi-output bug where window on a 4k monitor ended up being 2x scale (8k). Everything worked fine so I hardly noticed... Until focus changed to/from Firefox, and my poor aging ultrabook had to import 8k shm buffers as Gtk was rendering its focus change animation to the top level underneath, making the whole system freeze for an ungodly amount of time. :P
16:53 kennylevinsen: A pure Wayland backend would be *awesome*
16:54 robert_mader: kennylevinsen: FWIW: on Android they just query the maximum refresh rate of the display and use a software timer. I was thinking about doing the same, now that there's the "suspended" toplevel state. That would probably also make things easier with VVR and generally reduce CPU overhead. At the price of slightly worse frame timing.
17:01 kennylevinsen: We originally had some primitive fixed timer, IIRC it had pretty bad frame jitter - but maybe it could be done better, it's many years ago
17:04 robert_mader: IIRC the main issue was that it didn't match the screen refresh rate. You can still set it via `widget.wayland.vsync.enabled` and `layout.frame_rate` (unfortunately the later is integer only).
17:18 kennylevinsen: That could very well be, doesn't hurt to try