ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Brainium has quit [Quit: Konversation terminated!]
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
kelnos has quit [Remote host closed the connection]
kelnos has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
Leopold has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Elliu has joined #wayland
Elliu has left #wayland [#wayland]
louisg has joined #wayland
kts has quit [Quit: Konversation terminated!]
cool110 has joined #wayland
cool110 is now known as Guest2814
Guest2776 has quit [Remote host closed the connection]
Leopold__ has joined #wayland
Leopold has quit [Ping timeout: 480 seconds]
Company has joined #wayland
silverpower has quit [Ping timeout: 480 seconds]
silverpower has joined #wayland
mxz has joined #wayland
glennk has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
It seems that sometimes scroll events with XWayland just get dropped?
<JoshuaAshton>
I replaced the code in my Wayland compositor to instead call XTestFakeButtonEvent with 4/5 and that consistently works
<JoshuaAshton>
It's really strange...
<JoshuaAshton>
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?
<JoshuaAshton>
I should probably dig deeper into XServer to see what's going on but sleepy...
<JoshuaAshton>
FTR I am also testing specifically with Chromium which may also be doing something weird as usual :D
caveman has joined #wayland
rv1sr has joined #wayland
<Consolatis>
xev might be more appropriate for testing
Leopold__ has quit [Ping timeout: 480 seconds]
<Consolatis>
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
<Consolatis>
(on labwc that is)
<JoshuaAshton>
Lemme try xev in Gamescope...
<JoshuaAshton>
Hmmm, xev seems to give the right stuff for me with the XWayland scroll stuff
<JoshuaAshton>
Maybe Chrome is doing something with XInput2 and the more fine scroll stuff there?
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
leon-anavi has joined #wayland
kts has joined #wayland
<JoshuaAshton>
Consolatis: If you launch labwc nested rn, launch chromium, go to a page like asdasdhjkasdhjk, your first scroll event should always be dropped
<JoshuaAshton>
WAYLAND_DISPLAY= chromium
Leopold_ has joined #wayland
<JoshuaAshton>
I have that with 100% consistency
<Consolatis>
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
<JoshuaAshton>
I should boot into a real X server and see if it repros there too....
<JoshuaAshton>
ofourdan: Latest master and whatever latest release in my pkg mgr
<ofourdan>
iiuc, it's only the first event that gets dropped? That sounds like a valuator issue…
<JoshuaAshton>
ofourdan: That event is dropped in chrome always, even on regular X11 :S
<ofourdan>
ah
<JoshuaAshton>
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.
<JoshuaAshton>
For now I've just added some XTestFakeButtonEvent jank code to avoid going through the device/valuator path :/
<ofourdan>
well, that code (dix) is common between all xservers, so a possible bug there could affect the plain Xorg server as well.
<JoshuaAshton>
Going back to old xwayland before that MR doesn't help so eh.
<JoshuaAshton>
welp
<nmeum>
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?
<ofourdan>
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 :)
<ofourdan>
*doubt
<ofourdan>
*sounds
<ofourdan>
grr, friday typos! :(
<JoshuaAshton>
It seems almost like a timing thing :/
<JoshuaAshton>
Like it's totally random if Chrome likes my scrolls
<davidre>
nmeum: I think it means that you destroyed the wl_registry
<davidre>
Since you have no alive proxy libwayland discards the event
<nmeum>
yea, also just figured that out. it is in fact the bug in my code i was looking for ':D
<nmeum>
thanks!
mart has joined #wayland
tombl has joined #wayland
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #wayland
<JoshuaAshton>
ofourdan: oooo I found something weird....
<JoshuaAshton>
If I send axis events with 0's on frames the scroll wheel does nothing it fixes it...
garnacho has joined #wayland
<JoshuaAshton>
Ah
<JoshuaAshton>
XWayland reaaalllly hates it if I don't send both X and Y if one of them is 0
<JoshuaAshton>
That seems to be the big culprit here
<JoshuaAshton>
Really strange
<ofourdan>
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.
mblenc has joined #wayland
Guest2814 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest2826
<pq>
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.
phryk has quit []
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
kts has quit [Quit: Konversation terminated!]
phryk has joined #wayland
Hypfer has joined #wayland
Hypfer1 has quit [Ping timeout: 480 seconds]
Hypfer is now known as Hypfer1
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
phryk has quit []
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
fmuellner has joined #wayland
Brainium has joined #wayland
kts has joined #wayland
cmichael has joined #wayland
manuel1985 has joined #wayland
manuel1985 has quit []
<pq>
swick[m], are you using some kind of linter and link checked with color-and-hdr?
<pq>
*checker
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
azerov has quit []
azerov has joined #wayland
<swick[m]>
no, it seemed faster to just do the work than trying to set up tooling for it
<swick[m]>
but we probably should add something to CI
<swick[m]>
but this obviously fails with all the relative links in the repo
<pq>
d'oh
<swick[m]>
oh wait, it's a bit smart
<swick[m]>
it's just the links with only a fragment that fail
<swick[m]>
that should be trivial to fix
phryk has joined #wayland
<swick[m]>
blergh, it's a regression in the latest release
<swick[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
mblenc has joined #wayland
mblenc1 has quit [Remote host closed the connection]
mblenc has quit [Read error: Connection reset by peer]
mblenc has joined #wayland
junaid has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
radu24284303951534727071489559 has quit []
radu24284303951534727071489559 has joined #wayland
radu24284303951534727071489559 has quit []
kts has joined #wayland
radu24284303951534727071489559 has joined #wayland
<swick[m]>
pq: all done, and it found a few issues
radu24284303951534727071489559 has quit []
radu24284303951534727071489559 has joined #wayland
radu24284303951534727071489559 has quit []
radu24284303951534727071489559 has joined #wayland
radu24284303951534727071489559 has quit []
<pq>
swick[m], awesome, thanks for adding the CI stuff! I was just curious if you used any personally. :-D
radu24284303951534727071489559 has joined #wayland
radu24284303951534727071489559 has quit []
radu24284303951534727071489559 has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
radu24284303951534727071489559 has quit [Ping timeout: 480 seconds]
<ifreund>
what exactly does LIBINPUT_EVENT_TOUCH_CANCEL mean?
<ifreund>
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
<ifreund>
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
kts has joined #wayland
Fxzxmic has joined #wayland
rolf has quit []
<ifreund>
I'm starting to think that LIBINPUT_EVENT_TOUCH_CANCEL should be handled exactly the same LIBINPUT_EVENT_TOUCH_UP...
<zamundaaa[m]>
No, it should not
<zamundaaa[m]>
You should just send a wl_touch.cancel to clients
<zamundaaa[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
<ifreund>
zamundaaa: I still don't understand the semantic meaning of the LIBINPUT_EVENT_TOUCH_CANCEL event...
<ifreund>
it didn't seem to be related at all to the semantics of the wl_touch.cancel event from reading the libinput code
<zamundaaa[m]>
Both mean the same thing: "discard the touch points"
<ifreund>
ok, the libinput event only discards a single touch point but the wayland protocol event cant represent that
<ifreund>
I see what you mean about sending touch up in this case being wrong, thanks
<ifreund>
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
<zamundaaa[m]>
Yeah, I wondered about fixing that in Wayland before too, but in practice discarding all of them is fine
mblenc1 has joined #wayland
mblenc has quit [Remote host closed the connection]
<ifreund>
am I correct that the wl_touch.cancel event is not followed by a wl_touch.frame event?
<ifreund>
this seems to be what wlroots implements at least but it would be good to explicity state in the protocol
Company has quit [Ping timeout: 480 seconds]
Fxzxmic has quit [Quit: Konversation exit!]
junaid has quit [Quit: Lost terminal]
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<bwidawsk>
`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.
<bwidawsk>
hmm, also says: ` The client must acknowledge it and is then allowed to attach a buffer to map the surface.`
<bwidawsk>
but that is only after setting the role
<bwidawsk>
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
<vyivel>
tbh the wording isn't perfect there wrt. attaching and actually committing a buffer
<bwidawsk>
ah also: ` A role must be assigned before any other requests are made to the xdg_surface object.`
<bwidawsk>
so attaching a buffer would fail for that reason
<bwidawsk>
though it's unclear what failure should occur
<vyivel>
not_constructed?
<zamundaaa[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
<bwidawsk>
well, the compositor I'm testing doesn't seem to obey this anyway
<vyivel>
you mean it allows to attach a buffer?
<bwidawsk>
I don't seem to get an error
<vyivel>
i don't think anyone checks for specifically that