06:41JoshuaAshton: It seems that sometimes scroll events with XWayland just get dropped?
06:41JoshuaAshton: I replaced the code in my Wayland compositor to instead call XTestFakeButtonEvent with 4/5 and that consistently works
06:41JoshuaAshton: It's really strange...
06:42JoshuaAshton: I tested on kwin and labwc as well, and yeah, very occasionally, scroll events on XWayland just get dropped and dont' happen? Anyone else seen this before?
06:44JoshuaAshton: I should probably dig deeper into XServer to see what's going on but sleepy...
06:44JoshuaAshton: FTR I am also testing specifically with Chromium which may also be doing something weird as usual :D
06:49Consolatis: xev might be more appropriate for testing
06:51Consolatis: with xev I at least don't recognize any missing events, every click on the wheel seems to resut in press and release events for button 4/5
06:51Consolatis: (on labwc that is)
06:52JoshuaAshton: Lemme try xev in Gamescope...
06:53JoshuaAshton: Hmmm, xev seems to give the right stuff for me with the XWayland scroll stuff
06:54JoshuaAshton: Maybe Chrome is doing something with XInput2 and the more fine scroll stuff there?
07:01JoshuaAshton: Consolatis: If you launch labwc nested rn, launch chromium, go to a page like asdasdhjkasdhjk, your first scroll event should always be dropped
07:01JoshuaAshton: WAYLAND_DISPLAY= chromium
07:01JoshuaAshton: I have that with 100% consistency
07:05Consolatis: well, can't really say anything about that and I don't particularly feel like debugging chromium. maybe there is a simpler xev like test client that uses XInput2
07:05JoshuaAshton: I should boot into a real X server and see if it repros there too....
07:06JoshuaAshton: omg it does
07:06JoshuaAshton: X_X
07:54ofourdan: JoshuaAshton: hey, which version of Xwayland? Reason I ask is because that reminds me of https://gitlab.freedesktop.org/xorg/xserver/-/issues/1339 fixed by whot with https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1059
07:54JoshuaAshton: ofourdan: Latest master and whatever latest release in my pkg mgr
07:57ofourdan: iiuc, it's only the first event that gets dropped? That sounds like a valuator issue…
07:57JoshuaAshton: ofourdan: That event is dropped in chrome always, even on regular X11 :S
07:58ofourdan: ah
07:59JoshuaAshton: ofourdan: Seems like Gamescope has it worse than everyone for scrolling in Chrome on XWayland. No idea why. Other apps/games work totally fine using xwayland scroll code.
07:59JoshuaAshton: For now I've just added some XTestFakeButtonEvent jank code to avoid going through the device/valuator path :/
07:59ofourdan: well, that code (dix) is common between all xservers, so a possible bug there could affect the plain Xorg server as well.
08:02JoshuaAshton: Going back to old xwayland before that MR doesn't help so eh.
08:02JoshuaAshton: welp
08:03nmeum: danieldg: WAYLAND_DEBUG=1 tells me `discarded [unknown]@2.[event 0](0 fd, 32 byte)` on monitor hotplug. does this mean this is a compositor bug?
08:03ofourdan: oh, not surprising, I dount that MR caused such a regression, I was pointing atthat because it woulds similar so your issue could be along the same lines :)
08:03ofourdan: *doubt
08:03ofourdan: *sounds
08:03ofourdan: grr, friday typos! :(
08:08JoshuaAshton: It seems almost like a timing thing :/
08:08JoshuaAshton: Like it's totally random if Chrome likes my scrolls
08:09davidre: nmeum: I think it means that you destroyed the wl_registry
08:09davidre: Since you have no alive proxy libwayland discards the event
08:09nmeum: yea, also just figured that out. it is in fact the bug in my code i was looking for ':D
08:09nmeum: thanks!
08:25JoshuaAshton: ofourdan: oooo I found something weird....
08:25JoshuaAshton: If I send axis events with 0's on frames the scroll wheel does nothing it fixes it...
08:40JoshuaAshton: Ah
08:41JoshuaAshton: XWayland reaaalllly hates it if I don't send both X and Y if one of them is 0
08:41JoshuaAshton: That seems to be the big culprit here
08:41JoshuaAshton: Really strange
08:42ofourdan: I'm afraid I dunno that code well enough to be really helpful here, I think best would be to file an issue with all your findings and let whot comment on that when he's available.
09:15pq: haasn, wayland originally had only one clipboard (wl_data_device etc) which was not the primary-selection, but then people were too used to having primary-selection as a separate clipboard, so it got added. People wanted them to be independent, the form of protocol desing is irrelevant for fundamentally conflicting user desires.
12:16pq: swick[m], are you using some kind of linter and link checked with color-and-hdr?
12:16pq: *checker
12:44swick[m]: no, it seemed faster to just do the work than trying to set up tooling for it
12:45swick[m]: but we probably should add something to CI
12:51pq: perhaps
12:52swick[m]: podman run --user root -v ${PWD}:/tmp:z --workdir=/tmp --rm -i ghcr.io/tcort/markdown-link-check:stable $(find . -name '*.md')
12:54swick[m]: but this obviously fails with all the relative links in the repo
12:54pq: d'oh
12:54swick[m]: oh wait, it's a bit smart
12:55swick[m]: it's just the links with only a fragment that fail
12:56swick[m]: that should be trivial to fix
13:16swick[m]: blergh, it's a regression in the latest release
13:16swick[m]: podman run --user root -v ${PWD}:/tmp:z --workdir=/tmp --rm -i ghcr.io/tcort/markdown-link-check:3.11.2 $(find . -name '*.md') works just fine
14:17swick[m]: pq: all done, and it found a few issues
14:26pq: swick[m], awesome, thanks for adding the CI stuff! I was just curious if you used any personally. :-D
14:53swick[m]: emersion: is there anything else you want for https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/188 ?
15:19ifreund: what exactly does LIBINPUT_EVENT_TOUCH_CANCEL mean?
15:22ifreund: I can't find any docs on it in libinput. From reading the code it seems to be sent when touch hardware is disabled or if palm detection kicks in
15:22ifreund: I'm not sure how to translate this into wayland though. the wl_touch.cancel event affects all touch points not just a single one like the libinput cancel event
15:46ifreund: I'm starting to think that LIBINPUT_EVENT_TOUCH_CANCEL should be handled exactly the same LIBINPUT_EVENT_TOUCH_UP...
15:54zamundaaa[m]: No, it should not
15:55zamundaaa[m]: You should just send a wl_touch.cancel to clients
15:55zamundaaa[m]: If you send a touch up event, apps will act on the touch points as if the user actually tapped the screen, which has undesired side effects
15:56ifreund: zamundaaa: I still don't understand the semantic meaning of the LIBINPUT_EVENT_TOUCH_CANCEL event...
15:56ifreund: it didn't seem to be related at all to the semantics of the wl_touch.cancel event from reading the libinput code
15:57zamundaaa[m]: Both mean the same thing: "discard the touch points"
15:58ifreund: ok, the libinput event only discards a single touch point but the wayland protocol event cant represent that
15:59ifreund: I see what you mean about sending touch up in this case being wrong, thanks
16:01ifreund: I guess it's fine in practice to always discard all touch points for the client when any touch point is discarded by libinput, just a bit more work for the compositor to ensure consistency
16:02zamundaaa[m]: Yeah, I wondered about fixing that in Wayland before too, but in practice discarding all of them is fine
16:17ifreund: am I correct that the wl_touch.cancel event is not followed by a wl_touch.frame event?
16:17ifreund: this seems to be what wlroots implements at least but it would be good to explicity state in the protocol
16:54bwidawsk: `Creating an xdg_surface from a wl_surface which has a buffer attached or committed is a client error, and any attempts by a client to attach or manipulate a buffer prior to the first xdg_surface.configure call must also be treated as errors.` - As I read this, you can attach a buffer before ack_configure, just has to happen after the configure event.
16:55bwidawsk: hmm, also says: ` The client must acknowledge it and is then allowed to attach a buffer to map the surface.`
16:56bwidawsk: but that is only after setting the role
16:57bwidawsk: I suppose maybe it doesn't make sense to attach a buffer to an xdg surface that has no role, but it doesn't seem to be disallowed
16:58vyivel: tbh the wording isn't perfect there wrt. attaching and actually committing a buffer
16:58bwidawsk: ah also: ` A role must be assigned before any other requests are made to the xdg_surface object.`
16:59bwidawsk: so attaching a buffer would fail for that reason
16:59bwidawsk: though it's unclear what failure should occur
16:59vyivel: not_constructed?
17:00zamundaaa[m]: ifreund: kwin doesn't do a wl_touch.frame either, so I think that's right. Documenting that as a rule would indeed be good
17:00bwidawsk: well, the compositor I'm testing doesn't seem to obey this anyway
17:01vyivel: you mean it allows to attach a buffer?
17:01bwidawsk: I don't seem to get an error
17:01vyivel: i don't think anyone checks for specifically that
17:01bwidawsk: https://gitlab.freedesktop.org/bwidawsk/way-assay/-/blob/main/tests/tests/xdg/basic.rs?ref_type=heads#L16
17:02bwidawsk: well, this was written against Weston, I believe, but I didn't write this test
17:02vyivel: fairly sure wlroots would complain about this
17:05wlb: wayland Merge request !374 opened by Isaac Freund (ifreund) wl_touch.cancel: document lack of frame event https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/374
17:05bwidawsk: in this specific test, no request is issued against the xdg surface, so I actually think this test should pass
17:07vyivel: > any attempts by a client to attach or manipulate a buffer prior to the first xdg_surface.configure call must also be treated as errors
17:07bwidawsk: but the server doesn't need to actually send configure until roundtrip, right?
17:07bwidawsk: if that said `ack_configure` I think we'd be in business
17:07vyivel: the server doesn't (shouldn't) send a configure until an initial commit
17:09vyivel: but yeah, create xdg surface => create xdg surface role object (e.g. xdg_toplevel) => commit without a buffer (initial commit) => wait for configure => ack_configure => attach buffer => commit
17:09vyivel: skipping anything should result in an error
17:09bwidawsk: vyivel: yeah, okay, I agree. If there were a roundtrip before attach, it (I think) would be compliant
17:10vyivel: a compositor isn't guaranteed to send a configure event within roundtrip i'm pretty sure
17:10vyivel: like, it might decide that it doesn't want to show the surface right now and therefore doesn't have a suitable size for it
17:11bwidawsk: the this is a poor test for that reason
17:11bwidawsk: s/the/then
17:12bwidawsk: a compliant compositor may never send a configure...
17:12bwidawsk: interesting realization
17:12vyivel: fwiw most of them do
17:13vyivel: do send immediately after an initial commit, that is
17:13bwidawsk: yeah
17:15bwidawsk: that's kind of an unfortunate situation from a conformance perspective
20:34wlb: weston Issue #893 opened by Łukasz Adamczak (czak) First wl_surface_commit after unmapping doesn't trigger xdg_surface_configure https://gitlab.freedesktop.org/wayland/weston/-/issues/893
22:17wlb: weston Merge request !1479 opened by Jordan Williams (jwillikers) meson: Add missing dependencies on egl https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1479