ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
vincejv_ has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
majors has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
mxz_ has joined #wayland
mxz__ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
karenw has joined #wayland
mxz_ has joined #wayland
vincejv_ has quit []
vincejv has joined #wayland
sima has joined #wayland
tzimmermann has joined #wayland
coldfeet has joined #wayland
kts has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
gallo has joined #wayland
<pq>
kennylevinsen, colinmarc, I'm confused about "discarding". Content updates can never be discarded, because wl_surface related state is incremental and clients are not required re-send state that is already correct from their perspective.
<pq>
unless you talk about presentation-feedback?
<colinmarc>
hm, I'm using the terminology from presentation-feedback, but I meant "discarding" from the compositor's perspective: releasing the buffer immediately, not keeping it around or presenting it
<pq>
so just the buffer only and not other surface/xdg/etc state?
coldfeet has quit [Remote host closed the connection]
<pq>
There is still the slim chance, that maybe the client does not need to re-render to meet a configure event, in which case you're supposed to use the buffer that's already attached.
<pq>
if you have already released the buffer, you cannot read it anymore, so you can only release it once it cannot be needed anymore.
<colinmarc>
I see what you mean. If I just send the frame callback, that would probably be enough, right?
<colinmarc>
I don't need to throw away the buffer
<pq>
I suppose so.
<pq>
presentation-feedback can also say "discarded", because that update will never hit the screen as is. It says nothing about the buffer from that update not being used in a following update as existing state.
<pq>
I wonder if the terminology around "discarded" is misleading...
<colinmarc>
> It says nothing about the buffer from that update not being used in a following update as existing state.
<colinmarc>
Couldn't the client just recommit with the same buffer, in that case? I understand that you're saying it's not mandated by the protocol, but that was my intuition for what would happen
<pq>
A client can, but is not required.
<colinmarc>
I think I also misunderstood this, from ack_configure:
<colinmarc>
> When a configure event is received, if a client commits the surface in response to the configure event, then the client must make an ack_configure request sometime before the commit request, passing along the serial of the configure event.
<colinmarc>
So actually, that commit could be without a buffer, in which case the buffer pre-ack is the content update to use
<colinmarc>
I can't think of any disadvantage to holding on to the buffer - except that in 99% of cases it's probably not the content I want, so it's more defensive to throw it away.
<colinmarc>
Since most clients will do so anyway, why not specify that after an ack_configure the surface should be considered unmapped?
kts has quit [Quit: Leaving]
coldfeet has joined #wayland
<pq>
colinmarc, unmapped specifically might imply resetting too much surface state, so I wouldn't use that.
<pq>
unmapping means the surface actually disappears from screen and other things which is unwanted for a configuration change.
<pq>
until the client acks the configure, the old state remains in effect and live
<pq>
theoretically, the window should keep updating in its old state if the client posts updates without ack the configure
kts has joined #wayland
kasper93 has joined #wayland
<MrCooper>
pq: "superseded" or so might be clearer than "discarded" for presentation-feedback
vnd has quit [Ping timeout: 480 seconds]
eruditehermit has quit [Quit: Konversation terminated!]
kts has quit [Quit: Leaving]
fmuellner has joined #wayland
<pq>
yes, it would
nerdopolis has joined #wayland
Lucretia has joined #wayland
shider has joined #wayland
pq has joined #wayland
ity1 has joined #wayland
ity has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit []
nysach has joined #wayland
coldfeet has quit [Remote host closed the connection]
nysach has quit [Remote host closed the connection]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
nysach has joined #wayland
Sid127 has joined #wayland
nysach has quit [Remote host closed the connection]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
feaneron has joined #wayland
sima has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
nysach has joined #wayland
shider has quit [Ping timeout: 480 seconds]
Moprius has joined #wayland
nysach has quit [Remote host closed the connection]
nysach has quit [Remote host closed the connection]
kts has quit []
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
shider has joined #wayland
<jadahl>
zzag: hrm, how do e.g. gtk know when it should avoid doing its own key repeat? the protocol says "may", so it won't know until it receives anything, an arbitrary time after the 'down' event
<jadahl>
ah, nm, it's clearly explained
<jadahl>
seems go
<jadahl>
od
<colinmarc>
oh, I hadn't seen that! I would definitely use that change
nysach has joined #wayland
balrog_ has joined #wayland
nysach has quit [Remote host closed the connection]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
balrog_ has quit []
balrog has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
kts has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
The_Buhs_ has quit [Quit: The_Buhs_]
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
The_Buhs_ has joined #wayland
The_Buhs_ is now known as Guest4313
nysach has joined #wayland
Guest4313 is now known as The_Buhs
The_Buhs has quit [Quit: The_Buhs]
The_Buhs has joined #wayland
The_Buhs has quit []
The_Buhs has joined #wayland
nysach has quit [Remote host closed the connection]
nysach has quit [Remote host closed the connection]
yaslam has joined #wayland
<yaslam>
Hello
<yaslam>
I have a question, why is my mouse pointer laggier on Wayland than Xorg? I use a 60HZ display and it feels like there is a lot more input lag on Wayland than Xorg.
<yaslam>
Thanks
<ebassi>
yaslam: you probably want to ask on a user support channel for the desktop environment/compositor you're using
<yaslam>
ebassi: thanks, but I experience this in general on KDE Wayland, Sway, Hyprland, COSMIC Epoch etc... It seems all Wayland compositors have the same issue. Except KDE Wayland which still has this issue but the input lag is slightly less (still not as sharp as Xorg though).
<Company>
YaLTeR[m]: did you do compositor input lag measurements with your setup back when you also tested terminals?
<YaLTeR[m]>
I did yeah, seemed to work ok
<Company>
did you compare with Xorg?
tzimmermann has quit [Quit: Leaving]
<YaLTeR[m]>
Uncomposited X11 had a good advantage. Though, Wayland tearing flips weren't a thing so I couldn't test that
nysach has quit [Remote host closed the connection]
<Company>
we know you have to redo those soon
<Company>
because that graph is missing niri :p
<Company>
but don't hurry too much, because I need to first get the iconcache working so gtk stops failing in dense_cells
rv1sr has joined #wayland
<MrCooper>
yaslam: try GNOME 47, that can achieve low single-digit millisecond latency
<yaslam>
MrCooper: ah cool thanks
<yaslam>
Will try that some time
<colinmarc>
MrCooper: because you can turn off vsync?
ity1 has quit []
ity has joined #wayland
<MrCooper>
nope, dedicated KMS thread with RT priority which picks up current cursor position as late as possible for each display refresh cycle
<vyivel>
neat
<DemiMarie>
MrCooper: do you plan to make a blog post about this?
<MrCooper>
not ATM
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
<geemili>
Forgive my intrusion but I've been wondering why Wayland forces clients to parse keymaps and translate keycodes into symbols? It seems like an unecessary duplication of work, since the compositor has to interpret the events anyway. Why not send both the XKB symbol and the keycode?
<MrCooper>
yaslam: though it's still not optimal for with composited frames (when anything visibly changes other than the cursor moving), https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3964 is the missing piece for that, couldn't figure out the CI failures in time for 47; normally shouldn't hurt too much though
<colinmarc>
<geemili> "Forgive my intrusion but I've..." <- There was an extended discussion about this a couple weeks (longer?) back. I had a similar question. I was told that basically legacy apps require the keymap to do heuristics on shortcuts.
<yaslam>
MrCooper: ah k
sewn has joined #wayland
nysach has joined #wayland
nysach has quit [Remote host closed the connection]
<geemili>
Is that something that could be changed? Adding some other of getting keyboard input where the compositor handles translating the keycodes?
<geemili>
I've been writing my own code to parse xkbcommon keymaps and it just feels like an unnecessary dependency of the protocol at this point.
<colinmarc>
ooc, what language are you writing a client in that you can't use a c lib?
<colinmarc>
I think realistically, it's unlikely to change. It would require shifting more responsibility for complicated text input to the text-input protocol, which isn't supported everywhere.
<geemili>
I'm using Zig. I can use C libs, I just don't want to. If I did decide to use libxkbcommon I would want to package it using Zig, and that would require packaging Yacc or Bison, which aren't the yaks I've chosen to shave at the moment.
<colinmarc>
(great pun)
<geemili>
:P
<colinmarc>
imo, you should use xkbcommon. For better or worse, that is where all the nonsense like "type alt-u to insert an umlaut and then type another character under the umlaut"
<colinmarc>
* the umlaut" is handled
<geemili>
Oh yeah, I did try the text-input protocol, but ATM river doesn't seem to generate any text input events from the keyboard itself.
<geemili>
I mean, that would probably be the smart thing to do
<colinmarc>
in my ideal world that stuff would be handled by text-input and wl_keyboard would just communicate (scancode, Option<sym>), but last time I asked about that I was told it's a hard requirement for clients to see the keymap
<geemili>
Ah, that's disappointing.
<geemili>
I'll probably keep writing an xkbcommon compatible parser and port its test suite over TBH
<geemili>
Though again, not because it's the smart thing to do
<colinmarc>
I... really get it :p
kts has quit [Remote host closed the connection]
<YaLTeR[m]>
Company: later graphs have niri but I didn't bother retesting X11. I'll do it once tearing flips are working
paulk has quit [Ping timeout: 480 seconds]
plutones has quit [Remote host closed the connection]
yshui has quit [Ping timeout: 480 seconds]
yshui has joined #wayland
vincejv has quit [Remote host closed the connection]
___nick___ has joined #wayland
___nick___ has quit []
r00tobo has joined #wayland
___nick___ has joined #wayland
coldfeet has joined #wayland
Psi-Jack has quit [Quit: Do you type on your PS1 or play on your PS1?]
Psi-Jack has joined #wayland
mohit81582263530 has quit [Remote host closed the connection]
mohit81582263530 has joined #wayland
feaneron has quit [Remote host closed the connection]
feaneron has joined #wayland
feaneron has quit [Remote host closed the connection]
feaneron has joined #wayland
Moprius has joined #wayland
vincejv has joined #wayland
nysach has joined #wayland
<ericonr>
geemili: can't you link against system libraries? You're already on a *nix when using Wayland, just take advantage of that
Brainium has joined #wayland
nysach has quit [Remote host closed the connection]
linkmauve has left #wayland [#wayland]
rasterman has quit [Quit: Gettin' stinky!]
linkmauve has joined #wayland
nysach has joined #wayland
nysach_ has joined #wayland
nysach has quit [Read error: Connection reset by peer]
nysach_ has quit [Remote host closed the connection]
fmuellner has quit [Remote host closed the connection]
fmuellner has joined #wayland
rv1sr has quit [Read error: Connection reset by peer]
rv1sr has joined #wayland
fmuellner has quit [Remote host closed the connection]
glennk has joined #wayland
fmuellner has joined #wayland
<geemili>
ericonr: That might be the smart thing to do. However my goal at the moment is to statically link everything I can and rely mostly on well specified protocols.
sima has quit [Ping timeout: 480 seconds]
<geemili>
I don't "libxkbcommon will be at /usr/lib/libxkbcommon.so" is a guarantee made anywhere, so I don't want to rely on it. But again it's more a philosophical point, linking libxkbcommon would no doubt be the fatest way to go.
* ericonr
gives geemili libxkbcommon.a
coldfeet has quit [Remote host closed the connection]
Moprius has quit [Quit: bye]
rebtoor has joined #wayland
rebtoor has quit []
___nick___ has quit [Remote host closed the connection]
<emersion>
(not trying to start a discussion, just feeling like this is something Wayland devs should know about)
eruditehermit has joined #wayland
<kode54>
emersion: and there's already distributions packaging them
<jadahl>
emersion: sad to see indeed
checkfoc_us9 has quit []
checkfoc_us9 has joined #wayland
<bl4ckb0ne>
sad news, more fragmentation
<bl4ckb0ne>
but hey it will be quick!
* any1
prepares to submit frog-croak-v1
<any1>
It will be a coordinaton protocol between different frog clients to tell them when to say 'ribbit'.
<Ermine>
those protocols need to be implemented first anyway, otherwise they're just pile of xml
<any1>
They'll have to accept it, right? Otherwise, they're just setting themselves up as a competing standards committee. :)
<Eighth_Doctor>
Ermine: the protocols in frog-protocols already have implementations
<Eighth_Doctor>
there's gamescope and kwin already
<Eighth_Doctor>
these protocols were previously included in gamescope, but have been split out since there are two implementations already for them
<Eighth_Doctor>
and it looks like it's possible SDL will use it too
<Ermine>
eh
feaneron has quit [Ping timeout: 480 seconds]
MrCooper_ has joined #wayland
<geemili>
Another question that been on my mind: Is there a reason gamepads aren't handled by Wayland? I would think that compositors for, e.g. gaming handhelds, would want to do the same kind of input multiplexing for gamepads that is currently done for mouse pointers and keyboards.
<Eighth_Doctor>
there are proposed protocols for it