Closed melroy89 closed 1 year ago
I found out scroll stops working after telegam update sometimes. If I reboot system, and start telegram arain, scroll works fine on same tg version.
PS restarting telegram witout rebooting does not fix problem. Reboot only.
Not sure my comment will be usable but I want to mention that in my case (despite others) restarting Telegram fixes the issue without need to reboot in Ubuntu 20.04 (KDE).
Ubuntu 21.10
Telegram is the only software with broken scroll on my system.
Restarting Telegram helps, but this is very temporary workaround.
It is very sad :( Scroll is broken for me for several month already.
@ilya-fedin @john-preston gentle ping
Can I manually downgrade Qt or do something different to fix this issue?
No, Qt is a part of Telegram binary.
I mean recompile it manually or something like that. Is it trivial or new functionality from Qt is used?
I think build with Qt 5 is broken with official instructions currently, but theoretically it's possible if someone fixes cmake scripts (personally I'm not interested in that)
Guys, if you want to speed up this, it's better if you would comment the Qt bug rather than this issue
Right now Qt bug report looks like it's affecting only one person
Ok, I've reproduced this bug with turning off and on my usb hub multiple times.
qt.qpa.input.events: (tdesktop) scroll wheel compress XCB_INPUT_MOTION NO
qt.qpa.events: Event | XInput Event(XCB_INPUT_MOTION) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel got in XCB_GE_GENERIC
qt.qpa.input.events: (tdesktop) scroll wheel got event 6 in xi2HandleEvent
qt.qpa.input.events: (tdesktop) scroll wheel got input_motion in xi2HandleEvent
qt.qpa.input.events: XI2 mouse motion 420,143, time 318007192, source MouseEventNotSynthesized
qt.qpa.events: Event | XInput Event(XCB_INPUT_BUTTON_PRESS) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel got event 4 in xi2HandleEvent
qt.qpa.events: Event | XCB_XKB_* event(85) | sequence: 4822
qt.qpa.events: Event | XInput Event(XCB_INPUT_BUTTON_RELEASE) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel got event 5 in xi2HandleEvent
qt.qpa.events: Event | XCB_XKB_* event(85) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel check XCB_INPUT_MOTION compress
qt.qpa.input.events: (tdesktop) scroll wheel compress XCB_INPUT_MOTION NO
qt.qpa.events: Event | XInput Event(XCB_INPUT_MOTION) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel got in XCB_GE_GENERIC
qt.qpa.input.events: (tdesktop) scroll wheel got event 6 in xi2HandleEvent
qt.qpa.input.events: (tdesktop) scroll wheel got input_motion in xi2HandleEvent
qt.qpa.input.events: XI2 mouse motion 420,143, time 318007270, source MouseEventNotSynthesized
qt.qpa.events: Event | XInput Event(XCB_INPUT_BUTTON_PRESS) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel got event 4 in xi2HandleEvent
qt.qpa.events: Event | XCB_XKB_* event(85) | sequence: 4822
qt.qpa.events: Event | XInput Event(XCB_INPUT_BUTTON_RELEASE) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel got event 5 in xi2HandleEvent
qt.qpa.events: Event | XCB_XKB_* event(85) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel check XCB_INPUT_MOTION compress
qt.qpa.input.events: (tdesktop) scroll wheel compress XCB_INPUT_MOTION NO
qt.qpa.events: Event | XInput Event(XCB_INPUT_MOTION) | sequence: 4822
qt.qpa.input.events: (tdesktop) scroll wheel got in XCB_GE_GENERIC
qt.qpa.input.events: (tdesktop) scroll wheel got event 6 in xi2HandleEvent
qt.qpa.input.events: (tdesktop) scroll wheel got input_motion in xi2HandleEvent
I see in logs scroll events, but nothing happens in telegram.
Are you sure that it is 3rd party issue?
@ernado Can you please reproduce it while collecting logs like stated above:
https://github.com/telegramdesktop/tdesktop/issues/17254#issuecomment-983459527
Can you please provide a full log after that along with a couple of timestamps - when the scroll definitely was working (early timestamp) and when it definitely didn't, although the events should've been sent (later timestamp).
Sorry for flickering in video:
https://user-images.githubusercontent.com/866677/150084316-851bc340-fa05-4734-ad53-e4dfb4c97a5b.mp4
I'll post logs for repro soon
telegram-v3.2.6.debug20220119.txt
So issue is happening after register QInputDevice
, when USB hub is getting online and connecting mouse again.
So it looks like device registration is somehow related.
Also it not 100% reproducible, sometimes it just works after hub on-off-on cycle, probably some race (in QT?).
@ernado So, in this log, when did it work and when it stopped?
@john-preston telegram-scrolling-log.txt
[2022-01-20T01:29:43] <- OK
[2022-01-20T01:29:49] qt.qpa.screen: output "DP-2" is connected and enabled; was fake: ":1.0"
My USB hub is in my monitor, so screen is re-connected as well as other devices like mouse.
Scroll is not working from that moment.
[2022-01-20T01:29:56] <- Scroll attempt, not working
@ernado Ok, I've linked this information in the Qt bug report. I'm not sure I'm qualified (have enough time?) to debug it myself, I still hope Qt will fix this.
This bug occurs while switching devices on a hardware KVM as well. Ubuntu 20.04, Telegram version 3.4.3.
Hello, I have same issue, nothing help. Happens only with Telegram too :'(
Linux Mint xfce
The same - Pop!_OS 21.10. Logitech M590
Hi, I got same issue here, Telegram Desktop 3.4.3 on Snap, Ubuntu Mate 20.04, Logitech MX Anywhere 3.
Restarting Telegram does not work, have to restart laptop.
Scrolling via Touchpad still works.
Have the same issue. Before Telegram Desktop v 3.4.8 the mouse reconnection trick worked. Updating to v 3.4.8 makes it worse, now only restarting the app helps. Ubuntu 20.04.3 LTS
Same issue With Linux mint, I am using a kvm to swtich now and then , might that the trigger. Any solution? It is annoying to close and open the app each time
I believe comments like 'same issue' are enough, they're not really useful.
I believe comments like 'same issue' are enough, they're not really useful.
I am happy to provide more logs or run a debug version, just need to be told what I can provide for extra information!
Well, we have no idea what's needed, it's a Qt bug. Feel free to go to Qt bugtracker and ask Qt people if you want to help. But please no more 'same issue' here.
It is a third party issue, but I think it is a good idea to track it here as well, sounds serious enough. Please no flood here.
@ilya-fedin
From my end-user point-of-view this is a Telegram issue and I am not interested in some flimsy excuses.
Telegram right now is the only software installed on my system, that shows that kind of bug. If you chose third-party libs with bugs in your application, then of course you will have to handle them.
Right now, you are just ignoring everyone, which is why more and more people commented with “same issue” – because you were just not willing to react in any sensible way.
It is surely not the users responsibiliy to fix your broken dependencies or even figure out that this was caused by a broken dependency. And you even bundled the QT-deps into Telegram as stated above (“tdesktop doesn't use your system Qt, it has Qt 6.2 embedded in the binary”) – as an end-user we don't even have the chance of using another version of that dependency.
And then closing an issue with the obvious attitude of “wont fix”, is – from my point of view – snobbish and ignores your users who might have used your app a bit longer. Sir, you are effectivly losing users here and you just don't care at all.
And then closing an issue with the obvious attitude of “wont fix”, is – from my point of view – snobbish and ignores your users who might have used your app a bit longer. Sir, you are effectivly losing users here and you just don't care at all.
It's just about the ways of handling issues. If a project has a policy of closing third-party issues and tracking only in the dependency's bugtracker, it has full right to do so. If you don't like that, well, it's your problems.
It is surely not the users responsibiliy to fix your broken dependencies or even figure out that this was caused by a broken dependency.
No one says users should fix dependencies. What's asked is to stop endless commenting in a place where no one would help you anyway and you just make the discussion harder to read.
And you even bundled the QT-deps into Telegram as stated above (“tdesktop doesn't use your system Qt, it has Qt 6.2 embedded in the binary”) – as an end-user we don't even have the chance of using another version of that dependency.
It's your choice how to install tdesktop. You can install tdesktop from system repositories and it will use your system Qt. If you choose official universal packages, of course they would have bundled Qt, you can't have a relocatable binary that would work on all the Linux distributions and don't bundle high-level libraries, it works just like all other software having universal packages (AppImages, flatpak, snap). This is no more different than all other software on your system, but you've chosen to install tdesktop from universal package unlike all other software. That's only your choice.
If you chose third-party libs with bugs in your application, then of course you will have to handle them.
I've never seen a bugless library... Every software, every library has bugs. Handling every library is not something feasible. Libraries sometimes wrap low-level primitives you would need a special knowledge in order to fix. Qt is exactly this case, the bug seem to happen in low-level X code and no one here has knowledge to fix it.
Right now, you are just ignoring everyone, which is why more and more people commented with “same issue” – because you were just not willing to react in any sensible way.
No one ignores anyone. All the information and response was provided in first answers. Then, a stream of "same issue" messages made that helpful info invisible creating more messages by people who don't read entire discussion.
@feeela Sorry, but we'll still have to wait for Qt to fix that 😔
Sorry for bumping this issue for everyone, but I will cross-post:
On Linux host:
Looks like there is much simpler reproducer (at least it works for me with high success rate), so no system sleep needed.
@ernado You better write this (and add something like "I'm ready to help if needed, to collect some logs or anything.") in QTBUG linked above.
@john-preston yep, it was the first thing I did
Thank you for filing the initial QT bug, hope it will be fixed soon
@ilya-fedin
From my end-user point-of-view this is a Telegram issue and I am not interested in some flimsy excuses.
Telegram right now is the only software installed on my system, that shows that kind of bug. If you chose third-party libs with bugs in your application, then of course you will have to handle them.
Right now, you are just ignoring everyone, which is why more and more people commented with “same issue” – because you were just not willing to react in any sensible way.
It is surely not the users responsibiliy to fix your broken dependencies or even figure out that this was caused by a broken dependency. And you even bundled the QT-deps into Telegram as stated above (“tdesktop doesn't use your system Qt, it has Qt 6.2 embedded in the binary”) – as an end-user we don't even have the chance of using another version of that dependency.
And then closing an issue with the obvious attitude of “wont fix”, is – from my point of view – snobbish and ignores your users who might have used your app a bit longer. Sir, you are effectivly losing users here and you just don't care at all.
no, it was not attitude of “wont fix”.
Same issue. First time was approximately 4 months ago, ignored it bacause restart is fixing problem. Doesn't know how to reproduce, it happens when telegram is minimized for long time but not always.
Kubunu 20.04.2 Qt: 5.12.8
Yes, me too can confirm, Ubuntu 20.04. I've never experienced it before when using the .deb. I only started experiencing it now that I switched from the outdated .deb package to the snap one. Wheel always works initially but it stops at some point. It is really annoying, because it worked always for 5 years.
Since it is now a snap then whoever builds the package is the one who bundles in the relevant Qt libs. Not pointing fingers anywhere since I do not know who builds the snaps, but Ubuntu Qt versions should not matter directly?
@ztane Yes, I build the snaps on launchpad.
If it can help, I first noticed this bug when I unplugged/replugged mouse+keyboard from a little USB hub, because I use it on several computers. The bug occurred then, when this (unplug/plug) was done during a Telegram-Desktop session. I just had to stop Telegram and restart it again, to solve the issue. Today, with version 3.4.8 (I use ArchLinux, with frequent update) mouse wheel doesn't work at all, even if I stop and restart Telegram.
oops this seem to be solved, that strange, it worked in some other applications including firefox and didn't work on Telegram Desktop, even after restarting. I plugged it in a RISC-V based Deiban bookworm/sid (same 3.4.8 version), and it worked fine, I replugged it then in the x86 Archlinux and work too, so at least the bug of hotplug is resolved.
Stop telegram, unplug mouse. Plug back, start telegram, worked on Ubuntu 20.
Stop telegram, unplug mouse. Plug back, start telegram, worked on Ubuntu 20.
this is a quick fix, haha, thanks!
Same issue on Telegram v 3.5.2 (08.02.22), Ubuntu Mate 21.04 (Kernel Linux 5.11.0-49-generic x86_64) Telegram scroll breaks after about 2 days. Restarting Telegram solves the problem. Hibernation/suspension might be the cause, but not 100%.
I have the same issue on Telegram version 3.5, Qt 5.15.2 on SalientOS. Restarting Telegram fixes it without need to unplug my mouse. This seems to happen randomly after a while. I do swap my mouse to another PC pretty often, yet I can't reproduce this by simply unplugging and plugging the mouse back in while Telegram is running.
Desktop PC and I never suspend/hibernate it btw.
Exactly same behavior.
Telegram 3.5 on Manjaro. Can't reproduce by anything - problem just appears at some moment. Restart of Telegram without unplugging mouse fixes the problem in 100% of cases. Never used suspension or hibernation.
adding "i have the same bug" here won't help to be fixed, upvote at https://bugreports.qt.io/browse/QTBUG-98720
adding "i have the same bug" here won't help to be fixed, upvote at https://bugreports.qt.io/browse/QTBUG-98720
Why though? That issue has ref to this page. Besides people with this problem more likely will find this page. By describing different conditions and temporary fixes we can provide more info for people with problem. QT team already marked this as critical bug and can open this thread for info when they decide to solve it.
adding "i have the same bug" here won't help to be fixed, upvote at bugreports.qt.io/browse/QTBUG-98720
Why though? That issue has ref to this page. Besides people with this problem more likely will find this page. By describing different conditions and temporary fixes we can provide more info for people with problem. QT team already marked this as critical bug and can open this thread for info when they decide to solve it.
because they are who must fix it, posting here won't adding preasure qt devs to fix it because they very likely don't follow this issue.
Might worth noting the bug appears to me on Kubuntu 18.04 with telegram-desktop 3.4.3 as a Snap app, yet the bug does not appear on my other laptop running Kubuntu 20.04 with telegram-desktop 3.4.2 installed as a Flatpak app Edit: I've installed the flatpak app (3.5.2) and will run it on the Kubuntu 18.04 laptop where the bug is present, and will report back, so maybe it can indicate if it has something to do with Snap or is a hardware/kernel/xorg version related problem.
Steps to reproduce
Expected behaviour
Scrolling within the message window.
Actual behaviour
Telegram desktop doesn't respond to any scroll wheel action.
Operating system
Linux Mint 20.2 (Ubuntu based)
Version of Telegram Desktop
3.2.4
Installation source
Static binary from official website
Logs
No response