08:55pq: 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.
08:55pq: unless you talk about presentation-feedback?
08:56colinmarc: 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
08:57pq: so just the buffer only and not other surface/xdg/etc state?
08:59pq: 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.
09:00pq: if you have already released the buffer, you cannot read it anymore, so you can only release it once it cannot be needed anymore.
09:00colinmarc: I see what you mean. If I just send the frame callback, that would probably be enough, right?
09:00colinmarc: I don't need to throw away the buffer
09:00pq: I suppose so.
09:02pq: 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.
09:03pq: I wonder if the terminology around "discarded" is misleading...
09:03colinmarc: > It says nothing about the buffer from that update not being used in a following update as existing state.
09:03colinmarc: 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
09:04pq: A client can, but is not required.
09:06colinmarc: I think I also misunderstood this, from ack_configure:
09:06colinmarc: > 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.
09:06colinmarc: So actually, that commit could be without a buffer, in which case the buffer pre-ack is the content update to use
09:10colinmarc: 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.
09:11colinmarc: Since most clients will do so anyway, why not specify that after an ack_configure the surface should be considered unmapped?
09:49pq: colinmarc, unmapped specifically might imply resetting too much surface state, so I wouldn't use that.
09:51pq: unmapping means the surface actually disappears from screen and other things which is unwanted for a configuration change.
09:51pq: until the client acks the configure, the old state remains in effect and live
09:52pq: theoretically, the window should keep updating in its old state if the client posts updates without ack the configure
10:19MrCooper: pq: "superseded" or so might be clearer than "discarded" for presentation-feedback
10:59pq: yes, it would
13:13zzag: emersion: daniels: jadahl: is https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/368#note_2579854 good now?
13:26jadahl: 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
13:28jadahl: ah, nm, it's clearly explained
13:28jadahl: seems go
13:28jadahl: od
13:34colinmarc: oh, I hadn't seen that! I would definitely use that change
15:26wlb: wayland Merge request !368 merged \o/ (Add wl_keyboard key repeat events https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/368)
15:26wlb: wayland/main: Andri Yngvason * Add wl_keyboard key repeat events https://gitlab.freedesktop.org/wayland/wayland/commit/1b0d45e9c6bc protocol/wayland.xml
15:28any1: Hooray!
15:39yaslam: Hello
15:41yaslam: 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.
15:41yaslam: Thanks
15:42ebassi: yaslam: you probably want to ask on a user support channel for the desktop environment/compositor you're using
15:43yaslam: 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).
15:46Company: YaLTeR[m]: did you do compositor input lag measurements with your setup back when you also tested terminals?
15:47YaLTeR[m]: I did yeah, seemed to work ok
15:47Company: did you compare with Xorg?
15:48YaLTeR[m]: Uncomposited X11 had a good advantage. Though, Wayland tearing flips weren't a thing so I couldn't test that
15:49YaLTeR[m]: https://mastodon.online/@YaLTeR/110848066454900941
15:52Company: we know you have to redo those soon
15:52Company: because that graph is missing niri :p
15:53Company: but don't hurry too much, because I need to first get the iconcache working so gtk stops failing in dense_cells
16:01MrCooper: yaslam: try GNOME 47, that can achieve low single-digit millisecond latency
16:02yaslam: MrCooper: ah cool thanks
16:02yaslam: Will try that some time
16:07colinmarc: MrCooper: because you can turn off vsync?
16:08MrCooper: nope, dedicated KMS thread with RT priority which picks up current cursor position as late as possible for each display refresh cycle
16:09vyivel: neat
16:12DemiMarie: MrCooper: do you plan to make a blog post about this?
16:13MrCooper: not ATM
16:15geemili: 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?
16:17MrCooper: 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
16:21colinmarc: <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.
16:21yaslam: MrCooper: ah k
16:25geemili: Is that something that could be changed? Adding some other of getting keyboard input where the compositor handles translating the keycodes?
16:26geemili: 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.
16:27colinmarc: ooc, what language are you writing a client in that you can't use a c lib?
16:29colinmarc: 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.
16:31geemili: 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.
16:31colinmarc: (great pun)
16:31geemili: :P
16:32colinmarc: 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"
16:32colinmarc: * the umlaut" is handled
16:33geemili: 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.
16:33geemili: I mean, that would probably be the smart thing to do
16:33colinmarc: 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
16:34geemili: Ah, that's disappointing.
16:35geemili: I'll probably keep writing an xkbcommon compatible parser and port its test suite over TBH
16:36geemili: Though again, not because it's the smart thing to do
16:36colinmarc: I... really get it :p
16:43YaLTeR[m]: Company: later graphs have niri but I didn't bother retesting X11. I'll do it once tearing flips are working
18:35ericonr: geemili: can't you link against system libraries? You're already on a *nix when using Wayland, just take advantage of that
19:34geemili: 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.
19:36geemili: 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.
19:36ericonr:gives geemili libxkbcommon.a
20:07wlb: weston Issue #955 opened by () Support wlr data control / zwlr_data_control_manager_v1 https://gitlab.freedesktop.org/wayland/weston/-/issues/955
21:50emersion: FYI https://idtech.space/notice/AmJ60Dc5Vn0yigcxPM
21:51emersion: (not trying to start a discussion, just feeling like this is something Wayland devs should know about)
22:00kode54: emersion: and there's already distributions packaging them
22:20jadahl: emersion: sad to see indeed
22:38bl4ckb0ne: sad news, more fragmentation
22:39bl4ckb0ne: but hey it will be quick!
22:43any1:prepares to submit frog-croak-v1
22:46any1: It will be a coordinaton protocol between different frog clients to tell them when to say 'ribbit'.
22:47Ermine: those protocols need to be implemented first anyway, otherwise they're just pile of xml
22:47any1: They'll have to accept it, right? Otherwise, they're just setting themselves up as a competing standards committee. :)
22:50Eighth_Doctor: Ermine: the protocols in frog-protocols already have implementations
22:51Eighth_Doctor: there's gamescope and kwin already
22:51Eighth_Doctor: these protocols were previously included in gamescope, but have been split out since there are two implementations already for them
22:52Eighth_Doctor: and it looks like it's possible SDL will use it too
22:52Ermine: eh
23:32geemili: 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.
23:33Eighth_Doctor: there are proposed protocols for it
23:34Eighth_Doctor: ah here it is: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/244
23:51geemili: Oh, neat