From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jared Finder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74220: invisible cursor Date: Fri, 29 Nov 2024 11:12:39 -0800 Message-ID: <889037a6131ad45d7e5dfb69e119c060@finder.org> References: <87ldxwmppm.fsf@gmail.com> <86o72ssfm4.fsf@gnu.org> <87bjyscp5e.fsf@gmx.net> <2b5006ac22491fd8c509120ad653117d@finder.org> <8b70d54cd579f33d1e698a0f8927dc4f@finder.org> <865xo7cdpv.fsf@gnu.org> <86y112bim0.fsf@gnu.org> Reply-To: Jared Finder Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32188"; 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: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Nov 29 20:13:15 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 1tH6QV-0008BH-9F for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Nov 2024 20:13:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tH6QL-0006v1-5m; Fri, 29 Nov 2024 14:13: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 1tH6QJ-0006uf-7l for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 14:13: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 1tH6QI-0007ck-Su for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 14:13: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:MIME-Version:To:Subject; bh=FyJqM9CkRMTFV/DaORnJSS8OBY+JA7MXOF+99RcKyVU=; b=CN6oMxm3YV04YRXMKdY/+Q9nLKMToRq6sAPwT5AMnDd+uIZoiWXFCGFIuBhDM7gL3NaYC6iJpGhePXIElSYN5UB8YrJ+OEJt7C6MhCDwB9va5J0iXoWIEVIbbgtyt5GgAo54Sl8FZIijLZN/n6lE90YVedYYiYHrNxYhTPDUt8sXcYOCmTiP6+UHMcwciDiTRFRe4PIX1qyURBgKaW8YUHukiGW9QIMa11EWvCtelGgsOEEw/rybyC9cf3fwTWc////RZYwTTY3qhoREG87sc+TTucZKa6nIEm43vPcx09WL2WBmuEvurciTY5dZCHneC3sXe1d3LBhU75NKFonvzA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tH6QI-0002SH-NH for bug-gnu-emacs@gnu.org; Fri, 29 Nov 2024 14:13:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jared Finder Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Nov 2024 19:13:02 +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.17329075679409 (code B ref 74220); Fri, 29 Nov 2024 19:13:02 +0000 Original-Received: (at 74220) by debbugs.gnu.org; 29 Nov 2024 19:12:47 +0000 Original-Received: from localhost ([127.0.0.1]:44429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tH6Q2-0002Rf-FU for submit@debbugs.gnu.org; Fri, 29 Nov 2024 14:12:47 -0500 Original-Received: from greenhill.hpalace.com ([192.155.80.58]:43104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tH6Px-0002RN-Ng for 74220@debbugs.gnu.org; Fri, 29 Nov 2024 14:12:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=finder.org; s=2018; t=1732907559; bh=unJnTolXPcHcZRVzC5tQA/U/U9ITPFAAvcO4MGdhPcE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=jeTMBI/HgwHseMF+FqE+GdrWY5XHJVyz/5riZuCpD7RHar28r3IvaHH1kH0xCYR40 DWuGSPej4G4rsJMssuS0+qrzIBJG8rtckhc3bZdTx0co/vrVB8p+LCIkbc1B+R38qa aF7M7Bw8f1leg4hyhJ/ILFRXh7tsPqlpZTv9HtPKkZD3k6xGvYSVFP92AneQaWfQOE 3W1k8qj50DDR5EpkbywY27LeVDX9GKzjapbNzD0KyiibOru6NFK08kLA0n5t2rpjvN 5RwPOm9ENsVhmWrLW829d2fVawD9/mI5cGyJkjQcvxkzBq/0sQl2heJmGHCvuILRWT wuuDm2l9QhPng== Original-Received: from mail.finder.org (unknown [192.155.80.58]) by greenhill.hpalace.com (Postfix) with ESMTPSA id 73D24138A; Fri, 29 Nov 2024 19:12:39 +0000 (UTC) In-Reply-To: <86y112bim0.fsf@gnu.org> X-Sender: jared@finder.org 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:296103 Archived-At: On 2024-11-28 23:32, Eli Zaretskii wrote: >> 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 >> >> >> 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@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