GNU bug report logs - #74220
invisible cursor

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74220 in the body.
You can then email your comments to 74220 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Avraham Pinkas <ampinkas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: invisible cursor
Date: Tue, 5 Nov 2024 22:06:30 +0200

[Message part 1 (text/plain, inline)]

in a terminal (TTY), while gpm-mouse-mode is enabled, the cursor is
invisible.


In GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41,
 cairo version 1.18.0) of 2024-04-01, modified by Debian built on
 lcy02-amd64-083
Windowing system distributor 'The X.Org Foundation', version 11.0.12302006
System Description: Ubuntu 24.04.1 LTS

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --with-cairo --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
 -ffile-prefix-map=/build/emacs-0yuuFP/emacs-29.3+1=.
 -fstack-protector-strong -fstack-clash-protection -Wformat
 -Werror=format-security -fcf-protection
 -fdebug-prefix-map=/build/emacs-0yuuFP/emacs-29.3+1=/usr/src/emacs-1:29.3+1-1ubuntu2
 -Wall' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=3'
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

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

Important settings:
  value of $LC_MONETARY: en_IL.UTF-8
  value of $LC_NUMERIC: en_IL.UTF-8
  value of $LC_TIME: en_IL.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  timeclock-mode-line-display: t
  save-place-mode: t
  display-time-mode: t
  display-battery-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  isearch-fold-quotes-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  size-indication-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug mule-util info comp comp-cstr warnings
cus-edit pp cus-start org-element org-persist org-id org-refile avl-tree
generator oc-basic cl-extra help-mode ol-eww eww xdg url-queue thingatpt
mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill
kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus
gnus-cloud nnimap nnmail mail-source utf7 nnoo parse-time gnus-spec
gnus-int gnus-range message sendmail yank-media puny rfc822 mml mml-sec
epa derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils
mailheader gnus-win gnus nnheader gnus-util text-property-search
mail-utils range mm-util mail-prsvr wid-edit ol-docview doc-view
filenotify jka-compr image-mode exif dired dired-loaddefs ol-bibtex
bibtex iso8601 ol-bbdb ol-w3m ol-doi org-link-doi org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete
pcomplete comint ansi-osc ansi-color ring org-list org-footnote
org-faces org-entities time-date noutline outline icons ob-emacs-lisp
ob-core ob-eval org-cycle org-table ol rx org-fold org-fold-core
org-keys oc org-loaddefs find-func cal-menu calendar cal-loaddefs
org-version org-compat org-macs format-spec timeclock saveplace t-mouse
time battery dbus xml desktop frameset cus-load finder-inf package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs
cl-lib devhelp rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 302460 20031)
 (symbols 48 23059 0)
 (strings 32 80296 8705)
 (string-bytes 1 2415212)
 (vectors 16 47382)
 (vector-slots 8 1486833 182483)
 (floats 8 399 265)
 (intervals 56 875 0)
 (buffers 984 15))

[Message part 2 (text/html, inline)]

[#*message*-20241021-192018# (application/octet-stream, attachment)]

Message #8 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Avraham Pinkas <ampinkas <at> gmail.com>, Jared Finder <jared <at> finder.org>
Cc: 74220 <at> debbugs.gnu.org
Subject: Re: bug#74220: invisible cursor
Date: Wed, 06 Nov 2024 14:37:07 +0200

> From: Avraham Pinkas <ampinkas <at> gmail.com>
> Date: Tue, 5 Nov 2024 22:06:30 +0200
> 
> in a terminal (TTY), while gpm-mouse-mode is enabled, the cursor is invisible.

Does someone (Jared?) have a system with a gpm-mouse build and can
reproduce and debug this, please?

Message #11 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74220 <at> debbugs.gnu.org, Jared Finder <jared <at> finder.org>,
 Avraham Pinkas <ampinkas <at> gmail.com>
Subject: Re: bug#74220: invisible cursor
Date: Wed, 06 Nov 2024 14:55:33 +0100

>>>>> On Wed, 06 Nov 2024 14:37:07 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Avraham Pinkas <ampinkas <at> gmail.com>
    >> Date: Tue, 5 Nov 2024 22:06:30 +0200
    >> 
    >> in a terminal (TTY), while gpm-mouse-mode is enabled, the cursor is invisible.

    Eli> Does someone (Jared?) have a system with a gpm-mouse build and can
    Eli> reproduce and debug this, please?

Remind us what this needs? A real linux console, ie not an xterm?

Robert
-- 

Message #14 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Jared Finder <jared <at> finder.org>, Eli Zaretskii <eliz <at> gnu.org>,
 74220 <at> debbugs.gnu.org, Avraham Pinkas <ampinkas <at> gmail.com>
Subject: Re: bug#74220: invisible cursor
Date: Wed, 06 Nov 2024 15:03:29 +0100

Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> On Wed, 06 Nov 2024 14:37:07 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>
>     >> From: Avraham Pinkas <ampinkas <at> gmail.com>
>     >> Date: Tue, 5 Nov 2024 22:06:30 +0200
>     >> 
>     >> in a terminal (TTY), while gpm-mouse-mode is enabled, the cursor is invisible.
>
>     Eli> Does someone (Jared?) have a system with a gpm-mouse build and can
>     Eli> reproduce and debug this, please?
>
> Remind us what this needs? A real linux console, ie not an xterm?

Yes, GPM is for linux virtual consoles.

Message #17 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: jared <jared <at> finder.org>
To: Robert Pluim <rpluim <at> gmail.com>, Gerd Möllmann
 <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74220 <74220 <at> debbugs.gnu.org>,
 Avraham Pinkas <ampinkas <at> gmail.com>
Subject: Re: bug#74220: invisible cursor
Date: Wed, 6 Nov 2024 06:22:38 -0800

[Message part 1 (text/plain, inline)]

  
  
It requires both a Linux kernel with GPM support as well as an Emacs build with GPM enabled
  

  
I have tested GPM under a VM in the past. I can bring it up and check the state of things.   
  

  
   -- MJF
  

  

  
  
  
  
>   
> On Nov 6, 2024 at 6:03 AM, Gerd Möllmann  <gerd.moellmann <at> gmail.com>  wrote:
>   
>   
>  Robert Pluim  <rpluim <at> gmail.com>  writes:
>
> >>>>>>  On Wed, 06 Nov 2024 14:37:07 +0200, Eli Zaretskii  <eliz <at> gnu.org>  said:
> >
> >   >>  From: Avraham Pinkas  <ampinkas <at> gmail.com>
> >   >>  Date: Tue, 5 Nov 2024 22:06:30 +0200
> >   >>   
> >   >>  in a terminal (TTY), while gpm-mouse-mode is enabled, the cursor is invisible.
> >
> >  Eli>  Does someone (Jared?) have a system with a gpm-mouse build and can
> >  Eli>  reproduce and debug this, please?
> >
> >  Remind us what this needs? A real linux console, ie not an xterm?
>
> Yes, GPM is for linux virtual consoles.
>     
     

[Message part 2 (text/html, inline)]

Message #20 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Robert Pluim <rpluim <at> gmail.com>, Gerd Möllmann
 <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 74220 <74220 <at> debbugs.gnu.org>,
 Avraham Pinkas <ampinkas <at> gmail.com>
Subject: Re: bug#74220: invisible cursor
Date: Wed, 06 Nov 2024 07:38:52 -0800

>> On Nov 6, 2024 at 6:03 AM, Gerd Möllmann <gerd.moellmann <at> gmail.com> 
>> wrote:
>> 
>> Robert Pluim <rpluim <at> gmail.com> writes:
>> 
>>>>>>>> On Wed, 06 Nov 2024 14:37:07 +0200, Eli Zaretskii <eliz <at> gnu.org> 
>>>>>>>> said:
>>> 
>>>>> From: Avraham Pinkas <ampinkas <at> gmail.com>
>>>>> Date: Tue, 5 Nov 2024 22:06:30 +0200
>>>>> 
>>>>> in a terminal (TTY), while gpm-mouse-mode is enabled, the cursor is 
>>>>> invisible.
>>> 
>>> Eli> Does someone (Jared?) have a system with a gpm-mouse build and 
>>> can
>>> Eli> reproduce and debug this, please?
>>> 
>>> Remind us what this needs? A real linux console, ie not an xterm?
>> 
>> Yes, GPM is for linux virtual consoles.

I tested this locally at HEAD (b5845e) on Linux debian 6.1.0-13-amd64 
and everything is working fine.

Could you please describe what terminal (the output of "echo $TERM") and 
kernel version (the output of "uname -a") you are using when you have 
this issue? Can you try toggling M-x gpm-mouse-mode on and off and share 
if any errors are reported?

  -- MJF

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jared Finder via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Jared Finder <jared <at> finder.org>, Robert Pluim <rpluim <at> gmail.com>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 74220 <74220 <at> debbugs.gnu.org>, Avraham Pinkas <ampinkas <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#74220: invisible cursor
Date: Wed, 06 Nov 2024 17:17:49 +0100

On Wed, 06 Nov 2024 07:38:52 -0800 Jared Finder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> wrote:

>>> On Nov 6, 2024 at 6:03 AM, Gerd Möllmann <gerd.moellmann <at> gmail.com> wrote:
>>> Robert Pluim <rpluim <at> gmail.com> writes:
>>> 
>>>>>>>>> On Wed, 06 Nov 2024 14:37:07 +0200, Eli Zaretskii <eliz <at> gnu.org>
>>>>>>>>> said:
>>>> 
>>>>>> From: Avraham Pinkas <ampinkas <at> gmail.com>
>>>>>> Date: Tue, 5 Nov 2024 22:06:30 +0200
>>>>>> in a terminal (TTY), while gpm-mouse-mode is enabled, the cursor is
>>>>>> invisible.
>>>> Eli> Does someone (Jared?) have a system with a gpm-mouse build and can
>>>> Eli> reproduce and debug this, please?
>>>> Remind us what this needs? A real linux console, ie not an xterm?
>>> Yes, GPM is for linux virtual consoles.
>
> I tested this locally at HEAD (b5845e) on Linux debian 6.1.0-13-amd64 and
> everything is working fine.
>
> Could you please describe what terminal (the output of "echo $TERM") and
> kernel version (the output of "uname -a") you are using when you have this
> issue? Can you try toggling M-x gpm-mouse-mode on and off and share if any
> errors are reported?

I can reproduce the issue in the Linux terminal (echo $TERM => linux,
uname -a => Linux strobelfssd 6.10.6 #1 SMP PREEMPT_DYNAMIC Mon Aug 19
12:15:23 CEST 2024 x86_64 GNU/Linux).  When I start emacs there with -Q,
`C-h v gpm-mouse-mode' says the value is t and I see the blinking cursor
in the emacs window, but moving the mouse I see no gpm cursor, though I
can make and yank selections and pull down menus in Emacs with the mouse
(the blinking cursor is not moved by the mouse).  When I type `M-x
gpm-mouse-mode' there are no errors and a cursor appears that moves with
the mouse (the blinking cursor remains visible and unresponsive to the
mouse), though `C-h v gpm-mouse-mode' now says the value is nil; I can
make selections as before (though the highlighting is a different color
than before) but I cannot pull down menus with the mouse.  This is with
emacs-29, emacs-30 and master.

Steve Berman

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: "Jared Finder via \"Bug reports for GNU Emacs, the Swiss army knife of
 text editors\"" <bug-gnu-emacs <at> gnu.org>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 74220 <74220 <at> debbugs.gnu.org>, Avraham Pinkas <ampinkas <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Subject: Re: bug#74220: invisible cursor
Date: Sun, 17 Nov 2024 17:37:05 -0800

On 2024-11-06 08:17, Stephen Berman wrote:
> On Wed, 06 Nov 2024 07:38:52 -0800 Jared Finder via "Bug reports for 
> GNU Emacs, the Swiss army knife of text editors" 
> <bug-gnu-emacs <at> gnu.org> wrote:
> 
>> I tested this locally at HEAD (b5845e) on Linux debian 6.1.0-13-amd64 
>> and
>> everything is working fine.
>> 
>> Could you please describe what terminal (the output of "echo $TERM") 
>> and
>> kernel version (the output of "uname -a") you are using when you have 
>> this
>> issue? Can you try toggling M-x gpm-mouse-mode on and off and share if 
>> any
>> errors are reported?
> 
> I can reproduce the issue in the Linux terminal (echo $TERM => linux,
> uname -a => Linux strobelfssd 6.10.6 #1 SMP PREEMPT_DYNAMIC Mon Aug 19
> 12:15:23 CEST 2024 x86_64 GNU/Linux).  When I start emacs there with 
> -Q,

Thank you, I am able to reproduce the issue locally on "Linux debian 
6.11.5+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1~bpo12+1 
(2024-11-11) x86_64 GNU=Linux". I will investigate.

  -- MJF

Message #35 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: "Jared Finder via \"Bug reports for GNU Emacs, the Swiss army knife of
 text editors\"" <bug-gnu-emacs <at> gnu.org>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 74220 <74220 <at> debbugs.gnu.org>, Avraham Pinkas <ampinkas <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Subject: Re: bug#74220: invisible cursor
Date: Wed, 27 Nov 2024 19:13:56 -0800

On 2024-11-17 17:37, Jared Finder wrote:
> On 2024-11-06 08:17, Stephen Berman wrote:
>> On Wed, 06 Nov 2024 07:38:52 -0800 Jared Finder via "Bug reports for 
>> GNU Emacs, the Swiss army knife of text editors" 
>> <bug-gnu-emacs <at> gnu.org> wrote:
>> 
>>> I tested this locally at HEAD (b5845e) on Linux debian 6.1.0-13-amd64 
>>> and
>>> everything is working fine.
>>> 
>>> Could you please describe what terminal (the output of "echo $TERM") 
>>> and
>>> kernel version (the output of "uname -a") you are using when you have 
>>> this
>>> issue? Can you try toggling M-x gpm-mouse-mode on and off and share 
>>> if any
>>> errors are reported?
>> 
>> I can reproduce the issue in the Linux terminal (echo $TERM => linux,
>> uname -a => Linux strobelfssd 6.10.6 #1 SMP PREEMPT_DYNAMIC Mon Aug 19
>> 12:15:23 CEST 2024 x86_64 GNU/Linux).  When I start emacs there with 
>> -Q,
> 
> Thank you, I am able to reproduce the issue locally on "Linux debian 
> 6.11.5+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1~bpo12+1 
> (2024-11-11) x86_64 GNU=Linux". I will investigate.

This appears to be due to something happening at a lower level than 
Emacs, though perhaps Emacs is not interfacing with GPM correctly.

This started happening in multiple Emacs versions with Linux 6.7. I 
tested HEAD, 29.4, and 28.2 -- all three versions worked fine with Linux 
6.6.63 and then exhibit this bug starting with Linux 6.7. 
GPM_DrawPointer is still being called, of course (since this works in 
previous Linux versions), but is no longer having any effect.

I will keep investigating here.

  -- MJF

Message #41 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: "Jared Finder via \"Bug reports for GNU Emacs, the Swiss army knife of
 text editors\"" <bug-gnu-emacs <at> gnu.org>,
 Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 74220 <74220 <at> debbugs.gnu.org>, Avraham Pinkas <ampinkas <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Subject: Re: bug#74220: invisible cursor
Date: Thu, 28 Nov 2024 10:21:53 -0800

On 2024-11-27 19:13, Jared Finder wrote:
> On 2024-11-17 17:37, Jared Finder wrote:
>> On 2024-11-06 08:17, Stephen Berman wrote:
>>> On Wed, 06 Nov 2024 07:38:52 -0800 Jared Finder via "Bug reports for 
>>> GNU Emacs, the Swiss army knife of text editors" 
>>> <bug-gnu-emacs <at> gnu.org> wrote:
>>> 
>>>> I tested this locally at HEAD (b5845e) on Linux debian 
>>>> 6.1.0-13-amd64 and
>>>> everything is working fine.
>>>> 
>>>> Could you please describe what terminal (the output of "echo $TERM") 
>>>> and
>>>> kernel version (the output of "uname -a") you are using when you 
>>>> have this
>>>> issue? Can you try toggling M-x gpm-mouse-mode on and off and share 
>>>> if any
>>>> errors are reported?
>>> 
>>> I can reproduce the issue in the Linux terminal (echo $TERM => linux,
>>> uname -a => Linux strobelfssd 6.10.6 #1 SMP PREEMPT_DYNAMIC Mon Aug 
>>> 19
>>> 12:15:23 CEST 2024 x86_64 GNU/Linux).  When I start emacs there with 
>>> -Q,
>> 
>> Thank you, I am able to reproduce the issue locally on "Linux debian 
>> 6.11.5+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1~bpo12+1 
>> (2024-11-11) x86_64 GNU=Linux". I will investigate.
> 
> This appears to be due to something happening at a lower level than 
> Emacs, though perhaps Emacs is not interfacing with GPM correctly.
> 
> This started happening in multiple Emacs versions with Linux 6.7. I 
> tested HEAD, 29.4, and 28.2 -- all three versions worked fine with 
> Linux 6.6.63 and then exhibit this bug starting with Linux 6.7. 
> GPM_DrawPointer is still being called, of course (since this works in 
> previous Linux versions), but is no longer having any effect.
> 
> I will keep investigating here.

AH HA!

This was an intentional change to Linux 6.7 to avoid a potential 
privilege escalation. Specifically, apps without the capability 
CAP_SYS_ADMIN are no longer able to set the kernel selection buffer. 
Across Emacs versions, granting the Emacs binary the CAP_SYS_ADMIN 
capability (sudo setcap cap_sys_admin+ep path/to/emacs) fixes the issue.

But is this the right fix? CAP_SYS_ADMIN grants many dangerous 
capabilities on Linux. An alternative fix would be to update redisplay 
on terminals to draw the mouse cursor. Perhaps this is what is done on 
other OSes? I would like guidance here on which path is recommended.

  -- MJF

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: bug-gnu-emacs <at> gnu.org, gerd.moellmann <at> gmail.com, 74220 <at> debbugs.gnu.org,
 ampinkas <at> gmail.com, stephen.berman <at> gmx.net, rpluim <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Thu, 28 Nov 2024 22:20:28 +0200

> Date: Thu, 28 Nov 2024 10:21:53 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: "Jared Finder via \"Bug reports for GNU Emacs, the Swiss army knife of
>  text editors\"" <bug-gnu-emacs <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>,
>  Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii
>  <eliz <at> gnu.org>, 74220 <74220 <at> debbugs.gnu.org>, Avraham Pinkas
>  <ampinkas <at> gmail.com>
> 
> This was an intentional change to Linux 6.7 to avoid a potential 
> privilege escalation. Specifically, apps without the capability 
> CAP_SYS_ADMIN are no longer able to set the kernel selection buffer. 
> Across Emacs versions, granting the Emacs binary the CAP_SYS_ADMIN 
> capability (sudo setcap cap_sys_admin+ep path/to/emacs) fixes the issue.

Sorry, I don't follow: what does setting the kernel selection buffer
have to do with showing the cursor?  And how is it related to GPM?
What am I missing here?

> But is this the right fix? CAP_SYS_ADMIN grants many dangerous 
> capabilities on Linux. An alternative fix would be to update redisplay 
> on terminals to draw the mouse cursor. Perhaps this is what is done on 
> other OSes? I would like guidance here on which path is recommended.

Let's first understand the problem better.

(And I'm guessing that by "cursor" you mean "mouse pointer"?)

Message #53 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org, gerd.moellmann <at> gmail.com, 74220 <at> debbugs.gnu.org,
 ampinkas <at> gmail.com, stephen.berman <at> gmx.net, rpluim <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Thu, 28 Nov 2024 13:45:49 -0800

On 2024-11-28 12:20, Eli Zaretskii wrote:
>> Date: Thu, 28 Nov 2024 10:21:53 -0800
>> From: Jared Finder <jared <at> finder.org>
>> Cc: "Jared Finder via \"Bug reports for GNU Emacs, the Swiss army 
>> knife of
>>  text editors\"" <bug-gnu-emacs <at> gnu.org>, Robert Pluim 
>> <rpluim <at> gmail.com>,
>>  Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii
>>  <eliz <at> gnu.org>, 74220 <74220 <at> debbugs.gnu.org>, Avraham Pinkas
>>  <ampinkas <at> gmail.com>
>> 
>> This was an intentional change to Linux 6.7 to avoid a potential
>> privilege escalation. Specifically, apps without the capability
>> CAP_SYS_ADMIN are no longer able to set the kernel selection buffer.
>> Across Emacs versions, granting the Emacs binary the CAP_SYS_ADMIN
>> capability (sudo setcap cap_sys_admin+ep path/to/emacs) fixes the 
>> issue.
> 
> Sorry, I don't follow: what does setting the kernel selection buffer
> have to do with showing the cursor?  And how is it related to GPM?
> What am I missing here?
> 
>> But is this the right fix? CAP_SYS_ADMIN grants many dangerous
>> capabilities on Linux. An alternative fix would be to update redisplay
>> on terminals to draw the mouse cursor. Perhaps this is what is done on
>> other OSes? I would like guidance here on which path is recommended.
> 
> Let's first understand the problem better.
> 
> (And I'm guessing that by "cursor" you mean "mouse pointer"?)

Here's some more specifics:

Emacs draws the mouse pointer in handle_one_term_event in term.c. It 
does this by calling GPM_DrawPointer() with the intended x and y. This 
code is pretty old, a blame says it was from 2007.

GPM_DrawPointer is just a macro, see the GitHub mirror: 
https://github.com/telmich/gpm/blob/master/src/headers/gpm.h#L235. This 
calls a Linux ioctl() to draw the cursor. This code is also pretty old, 
a blame says it was from 2005.

The Linux ioctl() is called as follows, if it used symbolic constants 
and a struct instead of magic byte values:

struct {
    char  subcode;
    short xs, ys, xe, ye;
    short sel_mode;
} gpmbuf;

gpmbuf.subcode = TIOCL_SETSEL; // 2
gpmbuf.xs = gpmbuf.xe = x;
gpmbuf.ys = gpmbuf.ye = y;
gpmbuf.selmode = TIOCL_SELPOINTER; //3
ioctl(fd, TIOCLINUX, &gpmbuf);

This adds one other solution -- I could see if it is reasonable for the 
Linux kernel to not protect TIOCL_SELPOINTER while protecting the rest 
of TIOCL_SETSEL. I'm a bit nervous here as I don't understand the 
security implications of SELPOINTER vs other selections, though on first 
glance it seems reasonable.

  -- MJF

Message #59 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Fri, 29 Nov 2024 09:32:23 +0200

> Date: Thu, 28 Nov 2024 13:45:49 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: stephen.berman <at> gmx.net, bug-gnu-emacs <at> gnu.org, rpluim <at> gmail.com,
>  gerd.moellmann <at> gmail.com, 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> 
> On 2024-11-28 12:20, Eli Zaretskii wrote:
> > 
> > Sorry, I don't follow: what does setting the kernel selection buffer
> > have to do with showing the cursor?  And how is it related to GPM?
> > What am I missing here?
> > 
> >> But is this the right fix? CAP_SYS_ADMIN grants many dangerous
> >> capabilities on Linux. An alternative fix would be to update redisplay
> >> on terminals to draw the mouse cursor. Perhaps this is what is done on
> >> other OSes? I would like guidance here on which path is recommended.
> > 
> > Let's first understand the problem better.
> > 
> > (And I'm guessing that by "cursor" you mean "mouse pointer"?)
> 
> Here's some more specifics:
> 
> Emacs draws the mouse pointer in handle_one_term_event in term.c. It 
> does this by calling GPM_DrawPointer() with the intended x and y. This 
> code is pretty old, a blame says it was from 2007.
> 
> GPM_DrawPointer is just a macro, see the GitHub mirror: 
> https://github.com/telmich/gpm/blob/master/src/headers/gpm.h#L235. This 
> calls a Linux ioctl() to draw the cursor. This code is also pretty old, 
> a blame says it was from 2005.
> 
> The Linux ioctl() is called as follows, if it used symbolic constants 
> and a struct instead of magic byte values:
> 
> struct {
>      char  subcode;
>      short xs, ys, xe, ye;
>      short sel_mode;
> } gpmbuf;
> 
> gpmbuf.subcode = TIOCL_SETSEL; // 2
> gpmbuf.xs = gpmbuf.xe = x;
> gpmbuf.ys = gpmbuf.ye = y;
> gpmbuf.selmode = TIOCL_SELPOINTER; //3
> ioctl(fd, TIOCLINUX, &gpmbuf);

Thanks.  I think I see a far-away light at the end of the tunnel, but
I'm not yet sure whether it's daylight or the proverbial train.
What's missing in the above is the relation to "kernel selection
buffer".  I'm guessing that TIOCL_SETSEL is "setting the kernel
selection buffer", given its name, but I'm not sure.

> This adds one other solution -- I could see if it is reasonable for the 
> Linux kernel to not protect TIOCL_SELPOINTER while protecting the rest 
> of TIOCL_SETSEL. I'm a bit nervous here as I don't understand the 
> security implications of SELPOINTER vs other selections, though on first 
> glance it seems reasonable.

I actually wonder about something else: did the kernel developers
_intend_ to break mouse pointer drawing by GPM? or maybe they intend
to deprecate GPM as a whole?  I mean, Emacs is presumably not the only
application that uses GPM, and what you describe above is part of GPM
code, right?  So GPM should be now broken for all the other
applications as well, right?

A related question is how many Emacs users are there nowadays who run
Emacs on the Linux console and use the mouse?

If the Linux kernel developers intend to deprecate/drop GPM, and/or
GPM use in Emacs on the Linux console is not popular enough, we could
just document the need for CAP_SYS_ADMIN capability, and move on.  (We
should add that to PROBLEMS anyway, because people might be using past
Emacs versions where nothing else will work.)

Of course, if there's a better method of fixing this, we should try
it.  But since AFAIU the mouse pointer is drawn by GPM itself (am I
right?), it sounds like the fix should be done by GPM developers, no?

Message #62 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Fri, 29 Nov 2024 11:12:39 -0800

On 2024-11-28 23:32, Eli Zaretskii wrote:
>> Date: Thu, 28 Nov 2024 13:45:49 -0800
>> From: Jared Finder <jared <at> finder.org>
>> Cc: stephen.berman <at> gmx.net, bug-gnu-emacs <at> gnu.org, rpluim <at> gmail.com,
>>  gerd.moellmann <at> gmail.com, 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
>> 
>> >> But is this the right fix? CAP_SYS_ADMIN grants many dangerous
>> >> capabilities on Linux. An alternative fix would be to update redisplay
>> >> on terminals to draw the mouse cursor. Perhaps this is what is done on
>> >> other OSes? I would like guidance here on which path is recommended.
>> >
>> > Let's first understand the problem better.
>> >
>> > (And I'm guessing that by "cursor" you mean "mouse pointer"?)
>> 
>> Here's some more specifics:
>> 
>> Emacs draws the mouse pointer in handle_one_term_event in term.c. It
>> does this by calling GPM_DrawPointer() with the intended x and y. This
>> code is pretty old, a blame says it was from 2007.
>> 
>> GPM_DrawPointer is just a macro, see the GitHub mirror:
>> https://github.com/telmich/gpm/blob/master/src/headers/gpm.h#L235. 
>> This
>> calls a Linux ioctl() to draw the cursor. This code is also pretty 
>> old,
>> a blame says it was from 2005.
>> 
>> The Linux ioctl() is called as follows, if it used symbolic constants
>> and a struct instead of magic byte values:
>> 
>> struct {
>>      char  subcode;
>>      short xs, ys, xe, ye;
>>      short sel_mode;
>> } gpmbuf;
>> 
>> gpmbuf.subcode = TIOCL_SETSEL; // 2
>> gpmbuf.xs = gpmbuf.xe = x;
>> gpmbuf.ys = gpmbuf.ye = y;
>> gpmbuf.selmode = TIOCL_SELPOINTER; //3
>> ioctl(fd, TIOCLINUX, &gpmbuf);
> 
> Thanks.  I think I see a far-away light at the end of the tunnel, but
> I'm not yet sure whether it's daylight or the proverbial train.
> What's missing in the above is the relation to "kernel selection
> buffer".  I'm guessing that TIOCL_SETSEL is "setting the kernel
> selection buffer", given its name, but I'm not sure.

Yes, exactly.

The same TIOCL_SETSEL is also used for actually setting the selection. 
If selmode is TIOCL_SELCHAR, TIOCL_SELWORD, or TIOCL_SELLINE then the 
region from start to end is copied into a kernel-level buffer that can 
be pasted with TIOCL_PASTESEL.

The same TIOCL_SETSEL is also used for changes that appear to be 
completely unrelated to the kernel managed selection buffer.  Namely the 
following three modes: TIOCL_SELPOINTER, TIOCL_SELCLEAR (it only 
controls visuals), TIOCL_SELMOUSEREPORT (it reports the selection start 
coordinate).

>> This adds one other solution -- I could see if it is reasonable for 
>> the
>> Linux kernel to not protect TIOCL_SELPOINTER while protecting the rest
>> of TIOCL_SETSEL. I'm a bit nervous here as I don't understand the
>> security implications of SELPOINTER vs other selections, though on 
>> first
>> glance it seems reasonable.
> 
> I actually wonder about something else: did the kernel developers
> _intend_ to break mouse pointer drawing by GPM? or maybe they intend
> to deprecate GPM as a whole?  I mean, Emacs is presumably not the only
> application that uses GPM, and what you describe above is part of GPM
> code, right?  So GPM should be now broken for all the other
> applications as well, right?

GPM was explicitly intended to be supported from the Linux kernel 
discussions. 
https://lwn.net/ml/kernel-hardening/2023082203-slackness-sworn-2c80 <at> gregkh/.

I think Emacs is a special snowflake in that it doesn't (possibly 
can't?) rely on the GPM daemon drawing the mouse pointer. I did not see 
any other app with this problem. I tested Vim, Midnight Commander, Nano, 
and Bash. I don't know what is special about Emacs here. Perhaps the 
character under the mouse pointer is treated special in redisplay? Not 
sure.

I will reach out to the kernel mailing list and see if they are ok 
relaxing the check and fixing this on their end.

  -- MJF

Message #65 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sat, 30 Nov 2024 09:08:06 +0200

> Date: Fri, 29 Nov 2024 11:12:39 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: stephen.berman <at> gmx.net, rpluim <at> gmail.com, gerd.moellmann <at> gmail.com,
>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> 
> I think Emacs is a special snowflake in that it doesn't (possibly 
> can't?) rely on the GPM daemon drawing the mouse pointer. I did not see 
> any other app with this problem. I tested Vim, Midnight Commander, Nano, 
> and Bash. I don't know what is special about Emacs here. Perhaps the 
> character under the mouse pointer is treated special in redisplay? Not 
> sure.

Emacs needs to know where the mouse pointer is, and the rest it can
figure out by itself.  So if the GPM daemon drawing the mouse pointer
allows to know the pointer coordinates in a way that can be correlated
with the rows and column of the console, we should be okay.

Maybe when the GPM support for Emacs was written, the daemon couldn't
be used for drawing the pointer?

Anyway, one way to try to solve this is to try to use the
daemon-drawing of the mouse pointer.

> I will reach out to the kernel mailing list and see if they are ok 
> relaxing the check and fixing this on their end.

Thanks.

Message #68 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: jared <at> finder.org
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sat, 07 Dec 2024 14:34:44 +0200

> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> Date: Sat, 30 Nov 2024 09:08:06 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Fri, 29 Nov 2024 11:12:39 -0800
> > From: Jared Finder <jared <at> finder.org>
> > Cc: stephen.berman <at> gmx.net, rpluim <at> gmail.com, gerd.moellmann <at> gmail.com,
> >  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> > 
> > I think Emacs is a special snowflake in that it doesn't (possibly 
> > can't?) rely on the GPM daemon drawing the mouse pointer. I did not see 
> > any other app with this problem. I tested Vim, Midnight Commander, Nano, 
> > and Bash. I don't know what is special about Emacs here. Perhaps the 
> > character under the mouse pointer is treated special in redisplay? Not 
> > sure.
> 
> Emacs needs to know where the mouse pointer is, and the rest it can
> figure out by itself.  So if the GPM daemon drawing the mouse pointer
> allows to know the pointer coordinates in a way that can be correlated
> with the rows and column of the console, we should be okay.
> 
> Maybe when the GPM support for Emacs was written, the daemon couldn't
> be used for drawing the pointer?
> 
> Anyway, one way to try to solve this is to try to use the
> daemon-drawing of the mouse pointer.
> 
> > I will reach out to the kernel mailing list and see if they are ok 
> > relaxing the check and fixing this on their end.
> 
> Thanks.

Any progress here?

Message #71 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sat, 07 Dec 2024 11:14:46 -0800

On 2024-12-07 04:34, Eli Zaretskii wrote:
>> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, 
>> stephen.berman <at> gmx.net,
>>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
>> Date: Sat, 30 Nov 2024 09:08:06 +0200
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>> > Date: Fri, 29 Nov 2024 11:12:39 -0800
>> > From: Jared Finder <jared <at> finder.org>
>> > Cc: stephen.berman <at> gmx.net, rpluim <at> gmail.com, gerd.moellmann <at> gmail.com,
>> >  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
>> >
>> > I think Emacs is a special snowflake in that it doesn't (possibly
>> > can't?) rely on the GPM daemon drawing the mouse pointer. I did not see
>> > any other app with this problem. I tested Vim, Midnight Commander, Nano,
>> > and Bash. I don't know what is special about Emacs here. Perhaps the
>> > character under the mouse pointer is treated special in redisplay? Not
>> > sure.
>> 
>> Emacs needs to know where the mouse pointer is, and the rest it can
>> figure out by itself.  So if the GPM daemon drawing the mouse pointer
>> allows to know the pointer coordinates in a way that can be correlated
>> with the rows and column of the console, we should be okay.
>> 
>> Maybe when the GPM support for Emacs was written, the daemon couldn't
>> be used for drawing the pointer?
>> 
>> Anyway, one way to try to solve this is to try to use the
>> daemon-drawing of the mouse pointer.
>> 
>> > I will reach out to the kernel mailing list and see if they are ok
>> > relaxing the check and fixing this on their end.
>> 
>> Thanks.
> 
> Any progress here?

People on the Linux kernel mailing list agree this is a regression on 
Linux and that my suggested fix is probably appropriate. Tracking page: 
https://linux-regtracking.leemhuis.info/regzbot/regression/lore/CAG48ez0vg9W=oatvEqxvTSYNUx7htY23LxPrYCiuLZhZQuaGjg <at> mail.gmail.com/

  -- MJF

Message #74 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sat, 07 Dec 2024 21:29:48 +0200

> Date: Sat, 07 Dec 2024 11:14:46 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> 
> People on the Linux kernel mailing list agree this is a regression on 
> Linux and that my suggested fix is probably appropriate. Tracking page: 
> https://linux-regtracking.leemhuis.info/regzbot/regression/lore/CAG48ez0vg9W=oatvEqxvTSYNUx7htY23LxPrYCiuLZhZQuaGjg <at> mail.gmail.com/

Thanks, let's hope they will fix this soon.

Message #79 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sat, 08 Feb 2025 08:29:53 -0800

On 2024-12-07 11:29, Eli Zaretskii wrote:
>> Date: Sat, 07 Dec 2024 11:14:46 -0800
>> From: Jared Finder <jared <at> finder.org>
>> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, 
>> stephen.berman <at> gmx.net,
>>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
>> 
>> People on the Linux kernel mailing list agree this is a regression on
>> Linux and that my suggested fix is probably appropriate. Tracking 
>> page:
>> https://linux-regtracking.leemhuis.info/regzbot/regression/lore/CAG48ez0vg9W=oatvEqxvTSYNUx7htY23LxPrYCiuLZhZQuaGjg <at> mail.gmail.com/
> 
> Thanks, let's hope they will fix this soon.

An update: A fix will go out with Linux 6.14.  I am building the kernel 
locally to confirm the fix.

How do we want to note this issue in Emacs' release notes, if at all?

  -- MJF

Message #82 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sat, 08 Feb 2025 18:54:11 +0200

> Date: Sat, 08 Feb 2025 08:29:53 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> 
> On 2024-12-07 11:29, Eli Zaretskii wrote:
> >> Date: Sat, 07 Dec 2024 11:14:46 -0800
> >> From: Jared Finder <jared <at> finder.org>
> >> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, 
> >> stephen.berman <at> gmx.net,
> >>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> >> 
> >> People on the Linux kernel mailing list agree this is a regression on
> >> Linux and that my suggested fix is probably appropriate. Tracking 
> >> page:
> >> https://linux-regtracking.leemhuis.info/regzbot/regression/lore/CAG48ez0vg9W=oatvEqxvTSYNUx7htY23LxPrYCiuLZhZQuaGjg <at> mail.gmail.com/
> > 
> > Thanks, let's hope they will fix this soon.
> 
> An update: A fix will go out with Linux 6.14.  I am building the kernel 
> locally to confirm the fix.

Good news.

> How do we want to note this issue in Emacs' release notes, if at all?

It should be in PROBLEMS, not in NEWS.

Message #85 received at 74220 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sat, 08 Feb 2025 19:15:54 -0800

[Message part 1 (text/plain, inline)]

On 2025-02-08 08:54, Eli Zaretskii wrote:
>> Date: Sat, 08 Feb 2025 08:29:53 -0800
>> From: Jared Finder <jared <at> finder.org>
>> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, 
>> stephen.berman <at> gmx.net,
>>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
>> 
>> An update: A fix will go out with Linux 6.14.  I am building the 
>> kernel
>> locally to confirm the fix.
> 
> Good news.
> 
>> How do we want to note this issue in Emacs' release notes, if at all?
> 
> It should be in PROBLEMS, not in NEWS.

I have verified the fix.  Patch attached to mention in PROBLEMS.  I 
think this bug can be closed.

  -- MJF

[0001-etc-PROBLEMS-Document-problem-with-mouse-display-bug.patch (text/x-diff, attachment)]

Message #90 received at 74220-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jared Finder <jared <at> finder.org>
Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
 74220-done <at> debbugs.gnu.org, ampinkas <at> gmail.com
Subject: Re: bug#74220: invisible cursor
Date: Sun, 09 Feb 2025 09:18:33 +0200

> Date: Sat, 08 Feb 2025 19:15:54 -0800
> From: Jared Finder <jared <at> finder.org>
> Cc: gerd.moellmann <at> gmail.com, rpluim <at> gmail.com, stephen.berman <at> gmx.net,
>  74220 <at> debbugs.gnu.org, ampinkas <at> gmail.com
> 
> >> How do we want to note this issue in Emacs' release notes, if at all?
> > 
> > It should be in PROBLEMS, not in NEWS.
> 
> I have verified the fix.  Patch attached to mention in PROBLEMS.  I 
> think this bug can be closed.

Thanks, installed on the emacs-30 branch, and closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.