Skip to content

Fix X11 touchpad scrolling in elastic views - #339

Open
catap wants to merge 1 commit into
desktop-app:masterfrom
catap:x11-scroll
Open

Fix X11 touchpad scrolling in elastic views#339
catap wants to merge 1 commit into
desktop-app:masterfrom
catap:x11-scroll

Conversation

@catap

@catap catap commented Aug 14, 2026

Copy link
Copy Markdown

Normalize smooth wheel input while preserving ordinary wheel behavior; retain fractional deltas and report the visible viewport to QScroller.

Normalize smooth wheel input while preserving ordinary wheel behavior;
retain fractional deltas and report the visible viewport to QScroller.
@CLAassistant

CLAassistant commented Aug 14, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

Comment thread ui/ui_utility.cpp

constexpr auto kDefaultWheelScrollLines = 3;
constexpr auto kMagicScrollMultiplier = 2.5;
constexpr auto kX11SmoothScrollMultiplier = 5.;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why exactly that multilplier?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had tested different, this one make it works acceptable enough.

Comment thread ui/ui_utility.cpp
x11Touchpad = e->device()
&& e->device()->type() == base::TouchDevice::TouchPad;
#endif // Qt >= 6.0.0
const auto x11Smooth = !touch

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the current capability check doesn't suffice?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I don't understand you.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Comment thread ui/ui_utility.cpp
const auto x11Smooth = !touch
&& ::Platform::IsX11()
&& (pixelInput || !pixelDelta.isNull() || x11Touchpad);
if (x11Smooth && !angleDelta.isNull()) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're requiring both pixel delta and angle delta to be not null for the angle delta codepath?

Comment thread ui/ui_utility.cpp
* kX11SmoothScrollMultiplier)
/ float64(QWheelEvent::DefaultDeltasPerStep);
}
if (pixelInput || (x11Smooth && !pixelDelta.isNull())) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You already checked pixelDelta in the x11Smooth check?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

  1. A fix in OpenBSD code
  2. 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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know much about BSDs but I assume OpenBSD and NetBSD could share the same driver code?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some? Yes. Probably https://man.openbsd.org/wscons.4 and friends is more or less similar, but I have no idea how similarity has.

Comment thread ui/ui_utility.cpp
}
if (pixelInput || (x11Smooth && !pixelDelta.isNull())) {
return (::Platform::IsX11() && !touch
? QPointF(pixelDelta)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're breaking scrolling with scaling for X11 users

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I use it with DPI ~270

@ilya-fedin ilya-fedin Aug 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're breaking scrolling with scaling for X11 users

You broke the whole scroll using ElasticScroll() on Xenocara, ironic...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? What's the problem with it on Xenocara?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I think majority of Linux users are moved to Wayland which default options at Fedora, Ubuntu and so on.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it really help?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it does, and I fight here rounding by moving to float.

@ilya-fedin ilya-fedin Aug 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@ilya-fedin ilya-fedin Aug 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it compiles but fido won't actually work that way....

@nazarenkomykyta nazarenkomykyta Aug 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

@catap

catap commented Aug 21, 2026

Copy link
Copy Markdown
Author

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.

@ilya-fedin

Copy link
Copy Markdown
Contributor

that scroll finally works

While currently it doesn't work at all?

@catap

catap commented Aug 22, 2026

Copy link
Copy Markdown
Author

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.

@ilya-fedin

Copy link
Copy Markdown
Contributor

Can you answer each question in review? I'm not sure all changes are necessary and right.

@catap

catap commented Aug 22, 2026

Copy link
Copy Markdown
Author

@ilya-fedin I'll do it, but I need some time to recover context.

@catap

catap commented Aug 29, 2026

Copy link
Copy Markdown
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants