01:23wlb: weston Merge request !1459 opened by JeffyChen (JeffyCN) backend-drm: Cleanup output's disable head list when destroying it https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1459
08:57wlb: wayland-protocols Merge request !283 opened by Julian Orth (mahkoh) Add ext-audio-surface protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/283
09:16wlb: wayland/main: Simon Ser * protocol: mention wl_surface events from wl_output.{scale,transform} https://gitlab.freedesktop.org/wayland/wayland/commit/a74aa93394a6 protocol/wayland.xml
09:16wlb: wayland Merge request !350 merged \o/ (protocol: mention wl_surface events from wl_output.{scale,transform} https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/350)
09:39wlb: weston Merge request !1460 opened by Paul Pu (puhui) Issue#766: Fix segfault when using fullscreen when just hotplugging the display https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1460
09:46wlb: weston/main: Paul Pu * Fix segfault when using fullscreen when just hotplugging the display https://gitlab.freedesktop.org/wayland/weston/commit/4eee3c816d11 desktop-shell/shell.c
09:46wlb: weston Merge request !1460 merged \o/ (Issue#766: Fix segfault when using fullscreen when just hotplugging the display https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1460)
09:46wlb: weston Issue #766 closed \o/ (Segfault when clicking on a fullscreen surface after coming back from another TTY https://gitlab.freedesktop.org/wayland/weston/-/issues/766)
09:54wlb: weston Merge request !1452 merged \o/ (compositor/main: warn pipewire-output and remote-output without mode https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1452)
09:54wlb: weston/main: Diego Nieto * compositor/main: warn pipewire-output and remote-output https://gitlab.freedesktop.org/wayland/weston/commit/1db0da8c8d97 frontend/main.c
11:23wlb: weston/main: Jeffy Chen * backend-drm: Cleanup output's disable head list when destroying it https://gitlab.freedesktop.org/wayland/weston/commit/9406664a540a libweston/backend-drm/drm.c
11:23wlb: weston Merge request !1459 merged \o/ (backend-drm: Cleanup output's disable head list when destroying it https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1459)
11:37wlb: weston Merge request !1461 opened by Daniel Stone (daniels) Use sized internal formats and immutable textures in GL renderer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1461 [GL renderer]
12:31any1: https://github.com/any1/wayvnc/issues/293 - Thoughts?
12:36emersion: key repeat is client-side
12:36emersion: that is, Wayland clients will have a repeat timer
12:37zamundaaa[m]: Wouldn't you need the opposite to fix that problem?
12:37emersion: thus, asking the compositor to not repeat keys would not fix the issue
12:37emersion: the compositor would in turn need to ask its clients to not repeat keys
12:37d_ed[m]: by "repeated on the server side" I think he means the vnc server
12:38d_ed[m]: as in the client you remote into gets repeated keys
12:38d_ed[m]: not server as in compositor
12:38zamundaaa[m]: Yeah but the same thing applies
12:38any1: The VNC server doesn't repeat keys
12:38zamundaaa[m]: To fix it, you'd need the VNC server to handle key repeat
12:38zamundaaa[m]: Ehh VNC client
12:38emersion: rather, the VNC client
12:39emersion: and then pass through repeated keys with a special flag down to all Wayland clients
12:39zamundaaa[m]:wants key repeat in the compositor anyways, for similar reasons
12:39emersion: which is quite invasive
12:39any1: Yes, the VNC client should handle key repeat and they do, but if the server side client application also repeats, things go awry
12:40emersion: i suppose, one could disable key repeat in wayland clients entirely, but then this breaks other use cases like games
12:40d_ed[m]: zamundaaa[m]: > * <@zamundaaa:kde.org> wants key repeat in the compositor anyways, for similar reasons
12:40d_ed[m]: I know the input method people have issues with client side key repeats
12:40d_ed[m]: it doesn't have to, as long as we have different events for down, repeated, up
12:41emersion: what i mean is that there is no way forward with the current core wayland protocl
12:41d_ed[m]: ack
12:41emersion: there needs to be a protocol extension that all wayland clients would need to support
12:42emersion: the problem is not just at the virtual-keyboard protocol level
12:42zamundaaa[m]: Does it need to be an extension? Just a new version of wl_keyboard should be enough
12:47any1: Yeah. So we need to add a flag to virtual-keyboard and wl_keyboard. Then, get Qt and GTK onboard.
12:50any1: An alternative (which adds a bunch of delay) would be to extend VNC so that key events get timestamped and then pass them through a jitter buffer on the server side. This would also have to percolate through the community and there's very little chance that RealVNC would adopt it.
12:50emersion: i'm sceptical about adding this to wl_keyboard
12:51any1: emersion: You have a better idea?
12:51emersion: key repeat was intentionally left out of the core protocol
12:51any1: I'm sure they were good intentions... :)
12:52zamundaaa[m]: Isn't it just not in the core proto because it's some configuration thing? I really don't see why key repeat would belong anywhere but wl_keyboard
12:53emersion: the core protocol has decided that key repeat would be handled in clients
12:54emersion: i'd rather not force all clients to back-pedal to server-side key repeat because of a niche use-case
12:54zamundaaa[m]: Do correct me if I'm wrong, but I'm pretty sure no clients actually want client side key repeat?
12:56any1: So remote desktop over a high-latency connection is a niche usecase?
12:57any1: I'm pretty sure that this isn't only a problem for wayvnc. This must also be happening with other remote desktop solutions on wayland
12:59d_ed[m]: any1: Somewhat.
12:59d_ed[m]: The important part for me is that it's come up in lots of other niche places and they add up.
12:59d_ed[m]: Can you open a ticket that and I'll drop something on there
13:05any1: sure. After lunch
13:12pq: Wayland clients already get timestamps with key events. They could roll back key repeat to match the original pressed period... just as another possibility I bet no-one thought about or rejected outright.
13:12pq: anything that cares about how long a key is pressed needs to inspect the timestamps anyway, rather than assume event deliverly is instant.
13:13pq: I bet no-one does it when they should.
13:13pq: key repeat is just one aspect of that more profound problem, when the input device is beyond a random-latency link
13:14pq: you can solve key repeat specifically with special repeat events that replace client-side key repeat, but it won't help any other timings
13:15pq: maybe other timings just don't matter though
13:16any1: vnc doesn't time stamp key events so that would not help even if it were implemented in clients
13:16zamundaaa[m]: pq: I did think about it, but ignored it, because clients rolling back state is rarely implemented
13:17zamundaaa[m]: Even on Android with touch gestures that are a core part of OS navigation, not all apps roll back button presses that happen because of cancelled touch events
13:18pq: but Android defines that they should? So it's "just" bugs.
13:19pq: I find Android touch interface non-deterministic and error prone in general
13:19pq: as in, it misinterprets what I did
13:21zamundaaa[m]: I think it does, yes. Would be pretty stupid if not
13:24pq: whot, why did Wayland put key repeat implementation client-side, do you remember? Or should we ask krh?
13:26pq: I do think it was intentionally client-side, because otherwise wl_keyboard would have KEY_REPEATED key state.
13:27emersion: i tried searching the archives but didn't find anything
13:27emersion: my assumption as someone who didn't design it was simplicity
13:28emersion: X11 did have the repeat flag things, FWIW
13:28pq: the very early design decisions were not documented, and maybe perhaps even just experimental and then forgotten to revisit
13:30pq: The repeat event is also software generated, while down/up events are hardware generated.
13:30any1: I feel like sometimes people treat these early design decisions like royal decrees or perhaps even the word of "god"
13:30pq: any1, that's what they were.
13:31any1: sarcasm?
13:31pq: no, just a design by mostly one person, and not many other people reviewing that
13:31emersion: it just so happens that trying to add everything that X11 had in Wayland may not always be a good ida
13:32emersion: sometimes Wayland is missing a feature, sometimes not
13:32pq: and then the interfaces were declared stable, because developers would not gather and use it otherwise
13:32pq: once stable, they cannot be broken
13:32pq: but there also were not even nearly enough users to properly evaluate if the design decisions were the best
13:32pq: chicken-and-egg
13:34pq: There *had to* be a strong vision of how Wayland should work, or people drifting by would have added everything X11 and more to it. But the vision itself might have had flaws that became apparent only later.
13:35pq: like global interface not needing destroy requests, because they would get cleaned up anyway when the client disconnects
13:35zamundaaa[m]: pq: software vs hardware state doesn't make a lot of sense to me, modifiers and modifier locks are also software state
13:36pq: zamundaaa[m], they also are not key events. Unless it was a literal key pressed/released that also happens to affect modifier state.
13:37davidre: At least when I run libinput record I see a continuuos stream of evdev events when pressing a button and keeeping it pressed
13:38emersion: davidre: i don't
13:38davidre: weird
13:38emersion: KEYBOARD_KEY on press and on release, that's all
13:38any1: Some keyboards have auto-repeat built in, right?
13:39pq: anyhoo, here we are, and we do have the option of defining a new interface to replace wl_keyboard if we want to
13:39zamundaaa[m]: emersion: record, not debug-events
13:39davidre: emersion: Ah difference between actual events and what record shows
13:39davidre: With debug-events I see no repeat indeed
13:39davidre: So nevermind me
13:40pq: so "everything is an extension" design vision is paying off
13:40emersion: hm
13:41zamundaaa[m]: emersion: looking at the wl_keyboard interface, repeat_info is actually part of the core protocol...
13:41emersion: zamundaaa[m]: yes, because the cor protocol is designed with client side key repeat in mind
13:41emersion: core*
13:41any1: zamundaaa[m]: YEah, I was actually looking at the same thing
13:41emersion: davidre: i do see some events in record as well
13:41any1: https://wayland.app/protocols/wayland#wl_keyboard:event:repeat_info
13:42any1: since 4
13:42davidre: Maybe record is doing "client side" repeat as well? :D
13:43emersion: the main difference is the ev->value
13:43emersion: 0 for EV_KEY for release, 1 for keypress and 2 for autorepeat.
13:44emersion: so it does seem like the kernel provides libinput some autorepeat events
13:45any1: Fun. Anyway, since repeat_info is there already, what's the problem? Can't we just add repeat_info to virtual keyboard and call it done?
13:46zamundaaa[m]: repeat_info is just configuration of the client side repeat. What you need is actual key repeat over the protocol, right?
13:46pq: linux kernel can also emulate key repeat, it seems
13:47any1: zamundaaa[m]: I need to be able to tell the compositor to tell clients to not repeat keys for a particular wl_keyboard
13:47pq: EVIOCSREP
13:48zamundaaa[m]: any1: but then you'd just be disabling key repeat entirely
13:48zamundaaa[m]: The compositor has no way of transmitting key repeat events other than client side key repeat
13:49any1: zamundaaa[m]: Yes, I want to disable it for the wl_keyboard associated with the virtual keyboard.
13:49davidre: If you want no key repeat ever for a certain keyboard then your compositor could send a synthetic key up after every key down
13:49davidre: for that particular key board
13:50any1: Eh, no.
13:50davidre: eh
13:50davidre: Or just set repeat_info rate to 0
13:50davidre: A rate of zero will disable any repeating (regardless of the value of delay).
13:50any1: yes
13:51emersion: evdev has libevdev_get_repeat(), but no function to set the repeat settings
13:54any1: virtual-keyboard-v1 isn't a part of w-p. Where does it come from and whom do I talk to about changing it?
13:55emersion: changing virtual-keyboard-v1 won't solve your issues, any1
13:56emersion: to solve the issue, more is needed
13:56any1: Yes, implementing it in wlroots. :)
13:56davidre: emersion: evemu-record looks like this for me
13:57davidre: E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/HYkicZuGdenJclZKVBQliLDM>)
13:57emersion: any1, if you disable key repeat and then sent regular physical key events for key repeat, many clients will be broken
13:58davidre: there is # Event type 20 (EV_REP)
13:58davidre: # Event code 0 (REP_DELAY)
13:58davidre: # Event code 1 (REP_PERIOD)
13:58davidre: but seems not used for that
13:58any1: emersion: How would that break them?
13:59emersion: the classic example is games, i suppose
14:00any1: I'd say that gaming over VNC is a niche use-case. :)
14:00emersion: some would disagree
14:00any1: emersion: VNC clients send repeat events anyway, as it's in the spec
14:00emersion: just like libinput discards repeat events from the kernel, you can discard them in the server
14:00any1: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#L1545
14:03any1: Well, actually, this isn't actual the spec, but it's more like the "community spec"
14:03zamundaaa[m]: any1: the VNC client sending repeat events doesn't matter, because the compositor can't pass them onto the Wayland client
14:04zamundaaa[m]: You'd have to send a key event for lifting the key, and then another for pressing it again. That's not exactly a good way to go about it... and you'd have to convince compositors to implement that
14:04any1: zamundaaa[m]: Yes, I see.
14:07any1: Sending the up before the down might be a reasonable compromise in the mean time
14:08any1: But, yes, ideally, we'd want explicit repeat events in wl_keyboard.
14:10d_ed[m]: This is worth a read: https://www.csslayer.info/wordpress/linux/key-repetition-and-key-event-handling-issue-with-wayland-input-method-protocols/
14:10d_ed[m]: The author comes to a different conclusion about how to fix it, with the client sending the client side repeated key back to the compositor... but it seems in the same space
14:32daniels: pq, any1: the reason we decided to do client-side repeat was just efficiency - why have the compositor schedule a timer to send an event to wake up a client, when the client could just schedule its own timer to wake up and repeat
14:33emersion: right
14:40any1: Ok, I can create an MR for adding repeat events. Would I be likely to succeed in such an effort?
14:44daniels: d_ed[m]: that's actually super-useful, thanks for the link
15:16soreau: any1: so the case is currently, on latent connection, press a key and hold it, the client sends repeated presses and then sends release? and if you do it server side on latent connection, the server (finally) gets a key press and then it keeps repeating, even after key release, because it didn't get the release button until later? so you get unwanted repeats
15:17soreau: it does sounds like checking timestamps is a nice way to figure out what happened
15:18emersion: any1, maybe. if a MR is too much work, an issue summing up the discussion here would be good
15:19any1: emersion: It's not a lot of work, but if people are just going to nack it, it's not worth the effort
15:19emersion: i won't nack it
15:20emersion: i just want to properly explore the solution space
15:20pq: any1, these things are complicated enough that they cannot be fully discussed in IRC. So even if it would get eventually rejected, a place to store the discussion is valuable.
15:21any1: emersion: So you'd prefer to continue exploring in an issue before MR?
15:21soreau: any1: maybe make it optional so users can compare
15:22emersion: i don't mind either way
15:23any1: I'll do it later today. Need to do other things now
15:32dubiousness: this is where I occasionally feel that a public forum once a month could be invaluable, like a mumble call which is segmented into community questions and technical discussions. you do need a designated transcriber for such calls though
15:44pq: there is, the wayland-protocols meeting
15:46dubiousness: pq that’s just members isn’t it?
15:48pq: is it?
15:48pq: We certainly had a meeting when non-members expressed concerns about color management.
15:48pq: with them
15:49dubiousness: ah, looking at the notes it appears that changed last year
15:49zamundaaa[m]: Definitely not just members
15:49dubiousness: I retract the above and will attend the next one
15:50dubiousness: my info was clearly out of date :)
15:50wlb: wayland/main: Sébastien Marie * compat: prefer waitpid() over waitid() https://gitlab.freedesktop.org/wayland/wayland/commit/791912c67867 tests/ test-compositor.c test-runner.c
15:50wlb: wayland/main: Sébastien Marie * build: fix build and provide compat for OpenBSD https://gitlab.freedesktop.org/wayland/wayland/commit/d80bce5f1a09 egl/meson.build meson.build src/wayland-os.c tests/test-helpers.c tests/test-runner.c
15:50wlb: wayland Merge request !256 merged \o/ (build: fix build and provide compat for OpenBSD https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/256)
16:01davidre: "just" needs someone to schedule a meeting if a topic is in need of it
16:02davidre: there was none recently which means certianly that there aren't any divisive topics anymore to discuss :D
16:23wlb: weston/main: Arnaud Vrac * fullscreen-shell: unregister output created listener on shell destroy https://gitlab.freedesktop.org/wayland/weston/commit/ccb6413aa167 fullscreen-shell/fullscreen-shell.c
16:23wlb: weston/main: Arnaud Vrac * fullscreen-shell: handle output resize and move signals https://gitlab.freedesktop.org/wayland/weston/commit/acb1d6721e79 fullscreen-shell/fullscreen-shell.c
16:23wlb: weston/main: Arnaud Vrac * fullscreen-shell: restore focus when output is created https://gitlab.freedesktop.org/wayland/weston/commit/373ee4df45d9 fullscreen-shell/fullscreen-shell.c
16:23wlb: weston/main: Arnaud Vrac * fullscreen-shell: do not crash when presenting a null surface https://gitlab.freedesktop.org/wayland/weston/commit/238d5274a20b fullscreen-shell/fullscreen-shell.c
16:23wlb: weston Merge request !1397 merged \o/ (Fullscreen shell fixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1397)
16:35wlb: weston Merge request !1462 opened by Leandro Ribeiro (leandrohrb) Avoid assert hit in cmnoop_destroy() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1462
22:19wlb: wayland Merge request !368 opened by Andri Yngvason (andri) Add wl_keyboard key repeat events https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/368
22:24any1: There, now what to do about virtual-keyboard-v1?