GNU bug report logs - #74220
invisible cursor

Previous Next

Full log

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?

Previous Next

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