01:06 dryya: qQ$L`=AJp@@L<ZH!9uTAga=yt
03:15 clamps: < dryya> qQ$L`=AJp@@L<ZH!9uTAga=yt <- been a while since i've seen line noise, reminds me of my youth
03:31 Company: back when https://web.archive.org/web/20040604194346/http://bash.org/?244321 wasn't on the wayback machine yet?
06:30 wb9688: Hmm… is bash.org offline now? :/
06:48 wlb: weston/main: Philipp Zabel * helpers: Add an integer division helper that rounds up https://gitlab.freedesktop.org/wayland/weston/commit/b3d94c98431c shared/helpers.h
06:48 wlb: weston/main: Philipp Zabel * backend-pipewire: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/commit/4d14adaa2cef libweston/backend-pipewire/pipewire.c
06:48 wlb: weston Merge request !1310 merged \o/ (backend-pipewire: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1310)
06:52 wlb: weston/main: Philipp Zabel * backend-vnc: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/commit/5a95339d7aa7 libweston/backend-vnc/vnc.c
06:52 wlb: weston Merge request !1302 merged \o/ (backend-vnc: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1302)
06:56 wlb: weston/main: Philipp Zabel * backend-rdp: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/commit/e541aea2d760 libweston/backend-rdp/rdp.c
06:56 wlb: weston Merge request !1311 merged \o/ (backend-rdp: make sure to finish frames with timestamps in the past https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1311)
07:00 wlb: weston/main: Pekka Paalanen * backend-drm,pipewire,remoting: do not set monitor serial to "unknown" https://gitlab.freedesktop.org/wayland/weston/commit/3728d7e99b88 libweston/backend-drm/modes.c pipewire/pipewire-plugin.c remoting/remoting-plugin.c
07:00 wlb: weston/main: Pekka Paalanen * libweston: use xstrdup for head strings https://gitlab.freedesktop.org/wayland/weston/commit/c26335bfdbc6 libweston/compositor.c
07:00 wlb: weston/main: Pekka Paalanen * libweston: set default monitor strings https://gitlab.freedesktop.org/wayland/weston/commit/d79fc781527e libweston/ backend-drm/modes.c compositor.c
07:00 wlb: weston Merge request !1350 merged \o/ (Unify initial monitor strings https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1350)
07:03 wlb: weston Merge request !1346 merged \o/ (desktop-shell: Fix shell fade animations https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1346)
07:03 wlb: weston/main: Marius Vlad * 5 commits https://gitlab.freedesktop.org/wayland/weston/compare/d79fc781527e6a9ffc7c40eef4bfa4f0ba419577...8ac621d67252c1f93c4cc68ee3527e1f3083a50f
07:07 wlb: weston/main: Loïc Yhuel * gl-renderer: use correct read-back format and support WL_SHM_FORMAT_ABGR8888 https://gitlab.freedesktop.org/wayland/weston/commit/71616edc4dfc libweston/renderer-gl/gl-renderer.c
07:07 wlb: weston Merge request !1355 merged \o/ (gl-renderer: use correct read-back format and support WL_SHM_FORMAT_ABGR8888 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1355)
07:30 MrCooper: zamundaaa[m]: whoever you were talking to about synchronization, their messages didn't get bridged to IRC
09:25 heeen: should wl_output geometry reflect the dimensions of the display as mounted for the viewer or logically like it is driven
09:26 heeen: i.e. if a device is mounted portrait, but the screen is just turned 90° for that, is wl_output geometry 1280x800 or 800x1280
09:36 ascent12: heeen: I think it's the unrotated value
09:36 ascent12: Any client that really cares should really be using xdg_output to get more accurate information though
09:38 heeen: hrm. my compositor does not implement xdg_output I think
09:40 ascent12: zxdg_output_manager_v1 would be the name of the global, it's been around for a while at this point
09:40 heeen: [2473991.890] wl_output@12.geometry(0, 0, -1, -1, 0, "", "", 1)
09:40 heeen: [2473991.893] wl_output@12.mode(3, 1280, 800, 119910)
09:40 heeen: [2473991.894] wl_output@12.scale(1)
09:40 heeen: [2473991.896] wl_output@12.done()
09:40 heeen: weird
09:41 heeen: this is a QtWayland concottion
09:41 heeen: QScreen on the client side gives 1280x800
09:42 ascent12: You have to bind to zxdg_output_manager_v1 and use get_xdg_output to see the events
09:44 d_ed[m]: Qt will use xdg_output if available
09:44 d_ed[m]: as for rotation
09:45 heeen: The QWaylandXdgOutputManagerV1 extension provides a way for a compositor to describe outputs in a way that is more in line with the concept of an output on desktop oriented systems.
09:45 heeen: Some information may not make sense in other applications such as IVI systems.
09:45 heeen: hmm
09:45 heeen: my application is more like an embedded/ivi system than desktop
10:33 pq: If clients are allowed to warp a pointer within their (exposed input region?) window area while having pointer focus, should we worry about e.g. malicious web code taking the pointer hostage by forcefully keeping it in the window?
10:34 dottedmag: Do browsers provide API to warp pointers?
10:36 pq: I don't know.
10:37 pq: I might not worry about locally installed software. What about flatpak et al.?
10:39 pq: just thinking about worst case scenarios, are they significant enough to care about
10:40 pq: requiring a valid input serial might even be all that's needed
10:42 vsyrjala: does pointer warping have actual use cases (apart from x11 legacy)?
10:42 pq: yeah (discussed in the backlog), even if niche
10:57 davidre: pq: Keeping the cursor in the window: Doesnt the same worry apply to confinement and locked pointers?
10:58 pq: They should already have escape hatches in compositors.
10:58 davidre: I would escape that then warping would as well :)
10:58 davidre: *expect
10:58 pq: sure
11:00 pq: but then I don't think warping can be just one request to move to x,y that either works or not, would it not need feedback whether it actually did?
11:01 pq: or perhaps something like warping enabled/disabled events, so the client knows what's possible and can adapt UX
11:01 zamundaaa[m]: Dallas Strouse (she/her) 🧑‍🏫: you need to authenticate with NickServ again. Your messages aren't reaching IRC
11:01 zamundaaa[m]: pq: that sounds racy
11:02 pq: in some sense, it cannot be race-free, right?
11:02 davidre: pointer constraints has locked/unlocked, confined/unconfined signals currently
11:02 pq: that's actually a good point, how does the client know where the pointer is after a warp request and without the end user moving the pointer
11:04 pq: would there be a pointer focus leave+enter pair? but what if buttons are down?
11:18 davidre: pq: You could make it so that if a compositor deemed the warp request acceptable it would just respond as normal with wl_pointer::motion, client side there would only be one path for cursor position then
11:19 davidre: If the compositor doesnt allow it there would just be no motion event
11:22 davidre: I guess it could be a bit ambigious especially if there are buttons held by a user and things being async
11:22 davidre: maybe just a pointer_warped(x, y, surface) response by the compositor?
11:24 pq: wl_pointer.motion is not meant for such "software actions" though and might break the timestamp ordering
11:25 pq: pointer_warped event could make a lot of sense I guess
11:26 pq: it would allow compositors to warp pointers at will without the awkward pointer focus leave+enter cycle which just doesn't work if buttons are down, since we have no events defined for entering with buttons already held
11:27 pq: one source of compositor-side pointer warp is moving the window underneath the pointer
11:38 davidre: pq Of course it would only work if the client has the new global bound (or object created?) for these not client used usecases
11:38 davidre: Or are you thinking of adding such an event to wl_pointer
12:20 pq: davidre, the same problem still even if in wl_pointer, there would be clients who bind an older version.
12:21 davidre: I would guess clients supporting a newer wl_pointer is more likely then implementing a new pointer warp protocol just so compositor authors have it easier ;)
12:26 zamundaaa[m]: pq: wl_pointer.motion is already used for this purpose though, in pointer constraints
12:30 pq: ugh
18:40 orowith2os[m]: <zamundaaa[m]> "Dallas Strouse (she/her) 🧑‍🏫: yo..." <- I might as well just write my own IRC/Matrix client for how much this thing breaks
18:40 orowith2os[m]: holy crap