ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<emersion>
that is, Wayland clients will have a repeat timer
<zamundaaa[m]>
Wouldn't you need the opposite to fix that problem?
<emersion>
thus, asking the compositor to not repeat keys would not fix the issue
<emersion>
the compositor would in turn need to ask its clients to not repeat keys
<d_ed[m]>
by "repeated on the server side" I think he means the vnc server
<d_ed[m]>
as in the client you remote into gets repeated keys
<d_ed[m]>
not server as in compositor
<zamundaaa[m]>
Yeah but the same thing applies
<any1>
The VNC server doesn't repeat keys
<zamundaaa[m]>
To fix it, you'd need the VNC server to handle key repeat
<zamundaaa[m]>
Ehh VNC client
<emersion>
rather, the VNC client
<emersion>
and then pass through repeated keys with a special flag down to all Wayland clients
* zamundaaa[m]
wants key repeat in the compositor anyways, for similar reasons
<emersion>
which is quite invasive
<any1>
Yes, the VNC client should handle key repeat and they do, but if the server side client application also repeats, things go awry
<emersion>
i suppose, one could disable key repeat in wayland clients entirely, but then this breaks other use cases like games
<d_ed[m]>
zamundaaa[m]: > * <@zamundaaa:kde.org> wants key repeat in the compositor anyways, for similar reasons
<d_ed[m]>
I know the input method people have issues with client side key repeats
<d_ed[m]>
it doesn't have to, as long as we have different events for down, repeated, up
<emersion>
what i mean is that there is no way forward with the current core wayland protocl
<d_ed[m]>
ack
<emersion>
there needs to be a protocol extension that all wayland clients would need to support
<emersion>
the problem is not just at the virtual-keyboard protocol level
<zamundaaa[m]>
Does it need to be an extension? Just a new version of wl_keyboard should be enough
<any1>
Yeah. So we need to add a flag to virtual-keyboard and wl_keyboard. Then, get Qt and GTK onboard.
<any1>
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.
<emersion>
i'm sceptical about adding this to wl_keyboard
<any1>
emersion: You have a better idea?
<emersion>
key repeat was intentionally left out of the core protocol
<any1>
I'm sure they were good intentions... :)
<zamundaaa[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
<emersion>
the core protocol has decided that key repeat would be handled in clients
<emersion>
i'd rather not force all clients to back-pedal to server-side key repeat because of a niche use-case
<zamundaaa[m]>
Do correct me if I'm wrong, but I'm pretty sure no clients actually want client side key repeat?
<any1>
So remote desktop over a high-latency connection is a niche usecase?
<any1>
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
<d_ed[m]>
any1: Somewhat.
<d_ed[m]>
The important part for me is that it's come up in lots of other niche places and they add up.
<d_ed[m]>
Can you open a ticket that and I'll drop something on there
navi has joined #wayland
<any1>
sure. After lunch
<pq>
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.
<pq>
anything that cares about how long a key is pressed needs to inspect the timestamps anyway, rather than assume event deliverly is instant.
<pq>
I bet no-one does it when they should.
<pq>
key repeat is just one aspect of that more profound problem, when the input device is beyond a random-latency link
<pq>
you can solve key repeat specifically with special repeat events that replace client-side key repeat, but it won't help any other timings
<pq>
maybe other timings just don't matter though
<any1>
vnc doesn't time stamp key events so that would not help even if it were implemented in clients
<zamundaaa[m]>
pq: I did think about it, but ignored it, because clients rolling back state is rarely implemented
<zamundaaa[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
<pq>
but Android defines that they should? So it's "just" bugs.
<pq>
I find Android touch interface non-deterministic and error prone in general
<pq>
as in, it misinterprets what I did
<zamundaaa[m]>
I think it does, yes. Would be pretty stupid if not
<pq>
whot, why did Wayland put key repeat implementation client-side, do you remember? Or should we ask krh?
<pq>
I do think it was intentionally client-side, because otherwise wl_keyboard would have KEY_REPEATED key state.
<emersion>
i tried searching the archives but didn't find anything
<emersion>
my assumption as someone who didn't design it was simplicity
<emersion>
X11 did have the repeat flag things, FWIW
eroc1990 has joined #wayland
<pq>
the very early design decisions were not documented, and maybe perhaps even just experimental and then forgotten to revisit
<pq>
The repeat event is also software generated, while down/up events are hardware generated.
<any1>
I feel like sometimes people treat these early design decisions like royal decrees or perhaps even the word of "god"
<pq>
any1, that's what they were.
<any1>
sarcasm?
<pq>
no, just a design by mostly one person, and not many other people reviewing that
<emersion>
it just so happens that trying to add everything that X11 had in Wayland may not always be a good ida
<emersion>
sometimes Wayland is missing a feature, sometimes not
<pq>
and then the interfaces were declared stable, because developers would not gather and use it otherwise
<pq>
once stable, they cannot be broken
<pq>
but there also were not even nearly enough users to properly evaluate if the design decisions were the best
<pq>
chicken-and-egg
<pq>
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.
<pq>
like global interface not needing destroy requests, because they would get cleaned up anyway when the client disconnects
<zamundaaa[m]>
pq: software vs hardware state doesn't make a lot of sense to me, modifiers and modifier locks are also software state
<pq>
zamundaaa[m], they also are not key events. Unless it was a literal key pressed/released that also happens to affect modifier state.
<davidre>
At least when I run libinput record I see a continuuos stream of evdev events when pressing a button and keeeping it pressed
kts has quit [Ping timeout: 480 seconds]
<emersion>
davidre: i don't
<davidre>
weird
<emersion>
KEYBOARD_KEY on press and on release, that's all
<any1>
Some keyboards have auto-repeat built in, right?
<pq>
anyhoo, here we are, and we do have the option of defining a new interface to replace wl_keyboard if we want to
<zamundaaa[m]>
emersion: record, not debug-events
<davidre>
emersion: Ah difference between actual events and what record shows
<davidre>
With debug-events I see no repeat indeed
<davidre>
So nevermind me
<pq>
so "everything is an extension" design vision is paying off
<emersion>
hm
<zamundaaa[m]>
emersion: looking at the wl_keyboard interface, repeat_info is actually part of the core protocol...
<emersion>
zamundaaa[m]: yes, because the cor protocol is designed with client side key repeat in mind
<emersion>
core*
<any1>
zamundaaa[m]: YEah, I was actually looking at the same thing
<emersion>
davidre: i do see some events in record as well
<any1>
Well, actually, this isn't actual the spec, but it's more like the "community spec"
<zamundaaa[m]>
any1: the VNC client sending repeat events doesn't matter, because the compositor can't pass them onto the Wayland client
<zamundaaa[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
<any1>
zamundaaa[m]: Yes, I see.
nerdopolis has quit [Ping timeout: 480 seconds]
<any1>
Sending the up before the down might be a reasonable compromise in the mean time
<d_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
mvlad has joined #wayland
<daniels>
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
<emersion>
right
tyzef[BZH] has quit [Ping timeout: 480 seconds]
<any1>
Ok, I can create an MR for adding repeat events. Would I be likely to succeed in such an effort?
<daniels>
d_ed[m]: that's actually super-useful, thanks for the link
nerdopolis has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
qaqland has quit [Ping timeout: 480 seconds]
silverpower has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
<soreau>
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
<soreau>
it does sounds like checking timestamps is a nice way to figure out what happened
<emersion>
any1, maybe. if a MR is too much work, an issue summing up the discussion here would be good
qaqland has joined #wayland
<any1>
emersion: It's not a lot of work, but if people are just going to nack it, it's not worth the effort
<emersion>
i won't nack it
<emersion>
i just want to properly explore the solution space
<pq>
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.
<any1>
emersion: So you'd prefer to continue exploring in an issue before MR?
<soreau>
any1: maybe make it optional so users can compare
<emersion>
i don't mind either way
<any1>
I'll do it later today. Need to do other things now
<dubiousness>
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
<pq>
there is, the wayland-protocols meeting
<dubiousness>
pq that’s just members isn’t it?
<pq>
is it?
<pq>
We certainly had a meeting when non-members expressed concerns about color management.
<pq>
with them
<dubiousness>
ah, looking at the notes it appears that changed last year
<zamundaaa[m]>
Definitely not just members
<dubiousness>
I retract the above and will attend the next one