Fix X11 touchpad scrolling in elastic views - #339
Conversation
Normalize smooth wheel input while preserving ordinary wheel behavior; retain fractional deltas and report the visible viewport to QScroller.
|
|
||
| constexpr auto kDefaultWheelScrollLines = 3; | ||
| constexpr auto kMagicScrollMultiplier = 2.5; | ||
| constexpr auto kX11SmoothScrollMultiplier = 5.; |
There was a problem hiding this comment.
Why exactly that multilplier?
There was a problem hiding this comment.
I had tested different, this one make it works acceptable enough.
| x11Touchpad = e->device() | ||
| && e->device()->type() == base::TouchDevice::TouchPad; | ||
| #endif // Qt >= 6.0.0 | ||
| const auto x11Smooth = !touch |
There was a problem hiding this comment.
Why the current capability check doesn't suffice?
There was a problem hiding this comment.
Before your change, it was checking for e->device()->capabilities().testFlag(PixelScroll). This capability could be ever set only on a touchpad, it also replaces the !pixelDelta.isNull() check. I don't see what we get with an explicit check for a touchpad + !pixelDelta.isNull() but I see that it will lead to bugs on Wayland (it could return a null QPoint due to rounding which is compensated in the next frame).
| const auto x11Smooth = !touch | ||
| && ::Platform::IsX11() | ||
| && (pixelInput || !pixelDelta.isNull() || x11Touchpad); | ||
| if (x11Smooth && !angleDelta.isNull()) { |
There was a problem hiding this comment.
You're requiring both pixel delta and angle delta to be not null for the angle delta codepath?
| * kX11SmoothScrollMultiplier) | ||
| / float64(QWheelEvent::DefaultDeltasPerStep); | ||
| } | ||
| if (pixelInput || (x11Smooth && !pixelDelta.isNull())) { |
There was a problem hiding this comment.
You already checked pixelDelta in the x11Smooth check?
There was a problem hiding this comment.
What is copy and paste issue and side effect from iterated development of that patch to actually fix the scroll, and you are right that || condition never reached.
Before I address it and possible other review point, I'd like to understand do you at least consider to merge that fix in some way?
There was a problem hiding this comment.
That's a very hard question since generally I'm not opposed to fixes but the current feeling from the patch is that it masks some bug in OpenBSD input driver and when we decompose the patch to the real fix it could be that we would need either of two:
- A fix in OpenBSD code
- An explicit check for OpenBSD in tdesktop code to work around the OpenBSD bug
But I could be wrong of course so I have no idea what the end result will be. I propose to check the behavior on last tdesktop version without any patch firstly since it feels the patch was rebased a lot of times and not checked whether it's (or at least all parts of it) still needed.
There was a problem hiding this comment.
Yes, this patch was origianlly made for tdesktop 7.0.6, and after that was "rebased" to current master and tested by 64gram's port which was made by @nazarenkomykyta and I think he used patch from that PR.
I not sure that it is unique OpenBSD bug, because, as I said, NetBSD comunity had shared same issues.
Also, before recent update of tdesktop port 6.9.3 -> 7.0.6 I had issue with scroll only on contact / chat list, and not in chat messages. I had it for I think like a year (or longer, not sure) but I wasn't motivated enough to dig it.
Also, original (unpatched) version hasn't got scroll issue out of the box. It needs many contacts / chats in folder and it works well with few of them. And the same with chat. When I created a new group chat, here no scroll issue, but after some contetn it started to appears, and more messages in chat makes it worse.
There was a problem hiding this comment.
I don't know much about BSDs but I assume OpenBSD and NetBSD could share the same driver code?
There was a problem hiding this comment.
Some? Yes. Probably https://man.openbsd.org/wscons.4 and friends is more or less similar, but I have no idea how similarity has.
| } | ||
| if (pixelInput || (x11Smooth && !pixelDelta.isNull())) { | ||
| return (::Platform::IsX11() && !touch | ||
| ? QPointF(pixelDelta) |
There was a problem hiding this comment.
You're breaking scrolling with scaling for X11 users
There was a problem hiding this comment.
I'm doubt you reach that line at all so I don't think you see the consequences of this change. Can you confirm you actually reach it?
There was a problem hiding this comment.
You're breaking scrolling with scaling for X11 users
You broke the whole scroll using ElasticScroll() on Xenocara, ironic...
There was a problem hiding this comment.
Why? What's the problem with it on Xenocara?
There was a problem hiding this comment.
I assume you tested it on Wayland because usual Linux uses it
The userbase is so high that a bug here will lead to a high stream of issues even from X11 users. In fact when ElasticScroll was just made, there were complaints from users of all platforms, including X11-specific ones. There were multiple rounds of fixes until complaints stopped.
There was a problem hiding this comment.
Well, it doesn't work on OpenBSD and NetBSD (to my knwoledge). But I think nobody reported it to you. So, I think assumption that here will be a lot of complains is not true.
There was a problem hiding this comment.
I was talking solely about Linux, that it couldn't be broken on Linux with X11 and there be no mass reporting. I don't doubt that there's not much users on BSDs to get reports, especially given the lack of official builds.
There was a problem hiding this comment.
Well, I think majority of Linux users are moved to Wayland which default options at Fedora, Ubuntu and so on.
There was a problem hiding this comment.
There's still enough Linux X11 users. You can see an issue opened by Xwayland user just 5 hours ago and two PRs opened yesterday from a real X11 user (not Xwayland), one of them already merged though. And then periodically I see reports from users on ancient Debian/Devuan and X11 of course.
| if (phase == Qt::ScrollBegin) { | ||
| _wheelDeltaRemainder = {}; | ||
| } | ||
| auto exactPixels = ScrollDeltaF(e, touch); |
There was a problem hiding this comment.
Yes, it does, and I fight here rounding by moving to float.
There was a problem hiding this comment.
You mean the same what was done in #324? Author then concluded that subpixel scroll makes things feel worse and left just the main thread offload in telegramdesktop/tdesktop#31023 (telegramdesktop/tdesktop@4bf51f6 is the commit from the older version of the PR to make use of #324)
There was a problem hiding this comment.
Yes, and I'd like to say that current patch hasn't make scroll ideal. It is not that bad, but not ideal.
And, frankly, ElasticScroll logic is very complicated / tricky, so, yes, I can broke something somewhere and probably it can be made better.
Which input do you need to make sane investigation from scratch?
There was a problem hiding this comment.
Personally I have no idea what could go wrong on OpenBSD. But I tried to feed your PR to Claude and it confirmed my suspicions about driver bug in OpenBSD, even proposed a patch to it (xenocara/driver/xf86-input-ws/src/ws.c):
- SetScrollValuator(pWS, HSCROLL_AXIS, SCROLL_TYPE_HORIZONTAL, 4096, 0);
- SetScrollValuator(pWS, VSCROLL_AXIS, SCROLL_TYPE_VERTICAL, 4096, 0);
+ SetScrollValuator(pWS, HSCROLL_AXIS, SCROLL_TYPE_HORIZONTAL, 120, 0);
+ SetScrollValuator(pWS, VSCROLL_AXIS, SCROLL_TYPE_VERTICAL, 120, 0);
if (hw.hscroll || hw.vscroll) {
valuator_mask_zero(priv->scroll_mask);
valuator_mask_set_double(priv->scroll_mask,
- HSCROLL_AXIS, (double) hw.hscroll);
+ HSCROLL_AXIS, hw.hscroll * 120.0 / 4096.0);
valuator_mask_set_double(priv->scroll_mask,
- VSCROLL_AXIS, (double) hw.vscroll);
+ VSCROLL_AXIS, hw.vscroll * 120.0 / 4096.0);
But it also said that the current tdesktop version shouldn't be affected by it (7.0.6 still does).
There was a problem hiding this comment.
Maybe it compiles but fido won't actually work that way....
There was a problem hiding this comment.
Maybe it compiles but fido won't actually work that way....
https://developers.yubico.com/libfido2/Manuals/fido_assert_authdata_raw_ptr.html
The fido_assert_authdata_ptr(), fido_assert_authdata_raw_ptr(), fido_assert_clientdata_hash_ptr(), fido_assert_id_ptr(), fido_assert_user_id_ptr(), fido_assert_sig_ptr(), fido_assert_sigcount(), and fido_assert_flags() functions return pointers to the CBOR-encoded and raw authenticator data, client data hash, credential ID, user ID, signature, signature count, and authenticator data flags of statement idx in assert.
I've been using this hack for two weeks now, and it seems to be working.
There was a problem hiding this comment.
I've been using this hack for two weeks now, and it seems to be working.
This code path is for USB keys. Did you log in with a USB key?
There was a problem hiding this comment.
Otherwise, the 64gram will fail to
compile.
This code path is for USB keys. Did you log in with a USB key?
No, and I don't think it makes any sense on OpenBSD anyway.
What's great about this hack is that you don't have to add workarounds to the build system.
There was a problem hiding this comment.
@ilya-fedin for test of scroll I don't need actually working fido, so, I just used patch from @nazarenkomykyta , I have no idea does it broke fido or not, but it allows to compile tdesktop-7.1.3
So far scroll is very sensitive, but at least it can be used.
I'll keep your posted.
|
And yes, it is really help. This patch is included into tdesktop in OpenBSD ports, and I do have some positive reports that scroll finally works. Not perfect, but better. |
While currently it doesn't work at all? |
|
Currently it works, but it is extreamly sensetive, and any scroll moves to many messages up/down and make usage nearly impossible. Scroll in contancts, not chat, was broken for a while, but in chats it was broken recently, like a month or two. |
|
Can you answer each question in review? I'm not sure all changes are necessary and right. |
|
@ilya-fedin I'll do it, but I need some time to recover context. |
|
Ok, the last version of tdesktop works not perfect but works, and because I also have no time or motivation to dig more into scroll... and because @nazarenkomykyta looks like a man who willing to dig into it, well, I grand access to my fork should allow him to adjust that branch and do not reopen PR to continue discussion in this place. Alternativly this PR can be closed. Both way fine for me, and I sent to ports@openbsd.org update of tdesktop and remove of my patches: https://marc.info/?l=openbsd-ports&m=178799901300513&w=2 |
Normalize smooth wheel input while preserving ordinary wheel behavior; retain fractional deltas and report the visible viewport to QScroller.