00:15orowith2os: yeah, Cinnamon currently has no plans to support Wayland, on account of not having enough developers and NVIDIA being... annoying
04:16kchibisov: Is it correct that diff between timestamps is in milliseconds (I know it says it's in milliseconds granularity)?
04:17kchibisov: So for example if I diff 2 wl_pointer.button timestamps I get a time in milliseconds between them.
06:52emersion: yeah i think so
06:55kennylevinsen: wl_pointer.button specifically says millisecond timestamp
07:17luks2[m]: anybody have any experience getting tor browser to work with wayland? following the guide on the tor browser when i run $ ./start-tor-browser.desktop --verbose ; I get the following:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/VMTXXapECdWvKVPRVFMwYMgI>)
07:22kchibisov: kennylevinsen: I just think that I'm getting weird logs from the user. Like their libipunt debug events deltas are around 200-300ms, then the wayland log has seconds between some events. Maybe they just took them separatelly...
07:23kchibisov: And the lowest amount in wayland log is 370ms, while in libinput it was 150ms.
07:23kchibisov: Though, I have to explicitly go through the all events and find ms delta, because most were in seconds, so I got confused.
07:24emersion: what do you mean by "most are in seconds"?
07:24emersion: AFAIK everything is ms
07:26kchibisov: I mean, delta.
07:26kchibisov: Like if you take 2 button timestamps you get 10000.
07:26psykose: luks2[m]: your gtk3 on gentoo is compiled without x11 support but the prebuilt binary links a symbol from that
07:26kchibisov: So I though, maybe it was micros or something by accedent...
07:27luks2[m]: psykose: so gtk3 needs to have the X use flag for tor browser to work?
07:27kchibisov: Maybe their touchpad is just slow, but it's weird that in libinput log they have delta around 200ms and then in wayland logs they have lowest possible 380ms.
07:27kchibisov: it's like gnome added 200ms latency for them.
07:28psykose: luks2[m]: i already said that, yes
07:35luks2[m]: didn't even have gtk installed
07:39pH5: daniels: My understanding is that a transfer-write-before-shader-read image memory barrier should be enough to take care of that.
07:39pH5: daniels: I'll have a look at converting ivi-shell.
07:42daniels: pH5: nice, thankyou £
08:08luks2[m]: i recompiled gtk with the X useflag and now this is what happens... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/hrEvFVTVhzWxfziVDWPCADzo>)
08:50pq: Ermine, no, you can ask to participate, but the public invite emails don't contain the direct link to the meeting to avoid flooding the call.
08:55pq: that said, I wonder if the concern of too many people is founded - maybe they should try a couple times
08:57pq: kchibisov, you are aware that WAYLAND_DEBUG protocol dumps use CLOCK_REALTIME and input timestamps are generally CLOCK_MONOTONIC, right?
08:58kchibisov: pq: I was used timestamps for the button event.
08:58kchibisov: Not whatever wayland debug writes.
08:58kchibisov: I'd expecet button timestamps to be MONOTONIC.
08:59kchibisov: wl_pointer@28.button(440638, 228169719, 272, 1)
08:59kchibisov: I've used ^
08:59pq: protocol dumps use microseconds, and IIRC the basic input events use millisecond, but then there is the input-timestamps extension offering nanosecond ganularity
09:00kchibisov: Though, in my case the diff matched the wayland debug, which I found weird.
09:00kchibisov: Since I've expected the timestamp to be from libinput or something.
09:01pq: input event timestamps should come from the kernel directly with the events, which means either the kernel stamps them or they come from the input hardware
09:01pq: of course, I don't know what Mutter does
09:01kchibisov: I just feel like the user gave me logs from different stuff. Because libinput was twice as fast in their logs.
09:02pq: yeah, who knows
09:02kchibisov: And mutter timestamps matched wayland ones for whatever reason.
09:02kchibisov: diff*
09:02pq: that is odd
09:02pq: oh diff
09:02pq: sure
09:04pq: The protocol dump timestamps are taken when the message is printed, not when it's sent/received or crosses socket. If the timestamp diff matches the input event timestamp diff, that's a good thing.
09:05pq: it means delivery latency is constant
09:05kchibisov: It could be that someone took a time right when sending event though.
09:05pq: the kernel might do that, or mutter might do that, yeah
09:05kchibisov: While it's good for consistency, the user can't reach 400ms to trigger double clicks.
09:06pq: but if all delivery is as fast as it should, you can't tell who stamped it
09:06kchibisov: Since in libinput they have 200ms diffs, but on button events they have 380ms.
09:06pq: I thought you said the diffs match
09:07kchibisov: I've said that wayland debug diffs matched button timestamps diffs.
09:07kchibisov: But libinput diffs were twice lower.
09:07pq: interesting
09:07kchibisov: from libinput debug-events.
09:07pq: extremely heavy mutter extensions in use?
09:08kchibisov: I'm not sure, I could ask them :p
09:08kchibisov: But only when they use touchpad.
09:08kchibisov: With mouse they don't have such issue.
09:08pq: huh
09:09kchibisov: https://github.com/alacritty/alacritty/issues/7011#issuecomment-1633536576
09:09kchibisov: I've removed `HOLD_END`, though, maybe button press with touchpad registered on end...
09:10kchibisov: But the diff between hold begin and end usually 20ms.
09:10kchibisov: So it doesn't matter, it's still way less that 370ms.
09:11pq: I guess it kinda needs to, to make the difference between a tap and another gesture, because pointer protocol has no cancel event, does it?
09:12pq: if other gestures are possible
09:12kchibisov: Yeah, it should debounce of some sort.
09:12kchibisov: Though, If I accound end, it'll be 240ms avg.
09:15pq: kchibisov, did you notice that wayland log ha multiple different wl_pointer objects?
09:15pq: *has
09:15kchibisov: I know.
09:15kchibisov: That's expected.
09:16kchibisov: I've computed only based on a pointer which was actually used by logic that done double clicks.
09:16pq: multiple wl_seats?
09:16kchibisov: It's more like we have a clipboard separatelly running.
09:16kchibisov: on its own thread.
09:16pq: who is "we"?
09:16kchibisov: we -> alacritty.
09:17pq: so they each bind to a different wl_seat global?
09:17kchibisov: yes, they should.
09:17pq: really? Mutter exposes multiple wl_seats?
09:18kchibisov: Well, I guess we just create miltiple objects.
09:18pq: I mean literally different globals, not just bind twice the same global.
09:18kchibisov: No, we bind twice the same global.
09:18pq: in that case the wayland log makes no sense to me
09:19kchibisov: I could give you the log I have on sway.
09:19kchibisov: Just from startup.
09:19pq: oh wait, threads
09:19kchibisov: threads.
09:19pq: and printing the dispatching, this is not the wire sequence, yes
09:19pq: ok
09:20pq: no thanks, I shouldn't be looking at this really
09:20kchibisov: yeah, I don't want to look either. I'll plumb the input timestamps to all calculations and call it a day.
09:20pq: I don't seem to have anything to add here
09:22kchibisov: I know for sure that once we had 300ms they weren't able to trigger double click at all.
09:22kchibisov: And 400ms was taken from gtk4, which bumped it from 250ms since gtk2.
10:35pq: That "Wayland device tree" proposal feels very much non-Wayland to me.
10:36jadahl: pq: +1
10:37jadahl: there are also some inaccuracies in the motivation for needing it
10:37pq: I don't think I can afford to write a rebuttal, though.
10:37jadahl: I didn't have the strength last night, maybe later
11:24kennylevinsen: I am not sure if there is a real UX reason to differentiate between e.g. touchpad and mouse in the first place. Why should I not be able to flick with my mouse? :/
11:26kennylevinsen: Handling touchpad gestures is a real need for some use-cases (e.g., handwriting CJK input), but that's separate
11:27pq: yes
11:30wlb: weston Issue #777 opened by sdikshit786 (sdikshit786) [BUG]Unable to differentiate connectors by their name when displays are identical https://gitlab.freedesktop.org/wayland/weston/-/issues/777
11:31jadahl: yea, abs touchpad mode is a different beast. we've talked about it forever, but there is still no remotely usable CJK handwriting input method to hook it into
11:34kchibisov: jadahl: where does mutter get timestamps from for input events?
11:34jadahl: kchibisov: from libinput
11:35kchibisov: ¯\_(ツ)_/¯
11:35kchibisov: maybe libinput log I had is weird then.
11:35jadahl: maybe because libinput timestamps are us, while the wayland ones ar ms?
11:36kchibisov: They print time in seconds, I mean libinput debug-events.
11:36jadahl: aha
11:36kchibisov: And tell them in 1.1s
11:37jadahl: iirc the only time we dream up our own timestamps from the monotonic clock is for fake input events e.g. from vnc/rdp
11:38kchibisov: It just doesn't make sense that mutter timestamps diffs were ~2x of libinput.
11:43jadahl: only for touchpads?
11:46kchibisov: from their words.
11:47jadahl: kchibisov: could it be that libinput debug-events show timestamps relative to the time it started, and the debug shows them relative to the monotonic clock?
11:47kchibisov: But I compare the diff.
11:47kchibisov: So it doesn't matter.
11:47jadahl: diff between what?
11:48kchibisov: The issue is that delta between button presses and delta between GESTURE_HOLD_END is 2x difference.
11:48kchibisov: I'd ask them for interleaved log from both wayland and libinput though.
11:49jadahl: for gestures, there are magic stuff going on, but the timestamp are directly from libinput
11:49kchibisov: Well, they have gestures due to tap to click.
11:49jadahl: it's all from libinput_event_gesture_get_time_usec() and similar ones
11:49kchibisov: I know that on sway I have the deltas matching on my hardware.
11:53kchibisov: I'll direct the log to mutter bug tracker if it expose something strange, because the user started from the mutter bug tracker and then came to me.
11:53kchibisov: And then maybe it'll go to libinput or kernel, because I can't believe that they can't click under 400ms.
12:35jadahl: kchibisov: random thought, could it be difference in tap-to-click settings?
12:36kchibisov: Does libinput/gnome even allows them to be changed somehow?
12:36kchibisov: I thought it's just a bool?
12:36jadahl: yes, you can enable/disable tap-to-click
12:36jadahl: its a libinput device setting
12:37kchibisov: I know, but what difference are you talking about?
12:37jadahl: to get similar enough device events, you need to run libinput debug-events with matching configuration
12:37jadahl: there are timeouts relevant for tap-ta-click IIRC
12:37kchibisov: Hm, that's true, I guess.
15:36wlb: wayland Issue #395 opened by Naim Chowdhury (NaimChowdhury) xwayland applications blurry and qt renders incorrectly https://gitlab.freedesktop.org/wayland/wayland/-/issues/395
15:38wlb: wayland Issue #395 closed \o/ (xwayland applications blurry and qt renders incorrectly https://gitlab.freedesktop.org/wayland/wayland/-/issues/395)
15:40wlb: wayland Issue #396 opened by Naim Chowdhury (NaimChowdhury) Computer hard crashes when TV goes to sleep https://gitlab.freedesktop.org/wayland/wayland/-/issues/396
15:41wlb: wayland Issue #396 closed \o/ (Computer hard crashes when TV goes to sleep https://gitlab.freedesktop.org/wayland/wayland/-/issues/396)
15:44wlb: weston Merge request !1316 opened by Philipp Zabel (pH5) hmi-controller: Fix hmi_controller_destroy() when called from hmi_controller_create() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1316
16:50rahl: I'm using the linked script to run a shell with a secondary user, retaining gui access https://termbin.com/86xi
16:51rahl: But when the second user runs e.g. `wl-copy` I get "Failed to connect to wayland server"
16:52rahl: I figured it would be a permissions issue, on the /run/usr/1000 directory; tried giving group access to it, but no luck
16:53rahl: running dwl on artix, attempting only wayland but almost immediately had to set up xwayland as well
17:51wlb: weston Merge request !1317 opened by Philipp Zabel (pH5) ivi-shell: Automatically schedule view repaints on property changes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1317