From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#74220: invisible cursor Date: Fri, 29 Nov 2024 09:32:23 +0200 Message-ID: <86y112bim0.fsf@gnu.org> References: <87ldxwmppm.fsf@gmail.com> <86o72ssfm4.fsf@gnu.org> <87bjyscp5e.fsf@gmx.net> <2b5006ac22491fd8c509120ad653117d@finder.org> <8b70d54cd579f33d1e698a0f8927dc4f@finder.org> <865xo7cdpv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12067"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, rpluim@gmail.com, stephen.berman@gmx.net, 74220@debbugs.gnu.org, ampinkas@gmail.com To: Jared Finder Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 29 08:35:26 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tGvXA-0002yK-K6 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Nov 2024 08:35:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tGvWr-0006KG-LW; Fri, 29 Nov 2024 02:35:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGvWp-0006IJ-2j for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 02:35:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tGvWo-0007Eg-PP for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 02:35:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=ortPaBB2vSbRpIp7mfFwdZYWv6k2TXs9aDr76HuC4Fk=; b=sa51Yoa7xOVUcFgQHbL8uWgTC09hdFXTxKJ0rB3GzHFZO3sMfsYjajtunoUR+fDrVD1YuVGerz4q7pQxo+vCX6X3gNAljho6o7asep44qW1qpsqpSLt3gMBqM7YfE1VZCRTVi4SznJenwlg05RmeNX8r/xPn3/c4bkXBMlsjFa+cUJXii6bpcCkUm2R31JXORaw4kL6NCuVMb/QyQV517jXNGRmb4bUKTDIwU782itcAXBJyanZgZ4VO6OyWnxF97+CS0MegBfbCZQ5U4SRXF3vNNggeQXe3XnW86NM91NxjDjC6dsUIbhiFyBLdrX2lvXlhFT+HDlBoEEC40T2goQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tGvWn-0007sA-KG for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 02:35:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Nov 2024 07:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74220 X-GNU-PR-Package: emacs Original-Received: via spool by 74220-submit@debbugs.gnu.org id=B74220.173286568830228 (code B ref 74220); Fri, 29 Nov 2024 07:35:01 +0000 Original-Received: (at 74220) by debbugs.gnu.org; 29 Nov 2024 07:34:48 +0000 Original-Received: from localhost ([127.0.0.1]:40760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGvWa-0007rU-6H for submit@debbugs.gnu.org; Fri, 29 Nov 2024 02:34:48 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53188) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tGvWX-0007r9-Vd for 74220@debbugs.gnu.org; Fri, 29 Nov 2024 02:34:46 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGvUL-00067Q-3o; Fri, 29 Nov 2024 02:32:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ortPaBB2vSbRpIp7mfFwdZYWv6k2TXs9aDr76HuC4Fk=; b=hu8tDLycs53q OeInXnDhJ39Lx7DLSBUDd9tQ8La3zEH7rC3nI0dmq05nYAz6N8FJxjNiBmrGxNE+NYGBLpHqe6lux 7qdRPokDddS74NlVsImGJx59RsCn89OaSwWP2AJVQf/AQMt3qKIXNHQaWULHg8goBBAyuwHIspseC puxejVvLbQ3B9m5zbk2d2I2Jxug91RbquKG4WMjdQ9lmgi9tVr6xrfFJUn29D5iYi7m9KjyyCSsOV wTSr1eKi30FT9gr98kWWIUddWZzM8sEjWJ4rqp7pGpqXW53zUBdIuzK9LSfj5DCWG5dXozbs57jWV vL0cIC70knwavIH1F/JKJA==; In-Reply-To: (message from Jared Finder on Thu, 28 Nov 2024 13:45:49 -0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296079 Archived-At: > Date: Thu, 28 Nov 2024 13:45:49 -0800 > From: Jared Finder > 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?