bug#36779: 25.1; mouse click not recognized for frames with large left position

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

Recipe:
1. Prepare dual monitors (mines are 1920x1080 and 3840x2160)
2. emacs -Q
3. Type some texts
3. Place the window (frame) at large left position (> 3840 in my case)
4. Click anywhere in the text; no click is recogonized (in my case, at
least)

Since other X clients (such as xev) are fine, I presume this is an issue
of the X client (Emacs 25.1.1 in Debian GNU/Linux 9.6, on WSL) rather
than the X server (ASTEC-X 8.0.12 on Windows 10).



In GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2017-09-15, modified by Debian built on trouble
Windowing system distributor 'ASTEC, Inc.', version 11.0.6600
System Description:	Debian GNU/Linux 9.6 (stretch)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --with-x=yes --with-x-toolkit=gtk3
 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs25-wN2qS3/emacs25-25.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: ja_JP.UTF-8
  value of $XMODIFIERS: @im=ASTEC_IMS
  locale-coding-system: utf-8-unix

Major mode: Summary

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  transient-mark-mode: t

Recent messages:
6 messages retrieved
Mark set
Wrapped lines
Auto refiling...done
Refiling and deleting...done
Scanning +done...done
Mark set
Wrapped lines
Making completion list... [3 times]
Mark activated

Load-path shadows:
/usr/share/emacs/25.1/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs25/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/25.1/lisp/language/thai-word
/usr/share/emacs25/site-lisp/auctex/toolbar-x hides /usr/share/emacs/site-lisp/auctex/toolbar-x
/usr/share/emacs25/site-lisp/auctex/texmathp hides /usr/share/emacs/site-lisp/auctex/texmathp
/usr/share/emacs25/site-lisp/auctex/tex hides /usr/share/emacs/site-lisp/auctex/tex
/usr/share/emacs25/site-lisp/auctex/tex-style hides /usr/share/emacs/site-lisp/auctex/tex-style
/usr/share/emacs25/site-lisp/auctex/tex-mik hides /usr/share/emacs/site-lisp/auctex/tex-mik
/usr/share/emacs25/site-lisp/auctex/tex-jp hides /usr/share/emacs/site-lisp/auctex/tex-jp
/usr/share/emacs25/site-lisp/auctex/tex-ispell hides /usr/share/emacs/site-lisp/auctex/tex-ispell
/usr/share/emacs25/site-lisp/auctex/tex-info hides /usr/share/emacs/site-lisp/auctex/tex-info
/usr/share/emacs25/site-lisp/auctex/tex-font hides /usr/share/emacs/site-lisp/auctex/tex-font
/usr/share/emacs25/site-lisp/auctex/tex-fold hides /usr/share/emacs/site-lisp/auctex/tex-fold
/usr/share/emacs25/site-lisp/auctex/tex-buf hides /usr/share/emacs/site-lisp/auctex/tex-buf
/usr/share/emacs25/site-lisp/auctex/tex-bar hides /usr/share/emacs/site-lisp/auctex/tex-bar
/usr/share/emacs25/site-lisp/auctex/prv-emacs hides /usr/share/emacs/site-lisp/auctex/prv-emacs
/usr/share/emacs25/site-lisp/auctex/preview hides /usr/share/emacs/site-lisp/auctex/preview
/usr/share/emacs25/site-lisp/auctex/plain-tex hides /usr/share/emacs/site-lisp/auctex/plain-tex
/usr/share/emacs25/site-lisp/auctex/multi-prompt hides /usr/share/emacs/site-lisp/auctex/multi-prompt
/usr/share/emacs25/site-lisp/auctex/latex hides /usr/share/emacs/site-lisp/auctex/latex
/usr/share/emacs25/site-lisp/auctex/font-latex hides /usr/share/emacs/site-lisp/auctex/font-latex
/usr/share/emacs25/site-lisp/auctex/context hides /usr/share/emacs/site-lisp/auctex/context
/usr/share/emacs25/site-lisp/auctex/context-nl hides /usr/share/emacs/site-lisp/auctex/context-nl
/usr/share/emacs25/site-lisp/auctex/context-en hides /usr/share/emacs/site-lisp/auctex/context-en
/usr/share/emacs25/site-lisp/auctex/bib-cite hides /usr/share/emacs/site-lisp/auctex/bib-cite

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec epg epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mail-utils novice tabify imenu man eieio-opt speedbar sb-image ezimage
dframe find-func jka-compr info thingatpt sh-script smie executable pp
qp network-stream nsm auth-source cl-seq eieio eieio-core gnus-util
mm-util help-fns mail-prsvr password-cache starttls tls gnutls mew-varsx
mew-unix mew-auth mew-config mew-imap2 mew-imap mew-nntp2 mew-nntp
mew-pop mew-smtp mew-ssl mew-ssh mew-net mew-highlight mew-sort mew-fib
mew-ext mew-refile mew-demo mew-attach mew-draft mew-message mew-thread
mew-virtual mew-summary4 mew-summary3 mew-summary2 mew-summary
mew-search mew-pick mew-passwd mew-scan mew-syntax mew-bq mew-smime
mew-pgp mew-header mew-exec mew-mark mew-mime mew-edit mew-decode
mew-encode mew-cache mew-minibuf mew-complete mew-addrbook mew-local
mew-vars3 mew-vars2 mew-vars mew-env mew-lang-jp mew-mule3 mew-mule
mew-gemacs mew-key mew-func mew-blvs mew-const mew inf-caml caml
warnings texmathp misearch multi-isearch ediff-merg ediff-wind
ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff preview
prv-emacs tex-bar toolbar-x noutline outline font-latex byte-opt
bytecomp byte-compile cl-extra help-mode cconv cl-macs tex-jp tex-buf
latex easy-mmode edmacro kmacro tex-ispell tex-style tex dbus xml crm
advice easymenu tex-mode compile shell pcomplete comint ansi-color ring
latexenc omake-mode caml-font proof-site proof-autoloads pg-vars
mmm-auto mmm-vars mmm-compat cl gv cl-loaddefs pcase cl-lib
preview-latex tex-site auto-loads time-date mule-util japan-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 661822 37018)
 (symbols 48 36623 0)
 (miscs 40 862 1316)
 (strings 32 75682 20418)
 (string-bytes 1 2033793)
 (vectors 16 35872)
 (vector-slots 8 1560156 126774)
 (floats 8 377 683)
 (intervals 56 141765 238)
 (buffers 976 50))

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Wed, 24 Jul 2019 13:18:03 +0900
> Cc: sumii@ecei.tohoku.ac.jp
> 
> 
> Recipe:
> 1. Prepare dual monitors (mines are 1920x1080 and 3840x2160)
> 2. emacs -Q
> 3. Type some texts
> 3. Place the window (frame) at large left position (> 3840 in my case)
> 4. Click anywhere in the text; no click is recogonized (in my case, at
> least)

Are you saying that "C-h l" doesn't show any click events in this
case?

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Wed, Jul 24, 2019 at 11:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> > Date: Wed, 24 Jul 2019 13:18:03 +0900
> > Cc: sumii@ecei.tohoku.ac.jp
> >
> >
> > Recipe:
> > 1. Prepare dual monitors (mines are 1920x1080 and 3840x2160)
> > 2. emacs -Q
> > 3. Type some texts
> > 3. Place the window (frame) at large left position (> 3840 in my case)
> > 4. Click anywhere in the text; no click is recogonized (in my case, at
> > least)
>
> Are you saying that "C-h l" doesn't show any click events in this
> case?

Yes, that's the case.

For additional information, some of the menus (for example, "Edit" ->
"Replace" -> "Replace String...") also don't work (they can be clicked
but nothing happens) *only when* the window frame is placed at large
left position.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Thu, 25 Jul 2019 13:32:39 +0900
> Cc: 36779@debbugs.gnu.org, Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> 
> > > 1. Prepare dual monitors (mines are 1920x1080 and 3840x2160)
> > > 2. emacs -Q
> > > 3. Type some texts
> > > 3. Place the window (frame) at large left position (> 3840 in my case)
> > > 4. Click anywhere in the text; no click is recogonized (in my case, at
> > > least)
> >
> > Are you saying that "C-h l" doesn't show any click events in this
> > case?
> 
> Yes, that's the case.
> 
> For additional information, some of the menus (for example, "Edit" ->
> "Replace" -> "Replace String...") also don't work (they can be clicked
> but nothing happens) *only when* the window frame is placed at large
> left position.

Sounds like some problem with mouse support in that configuration?  I
guess someone will needs to reproduce this under a debugger and see
what kind of data do we get from X.

Thanks.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Thu, Jul 25, 2019 at 9:49 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Sounds like some problem with mouse support in that configuration?  I
> guess someone will needs to reproduce this under a debugger and see
> what kind of data do we get from X.

I can try to build Emacs from the source with debugging information
and run it under a debugger if somebody tells me what code point and
data I should look at.  I will also check if other Gtk3 applications
work.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

P.S.

> I will also check if other Gtk3 applications work.

I did, and gnome-calculator and gedit worked well with no problem in the
same environment.

Meanwhile, I received information from costumer support of the X server
that the problem may be related to RandR extension.  I am not yet sure
which side (the client or server) is causing the problem, and will continue
investigation.

[-- Attachment #2: Type: text/html, Size: 578 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics]

 > Meanwhile, I received information from costumer support of the X server
 > that the problem may be related to RandR extension.  I am not yet sure
 > which side (the client or server) is causing the problem, and will continue
 > investigation.

Does evaluating

(display-monitor-attributes-list)

give a reasonable result?

martin

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Sat, Jul 27, 2019 at 3:52 PM martin rudalics <rudalics@gmx.at> wrote:
>  > Meanwhile, I received information from costumer support of the X server
>  > that the problem may be related to RandR extension.  I am not yet sure
>  > which side (the client or server) is causing the problem, and will continue
>  > investigation.
>
> Does evaluating
>
> (display-monitor-attributes-list)
>
> give a reasonable result?

Yes, it looks correct (according to the feature of the X server, which
treats multiple monitors as a big, single monitor):

(display-monitor-attributes-list)
(((geometry 0 0 5760 2160) (workarea 0 0 5760 2160) (mm-size 1016 381)
(frames #<frame emacs@LAPTOP-0TO7HGG8 0x1132c30>) (source . "Gdk")))

I have also tried disabling RandR extension of the X server, but
nothing changed.

Additionally, I noticed that the *shape* of the mouse cursor changes
correctly in accordance with the contents of the window frame at the
mouse position; however, no click is recognized *except for* some
"shallow" part of the menu.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics]

 > Additionally, I noticed that the *shape* of the mouse cursor changes
 > correctly in accordance with the contents of the window frame at the
 > mouse position; however, no click is recognized *except for* some
 > "shallow" part of the menu.

Can you mark text with the mouse?  Does the bug happen only when the
entire frame is positioned to the right of 3840 or do you see it with
a frame starting before 3840 but extending to the right of the display
as well?

If you want to debug mouse clicks it should suffice to set a break
point with gdb at the top of the body below the lines

     case ButtonRelease:
     case ButtonPress:

of xterm.c (in Emacs 25 they are at line 8499 here) and look whether
it triggers.  If it triggers, then the call of x_window_to_frame in

         f = (x_mouse_grabbed (dpyinfo) ? dpyinfo->last_mouse_frame
	     : x_window_to_frame (dpyinfo, event->xbutton.window));

should give us some preliminary information.

martin

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 9907 bytes --]

On Tue, Jul 30, 2019 at 12:16 AM martin rudalics <rudalics@gmx.at> wrote:
> Can you mark text with the mouse?

No, I cannot.

> Does the bug happen only when the
> entire frame is positioned to the right of 3840

Yes, that's the case.

> or do you see it with
> a frame starting before 3840 but extending to the right of the display
> as well?

This situation does *not* exhibit the bug.

> If you want to debug mouse clicks it should suffice to set a break
> point with gdb at the top of the body below the lines
>
>      case ButtonRelease:
>      case ButtonPress:
>
> of xterm.c (in Emacs 25 they are at line 8499 here) and look whether
> it triggers.  If it triggers, then the call of x_window_to_frame in
>
>          f = (x_mouse_grabbed (dpyinfo) ? dpyinfo->last_mouse_frame
>              : x_window_to_frame (dpyinfo, event->xbutton.window));
>
> should give us some preliminary information.

Thanks!  I built both Emacs 25.1 and 26.2 (latest release) from the
sources, and confirmed that *both* exhibits the same problem in my
environment.
I run gdb for the latter (Emacs 26.2) and the values of *dpyinfo and
event->xbutton at that code point (line 8848) are:

When the problem occurs:

(gdb) p *dpyinfo
$5 = {next = 0x0, terminal = 0x2c955d0, display = 0x2cae000, connection =
5, name_list_element = 19285939, reference_count = 1, screen = 0x2cac5b0,
  resx = 144, resy = 144, visual = 0x2cac640, cmap = 32, n_planes = 24,
grabbed = 0, icon_bitmap_id = -2, root_window = 51, client_leader_window =
0,
  vertical_scroll_bar_cursor = 25165834, horizontal_scroll_bar_cursor =
25165838, invisible_cursor = 25165843,
  toggle_visible_pointer = 0x4becb0 <x_toggle_visible_pointer>, xg_cursor =
0x2dfbcc0, xrdb = 0x2e068f0, smallest_char_width = 13,
  smallest_font_height = 25, scratch_cursor_gc = 0x34752e0, mouse_highlight
= {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 0,
    mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0,
mouse_face_window = 0, mouse_face_face_id = 0, mouse_face_overlay = 0,
    mouse_face_mouse_frame = 0x1385c30 <bss_sbrk_buffer+7883952>,
mouse_face_mouse_x = 475, mouse_face_mouse_y = 151, mouse_face_past_end =
false,
    mouse_face_defer = false, mouse_face_hidden = false}, x_id = 1,
x_id_name = 0x2c34510 "emacs@LAPTOP-0TO7HGG8", n_fonts = 4, bitmaps = 0x0,
  bitmaps_size = 0, bitmaps_last = 0, meta_mod_mask = 8, shift_lock_mask =
0, alt_mod_mask = 0, super_mod_mask = 0, hyper_mod_mask = 0,
  Xatom_wm_protocols = 125, Xatom_wm_take_focus = 127,
Xatom_wm_save_yourself = 300, Xatom_wm_delete_window = 126,
Xatom_wm_change_state = 123,
  Xatom_wm_configure_denied = 301, Xatom_wm_window_moved = 302,
Xatom_wm_client_leader = 178, Xatom_editres = 303, Xatom_CLIPBOARD = 133,
  Xatom_TIMESTAMP = 304, Xatom_TEXT = 129, Xatom_DELETE = 305,
Xatom_COMPOUND_TEXT = 128, Xatom_UTF8_STRING = 135, Xatom_MULTIPLE = 306,
  Xatom_INCR = 307, Xatom_EMACS_TMP = 308, Xatom_TARGETS = 132, Xatom_NULL
= 309, Xatom_ATOM = 4, Xatom_ATOM_PAIR = 310, Xatom_CLIPBOARD_MANAGER = 311,
  Xatom_PIXEL_SIZE = 94, Xatom_AVERAGE_WIDTH = 98,
Xatom_MULE_BASELINE_OFFSET = 313, Xatom_MULE_RELATIVE_COMPOSE = 314,
Xatom_MULE_DEFAULT_ASCENT = 315,
  Xatom_DONE = 316, Xatom_PAGE = 317, Xatom_Scrollbar = 318,
Xatom_Horizontal_Scrollbar = 319, Xatom_XEMBED = 320, Xatom_XEMBED_INFO =
312,
  x_focus_frame = 0x1385c30 <bss_sbrk_buffer+7883952>, x_focus_event_frame
= 0x1385c30 <bss_sbrk_buffer+7883952>,
  x_highlight_frame = 0x1385c30 <bss_sbrk_buffer+7883952>,
x_pending_autoraise_frame = 0x0, last_mouse_frame = 0x0,
last_mouse_glyph_frame = 0x0,
  last_mouse_motion_frame = 0x1385c30 <bss_sbrk_buffer+7883952>,
last_mouse_scroll_bar = 0x0, last_user_time = 1091249789,
last_mouse_motion_x = 475,
  last_mouse_motion_y = 170, last_mouse_glyph = {x = 463, y = 150, width =
13, height = 25}, last_mouse_movement_time = 1091249693, gray = 25165839,
  xim = 0x2e445a0, xim_styles = 0x2cbb770, xim_callback_data = 0x2e39040,
color_names = 0x2df2920, color_cells = 0x0, ncolor_cells = 0, red_bits = 8,
  blue_bits = 8, green_bits = 8, red_offset = 16, blue_offset = 0,
green_offset = 8, wm_type = X_WMTYPE_UNKNOWN, x_dnd_atoms = 0x2e85520,
  x_dnd_atoms_size = 8, x_dnd_atoms_length = 6, Xatom_net_supported = 321,
Xatom_net_supporting_wm_check = 322, net_supported_atoms = 0x0,
  nr_net_supported_atoms = 0, net_supported_window = 0,
Xatom_net_window_type = 279, Xatom_net_window_type_tooltip = 287,
Xatom_net_active_window = 256,
  Xatom_net_wm_state = 266, Xatom_net_wm_state_fullscreen = 269,
Xatom_net_wm_state_maximized_horz = 273, Xatom_net_wm_state_maximized_vert
= 272,
  Xatom_net_wm_state_sticky = 276, Xatom_net_wm_state_above = 267,
Xatom_net_wm_state_below = 268, Xatom_net_wm_state_hidden = 270,
  Xatom_net_wm_state_skip_taskbar = 274, Xatom_net_frame_extents = 258,
Xatom_net_current_desktop = 257, Xatom_net_workarea = 324,
  Xatom_xsettings_sel = 295, Xatom_xsettings_prop = 326,
Xatom_xsettings_mgr = 327, xsettings_window = 0, Xatom_net_wm_name = 263,
  Xatom_net_wm_icon_name = 262, Xatom_net_wm_window_opacity = 323,
Xatom_SM_CLIENT_ID = 325, xrandr_major_version = 0, xrandr_minor_version =
0,
  xcb_connection = 0x2caf250, supports_xdbe = false}
(gdb) p event->xbutton
$6 = {type = 4, serial = 5265, send_event = 0, display = 0x2cae000, window
= 25166151, root = 51, subwindow = 0, time = 1091249789, x = 475, y = 170,
  x_root = 4326, y_root = 281, state = 0, button = 1, same_screen = 1}

When no problem occurs:

(gdb) p event->xbutton
$8 = {next = 0x0, terminal = 0x2c955d0, display = 0x2cae000, connection =
5, name_list_element = 19285939, reference_count = 1, screen = 0x2cac5b0,
  resx = 144, resy = 144, visual = 0x2cac640, cmap = 32, n_planes = 24,
grabbed = 0, icon_bitmap_id = -2, root_window = 51, client_leader_window =
0,
  vertical_scroll_bar_cursor = 25165834, horizontal_scroll_bar_cursor =
25165838, invisible_cursor = 25165843,
  toggle_visible_pointer = 0x4becb0 <x_toggle_visible_pointer>, xg_cursor =
0x2dfbcc0, xrdb = 0x2e068f0, smallest_char_width = 13,
  smallest_font_height = 25, scratch_cursor_gc = 0x34752e0, mouse_highlight
= {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 0,
    mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0,
mouse_face_window = 0, mouse_face_face_id = 0, mouse_face_overlay = 0,
    mouse_face_mouse_frame = 0x1385c30 <bss_sbrk_buffer+7883952>,
mouse_face_mouse_x = 541, mouse_face_mouse_y = 118, mouse_face_past_end =
false,
    mouse_face_defer = false, mouse_face_hidden = false}, x_id = 1,
x_id_name = 0x2c34510 "emacs@LAPTOP-0TO7HGG8", n_fonts = 4, bitmaps = 0x0,
  bitmaps_size = 0, bitmaps_last = 0, meta_mod_mask = 8, shift_lock_mask =
0, alt_mod_mask = 0, super_mod_mask = 0, hyper_mod_mask = 0,
  Xatom_wm_protocols = 125, Xatom_wm_take_focus = 127,
Xatom_wm_save_yourself = 300, Xatom_wm_delete_window = 126,
Xatom_wm_change_state = 123,
  Xatom_wm_configure_denied = 301, Xatom_wm_window_moved = 302,
Xatom_wm_client_leader = 178, Xatom_editres = 303, Xatom_CLIPBOARD = 133,
  Xatom_TIMESTAMP = 304, Xatom_TEXT = 129, Xatom_DELETE = 305,
Xatom_COMPOUND_TEXT = 128, Xatom_UTF8_STRING = 135, Xatom_MULTIPLE = 306,
  Xatom_INCR = 307, Xatom_EMACS_TMP = 308, Xatom_TARGETS = 132, Xatom_NULL
= 309, Xatom_ATOM = 4, Xatom_ATOM_PAIR = 310, Xatom_CLIPBOARD_MANAGER = 311,
  Xatom_PIXEL_SIZE = 94, Xatom_AVERAGE_WIDTH = 98,
Xatom_MULE_BASELINE_OFFSET = 313, Xatom_MULE_RELATIVE_COMPOSE = 314,
Xatom_MULE_DEFAULT_ASCENT = 315,
  Xatom_DONE = 316, Xatom_PAGE = 317, Xatom_Scrollbar = 318,
Xatom_Horizontal_Scrollbar = 319, Xatom_XEMBED = 320, Xatom_XEMBED_INFO =
312,
  x_focus_frame = 0x1385c30 <bss_sbrk_buffer+7883952>, x_focus_event_frame
= 0x1385c30 <bss_sbrk_buffer+7883952>,
  x_highlight_frame = 0x1385c30 <bss_sbrk_buffer+7883952>,
x_pending_autoraise_frame = 0x0, last_mouse_frame = 0x0,
last_mouse_glyph_frame = 0x0,
  last_mouse_motion_frame = 0x1385c30 <bss_sbrk_buffer+7883952>,
last_mouse_scroll_bar = 0x0, last_user_time = 1091390837,
last_mouse_motion_x = 546,
  last_mouse_motion_y = 118, last_mouse_glyph = {x = 541, y = 100, width =
13, height = 25}, last_mouse_movement_time = 1091389269, gray = 25165839,
  xim = 0x2e445a0, xim_styles = 0x2cbb770, xim_callback_data = 0x2e39040,
color_names = 0x2df2920, color_cells = 0x0, ncolor_cells = 0, red_bits = 8,
  blue_bits = 8, green_bits = 8, red_offset = 16, blue_offset = 0,
green_offset = 8, wm_type = X_WMTYPE_UNKNOWN, x_dnd_atoms = 0x2e85520,
  x_dnd_atoms_size = 8, x_dnd_atoms_length = 6, Xatom_net_supported = 321,
Xatom_net_supporting_wm_check = 322, net_supported_atoms = 0x0,
  nr_net_supported_atoms = 0, net_supported_window = 0,
Xatom_net_window_type = 279, Xatom_net_window_type_tooltip = 287,
Xatom_net_active_window = 256,
  Xatom_net_wm_state = 266, Xatom_net_wm_state_fullscreen = 269,
Xatom_net_wm_state_maximized_horz = 273, Xatom_net_wm_state_maximized_vert
= 272,
  Xatom_net_wm_state_sticky = 276, Xatom_net_wm_state_above = 267,
Xatom_net_wm_state_below = 268, Xatom_net_wm_state_hidden = 270,
  Xatom_net_wm_state_skip_taskbar = 274, Xatom_net_frame_extents = 258,
Xatom_net_current_desktop = 257, Xatom_net_workarea = 324,
  Xatom_xsettings_sel = 295, Xatom_xsettings_prop = 326,
Xatom_xsettings_mgr = 327, xsettings_window = 0, Xatom_net_wm_name = 263,
  Xatom_net_wm_icon_name = 262, Xatom_net_wm_window_opacity = 323,
Xatom_SM_CLIENT_ID = 325, xrandr_major_version = 0, xrandr_minor_version =
0,
  xcb_connection = 0x2caf250, supports_xdbe = false}
$9 = {type = 4, serial = 9839, send_event = 0, display = 0x2cae000, window
= 25166151, root = 51, subwindow = 0, time = 1091390837, x = 546, y = 118,
  x_root = 2467, y_root = 229, state = 0, button = 1, same_screen = 1}

I haven't yet pursued further executions (I need to sit in front of the
second, 60-inch 4K display for this!), but will do (so, advice is welcome!).

        Eijiro

[-- Attachment #2: Type: text/html, Size: 10676 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics]

 >> Can you mark text with the mouse?
 > No, I cannot.

So the mouse down event is probably not recognized.

 >> Does the bug happen only when the
 >> entire frame is positioned to the right of 3840
 > Yes, that's the case.
 >
 >> or do you see it with
 >> a frame starting before 3840 but extending to the right of the display
 >> as well?
 > This situation does*not*  exhibit the bug.

Thanks for clarifying this.

 > Thanks!  I built both Emacs 25.1 and 26.2 (latest release) from the
 > sources, and confirmed that*both*  exhibits the same problem in my
 > environment.
 > I run gdb for the latter (Emacs 26.2)

Please continue using 26.2 for debugging.

 > and the values of *dpyinfo and
 > event->xbutton at that code point (line 8848) are:
 >
 > When the problem occurs:

These do not reveal any great differences, I suppose the
x_root values

 >    x_root = 4326, y_root = 281, state = 0, button = 1, same_screen = 1}

and

 >    x_root = 2467, y_root = 229, state = 0, button = 1, same_screen = 1}

are the expected ones, the first larger than 3840 the second smaller.

 > I haven't yet pursued further executions (I need to sit in front of the
 > second, 60-inch 4K display for this!), but will do (so, advice is welcome!).

The subsequent code is among the most convoluted ones Emacs has,
sprinkled with USE_GTK, USE_X_TOOLKIT and USE_TOOLKIT_SCROLL_BARS
defines, so you have all my sympathy.  But maybe stepping into
x_window_to_frame already exhibits that the latter is not able to find
a suitable frame ...

martin

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Tue, Jul 30, 2019 at 4:01 PM martin rudalics <rudalics@gmx.at> wrote:
>  >> Can you mark text with the mouse?
>  > No, I cannot.
> So the mouse down event is probably not recognized.

In fact, it seems partially recognized.  I find the situation with
split windows (C-x 3) even weirder - too weird that I cannot explain
in text, so forgive me for the Dropbox link to a ~100 MB movie (with
sounds of the mouse button up and down - sorry for my unstable left
hand!):

https://www.dropbox.com/s/dbzigg9qggkyvig/IMG_6263.MOV?dl=0

As you can see, the behavior of mouse clicks on the right split window
seems almost random.  The environment is:

- My left 1920x1080 monitor is
https://www.dropbox.com/s/32f4pijigil3dgf/IMG_6260.JPG?dl=0

- My right 3840x2160 monitor is
https://www.dropbox.com/s/2advpxq1988uxac/IMG_6259.JPG?dl=0

- The border between the split windows of Emacs is slightly to the
right of the center of the right monitor.

- The X server treats the two monitors like a single 5760x2160 monitor.

- Given that, there seems nothing wrong with the output of xdpyinfo
and (display-monitor-attributes-list).

- There also seems nothing wrong with other X clients or GTK applications.

An additional (perhaps important) observation is:

- The problem occurs only when the right display is added after the X
server (and its first X client - mlterm in my case) started.

>  > I haven't yet pursued further executions (I need to sit in front of the
>  > second, 60-inch 4K display for this!), but will do (so, advice is welcome!).
>
> The subsequent code is among the most convoluted ones Emacs has,
> sprinkled with USE_GTK, USE_X_TOOLKIT and USE_TOOLKIT_SCROLL_BARS
> defines, so you have all my sympathy.  But maybe stepping into
> x_window_to_frame already exhibits that the latter is not able to find
> a suitable frame ...

The code is fine, but I just cannot carry the 60-inch monitor with me
to other places (lecture halls, meeting rooms, cafe, home, etc.) and
have to find time:-) to sit in my office to investigate this (but I
will continue to look into what's happening)!:-)

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Tue, 30 Jul 2019 21:01:00 +0900
> Cc: Eli Zaretskii <eliz@gnu.org>, 36779@debbugs.gnu.org, 
> 	Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> 
> - The problem occurs only when the right display is added after the X
> server (and its first X client - mlterm in my case) started.
> 
> >  > I haven't yet pursued further executions (I need to sit in front of the
> >  > second, 60-inch 4K display for this!), but will do (so, advice is welcome!).
> >
> > The subsequent code is among the most convoluted ones Emacs has,
> > sprinkled with USE_GTK, USE_X_TOOLKIT and USE_TOOLKIT_SCROLL_BARS
> > defines, so you have all my sympathy.  But maybe stepping into
> > x_window_to_frame already exhibits that the latter is not able to find
> > a suitable frame ...
> 
> The code is fine, but I just cannot carry the 60-inch monitor with me
> to other places (lecture halls, meeting rooms, cafe, home, etc.) and
> have to find time:-) to sit in my office to investigate this (but I
> will continue to look into what's happening)!:-)

Could all this be somehow related to the GTK HiDPI thing, perhaps?

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Robert Pluim]

>>>>> On Tue, 30 Jul 2019 21:01:00 +0900, Eijiro Sumii <sumii@ecei.tohoku.ac.jp> said:

    Eijiro> On Tue, Jul 30, 2019 at 4:01 PM martin rudalics <rudalics@gmx.at> wrote:
    >> >> Can you mark text with the mouse?
    >> > No, I cannot.
    >> So the mouse down event is probably not recognized.

    Eijiro> In fact, it seems partially recognized.  I find the situation with
    Eijiro> split windows (C-x 3) even weirder - too weird that I cannot explain
    Eijiro> in text, so forgive me for the Dropbox link to a ~100 MB movie (with
    Eijiro> sounds of the mouse button up and down - sorry for my unstable left
    Eijiro> hand!):

    Eijiro> https://www.dropbox.com/s/dbzigg9qggkyvig/IMG_6263.MOV?dl=0

    Eijiro> As you can see, the behavior of mouse clicks on the right split window
    Eijiro> seems almost random.  The environment is:

    Eijiro> - My left 1920x1080 monitor is
    Eijiro> https://www.dropbox.com/s/32f4pijigil3dgf/IMG_6260.JPG?dl=0

    Eijiro> - My right 3840x2160 monitor is
    Eijiro> https://www.dropbox.com/s/2advpxq1988uxac/IMG_6259.JPG?dl=0

    Eijiro> - The border between the split windows of Emacs is slightly to the
    Eijiro> right of the center of the right monitor.

    Eijiro> - The X server treats the two monitors like a single 5760x2160 monitor.

That seems strange: It scales the height of the left monitor but not
the width? Or does the X server pretend that itʼs a single monitor
with a chunk missing?

Regards

Robert

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

> Or does the X server pretend that itʼs a single monitor
> with a chunk missing?

Yes, and everything seems to work well *except for* this problem with Emacs
(I'm still unsure which "side", or what, is causing the problem).

[-- Attachment #2: Type: text/html, Size: 456 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics]

 > - My left 1920x1080 monitor is
 > https://www.dropbox.com/s/32f4pijigil3dgf/IMG_6260.JPG?dl=0
 >
 > - My right 3840x2160 monitor is
 > https://www.dropbox.com/s/2advpxq1988uxac/IMG_6259.JPG?dl=0
 >
 > - The border between the split windows of Emacs is slightly to the
 > right of the center of the right monitor.

But this means that your Emacs frame starts before the critical mark
of 3840 contradicting your earlier response

 >> Does the bug happen only when the
 >> entire frame is positioned to the right of 3840
 >
 > Yes, that's the case.

 > An additional (perhaps important) observation is:
 >
 > - The problem occurs only when the right display is added after the X
 > server (and its first X client - mlterm in my case) started.

Did you start Emacs before adding the right display or after?

martin

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

>  > - My left 1920x1080 monitor is
>  > https://www.dropbox.com/s/32f4pijigil3dgf/IMG_6260.JPG?dl=0
>  >
>  > - My right 3840x2160 monitor is
>  > https://www.dropbox.com/s/2advpxq1988uxac/IMG_6259.JPG?dl=0
>  >
>  > - The border between the split windows of Emacs is slightly to the
>  > right of the center of the right monitor.
>
> But this means that your Emacs frame starts before the critical mark
> of 3840 contradicting your earlier response


>
>  >> Does the bug happen only when the
>  >> entire frame is positioned to the right of 3840
>  >
>  > Yes, that's the case.


I hadn't tried split windows at that time.  This time, only the right split
window starts at x > 3840 and exhibits the problem, while the left one does
not, as you can see in the movie.


>
>  > An additional (perhaps important) observation is:
>  >
>  > - The problem occurs only when the right display is added after the X
>  > server (and its first X client - mlterm in my case) started.
>
> Did you start Emacs before adding the right display or after?


The problem occurs in both cases.

[-- Attachment #2: Type: text/html, Size: 2007 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

P.S.

On Wed, Jul 31, 2019 at 6:27 AM Eijiro Sumii <sumii@ecei.tohoku.ac.jp> wrote:
>> Or does the X server pretend that itʼs a single monitor
>> with a chunk missing?
>
> Yes, and everything seems to work well *except for* this problem with Emacs (I'm still unsure which "side", or what, is causing the problem).

For reference, I tried setting the resolution of both monitors to 1920
x 1080, so that the X server treats them like a single 3840 x 1080
monitor with no "missing chunk"; the result is that mouse clicks on an
Emacs window/frame don't work when it is positioned at x > 1920 (again
everything else seems fine as far as I checked).

I will continue investigation on these mysteries.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 2472 bytes --]

After more investigations (with Emacs 26.2 and GTK 3.22.11 - the
latter is old but easier to compile in my environment), it turned out
that the x-coordinates given to (GTK and) Emacs from the X server are
sometimes (though not always) incorrect and negative:

Thread 1 "emacs" hit Breakpoint 1, handle_one_xevent (dpyinfo=0x2da2c60,
event=0x7ffffffecf40, finish=0xc42d8c <current_finish>,
hold_quit=0x7ffffffed210)    at xterm.c:8838
8838            bool tool_bar_p = false;
(gdb) display event->xbutton
1: event->xbutton = {type = 4, serial = 3674, send_event = 0, display =
0x2d6d000, window = 12583239, root = 51, subwindow = 0, time = 1342862408,
  x = -601, y = 206, x_root = 1919, y_root = 372, state = 0, button = 1,
same_screen = 1}
(gdb) up
#1  0x0000000000519853 in event_handler_gdk (gxev=0x7ffffffecf40,
ev=0x2d87b50, data=0x0) at xterm.c:7594
7594          += handle_one_xevent (dpyinfo, xev, &current_finish,
(gdb)
#2  0x00007ffffdb85dc8 in gdk_event_apply_filters (xevent=0x7ffffffecf40,
event=0x2d87b50, window=0x0) at gdkeventsource.c:79
79          result = filter->function (xevent, event, filter->data);
(gdb)
#3  0x00007ffffdb861ba in gdk_event_source_translate_event
(event_source=0x2d87780, xevent=0x7ffffffecf40) at gdkeventsource.c:198
198          result = gdk_event_apply_filters (xevent, event, NULL);
(gdb)
#4  0x00007ffffdb86543 in _gdk_x11_display_queue_events (display=0x2d79100)
at gdkeventsource.c:341
341          event = gdk_event_source_translate_event (event_source,
&xevent);
(gdb)
#5  0x00007ffffdb3846a in gdk_display_get_event (display=0x2d79100) at
gdkdisplay.c:438
438        GDK_DISPLAY_GET_CLASS (display)->queue_events (display);
(gdb) down
#4  0x00007ffffdb86543 in _gdk_x11_display_queue_events (display=0x2d79100)
at gdkeventsource.c:341
341          event = gdk_event_source_translate_event (event_source,
&xevent);
(gdb) display xevent->xbutton
2: xevent->xbutton = {type = 4, serial = 3674, send_event = 0, display =
0x2d6d000, window = 12583239, root = 51, subwindow = 0, time = 1342862408,
  x = -601, y = 206, x_root = 1919, y_root = 372, state = 0, button = 1,
same_screen = 1}

According to the user support, this is a limitation of the
(proprietary) X server when multiple monitors and resolutions are
switched after it has started.  Why this happens only to Emacs (not
other X clients or GTK applications) is still a mystery to me, but I
think we can close this issue.  Sorry and _many_ thanks for all the
help!

[-- Attachment #2: Type: text/html, Size: 2712 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics]

 > After more investigations (with Emacs 26.2 and GTK 3.22.11 - the
 > latter is old but easier to compile in my environment), it turned out
 > that the x-coordinates given to (GTK and) Emacs from the X server are
 > sometimes (though not always) incorrect and negative:
[...]
 > According to the user support, this is a limitation of the
 > (proprietary) X server when multiple monitors and resolutions are
 > switched after it has started.  Why this happens only to Emacs (not
 > other X clients or GTK applications) is still a mystery to me, but I
 > think we can close this issue.  Sorry and _many_ thanks for all the
 > help!

Could you please provide us a few lines (including details about that
X server) so we can add them to etc/PROBLEMS.

Thanks, martin

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

Sorry for my late response!

On Wed, Aug 7, 2019 at 9:04 PM martin rudalics <rudalics@gmx.at> wrote:
> Could you please provide us a few lines (including details about that
> X server) so we can add them to etc/PROBLEMS.

How about:

----------
* X runtime problems

** General X problems

*** Coordinates of mouse clicks not recognized correctly on multiple monitors

This problem happens on a proprietary X server ( http://www.astec-x.com/ )
when the number of monitors is changed after the server has started.
It is a limitation of the server according to the manufacturer, but
known to exhibit only in combination with Emacs (not other X clients
or GNOME applications) for some unknown reason.  See
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
----------

Thanks,

        Eijiro

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Tue, 13 Aug 2019 18:09:00 +0900
> Cc: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>, 36779@debbugs.gnu.org
> 
> * X runtime problems
> 
> ** General X problems
> 
> *** Coordinates of mouse clicks not recognized correctly on multiple monitors
> 
> This problem happens on a proprietary X server ( http://www.astec-x.com/ )
> when the number of monitors is changed after the server has started.
> It is a limitation of the server according to the manufacturer, but
> known to exhibit only in combination with Emacs (not other X clients
> or GNOME applications) for some unknown reason.  See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
> ----------

Thanks.  Some comments:

  . We generally avoid naming proprietary products, and instead say
    something like "some proprietary X servers".
  . The part that this problem is only known to happen with Emacs
    doesn't seem important (this is, after all, a file that deals
    solely with Emacs-related problems), and I'd omit it.
  . I'd prefer not to send the reader to read the bug discussion, and
    instead would tell here the important parts of what was said there
    that clarify the issue (if there are such details there).
  . We usually try to describe some workarounds -- do they exist in
    this case?

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Tue, Aug 13, 2019 at 11:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
...
> > * X runtime problems
> >
> > ** General X problems
> >
> > *** Coordinates of mouse clicks not recognized correctly on multiple monitors
> >
> > This problem happens on a proprietary X server ( http://www.astec-x.com/ )
> > when the number of monitors is changed after the server has started.
> > It is a limitation of the server according to the manufacturer, but
> > known to exhibit only in combination with Emacs (not other X clients
> > or GNOME applications) for some unknown reason.  See
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
> > ----------
>
> Thanks.  Some comments:
>
>   . We generally avoid naming proprietary products, and instead say
>     something like "some proprietary X servers".

I gave the (link to) details of the X server (while avoiding to write
the product name, though the address includes it, which in fact may be
useful when searching the file for the former as long as the case is
ignored) since I was asked to do so.  The description "some
proprietary X servers" is not factual since (at least) I am not aware
of any other X server that exhibits the problem.  I had considered
"some proprietary X server" of course but that does not seem to give
useful information (if we keep the description vague, what is the
purpose of the file?).

>   . The part that this problem is only known to happen with Emacs
>     doesn't seem important (this is, after all, a file that deals
>     solely with Emacs-related problems), and I'd omit it.

That part is important since, while the manufacturer says the problem
is due to a limitation of the X server, it seems to happen only to
Emacs, which greatly confused me and is crucial information for
possible users in the same situation.

>   . I'd prefer not to send the reader to read the bug discussion, and
>     instead would tell here the important parts of what was said there
>     that clarify the issue (if there are such details there).

I linked to this discussion since the "details" are too complex to be
summarized in "a few lines" (as I was instructed).  Personally, I wish
if other entries in the file also included links to more detailed
discussions!

>   . We usually try to describe some workarounds -- do they exist in
>     this case?

The workaround is to avoid changing the monitor configuration after
the X server has started (or, equivalently, restart the X server every
time after such a change), which I believe is already clear from my
description.

Cheers,

        Eijiro

bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics]

 >>    . We generally avoid naming proprietary products, and instead say
 >>      something like "some proprietary X servers".
 >
 > I gave the (link to) details of the X server (while avoiding to write
 > the product name, though the address includes it, which in fact may be
 > useful when searching the file for the former as long as the case is
 > ignored) since I was asked to do so.  The description "some
 > proprietary X servers" is not factual since (at least) I am not aware
 > of any other X server that exhibits the problem.  I had considered
 > "some proprietary X server" of course but that does not seem to give
 > useful information (if we keep the description vague, what is the
 > purpose of the file?).

I agree with Eijiro and consider his description quite tactful in this
regard.

 >>    . The part that this problem is only known to happen with Emacs
 >>      doesn't seem important (this is, after all, a file that deals
 >>      solely with Emacs-related problems), and I'd omit it.
 >
 > That part is important since, while the manufacturer says the problem
 > is due to a limitation of the X server, it seems to happen only to
 > Emacs, which greatly confused me and is crucial information for
 > possible users in the same situation.

This part could be omitted if we left in the reference to the bug
report.

 >    . I'd prefer not to send the reader to read the bug discussion, and
 >>      instead would tell here the important parts of what was said there
 >>      that clarify the issue (if there are such details there).
 >
 > I linked to this discussion since the "details" are too complex to be
 > summarized in "a few lines" (as I was instructed).  Personally, I wish
 > if other entries in the file also included links to more detailed
 > discussions!

Since I often miss such links too I strongly agree with Eijiro.

 >>    . We usually try to describe some workarounds -- do they exist in
 >>      this case?
 >
 > The workaround is to avoid changing the monitor configuration after
 > the X server has started (or, equivalently, restart the X server every
 > time after such a change), which I believe is already clear from my
 > description.

Still that workaround should be explicitly mentioned.

martin

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Wed, Aug 14, 2019 at 5:59 PM martin rudalics <rudalics@gmx.at> wrote:
> This part could be omitted if we left in the reference to the bug
> report.
...
> Still that workaround should be explicitly mentioned.

OK, then:

----------
* X runtime problems

** General X problems

*** Coordinates of mouse clicks not recognized correctly on multiple monitors

This problem happens on a proprietary X server ( http://www.astec-x.com/ )
when the number of monitors is changed after the server has started.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
A workaround is to restart the X server after the monitor configuration
has been changed.
----------

Best,

        Eijiro

bug#36779: 25.1; mouse click not recognized for frames with large left position

[martin rudalics]

 > ----------
 > * X runtime problems
 >
 > ** General X problems
 >
 > *** Coordinates of mouse clicks not recognized correctly on multiple monitors
 >
 > This problem happens on a proprietary X server ( http://www.astec-x.com/ )
 > when the number of monitors is changed after the server has started.
 > See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
 > A workaround is to restart the X server after the monitor configuration
 > has been changed.
 > ----------

I'd install this unless Eli still objects.  Eli, do you really
disapprove linking to bug reports?  If so, I'd have to fix some
earlier other additions too.

Thanks, martin

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>, 36779@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 15 Aug 2019 10:11:08 +0200
> 
> I'd install this unless Eli still objects.

I don't object, I'm just unhappy.

> Eli, do you really disapprove linking to bug reports?

I think PROBLEMS entries should be short and concise.  They should
tell the reader what is the reason for the problem and how to fix it
in a cookbook fashion.  Sending the reader to read up a discussion of
a bug is inconsistent with doing that.  Let's please not forget that
people who read PROBLEMS are already annoyed by the problem, they are
not in the mood of reading too much.  They need TL;DR, the bottom
line.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Fri, Aug 16, 2019 at 12:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
> I think PROBLEMS entries should be short and concise.  They should
> tell the reader what is the reason for the problem

For this purpose, I think the first sentence suffices as a minimal
summary, while the details can only be explained via the link.

> and how to fix it

Again I think this is clear from the first sentence (and an explicit
workaround has also been added in the third sentence).

> in a cookbook fashion.  Sending the reader to read up a discussion of
> a bug is inconsistent with doing that.

Since the first (and third) sentenc(es) give(s) a cookbook summary,
the details can best be left for the link (at least that was my
intention when I wrote it, which I believe is clear from the explicit
phrase "for details").

> Let's please not forget that
> people who read PROBLEMS are already annoyed by the problem, they are
> not in the mood of reading too much.  They need TL;DR, the bottom
> line.

Again I believe the first (and third) sentenc(es) is/are the necessary
and sufficient TL;DR, while the link is needed for people who want to
know the details (at least I would be annoyed if there is only a few
line summary and no more information).

Best,

	Eijiro

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> Date: Fri, 16 Aug 2019 16:33:56 +0900 (JST)
> Cc: rudalics@gmx.at, 36779@debbugs.gnu.org, sumii@ecei.tohoku.ac.jp
> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> 
> On Fri, Aug 16, 2019 at 12:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > I think PROBLEMS entries should be short and concise.  They should
> > tell the reader what is the reason for the problem
> 
> For this purpose, I think the first sentence suffices as a minimal
> summary, while the details can only be explained via the link.
> 
> > and how to fix it
> 
> Again I think this is clear from the first sentence (and an explicit
> workaround has also been added in the third sentence).

My point was that we should try explaining the reasons and the fix
both concisely and completely, such that there would be no reason to
read about the details, none at all.  IOW, PROBLEMS should be
self-contained.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

> My point was that we should try explaining the reasons and the fix
> both concisely and completely, such that there would be no reason to
> read about the details, none at all.  IOW, PROBLEMS should be
> self-contained.


I'm afraid that is just not possible, at least in this case.

[-- Attachment #2: Type: text/html, Size: 517 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Fri, 16 Aug 2019 17:43:42 +0900
> Cc: 36779@debbugs.gnu.org, Eijiro Sumii <sumii@ecei.tohoku.ac.jp>, rudalics@gmx.at
> 
>  My point was that we should try explaining the reasons and the fix
>  both concisely and completely, such that there would be no reason to
>  read about the details, none at all.  IOW, PROBLEMS should be
>  self-contained.
> 
> I'm afraid that is just not possible, at least in this case.

I'm sure I can write a self-contained entry for this problem, if you
want me to.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Fri, Aug 16, 2019 at 9:49 PM Eli Zaretskii <eliz@gnu.org> wrote:
> I'm sure I can write a self-contained entry for this problem, if you
> want me to.

As I wrote a few times, the reason why the problem seems to happen
only to Emacs is still unknown, and I presume some readers would be
eager to understand the (rather complex) situation, for which they
have to read the gdb logs and watch the movie.  I don't think there is
any way to explain them in "a few lines".

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Fri, 16 Aug 2019 22:03:38 +0900
> Cc: 36779@debbugs.gnu.org, rudalics@gmx.at, 
> 	Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> 
> On Fri, Aug 16, 2019 at 9:49 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > I'm sure I can write a self-contained entry for this problem, if you
> > want me to.
> 
> As I wrote a few times, the reason why the problem seems to happen
> only to Emacs is still unknown, and I presume some readers would be
> eager to understand the (rather complex) situation, for which they
> have to read the gdb logs and watch the movie.  I don't think there is
> any way to explain them in "a few lines".

An entry in PROBLEMS doesn't need to explain all the internal details,
just what software causes it and how to work around it.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

> > As I wrote a few times, the reason why the problem seems to happen
> > only to Emacs is still unknown, and I presume some readers would be
> > eager to understand the (rather complex) situation, for which they
> > have to read the gdb logs and watch the movie.  I don't think there is
> > any way to explain them in "a few lines".
>
> An entry in PROBLEMS doesn't need to explain all the internal details,
> just what software causes it and how to work around it.


In our case "what software causes it" (Emacs or the X server) is not clear,
and the "workaround" is quite unsatisfactory (having to restart the entire
X system - the server and all the clients).  That's why some readers would
need the link to the details.  (At least I would be rather frustrated if
the file only tells the problem without information for such details!)

[-- Attachment #2: Type: text/html, Size: 1166 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Sat, 17 Aug 2019 06:09:54 +0900
> Cc: 36779@debbugs.gnu.org, Eijiro Sumii <sumii@ecei.tohoku.ac.jp>, rudalics@gmx.at
> 
>  > As I wrote a few times, the reason why the problem seems to happen
>  > only to Emacs is still unknown, and I presume some readers would be
>  > eager to understand the (rather complex) situation, for which they
>  > have to read the gdb logs and watch the movie.  I don't think there is
>  > any way to explain them in "a few lines".
> 
>  An entry in PROBLEMS doesn't need to explain all the internal details,
>  just what software causes it and how to work around it.
> 
> In our case "what software causes it" (Emacs or the X server) is not clear, and the "workaround" is quite
> unsatisfactory (having to restart the entire X system - the server and all the clients).  That's why some readers
> would need the link to the details.  (At least I would be rather frustrated if the file only tells the problem without
> information for such details!)

Like I said: I'm sure I can do that, if you are interested to see how.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

> Like I said: I'm sure I can do that, if you are interested to see how.

I'm not so sure, but I think an alternative proposal is always good.

Thanks,

        Eijiro

[-- Attachment #2: Type: text/html, Size: 381 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Stefan Kangas]

martin rudalics <rudalics@gmx.at> writes:

>> ----------
>> * X runtime problems
>>
>> ** General X problems
>>
>> *** Coordinates of mouse clicks not recognized correctly on multiple monitors
>>
>> This problem happens on a proprietary X server ( http://www.astec-x.com/ )
>> when the number of monitors is changed after the server has started.
>> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
>> A workaround is to restart the X server after the monitor configuration
>> has been changed.
>> ----------
>
> I'd install this unless Eli still objects.  Eli, do you really
> disapprove linking to bug reports?  If so, I'd have to fix some
> earlier other additions too.

Nothing like this was installed into PROBLEMS, AFAICT.

Eli offered to write a more concise entry here, but was discouraged from
doing that for some inexplicable reason.

May I propose that we either install the above, or (even better) that
Eli summarizes this problem as he see fit and installs it?

Best regards,
Stefan Kangas

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 25 Aug 2020 17:15:41 -0700
> Cc: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>, Eli Zaretskii <eliz@gnu.org>, 36779@debbugs.gnu.org
> 
> martin rudalics <rudalics@gmx.at> writes:
> 
> >> ----------
> >> * X runtime problems
> >>
> >> ** General X problems
> >>
> >> *** Coordinates of mouse clicks not recognized correctly on multiple monitors
> >>
> >> This problem happens on a proprietary X server ( http://www.astec-x.com/ )
> >> when the number of monitors is changed after the server has started.
> >> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
> >> A workaround is to restart the X server after the monitor configuration
> >> has been changed.
> >> ----------
> >
> > I'd install this unless Eli still objects.  Eli, do you really
> > disapprove linking to bug reports?  If so, I'd have to fix some
> > earlier other additions too.
> 
> Nothing like this was installed into PROBLEMS, AFAICT.
> 
> Eli offered to write a more concise entry here, but was discouraged from
> doing that for some inexplicable reason.
> 
> May I propose that we either install the above, or (even better) that
> Eli summarizes this problem as he see fit and installs it?

I think just removing the sentence that refers to the bug report
should do in this case, as both the problem and the only workaround we
know about are already described.  With that change, we can install
this in PROBLEMS.

Thanks.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

Can't the case number (#36779) be included at least, for those who need
more details (without having to Googling around)?

Cheers,

        Eijiro

2020年8月26日(水) 15:11 Eli Zaretskii <eliz@gnu.org>:

> > From: Stefan Kangas <stefan@marxist.se>
>
> > Date: Tue, 25 Aug 2020 17:15:41 -0700
>
> > Cc: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>, Eli Zaretskii <eliz@gnu.org>,
> 36779@debbugs.gnu.org
>
> >
>
> > martin rudalics <rudalics@gmx.at> writes:
>
> >
>
> > >> ----------
>
> > >> * X runtime problems
>
> > >>
>
> > >> ** General X problems
>
> > >>
>
> > >> *** Coordinates of mouse clicks not recognized correctly on multiple
> monitors
>
> > >>
>
> > >> This problem happens on a proprietary X server (
> http://www.astec-x.com/ )
>
> > >> when the number of monitors is changed after the server has started.
>
> > >> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36779 for details.
>
> > >> A workaround is to restart the X server after the monitor
> configuration
>
> > >> has been changed.
>
> > >> ----------
>
> > >
>
> > > I'd install this unless Eli still objects.  Eli, do you really
>
> > > disapprove linking to bug reports?  If so, I'd have to fix some
>
> > > earlier other additions too.
>
> >
>
> > Nothing like this was installed into PROBLEMS, AFAICT.
>
> >
>
> > Eli offered to write a more concise entry here, but was discouraged from
>
> > doing that for some inexplicable reason.
>
> >
>
> > May I propose that we either install the above, or (even better) that
>
> > Eli summarizes this problem as he see fit and installs it?
>
>
>
> I think just removing the sentence that refers to the bug report
>
> should do in this case, as both the problem and the only workaround we
>
> know about are already described.  With that change, we can install
>
> this in PROBLEMS.
>
>
>
> Thanks.
>
>

[-- Attachment #2: Type: text/html, Size: 3038 bytes --]

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Wed, 26 Aug 2020 15:19:39 +0900
> Cc: 36779@debbugs.gnu.org, Stefan Kangas <stefan@marxist.se>, rudalics@gmx.at
> 
> Can't the case number (#36779) be included at least, for those who need more details (without having to
> Googling around)?

Which parts of the discussion of bug#36779 do you find useful for
understanding the issue and how to work around it?  I skimmed the
discussion and found nothing useful there, but maybe I missed
something.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eijiro Sumii]

On Wed, Aug 26, 2020 at 3:35 PM Eli Zaretskii <eliz@gnu.org> wrote:
> Which parts of the discussion of bug#36779 do you find useful for
> understanding the issue and how to work around it?  I skimmed the
> discussion and found nothing useful there, but maybe I missed
> something.

Those who are troubled with a similar problem, or those who try to fix
it, would want to know details such as the video and logs, just for
example.

We have been delayed for more than a year - I am not sure if this is normal.

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Eijiro Sumii <sumii@ecei.tohoku.ac.jp>
> Date: Wed, 26 Aug 2020 16:40:56 +0900
> Cc: 36779@debbugs.gnu.org, stefan@marxist.se, rudalics@gmx.at
> 
> On Wed, Aug 26, 2020 at 3:35 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > Which parts of the discussion of bug#36779 do you find useful for
> > understanding the issue and how to work around it?  I skimmed the
> > discussion and found nothing useful there, but maybe I missed
> > something.
> 
> Those who are troubled with a similar problem, or those who try to fix
> it, would want to know details such as the video and logs, just for
> example.

Sorry, I don't understand: which video and what logs?

The PROBLEMS file is not for people who fix bugs, it is for people who
need to work around the problems which cannot be fixed.  People who
want to fix bugs should search the Emacs bug database.

> We have been delayed for more than a year - I am not sure if this is normal.

I don't understand this part either: what kind of delay are you
talking about?  Who was delayed, and how?

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 363 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> I think just removing the sentence that refers to the bug report
> should do in this case, as both the problem and the only workaround we
> know about are already described.  With that change, we can install
> this in PROBLEMS.

I've pushed the attached patch to master as commit 2fd9860481.

Should this bug be left open?

[-- Attachment #2: 0001-Add-ASTEC-X-issue-to-PROBLEMS.patch --]
[-- Type: text/x-diff, Size: 1045 bytes --]

From 2fd9860481833434367834926d14a0dc299edcce Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Thu, 27 Aug 2020 07:58:17 +0200
Subject: [PATCH] Add ASTEC-X issue to PROBLEMS

* etc/PROBLEMS: Mention problem with multiple monitors on proprietary
X Server ASTEC-X.  (Bug#36779)
---
 etc/PROBLEMS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index f68a183c5d..67537f6e33 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1602,6 +1602,12 @@ even if you should be able to paste, and similar).
 You can get back menus on each frame by starting emacs like this:
 % env UBUNTU_MENUPROXY= emacs
 
+*** Mouse click coordinates not recognized correctly on multiple monitors.
+
+This happens on the proprietary X server ASTEC-X when the number of
+monitors is changed after the server has started.  A workaround is to
+restart the X server after the monitor configuration has been changed.
+
 * Runtime problems on character terminals
 
 ** The meta key does not work on xterm.
-- 
2.28.0

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 27 Aug 2020 02:36:47 -0700
> Cc: rudalics@gmx.at, sumii@ecei.tohoku.ac.jp, 36779@debbugs.gnu.org
> 
> I've pushed the attached patch to master as commit 2fd9860481.

Thanks.

> Should this bug be left open?

What else is left to do here?

bug#36779: 25.1; mouse click not recognized for frames with large left position

[Stefan Kangas]

Eijiro Sumii <sumii@ecei.tohoku.ac.jp> writes:

> According to the user support, this is a limitation of the
> (proprietary) X server when multiple monitors and resolutions are
> switched after it has started.  Why this happens only to Emacs (not
> other X clients or GTK applications) is still a mystery to me, but I
> think we can close this issue.  Sorry and _many_ thanks for all the
> help!

Eli Zaretskii <eliz@gnu.org> writes:

>> Should this bug be left open?
>
> What else is left to do here?

It looks like there is nothing left to do, so I'm closing this bug now.