ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
glennk has quit [Ping timeout: 480 seconds]
Leopold has quit [Ping timeout: 480 seconds]
lsd|2 has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
julio7359 has joined #wayland
guru_ has joined #wayland
<wlb> 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
Guru_DE has quit [Ping timeout: 480 seconds]
navi has quit [Quit: WeeChat 4.1.2]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
zxrom has quit [Quit: Leaving]
Company has joined #wayland
mtj has joined #wayland
mtj has quit []
kts has joined #wayland
mtj has joined #wayland
kts has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
silverpower_ has quit [Ping timeout: 480 seconds]
julio7359 has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit []
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
checkfoc_us has quit []
checkfoc_us has joined #wayland
kts has joined #wayland
julio7359 has joined #wayland
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
mxz has joined #wayland
kts has quit [Ping timeout: 480 seconds]
calcul0n has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
tyzef has joined #wayland
peelz has quit [Read error: Connection reset by peer]
peelz has joined #wayland
glennk has joined #wayland
rv1sr has joined #wayland
garnacho has joined #wayland
tzimmermann has joined #wayland
Guest310 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest412
leon-anavi has joined #wayland
<wlb> 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
<wlb> 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
<wlb> 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)
<wlb> 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
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
rv1sr has quit []
<wlb> 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
<wlb> 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)
<wlb> 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)
zxrom has joined #wayland
<wlb> 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)
<wlb> weston/main: Diego Nieto * compositor/main: warn pipewire-output and remote-output https://gitlab.freedesktop.org/wayland/weston/commit/1db0da8c8d97 frontend/main.c
fmuellner has joined #wayland
kts has joined #wayland
tyzef[BZH] has joined #wayland
tyzef has quit [Read error: Connection reset by peer]
tent4051 has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
<wlb> 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
<wlb> 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)
privacy has joined #wayland
rasterman has joined #wayland
<wlb> 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]
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
nerdopolis has joined #wayland
kts has quit [Ping timeout: 480 seconds]
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
nerdopolis has quit [Remote host closed the connection]
kts has joined #wayland
nerdopolis has joined #wayland
<emersion> key repeat is client-side
<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
eroc1990 has quit [Quit: The Lounge - https://thelounge.chat]
<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> since 4
kts has joined #wayland
<davidre> Maybe record is doing "client side" repeat as well? :D
<emersion> the main difference is the ev->value
<emersion> 0 for EV_KEY for release, 1 for keypress and 2 for autorepeat.
<emersion> so it does seem like the kernel provides libinput some autorepeat events
<any1> 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?
<zamundaaa[m]> repeat_info is just configuration of the client side repeat. What you need is actual key repeat over the protocol, right?
<pq> linux kernel can also emulate key repeat, it seems
<any1> zamundaaa[m]: I need to be able to tell the compositor to tell clients to not repeat keys for a particular wl_keyboard
<pq> EVIOCSREP
<zamundaaa[m]> any1: but then you'd just be disabling key repeat entirely
<zamundaaa[m]> The compositor has no way of transmitting key repeat events other than client side key repeat
<any1> zamundaaa[m]: Yes, I want to disable it for the wl_keyboard associated with the virtual keyboard.
<davidre> If you want no key repeat ever for a certain keyboard then your compositor could send a synthetic key up after every key down
<davidre> for that particular key board
<any1> Eh, no.
<davidre> eh
<davidre> Or just set repeat_info rate to 0
<davidre> A rate of zero will disable any repeating (regardless of the value of delay).
<any1> yes
<emersion> evdev has libevdev_get_repeat(), but no function to set the repeat settings
junaid has joined #wayland
<any1> virtual-keyboard-v1 isn't a part of w-p. Where does it come from and whom do I talk to about changing it?
<emersion> changing virtual-keyboard-v1 won't solve your issues, any1
<emersion> to solve the issue, more is needed
<any1> Yes, implementing it in wlroots. :)
<davidre> emersion: evemu-record looks like this for me
junaid has quit [Remote host closed the connection]
<davidre> E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/HYkicZuGdenJclZKVBQliLDM>)
<emersion> any1, if you disable key repeat and then sent regular physical key events for key repeat, many clients will be broken
<davidre> there is # Event type 20 (EV_REP)
<davidre> # Event code 1 (REP_PERIOD)
<davidre> # Event code 0 (REP_DELAY)
<davidre> but seems not used for that
<any1> emersion: How would that break them?
<emersion> the classic example is games, i suppose
<any1> I'd say that gaming over VNC is a niche use-case. :)
<emersion> some would disagree
<any1> emersion: VNC clients send repeat events anyway, as it's in the spec
<emersion> just like libinput discards repeat events from the kernel, you can discard them in the server
<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
<any1> But, yes, ideally, we'd want explicit repeat events in wl_keyboard.
<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
<dubiousness> my info was clearly out of date :)
<wlb> 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
<wlb> 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
<wlb> wayland Merge request !256 merged \o/ (build: fix build and provide compat for OpenBSD https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/256)
<davidre> "just" needs someone to schedule a meeting if a topic is in need of it
<davidre> there was none recently which means certianly that there aren't any divisive topics anymore to discuss :D
<wlb> 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
<wlb> 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
<wlb> 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
<wlb> 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
<wlb> weston Merge request !1397 merged \o/ (Fullscreen shell fixes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1397)
glennk has joined #wayland
<wlb> weston Merge request !1462 opened by Leandro Ribeiro (leandrohrb) Avoid assert hit in cmnoop_destroy() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1462
tzimmermann has quit [Quit: Leaving]
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
IMTheNachoMan has joined #wayland
Leopold_ has joined #wayland
tyzef[BZH] has joined #wayland
tyzef[BZH] is now known as tyzef
kts has quit [Quit: Leaving]
d42 has quit []
rv1sr has joined #wayland
tyzef has quit [Quit: WeeChat 3.8]
d42 has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
fossdd has joined #wayland
Brainium has joined #wayland
Brainium has quit [Remote host closed the connection]
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
TimWolla has quit [Quit: Bye]
TimWolla has joined #wayland
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
Company has quit [Quit: Leaving]
andreasbackx has joined #wayland
andreasbackx has quit [Remote host closed the connection]
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
leon-anavi has quit [Quit: Leaving]
calcul0n has quit [Remote host closed the connection]
tyzef has joined #wayland
calcul0n has joined #wayland
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
calcul0n has quit [Remote host closed the connection]
calcul0n has joined #wayland
<wlb> wayland Merge request !368 opened by Andri Yngvason (andri) Add wl_keyboard key repeat events https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/368
<any1> There, now what to do about virtual-keyboard-v1?
calcul0n has quit [Quit: Leaving]
calcul0n has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
calcul0n has quit [Ping timeout: 480 seconds]
Kerr_ has quit [Quit: Bye.]
tyzef has quit [Quit: WeeChat 3.8]
tyzef has joined #wayland
tyzef has quit []
tyzef has joined #wayland
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
mvlad has quit [Remote host closed the connection]
cool110 has joined #wayland
Guest412 has quit []
cool110 is now known as Guest482
fossdd has quit [Ping timeout: 480 seconds]
fossdd has joined #wayland
shtrom has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
fossdd has quit [Ping timeout: 480 seconds]
lsd|2 has joined #wayland
fossdd has joined #wayland
nerdopolis has joined #wayland