GNU bug report logs -
#54436
28.0.91; Only every second mouse wheel scroll is registered
Previous Next
Reported by: Urban Duh <urby.duh <at> gmail.com>
Date: Thu, 17 Mar 2022 14:19:02 UTC
Severity: normal
Tags: notabug
Found in version 28.0.91
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54436 in the body.
You can then email your comments to 54436 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Thu, 17 Mar 2022 14:19:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Urban Duh <urby.duh <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 17 Mar 2022 14:19:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Only every second mouse wheel scroll move is registered, instead of all of
them. This happens when scrolling the text and also when using
keybindings (i. e. C-h <wheel-up> is activated only after scrolling
twice). The two scrolls do not need to be in quick succession, I can
scroll once (and nothing happens), wait for a long time and then the
next scroll is registered.
Currently using Doom Emacs on Emacs 28.0.91 with native compilation on
Arch Linux running GNOME on Xorg, but the same thing can be reproduced
in Emacs 29.0.50, on Wayland and in other WMs (I tried Qtile). The same
issue exists on Emacs without any customizations (just installing
emacs-git or emacs-gcc-wayland-devel-bin from AUR without Doom). Emacs
27 (package emacs from Arch Extra repository) does not have this issue
and works fine.
I am new to Emacs, so I'm not completely sure what other info I should
provide, so do not hesitate to contact me for more info.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Sat, 19 Mar 2022 00:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 54436 <at> debbugs.gnu.org (full text, mbox):
Urban Duh <urby.duh <at> gmail.com> writes:
> Only every second mouse wheel scroll move is registered, instead of all of
> them. This happens when scrolling the text and also when using
> keybindings (i. e. C-h <wheel-up> is activated only after scrolling
> twice). The two scrolls do not need to be in quick succession, I can
> scroll once (and nothing happens), wait for a long time and then the
> next scroll is registered.
>
> Currently using Doom Emacs on Emacs 28.0.91 with native compilation on
> Arch Linux running GNOME on Xorg, but the same thing can be reproduced
> in Emacs 29.0.50, on Wayland and in other WMs (I tried Qtile). The same
> issue exists on Emacs without any customizations (just installing
> emacs-git or emacs-gcc-wayland-devel-bin from AUR without Doom). Emacs
> 27 (package emacs from Arch Extra repository) does not have this issue
> and works fine.
>
> I am new to Emacs, so I'm not completely sure what other info I should
> provide, so do not hesitate to contact me for more info.
Are you running PGTK? It's not present in the official pretests of
Emacs 28, but several very irresponsible individuals are haphazardly
merging the code from Emacs 29 into Emacs 28, and then distributing
packages labeled "enhanced or "wayland" on platforms such as the AUR.
If you're running X, don't use PGTK. Here's the problem in this
specific case: GTK uses the X input extension to detect mouse wheel
movement, which relies on keeping the mouse wheel "valuators" in synch
with the X server, and calculating the difference between GTK's own
record of the valuator values and the X server's reported values every
time a valuator changes.
This is made complicated by the fact that an X window does not get
events to update the valuators unless it has the grab, or the mouse
pointer is on top of it.
So, every time the mouse enters a window, GTK marks the valuator as
invalid, after which two consecutive wheel events are required before
any more wheel movement will be recorded: one to obtain the current
value of the valuator, and another one so that the distance the wheel
has moved can be calculated.
Selecting for input extension events results in the corresponding core
event mask being deactivated on the window. Some very smart window
managers select for core wheel events (which are just button events) on
the WM frame window, or the root window, and since there is no core
button event mask on the Emacs frame window when GTK is using the input
extension, the button events representing wheel movement get propagated
up to the frame (or root) window, and that causes a grab to be activated
and then deactivated, generating incorrect entry events, which then
cause GTK to invalidate its own record of the scroll valuators, and
causes wheel movement to be ignored at random.
The solution is to use the official build of Emacs 28, and to not use
PGTK on X Windows if you want to run Emacs 29.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Sat, 19 Mar 2022 14:19:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 54436 <at> debbugs.gnu.org (full text, mbox):
Po Lu <luangruo <at> yahoo.com> writes:
> Are you running PGTK? It's not present in the official pretests of
> Emacs 28, but several very irresponsible individuals are haphazardly
> merging the code from Emacs 29 into Emacs 28, and then distributing
> packages labeled "enhanced or "wayland" on platforms such as the AUR.
Well, it's free software, so people can do what they want. But bugs in
these Frankenstein Emacs versions should be reported to the people that
distribute them, which in this case is Arch Linux.
> The solution is to use the official build of Emacs 28, and to not use
> PGTK on X Windows if you want to run Emacs 29.
So there doesn't seem to be anything to be done on the Emacs side here,
and I'm therefore closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) notabug.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 19 Mar 2022 14:19:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
54436 <at> debbugs.gnu.org and Urban Duh <urby.duh <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 19 Mar 2022 14:19:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Sun, 20 Mar 2022 16:56:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 54436 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for the insightful answers. The issue was indeed PGTK, the official
build of Emacs 28 works fine. I didn't realize that the version I used was
not official, sorry.
However, the same issue still exists in Emacs 29 on Wayland and X (tested
on GNOME on both X and Wayland, using emacs-git with PGTK from AUR, which
compiles from development master branch), where PGTK is officially
supported. Based on your responses, it seems that this is a known issue,
but I cannot find any corresponding bug report (I could have missed it
though, I'm a bit clumsy with GNU's bug report logs). Should this bug
report be moved to Emacs version 29? Or should I report the issue again for
Emacs 29?
On Sat, 19 Mar 2022 at 15:18, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Po Lu <luangruo <at> yahoo.com> writes:
>
> > Are you running PGTK? It's not present in the official pretests of
> > Emacs 28, but several very irresponsible individuals are haphazardly
> > merging the code from Emacs 29 into Emacs 28, and then distributing
> > packages labeled "enhanced or "wayland" on platforms such as the AUR.
>
> Well, it's free software, so people can do what they want. But bugs in
> these Frankenstein Emacs versions should be reported to the people that
> distribute them, which in this case is Arch Linux.
>
> > The solution is to use the official build of Emacs 28, and to not use
> > PGTK on X Windows if you want to run Emacs 29.
>
> So there doesn't seem to be anything to be done on the Emacs side here,
> and I'm therefore closing this bug report.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
> bloggy blog: http://lars.ingebrigtsen.no
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Mon, 21 Mar 2022 02:15:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 54436 <at> debbugs.gnu.org (full text, mbox):
Urban Duh <urby.duh <at> gmail.com> writes:
> Thanks for the insightful answers. The issue was indeed PGTK, the
> official build of Emacs 28 works fine. I didn't realize that the
> version I used was not official, sorry. However, the same issue still
> exists in Emacs 29 on Wayland and X (tested on GNOME on both X and
> Wayland, using emacs-git with PGTK from AUR, which compiles from
> development master branch), where PGTK is officially supported. Based
> on your responses, it seems that this is a known issue
The PGTK build is not supported on X Windows even in Emacs 29. It just
doesn't work well enough.
On the other hand, I don't see why that would happen on Wayland. Do you
see a similar problem with a different mouse? And can you verify that
your build is actually running in Wayland and not Xwayland?
Thanks.
> but I cannot find any corresponding bug report (I could have missed it
> though, I'm a bit clumsy with GNU's bug report logs). Should this bug
> report be moved to Emacs version 29? Or should I report the issue
> again for Emacs 29?
You should leave it as-is, I think.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Mon, 21 Mar 2022 09:21:01 GMT)
Full text and
rfc822 format available.
Message #24 received at 54436 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> On the other hand, I don't see why that would happen on Wayland. Do you
> see a similar problem with a different mouse? And can you verify that
> your build is actually running in Wayland and not Xwayland?
I have the same issue with two different mouses (Logitech MX Master 3 and
a cheap off-brand mouse). My build is running Wayland (tested with xeyes
and by disabling Xwayland on gnome via gnome-shell --no-x11).
On Mon, 21 Mar 2022 at 03:14, Po Lu <luangruo <at> yahoo.com> wrote:
> Urban Duh <urby.duh <at> gmail.com> writes:
>
> > Thanks for the insightful answers. The issue was indeed PGTK, the
> > official build of Emacs 28 works fine. I didn't realize that the
> > version I used was not official, sorry. However, the same issue still
> > exists in Emacs 29 on Wayland and X (tested on GNOME on both X and
> > Wayland, using emacs-git with PGTK from AUR, which compiles from
> > development master branch), where PGTK is officially supported. Based
> > on your responses, it seems that this is a known issue
>
> The PGTK build is not supported on X Windows even in Emacs 29. It just
> doesn't work well enough.
>
> On the other hand, I don't see why that would happen on Wayland. Do you
> see a similar problem with a different mouse? And can you verify that
> your build is actually running in Wayland and not Xwayland?
>
> Thanks.
>
> > but I cannot find any corresponding bug report (I could have missed it
> > though, I'm a bit clumsy with GNU's bug report logs). Should this bug
> > report be moved to Emacs version 29? Or should I report the issue
> > again for Emacs 29?
>
> You should leave it as-is, I think.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Mon, 21 Mar 2022 11:06:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 54436 <at> debbugs.gnu.org (full text, mbox):
Urban Duh <urby.duh <at> gmail.com> writes:
>> On the other hand, I don't see why that would happen on Wayland. Do you
>> see a similar problem with a different mouse? And can you verify that
>> your build is actually running in Wayland and not Xwayland?
>
> I have the same issue with two different mouses (Logitech MX Master 3 and
> a cheap off-brand mouse). My build is running Wayland (tested with xeyes
> and by disabling Xwayland on gnome via gnome-shell --no-x11).
What happens if you set mwheel-coalesce-scroll-events to nil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#54436
; Package
emacs
.
(Tue, 22 Mar 2022 14:00:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 54436 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This makes scrolling behave as it should on Wayland. On X however, Emacs
now receives too many scroll events per scroll on certain mouses. On
Logitech MX master 3, every mouse wheel scroll is registered as a double or
triple scroll. I would guess this has something to do with its scroll
wheel, since it has an electromagnetic scroll wheel. Such issues do not
exists on Emacs 28 though, but I guess I could probably make it usable by
binding triple scroll to normal scroll.
On Mon, 21 Mar 2022 at 12:05, Po Lu <luangruo <at> yahoo.com> wrote:
> Urban Duh <urby.duh <at> gmail.com> writes:
>
> >> On the other hand, I don't see why that would happen on Wayland. Do you
> >> see a similar problem with a different mouse? And can you verify that
> >> your build is actually running in Wayland and not Xwayland?
> >
> > I have the same issue with two different mouses (Logitech MX Master 3 and
> > a cheap off-brand mouse). My build is running Wayland (tested with xeyes
> > and by disabling Xwayland on gnome via gnome-shell --no-x11).
>
> What happens if you set mwheel-coalesce-scroll-events to nil?
>
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 20 Apr 2022 11:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 57 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.