01:45 ezzieyguywuf: when the window is being dragged, is there a way for me to know how much it has moved?
02:39 danieldg: I don't think so; if it's dragged by the SSD it might not even know. Output enter/leave events will give some information, if available
08:13 MrCooper: DemiMarie: "Mutter is the only major desktop compositor that doesn’t support xdg-decoration" is unfair to weston ;)
08:14 MrCooper: ifreund: actually, Xwayland uses only frame events for frame timing so far
08:15 MrCooper: colinmarc: one potential issue with delaying frame events like that is: if the client also tries to minimize latency by waiting for some time after receiving the frame event, there could be a bad feedback loop
08:30 MrCooper: daniels: "[with Wayland] it is possible to achieve latency just as low as non-composited X11" is technically only true assuming the Wayland compositor allows tearing for its composited output? Is there any compositor which actually does that?
08:42 YaLTeR[m]: [@_oftc_MrCooper:matrix.org](https://matrix.to/#/@_oftc_MrCooper:matrix.org) some compositors added a setting for this; I think generally everyone's waiting on kernel API fixes for async flips
08:43 kchibisov: IIRC someone said(mahkoh) that you don't actually need async flips to achieve that, but rather scheduling good enough will also work.
08:45 wlb: wayland-protocols Merge request !383 opened by Jonas Ådahl (jadahl) build: Bump version to 1.41 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/383
08:47 kchibisov: And that jay has some sort of that scheduling, though, I never tested myself, nor I have a setup to actually measure latency.
08:47 colinmarc: <MrCooper> "Colin Marc: one potential..." <- The frame callback sets the upper bound, no? If the client comes in under that it's their decision. I don't see how that would cause a feedback loop, as long as I'm counting the render time as frame callback -> buffer ready
08:48 MrCooper: kchibisov: no amount of scheduling without tearing can match tearing
08:48 MrCooper: in terms of latency
08:48 kchibisov: it's true that tearing is _better on average_.
08:48 colinmarc: <MrCooper> "ifreund: actually, Xwayland uses..." <- so fifo / commit-timing are only useful for sdl3 native games (or the equivalent) right now?
08:49 YaLTeR[m]: Not much you can do when idling in a text editor and pressing a key at the start of a monitor vblank cycle. Tearing helps here
08:50 YaLTeR[m]: And in games too if you run them unlimited fps
08:50 MrCooper: colinmarc: that assumes the 'frame callback -> buffer ready' interval is as short as possible, which isn't true with such a client
08:50 MrCooper: colinmarc: only Wayland-native clients use those protocols, yeah
08:51 colinmarc: MrCooper: It seems like the worst feedback loop possible would be that I keep backing the frame callback back until I'm sending it as early as possible, at the start of the frame. which is the same as the present situation and if the client wants to try to come in later, leaves it in their hands
08:52 MrCooper: YaLTeR[m]: isn't that setting just about supporting the tearing protocol, and there's only tearing when a fullscreen client uses the protocol?
08:52 YaLTeR[m]: Depends on how the compositor implements it
08:55 MrCooper: to be clear, I don't consider non-composited X or compositing with tearing acceptable in 2025, just trying to ensure apples are compared to apples
08:55 wlb: wayland-protocols/main: Jonas Ådahl * build: Bump version to 1.41 https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/71da8bd7f9fd meson.build
08:55 wlb: wayland-protocols Merge request !383 merged \o/ (build: Bump version to 1.41 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/383)
08:58 wlb: wayland-protocols New tag: 1.41 https://gitlab.freedesktop.org/wayland/wayland-protocols/tags/1.41
08:59 MrCooper: colinmarc: if the compositor decides to send the frame event later than before, and the client also decides to wait longer after the same frame event, there's a high risk of the client missing the next refresh cycle
08:59 colinmarc: right, but the algorithm would then send the frame event earlier and earlier
09:00 colinmarc: and that converges on the beginning of the frame, which is exactly the same as the current situation
09:00 colinmarc: then we have a smart client with as much time as it wants to try and be clever
09:01 MrCooper: the result might be the timings fluctuating between maxima and minima, with frequent frame drops; that's the bad feedback loop
09:01 kchibisov: if client tries to do _smart scheduling_ and doesn't account for delta in frame events, it's probably wrong.
09:02 kchibisov: doing smart scheduling just with frame events is also not great, since you have presentation protocol for that.
09:07 MrCooper: colinmarc: the client will also wait less after frame drops, so the compositor will see the 'frame callback -> buffer ready' interval go down and send frame events later again
09:09 colinmarc: MrCooper: I see what you mean, but I feel like the design has to account for a bit of hysteresis (with padding) anyway
09:10 colinmarc: and my plan is to use a fancy percentile approximation and base my scheduling on the p99 for render time, which should catch frame drops if they're frequent
09:10 colinmarc: not sure if that's actually what hysteresis means but you get my meaning
09:42 wlb: wayland.freedesktop.org Merge request !95 opened by Jonas Ådahl (jadahl) releases: Add wayland-protocols 1.40 and 1.41 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/95
10:03 wlb: wayland.freedesktop.org/main: Jonas Ådahl * releases: Add wayland-protocols 1.40 and 1.41 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/9a3bf2bfb19c releases.html
10:03 wlb: wayland.freedesktop.org/main: Jonas Ådahl * releases: Remove stray newline https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/commit/f5fce8dcb687 releases.html
10:03 wlb: wayland.freedesktop.org Merge request !95 merged \o/ (releases: Add wayland-protocols 1.40 and 1.41 https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/-/merge_requests/95)
10:08 davidre: \o/
13:25 pq: kchibisov, re: non-composited X11; sure GPU acceleration worked. Either AIGLX or sending clip lists(?) to the client-side GLX so it knows to not paint over someone else's window. I think?
13:27 kchibisov: pq: I made an assumption since if you share some common buffer it's either on gpu or cpu.
13:28 kchibisov: I'm not sure you can transparently draw from gpu to cpu buffer and visa-versa, you need some copy in place.
13:32 pq: it's on the gpu
13:33 pq: X11 drawing commands are executed on the server, so the core drawing requests can target a gpu framebuffer "just" as well
13:34 kchibisov: Yeah, I understand that if it's a server side drawing it'll work.
13:34 kchibisov: I just assumed that there was some client side drawing.
13:35 kchibisov: e.g. if I want to put some png on screen, I should likely upload it into texture of some sort.
13:36 pq: I think there were X11 extensions for client-side direct access to the hw fb, but those may have indeed conflicted with GPU architecture.
13:36 pq: yes, you would
13:36 kchibisov: yeah, so there should be a request to X11 to upload my data to some atlas and then I'd reference it from that atlas.
13:37 pq: yes, there are, many I believe
13:37 pq: Pixmap
13:37 kchibisov: so it seems like it won't generally be more efficient than composing, since someone should compose anyway.
13:38 pq: it can run on a fraction of the memory, though
13:40 kchibisov: it's true that it would make sw rendered clients faster though, since they can opt in predefined model of doing so.
13:41 kchibisov: instead of using OpenGL.
13:43 MrCooper: kchibisov pq: DRI1 used global clip lists in shared memory (which allowed client-side presentation to work, but broke with compositing), DRI2 & DRI3 handle presentation in the server
13:44 pq: ah yes, my memory didn't completely fail then :-)
13:46 MrCooper: (presentation as in effectively copying contents from a back buffer to a window, which in some cases can be optimized by just flipping the buffers)
14:12 wlb: weston Merge request !1690 opened by Robert Mader (rmader) gitlab-ci: Bump wayland-protocols to 1.41 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1690
16:09 wlb: weston/main: Daniel Stone * 26 commits https://gitlab.freedesktop.org/wayland/weston/compare/c112760368b0c8b24ab87eed40691e7c52bca3c4...e72839f52c2bffc41e920a0085474c79c94a10e8
16:09 wlb: weston Merge request !1676 merged \o/ (Improve read-back: Texture swizzles (3/4) https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1676)
16:29 Decker: I was looking into supporting pen inputs; it looks like this would be done with libinput - but then how do I move the cursor to the right relative position too? Or is the best I can hope for is to draw a dot or something in a surface handling the input?
17:55 wlb: weston/main: Robert Mader * gitlab-ci: Bump wayland-protocols to 1.41 https://gitlab.freedesktop.org/wayland/weston/commit/de6f0b870a95 .gitlab-ci.yml .gitlab-ci/build-deps.sh
17:55 wlb: weston Merge request !1690 merged \o/ (gitlab-ci: Bump wayland-protocols to 1.41 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1690)
20:38 hugeblank: hey there, I'm trying to get a set of foot pedals to work in tandem with my keyboard (in sway) so I can have my mod key as one of the pedals. I was told there might be a way to merge the inputs using libinput but it's unclear to me how I would get that working. Does anyone have any insight into this?
20:47 selckin: xremap maybe
20:50 hugeblank: I was hoping I wouldn't have to use an external tool to do what I wanted. Like theoretically it should be possible with some combination of sway/wlroots/xkb/libinput/evdev
20:53 hugeblank: oh and xremap doesn't look like it'd do what I want. I already have the pedals bound to the right keys, it's using them in combination with my keyboard that doesn't work.
20:54 hugeblank: For example leftmeta+1 switches focus to workspace 1. I would expect pressing the pedal + 1 on my keyboard to do that. It does not. Because the devices input events are handled separately for reasons unbeknownst to me.
20:58 kchibisov: I'm pretty sure if keyboards have the same keymap sway should group them into one logical.
21:08 hugeblank: kchibisov: how do I check that?
21:08 kchibisov: just set the same settings for all of them.
21:08 hugeblank: like, with xkb, or?
21:08 kchibisov: or try setting nothing at all in sway for your keyboards.
21:09 kchibisov: in sway config all keyboard settings must match for all keyboard iirc for them to be grouped.
21:09 kchibisov: I've replied to you in #sway about it as well.
21:10 hugeblank: ah! thanks, I'll move over there. I have some more questions.