unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Jared Finder <jared@finder.org>
Cc: gerd.moellmann@gmail.com, rpluim@gmail.com,
	stephen.berman@gmx.net, 74220@debbugs.gnu.org,
	ampinkas@gmail.com
Subject: bug#74220: invisible cursor
Date: Fri, 29 Nov 2024 09:32:23 +0200	[thread overview]
Message-ID: <86y112bim0.fsf@gnu.org> (raw)
In-Reply-To: <a0ea4f824292808131cff24091eb7c0c@finder.org> (message from Jared Finder on Thu, 28 Nov 2024 13:45:49 -0800)

> Date: Thu, 28 Nov 2024 13:45:49 -0800
> From: Jared Finder <jared@finder.org>
> Cc: stephen.berman@gmx.net, bug-gnu-emacs@gnu.org, rpluim@gmail.com,
>  gerd.moellmann@gmail.com, 74220@debbugs.gnu.org, ampinkas@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?





  reply	other threads:[~2024-11-29  7:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-05 20:06 bug#74220: invisible cursor Avraham Pinkas
2024-11-06 12:37 ` Eli Zaretskii
2024-11-06 13:55   ` Robert Pluim
2024-11-06 14:03     ` Gerd Möllmann
2024-11-06 14:22   ` jared via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-06 15:38     ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-06 16:17       ` Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-18  1:37         ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-28  3:13           ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-28 18:21             ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-28 20:20               ` Eli Zaretskii
2024-11-28 21:45                 ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-11-29  7:32                   ` Eli Zaretskii [this message]
2024-11-29 19:12                     ` Jared Finder via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86y112bim0.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=74220@debbugs.gnu.org \
    --cc=ampinkas@gmail.com \
    --cc=gerd.moellmann@gmail.com \
    --cc=jared@finder.org \
    --cc=rpluim@gmail.com \
    --cc=stephen.berman@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).