ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
natewrench has joined #wayland
natewrench has quit []
tent405 has quit [Ping timeout: 480 seconds]
tawonga1 has quit [Quit: WeeChat 4.0.0]
tawonga has joined #wayland
<orowith2os>
yeah, Cinnamon currently has no plans to support Wayland, on account of not having enough developers and NVIDIA being... annoying
tawonga has quit []
epony has quit [Remote host closed the connection]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
kabaka has joined #wayland
kabaka is now known as Guest5815
MrCooper_ has joined #wayland
MrCooper has quit [Read error: Connection reset by peer]
Brainium has quit [Quit: Konversation terminated!]
Fxzxmic has joined #wayland
carlos_ has quit [Ping timeout: 480 seconds]
Guest5519 has quit [Remote host closed the connection]
cool110 has joined #wayland
cool110 is now known as Guest5828
rv1sr has joined #wayland
Plasm0duck has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
<kchibisov>
Is it correct that diff between timestamps is in milliseconds (I know it says it's in milliseconds granularity)?
<kchibisov>
So for example if I diff 2 wl_pointer.button timestamps I get a time in milliseconds between them.
<kchibisov>
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...
<kchibisov>
And the lowest amount in wayland log is 370ms, while in libinput it was 150ms.
<kchibisov>
Though, I have to explicitly go through the all events and find ms delta, because most were in seconds, so I got confused.
<emersion>
what do you mean by "most are in seconds"?
<emersion>
AFAIK everything is ms
<kchibisov>
I mean, delta.
<kchibisov>
Like if you take 2 button timestamps you get 10000.
<psykose>
luks2[m]: your gtk3 on gentoo is compiled without x11 support but the prebuilt binary links a symbol from that
<kchibisov>
So I though, maybe it was micros or something by accedent...
<luks2[m]>
psykose: so gtk3 needs to have the X use flag for tor browser to work?
<kchibisov>
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.
<kchibisov>
it's like gnome added 200ms latency for them.
<psykose>
luks2[m]: i already said that, yes
<luks2[m]>
didn't even have gtk installed
<pH5>
daniels: My understanding is that a transfer-write-before-shader-read image memory barrier should be enough to take care of that.
<pH5>
daniels: I'll have a look at converting ivi-shell.
<pq>
protocol dumps use microseconds, and IIRC the basic input events use millisecond, but then there is the input-timestamps extension offering nanosecond ganularity
<kchibisov>
Though, in my case the diff matched the wayland debug, which I found weird.
<kchibisov>
Since I've expected the timestamp to be from libinput or something.
<pq>
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
<pq>
of course, I don't know what Mutter does
<kchibisov>
I just feel like the user gave me logs from different stuff. Because libinput was twice as fast in their logs.
<pq>
yeah, who knows
<kchibisov>
And mutter timestamps matched wayland ones for whatever reason.
<kchibisov>
diff*
<pq>
that is odd
<pq>
oh diff
<pq>
sure
<pq>
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.
<pq>
it means delivery latency is constant
<kchibisov>
It could be that someone took a time right when sending event though.
<pq>
the kernel might do that, or mutter might do that, yeah
<kchibisov>
While it's good for consistency, the user can't reach 400ms to trigger double clicks.
<pq>
but if all delivery is as fast as it should, you can't tell who stamped it
MrCooper_ is now known as MrCooper
<kchibisov>
Since in libinput they have 200ms diffs, but on button events they have 380ms.
<pq>
I thought you said the diffs match
<kchibisov>
I've said that wayland debug diffs matched button timestamps diffs.
<kchibisov>
But libinput diffs were twice lower.
<pq>
interesting
<kchibisov>
from libinput debug-events.
<pq>
extremely heavy mutter extensions in use?
<kchibisov>
I'm not sure, I could ask them :p
<kchibisov>
But only when they use touchpad.
<kchibisov>
With mouse they don't have such issue.
<kchibisov>
I've removed `HOLD_END`, though, maybe button press with touchpad registered on end...
<kchibisov>
But the diff between hold begin and end usually 20ms.
<kchibisov>
So it doesn't matter, it's still way less that 370ms.
<pq>
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?
<pq>
if other gestures are possible
<kchibisov>
Yeah, it should debounce of some sort.
<kchibisov>
Though, If I accound end, it'll be 240ms avg.
<pq>
kchibisov, did you notice that wayland log ha multiple different wl_pointer objects?
<pq>
*has
<kchibisov>
I know.
<kchibisov>
That's expected.
<kchibisov>
I've computed only based on a pointer which was actually used by logic that done double clicks.
<pq>
multiple wl_seats?
<kchibisov>
It's more like we have a clipboard separatelly running.
<kchibisov>
on its own thread.
<pq>
who is "we"?
<kchibisov>
we -> alacritty.
<pq>
so they each bind to a different wl_seat global?
<kchibisov>
yes, they should.
<pq>
really? Mutter exposes multiple wl_seats?
<kchibisov>
Well, I guess we just create miltiple objects.
<pq>
I mean literally different globals, not just bind twice the same global.
<kchibisov>
No, we bind twice the same global.
<pq>
in that case the wayland log makes no sense to me
<kchibisov>
I could give you the log I have on sway.
<kchibisov>
Just from startup.
<pq>
oh wait, threads
<kchibisov>
threads.
<pq>
and printing the dispatching, this is not the wire sequence, yes
<pq>
ok
<pq>
no thanks, I shouldn't be looking at this really
<kchibisov>
yeah, I don't want to look either. I'll plumb the input timestamps to all calculations and call it a day.
<pq>
I don't seem to have anything to add here
<kchibisov>
I know for sure that once we had 300ms they weren't able to trigger double click at all.
<kchibisov>
And 400ms was taken from gtk4, which bumped it from 250ms since gtk2.
Lucretia has joined #wayland
cmichael has joined #wayland
MrCooper has quit [Remote host closed the connection]
fmuellner has joined #wayland
MrCooper has joined #wayland
gilvbp has joined #wayland
<pq>
That "Wayland device tree" proposal feels very much non-Wayland to me.
nerdopolis has joined #wayland
<jadahl>
pq: +1
<jadahl>
there are also some inaccuracies in the motivation for needing it
<pq>
I don't think I can afford to write a rebuttal, though.
<jadahl>
I didn't have the strength last night, maybe later
carlos_ has joined #wayland
kts has joined #wayland
<kennylevinsen>
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? :/
jmdaemon has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Handling touchpad gestures is a real need for some use-cases (e.g., handwriting CJK input), but that's separate
<jadahl>
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
<kchibisov>
jadahl: where does mutter get timestamps from for input events?
<jadahl>
kchibisov: from libinput
<kchibisov>
¯\_(ツ)_/¯
<kchibisov>
maybe libinput log I had is weird then.
<jadahl>
maybe because libinput timestamps are us, while the wayland ones ar ms?
<kchibisov>
They print time in seconds, I mean libinput debug-events.
<jadahl>
aha
<kchibisov>
And tell them in 1.1s
<jadahl>
iirc the only time we dream up our own timestamps from the monotonic clock is for fake input events e.g. from vnc/rdp
<kchibisov>
It just doesn't make sense that mutter timestamps diffs were ~2x of libinput.
<jadahl>
only for touchpads?
<kchibisov>
from their words.
<jadahl>
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?
<kchibisov>
But I compare the diff.
<kchibisov>
So it doesn't matter.
<jadahl>
diff between what?
<kchibisov>
The issue is that delta between button presses and delta between GESTURE_HOLD_END is 2x difference.
<kchibisov>
I'd ask them for interleaved log from both wayland and libinput though.
<jadahl>
for gestures, there are magic stuff going on, but the timestamp are directly from libinput
<kchibisov>
Well, they have gestures due to tap to click.
<jadahl>
it's all from libinput_event_gesture_get_time_usec() and similar ones
<kchibisov>
I know that on sway I have the deltas matching on my hardware.
<kchibisov>
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.
<kchibisov>
And then maybe it'll go to libinput or kernel, because I can't believe that they can't click under 400ms.
<jadahl>
kchibisov: random thought, could it be difference in tap-to-click settings?
<kchibisov>
Does libinput/gnome even allows them to be changed somehow?
<kchibisov>
I thought it's just a bool?
<jadahl>
yes, you can enable/disable tap-to-click
<jadahl>
its a libinput device setting
<kchibisov>
I know, but what difference are you talking about?
<jadahl>
to get similar enough device events, you need to run libinput debug-events with matching configuration
<jadahl>
there are timeouts relevant for tap-ta-click IIRC
<kchibisov>
Hm, that's true, I guess.
natewrench has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
natewrench has left #wayland [#wayland]
nehsou^ has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
MrCooper has quit [Remote host closed the connection]
kts has joined #wayland
gilvbp has quit [Quit: Connection closed for inactivity]
overholts has joined #wayland
epony has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]