bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Stephen Berman]

0. emacs -Q
1. Display a buffer with enough lines to scroll, e.g.:
   C-x d /path/to/emacs/sources RET
2. Scroll mouse wheel
=> The buffers fails to scroll.
3. Type `C-h k' and then scroll the mouse wheel
=> The echo area shows no input, only the prompt "Describe the following
   key, mouse click, or menu item: "

I see this only on the Lucid build.  Also on Lucis, if I hold down
mouse-1 or mouse-3 and simultaneously scroll the wheel, then the buffer
does scroll.  After releasing mouse-1 or mouse-3, scrolling the wheel
scrolls the buffer once by one line (either up or down).  Further
scrolling of the wheel fails to scroll the buffer.


In GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.17.6, Xaw scroll bars) of 2022-08-28 built on strobelfs2
Repository revision: 35af917f187719fecadde278a51fd10bf47eed07
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Linux From Scratch r11.0-165

Configured using:
 'configure -C --with-x-toolkit=lucid --with-xinput2 'CFLAGS=-Og -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> 0. emacs -Q
> 1. Display a buffer with enough lines to scroll, e.g.:
>    C-x d /path/to/emacs/sources RET
> 2. Scroll mouse wheel
> => The buffers fails to scroll.
> 3. Type `C-h k' and then scroll the mouse wheel
> => The echo area shows no input, only the prompt "Describe the following
>    key, mouse click, or menu item: "
>
> I see this only on the Lucid build.  Also on Lucis, if I hold down
> mouse-1 or mouse-3 and simultaneously scroll the wheel, then the buffer
> does scroll.  After releasing mouse-1 or mouse-3, scrolling the wheel
> scrolls the buffer once by one line (either up or down).  Further
> scrolling of the wheel fails to scroll the buffer.

To be clear here, you are talking about wheel-up and wheel-down events,
correct?

Input extension builds do not normally report mouse-1 or mouse-3; that
only happens if the input extension could not be set up for some reason.

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Input extension builds do not normally report mouse-1 or mouse-3; that
> only happens if the input extension could not be set up for some reason.

Please ignore that, I wasn't really thinking when I wrote this.

Unfortunately, I cannot reproduce the bug on any build of Emacs.  Please
instrument the following code around line 21053 of xterm.c as follows:


		      /* See the comment on top of x_cache_xi_devices
			 for more details on how scroll wheel movement
			 is reported on XInput 2.  */
		      delta = x_get_scroll_valuator_delta (dpyinfo, device,
							   i, *values, &val);
		      values++;

		      if (!val)
			{
			  other_valuators_found = true;
			  continue;
			}

		      printf ("%g\n", delta); <=== add this instrumentation

		      if (delta != DBL_MAX)
			{

and show what is printed when you try to scroll using the mouse.

Thanks.

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Stephen Berman]

On Tue, 30 Aug 2022 09:25:45 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> 0. emacs -Q
>> 1. Display a buffer with enough lines to scroll, e.g.:
>>    C-x d /path/to/emacs/sources RET
>> 2. Scroll mouse wheel
>> => The buffers fails to scroll.
>> 3. Type `C-h k' and then scroll the mouse wheel
>> => The echo area shows no input, only the prompt "Describe the following
>>    key, mouse click, or menu item: "
>>
>> I see this only on the Lucid build.  Also on Lucis, if I hold down
>> mouse-1 or mouse-3 and simultaneously scroll the wheel, then the buffer
>> does scroll.  After releasing mouse-1 or mouse-3, scrolling the wheel
>> scrolls the buffer once by one line (either up or down).  Further
>> scrolling of the wheel fails to scroll the buffer.
>
> To be clear here, you are talking about wheel-up and wheel-down events,
> correct?

Yes.

On Tue, 30 Aug 2022 09:29:34 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Unfortunately, I cannot reproduce the bug on any build of Emacs.  Please
> instrument the following code around line 21053 of xterm.c as follows:
>
>
> 		      /* See the comment on top of x_cache_xi_devices
> 			 for more details on how scroll wheel movement
> 			 is reported on XInput 2.  */
> 		      delta = x_get_scroll_valuator_delta (dpyinfo, device,
> 							   i, *values, &val);
> 		      values++;
>
> 		      if (!val)
> 			{
> 			  other_valuators_found = true;
> 			  continue;
> 			}
>
> 		      printf ("%g\n", delta); <=== add this instrumentation
>
> 		      if (delta != DBL_MAX)
> 			{
>
> and show what is printed when you try to scroll using the mouse.

1.79769e+308

(This is printed in the shell I invoked emacs -Q from each time I scroll
the mouse wheel up or down.)

Steve Berman

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> 1.79769e+308

Please instrument this piece of xterm.c, around line 20724, as follows:

  	      xi_reset_scroll_valuators_for_device_id (dpyinfo, enter->deviceid,
						       true);
#endif
	      printf ("Enter %d %d\n", enter->mode, enter->detail); <===

	      {
#ifdef HAVE_XWIDGETS
		struct xwidget_view *xwidget_view = xwidget_view_from_window (enter->event);

and this piece of the same function, around line 20843, as follows:

	      if (device)
		xi_report_motion_window_clear (device);
	      printf ("Leave %d %d\n", leave->mode, leave_detail); <====

and see what is printed as you move the mouse wheel.

Should it print "Enter" and "Leave" repetitively, please try the
following patch:

diff --git a/src/xfns.c b/src/xfns.c
index 0b1f707e9f..bebac747fb 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -3996,6 +3996,9 @@ x_window (struct frame *f, long window_prompting)
   /* Make all the standard events reach the Emacs frame.  */
   attributes.event_mask = STANDARD_EVENT_SET;
 
+  if (FRAME_DISPLAY_INFO (f)->supports_xi2)
+    attributes.event_mask &= ~(ButtonPressMask | ButtonReleaseMask);
+
 #ifdef HAVE_X_I18N
   if (FRAME_XIC (f))
     {

Thanks in advance.

P.S. I can't see anything wrong with that patch at first glance;
however, it is a big change to very old code, so please report any
issues that show up with it applied.

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Stephen Berman]

On Tue, 30 Aug 2022 18:15:29 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> 1.79769e+308
>
> Please instrument this piece of xterm.c, around line 20724, as follows:
>
>   	      xi_reset_scroll_valuators_for_device_id (dpyinfo, enter->deviceid,
> 						       true);
> #endif
> 	      printf ("Enter %d %d\n", enter->mode, enter->detail); <===
>
> 	      {
> #ifdef HAVE_XWIDGETS
> 		struct xwidget_view *xwidget_view = xwidget_view_from_window (enter->event);
>
> and this piece of the same function, around line 20843, as follows:
>
> 	      if (device)
> 		xi_report_motion_window_clear (device);
> 	      printf ("Leave %d %d\n", leave->mode, leave_detail); <====
                                                    ^^^^^^^^^^^^
This failed to build; I assume you meant leave->detail, which did build.

> and see what is printed as you move the mouse wheel.

The shell output looks like this:

Enter 0 3
Leave 1 0
Enter 2 0
Leave 1 0
Enter 2 0
Leave 1 0
Enter 2 0
Leave 1 0
... (and so on)

> Should it print "Enter" and "Leave" repetitively, please try the
> following patch:
>
> diff --git a/src/xfns.c b/src/xfns.c
> index 0b1f707e9f..bebac747fb 100644
> --- a/src/xfns.c
> +++ b/src/xfns.c
> @@ -3996,6 +3996,9 @@ x_window (struct frame *f, long window_prompting)
>    /* Make all the standard events reach the Emacs frame.  */
>    attributes.event_mask = STANDARD_EVENT_SET;
>
> +  if (FRAME_DISPLAY_INFO (f)->supports_xi2)
> +    attributes.event_mask &= ~(ButtonPressMask | ButtonReleaseMask);
> +
>  #ifdef HAVE_X_I18N
>    if (FRAME_XIC (f))
>      {
>
> Thanks in advance.
>
> P.S. I can't see anything wrong with that patch at first glance;
> however, it is a big change to very old code, so please report any
> issues that show up with it applied.

After applying the patch and rebuilding, scrolling the mouse wheel is
still a no-op.

Steve Berman

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> This failed to build; I assume you meant leave->detail, which did build.

Yes, that's what I meant, sorry.

> The shell output looks like this:
>
> Enter 0 3
> Leave 1 0
> Enter 2 0
> Leave 1 0
> Enter 2 0
> Leave 1 0
> Enter 2 0
> Leave 1 0
> ... (and so on)

[...]

> After applying the patch and rebuilding, scrolling the mouse wheel is
> still a no-op.

What window manager are you using?
Is it xfwm4 by any chance?

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Stephen Berman]

On Tue, 30 Aug 2022 20:48:23 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> This failed to build; I assume you meant leave->detail, which did build.
>
> Yes, that's what I meant, sorry.
>
>> The shell output looks like this:
>>
>> Enter 0 3
>> Leave 1 0
>> Enter 2 0
>> Leave 1 0
>> Enter 2 0
>> Leave 1 0
>> Enter 2 0
>> Leave 1 0
>> ... (and so on)
>
> [...]
>
>> After applying the patch and rebuilding, scrolling the mouse wheel is
>> still a no-op.
>
> What window manager are you using?
> Is it xfwm4 by any chance?

Yes:

$ xfwm4 --version
	This is xfwm4 version 4.16.1 (revision 5f61a84ad) for Xfce 4.16
	Released under the terms of the GNU General Public License.
	Compiled against GTK+-3.24.31, using GTK+-3.24.33.

	Build configuration and supported features:
	- Startup notification support:                 Yes
	- XSync support:                                Yes
	- Render support:                               Yes
	- Xrandr support:                               Yes
	- Xpresent support:                             No
	- X Input 2 support:                            No
	- Embedded compositor:                          Yes
	- Epoxy support:                                Yes
	- KDE systray proxy (deprecated):               No

Perhaps the missing XInput2 support is causing the problem?

Steve Berman

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> Yes:
>
> $ xfwm4 --version
> 	This is xfwm4 version 4.16.1 (revision 5f61a84ad) for Xfce 4.16
> 	Released under the terms of the GNU General Public License.
> 	Compiled against GTK+-3.24.31, using GTK+-3.24.33.
>
> 	Build configuration and supported features:
> 	- Startup notification support:                 Yes
> 	- XSync support:                                Yes
> 	- Render support:                               Yes
> 	- Xrandr support:                               Yes
> 	- Xpresent support:                             No
> 	- X Input 2 support:                            No
> 	- Embedded compositor:                          Yes
> 	- Epoxy support:                                Yes
> 	- KDE systray proxy (deprecated):               No
>
> Perhaps the missing XInput2 support is causing the problem?

Please try enabling that, but we should work around the bug in xfwm
builds without XInput 2 anyway.

In fact, this bug was fixed several months ago, but the fix disappeared
sometime during the following cleanups to the scroll valuator management
code.

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Stephen Berman]

On Tue, 30 Aug 2022 21:44:25 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Yes:
>>
>> $ xfwm4 --version
>> 	This is xfwm4 version 4.16.1 (revision 5f61a84ad) for Xfce 4.16
>> 	Released under the terms of the GNU General Public License.
>> 	Compiled against GTK+-3.24.31, using GTK+-3.24.33.
>>
>> 	Build configuration and supported features:
>> 	- Startup notification support:                 Yes
>> 	- XSync support:                                Yes
>> 	- Render support:                               Yes
>> 	- Xrandr support:                               Yes
>> 	- Xpresent support:                             No
>> 	- X Input 2 support:                            No
>> 	- Embedded compositor:                          Yes
>> 	- Epoxy support:                                Yes
>> 	- KDE systray proxy (deprecated):               No
>>
>> Perhaps the missing XInput2 support is causing the problem?
>
> Please try enabling that, but we should work around the bug in xfwm
> builds without XInput 2 anyway.

I rebuilt xfwm4 with --enable-xi2, logged out and back in, but still the
Lucid build does not respond to mouse wheel scrolling.  (I also tried
rebuilding Lucid without --with-xinput2, but that also made no difference.)

> In fact, this bug was fixed several months ago, but the fix disappeared
> sometime during the following cleanups to the scroll valuator management
> code.

Well, here's hoping you find it again!

Steve Berman

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> Well, here's hoping you find it again!

I did; should be fixed now, thanks.

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Stephen Berman]

On Wed, 31 Aug 2022 10:19:10 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Well, here's hoping you find it again!
>
> I did; should be fixed now, thanks.

Hm, I pulled from master including the patch, but with the Lucid build
and xfwm4 scrolling the mouse wheel remains a no-op and `C-h k' does not
show any event.

Steve Berman

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> Hm, I pulled from master including the patch, but with the Lucid build
> and xfwm4 scrolling the mouse wheel remains a no-op and `C-h k' does not
> show any event.

Right, I missed some code specific to the Xt builds.  Please try again.

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Stephen Berman]

On Thu, 01 Sep 2022 21:21:44 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Hm, I pulled from master including the patch, but with the Lucid build
>> and xfwm4 scrolling the mouse wheel remains a no-op and `C-h k' does not
>> show any event.
>
> Right, I missed some code specific to the Xt builds.  Please try again.

Yep, now the Lucid build on xfwm4 responds as it should to mouse wheel
scrolling.  Thanks for the fix!

Steve Berman

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stephen Berman <stephen.berman@gmx.net> writes:

> Yep, now the Lucid build on xfwm4 responds as it should to mouse wheel
> scrolling.  Thanks for the fix!

Thanks for testing.

bug#57476: 29.0.50; Mouse wheel event ignored on Lucid build

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Po Lu <luangruo@yahoo.com> writes:

> Thanks for testing.

Unfortunately, the fix is the cause of bug#58980.

I'm not sure what to do here.  xfwm4 is a very important window manager,
but so is working scroll wheel support.