telmich / gpm Goto Github PK

Using this device via a PL2303 Serial->USB adatper on Alpine Linux x86_64 edge, kernel 6.1.38-1-lts.

GPM is version 1.20.7-r4.

When testing out the mouse via mouse-test, here is what I see:

This program is designed to help you in detecting what type your
mouse is. Please follow the instructions of this program. If you're
bored before it is done, you can always press your 'Interrupt' key
(usually Ctrl-C)

	 *** Remember: don't run any software which reads the mouse device
	 *** while making this test. This includes "gpm","selection", "X"

Note that this program is by no means complete, and its main role is
to detect how does the middle button work on serial mice

Ok, so your mouse device is "/dev/ttyUSB0"


The possible mouse types are:
	mman (Mouseman)
	ms
	bare (Microsoft)
	bm (BusMouse)
	brw
	calr
	evdev
	exps2 (ExplorerPS/2)
	js (Joystick)
	genitizer
	imps2
	logi (Logitech)
	logim
	mm (MMSeries)
	ms3
	ms+
	ms+lr
	msc (MouseSystems)
	netmouse
	pnp
	ps2 (PS/2)
	sun
	syn (synaptics)
	synps2 (synaptics_ps2)
	twid
	vsxxxaa
	wacom

Now please press and release your left mouse button,
one time only

	Removing type "bm" because of 'different read() semantics'
	Removing type "calr" because of 'different read() semantics'
	Removing type "evdev" because of 'different read() semantics'
	Removing type "js" because of 'different read() semantics'
	Removing type "logi" because of 'different read() semantics'
	Removing type "syn" because of 'different read() semantics'

Now you will be asked to generate different kind of events,
in order to understand what protocol is your mouse speaking
	Baud rate is 1200

==> Detecting the packet size

Now please press and release several times
the left button of your mouse, *** trying not to move it ***

Press any key when you've done enough
matches for 3 bytes: 156   -- matches for 5 bytes: 0
** type 'mman' still possible
** type 'ms' still possible
** type 'bare' still possible
	Removing type "brw" because of 'different packet lenght'
	Removing type "exps2" because of 'different packet lenght'
	Removing type "genitizer" because of 'incorrect button detected'
	Removing type "imps2" because of 'different packet lenght'
	Removing type "logim" because of 'different packet lenght'
	Removing type "mm" because of 'incorrect button detected'
	Removing type "ms3" because of 'different packet lenght'
** type 'ms+' still possible
** type 'ms+lr' still possible
	Removing type "msc" because of 'different packet lenght'
	Removing type "netmouse" because of 'different packet lenght'
** type 'pnp' still possible
	Removing type "ps2" because of 'incorrect button detected'
	Removing type "sun" because of 'incorrect button detected'
	Removing type "synps2" because of 'different packet lenght'
	Removing type "twid" because of 'different packet lenght'
	Removing type "vsxxxaa" because of 'incorrect button detected'
	Removing type "wacom" because of 'different packet lenght'

Your mouse is one of the ms family, but do you have the middle button (y/n)? 

Your mouse is one of the ms family, but do you have the middle button (y/n)? n

Then, you should use the "bare" protocol on "/dev/ttyUSB0"

The mouse lights up when clicked in mouse-test, but is otherwise unresponsive.

When issuing any of the following:

$ doas gpm -m /dev/ttyUSB0 -t bare
$ doas gpm -m /dev/ttyUSB0 -t ms
$ doas gpm -m /dev/ttyUSB0 -t ms+
$ doas gpm -m /dev/ttyUSB0 -t ms+lr
$ doas gpm -m /dev/ttyUSB0 -t mman
$ doas gpm -m /dev/ttyUSB0 -t pnp

The mouse lights up when clicked but is otherwise unresponsive, but the lights only work for about 3s after the gpm daemon is started, afterwards it is completely unresponsive.

I'd like to note that this setup works fine, even under Windows 11, so I know the hardware itself is not suspect at this time.

How do I go about investigating what protocol this mouse might be using, or collecting any other information that might be useful for this mouse?

It'd be really special for me to be able to use this mouse, but I understand that this is niche and very old.

Thank you!

Hey there, got some oddity happening whenever i have gpm running.
At login as soon as i press enter,right after the user login name,it appears like the enter key is stuck on repeat. It does this a few times until the login screen defaults back waiting for a login. I never get the chance to type in the password. Maybe the keyboard is seen as some sort of mouse? it's a Microsoft Comfort Curve if it makes any difference.

It's only when do any type of Login that it happens, and only if i do "user [enter]" ,
if i just press "[enter]" it doesn't repeat.

A headscratcher this one. (atleast for me)

Both mouse and keyboard are of the USB type.

Hope i've made myself understood otherwise i'll do a video and put up on youtube. Thanks.

gpm-mice.c.diff.txt
During compilation on gentoo we see following:

• QA Notice: Package triggers severe warnings which indicate that it

•        may exhibit random runtime failures.
  

• mice.c:1843:10: warning: ‘p’ is used uninitialized in this function [-Wuninitialized]

simple fix for that is attached

daemon(0,0) does:

• fork
• setsid
• chdir / (1st arg = 0)
• redirects standard input, standard output and standard error to /dev/null (2nd arg = 0)

if daemon(0,0) fails, that does not mean that fork failed. I can fail at setsid, chdir or redirections to /dev/null

I got gpm failed errno=37. Doing strace show that fork succeed indeed. The problem was that /dev/null is not a char device and lock failed.
The correct error should be "daemonize failed" not "fork failed"!
(Because of the missleading message I lost time.)

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• strdup ⇒ parse_argv
• fprintf ⇒ check_uniqueness

synaptics.c:2355:25: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]

Source code is

if ( bytes [0] == 'S' && bytes [0] == 'T'){

synaptics.c:2425:26: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op]

Duplicate

There is an error during compilation on Debian sid: files in src/prog cannot include gpm.h. Here is the message:

Makefile:90: recipe for target 'dep' failed
make[1]: [dep] Error 1 (ignored)
# create dependencies
for DEPS in `echo *.c */*.c`; do \
gcc -I. -I /home/doc/src/gpm/src -M  -I/home/doc/src/gpm/src -DHAVE_CONFIG_H -include headers/config.h -Wall -DSYSCONFDIR="\"/usr/local/etc\"" -DSBINDIR="\"/usr/local/sbin\"" -D_GNU_SOURCE  $DEPS | \
/bin/sed 's/^\(.*\)\.o\([ :]+\)/\1.o \1.lo\2/g' >> .depend ; done
prog/display-buttons.c:40:57: fatal error: gpm.h: No such file or directory
compilation terminated.
prog/display-coords.c:42:57: fatal error: gpm.h: No such file or directory
compilation terminated.
prog/get-versions.c:25:57: fatal error: gpm.h: No such file or directory
compilation terminated.

Steps to reproduce it:

./autogen.sh
./configure
make

GPM is failing to give mouse support in console with the following error:

*** err [daemon/getmousedata.c(47)]:
Error in read()ing first: Invalid argument

I am using Gentoo. I have two mice. A Logitech USB mouse and touchpad. Device nodes are created in /dev/input/event5 and /dev/input/event6. I have tested them with libinput debug-events. They are working just fine so I think kernel drivers are ok.

-event2   DEVICE_ADDED     Power Button                      seat0 default group1  cap:k
-event3   DEVICE_ADDED     Video Bus                         seat0 default group2  cap:k
-event0   DEVICE_ADDED     Lid Switch                        seat0 default group3  cap:S
-event1   DEVICE_ADDED     Sleep Button                      seat0 default group4  cap:k
-event5   DEVICE_ADDED     Logitech USB Optical Mouse        seat0 default group5  cap:p left scroll-nat scroll-button
-event4   DEVICE_ADDED     AT Translated Set 2 keyboard      seat0 default group6  cap:k
-event6   DEVICE_ADDED     SynPS/2 Synaptics TouchPad        seat0 default group7  cap:pg  size 100x76mm tap(dl off) left scroll-nat scroll-2fg-edge click-buttonareas-clickfinger dwt-on
-event7   DEVICE_ADDED     TPPS/2 IBM TrackPoint             seat0 default group8  cap:p left scroll-nat scroll-button
-event5   POINTER_BUTTON    +2.36s      BTN_LEFT (272) pressed, seat count: 1
 event5   POINTER_BUTTON    +2.41s      BTN_LEFT (272) released, seat count: 0
 event5   POINTER_BUTTON    +4.56s      BTN_RIGHT (273) pressed, seat count: 1
 event5   POINTER_BUTTON    +4.66s      BTN_RIGHT (273) released, seat count: 0
 event5   POINTER_MOTION    +6.72s        0.31/ -0.31 ( +1.00/ -1.00)
 event5   POINTER_MOTION    +6.72s        1.77/ -1.77 ( +2.00/ -2.00)
 event5   POINTER_MOTION    +6.73s        4.19/ -1.05 ( +4.00/ -1.00)

GPM configuration file:

# /etc/init.d/gpm

# Please uncomment the type of mouse you have and the appropriate MOUSEDEV entry

MOUSE=ps2
#MOUSE=imps2
#MOUSEDEV=/dev/psaux
MOUSEDEV=/dev/input/event5

# Extra settings

#RESPONSIVENESS=
#REPEAT_TYPE=raw

# Please uncomment this line if you want gpm to understand charsets used
# in URLs and names with ~ or : in them, etc. This is a good idea to turn on!

APPEND="-l \"a-zA-Z0-9_.:~/\300-\326\330-\366\370-\377\""

# Various other options, see gpm(8) manpage for more.

#APPEND="-g 1 -A60"
#APPEND="-l \"a-zA-Z0-9_.:~/\300-\326\330-\366\370-\377\" -g 1 -A60"

After invoking /etc/init.d/gpm start GPM starts properly. But when any mouse event occurs GPM throws above error in log file in an infinite loop and mouse doesn't work.

The functions "ioctl" and "exit" do not belong to the list of async-signal-safe functions.
I guess that a different program design will be needed for your functions "gpm_winch_hook" and "killed".

I would like to access the selection buffer from script.
It's there any device file which I can read from?

Reported by @jwilk in Debian as https://bugs.debian.org/1022113:

Package: gpm
Version: 1.20.7-10+b1

gpm crashes when I do "stty cols 1".

GDB says:

   Program received signal SIGFPE, Arithmetic exception.
   0x565eaf44 in processMouse (fd=5, event=0xff9a6980, type=0x565f73e0 <mice+480>, kd_mode=0) at daemon/processmouse.c:173
   173           fine_dx %= (which_mouse->opt_scale);           fine_dy %= (which_mouse->opt_scaley);
   (gdb) print which_mouse->opt_scale
   $1 = 10
   (gdb) print which_mouse->opt_scaley
   $2 = 0
   (gdb) bt
   #0  0x565eaf44 in processMouse (fd=5, event=0xff9a6980, type=0x565f73e0 <mice+480>, kd_mode=0) at daemon/processmouse.c:173
   #1  0x565e9926 in old_main () at daemon/old_main.c:200
   #2  0x565de57c in main (argc=5, argv=0xff9a6b14) at daemon/main.c:33

I think the culprit is the get_console_size() function, which does:

   (which_mouse->opt_scaley)=(which_mouse->opt_scale)*50*maxx/80/maxy;

If maxx is small and maxy is large (200 in my case), you could indeed end up
with opt_scaley set to 0.


-- System Information:
Architecture: i386

Versions of packages gpm depends on:
ii  init-system-helpers  1.65.2
ii  ucf                  3.0043
ii  debconf              1.5.79
ii  libc6                2.35-3
ii  libgpm2              1.20.7-10+b1

Seams like Gpm_Events with type = GPM_DRAG or GPM_UP reports have differently rounded x coordinate than other event types. When pressing LMB at the left screen edge, Gpm_Event::x is 0 (instead of 1). That happens only if mouse is positioned at the left screen edge "in pixels". After moving mouse very slightly to the right (while cursor still occupies same character cell) works fine, Gpm_Event::x is 1 for all types of events.

I've tested it on Fedora and Arch, using different mice, everywhere same issue.

Intro

GPM should switch to reporting mouse events as part of the input stream towards apps, as graphical terminal emulators do.

Why?

GPM mouse support typically only works in apps that run directly in the console. It does not work inside screen or tmux, does not work inside luit, does not work across a su or sudo, does not work over ssh. With xterm-style reporting you get these for free.

Mouse handling apps would no longer need to link against gpm and have a dependency on this package (the library). Their codebase could probably be simplified, they could drop all the gpm-specific code, and retain only the xterm-specific code (which they presumably already have), that one would handle gpm events as well.

Similarly, ncurses could also drop its gpm dependency, eliminating the dependency loop between ncurses and gpm (#19).

Current state

The Linux kernel has supported xterm-style mouse reporting since 2000. The required call is ioctl(..., TIOCLINUX, ...), the first byte of the payload is TIOCL_SETSEL (2), then 4 shorts for the selection's (ouch, what selection?) coordinates, and another short with the TIOCL_SELMOUSEREPORT bit set, in which case TIOCL_SETSEL is in my opinion semantically misused to report a mouse event according to the TIOCL_SELBUTTONMASK mask, rather than defining a selection.

A patch called xterm-mouse-for-console.patch was created also back in 2000. I've found it inside gpm-1.99.7's source tree, but not under gpm-1.20.7's. Probably no need to say, the patch created 18 years ago does not apply.

In #4 @seyko2 created another patch in 2014, that attempt also stalled.

Kernel limitations, desired work

The legacy xterm mouse protocol, supported by the kernel, can only report coordinates up to 223. I think the Linux console can be wider than this (e.g. in framebuffer mode), can't it? Moreover, coordinates above 95 are broken by charset converting layers (e.g. luit). There were two unsuccessful (technically problematic) attempts to fix this (extensions 1005 and 1015), and one apparently successful widespreadly used one (1006). The kernel should add support for the latter.

The implementation of the legacy mode in the kernel suffers from an overflow, if clicked beyond column (or row) 223. E.g. column 227 is converted to byte 3, which presumably (I haven't verified) will be interpreted as ^C interrupt by the line discipline (see gnome-terminal counterpart issue). In such cases, no mouse event should be reported.

There are 4 bits under TIOCL_SELBUTTONMASK that denote two modifiers, and the mouse button that was pressed or a generic value for releasing.

There are 3 keyboard modifiers that should be of interest, xterm and other emulators support denoting Ctrl, Shift and Alt. Now, gpm might decide that it doesn't support all three, maybe forces its own selection operation and does not forward anything to the apps whenever a modifier of its own choice is held down. However, I don't think this decision and restriction belongs to the kernel. Furthermore, which modifier this is (if at all) could be a runtime config option of gpm. I think the kernel's interface should be extended to support all three modifier keys.

The aforementioned 1006 extension adds another twist: at mouse release, the exact button that was released is reported. For this to work, the 2 bits denoting which button was pressed or a generic value for releasing any button is no longer sufficient. The interface should be extended here as well.

Mouse wheel scrolling events aren't supported. They should be.

There's a mouse extension 1002 where mouse movements are reported while a button is being held down. This is not supported by the kernel, but should.

There's a mouse extension 1003 where mouse movements are reported even when no button is being held down. I think this is somewhat debatable whether this is a good one, but I don't think it can hurt to add, and if gpm supports reporting such events via its own protocol (I don't know whether it supports) then for feature parity, in order to switch to the new design without feature regressions, this mode should be added. (Even if gpm decides not to support this mode, I think it should still be added to the kernel.)

I find it a pretty unfortunate design to piggyback on the TIOCL_SETSEL, as if mouse reporting was a special case of selection. It totally isn't. And then there are two pairs of coordinates passed, out of which only the first one is used (which is again a bit weird, with mouse dragging if anything then the second would make more sense).

In my opinion, the cleanest would be to redesign mouse reporting using a new value as the first byte (e.g. after TIOCL_GETMOUSEREPORTING the next value of 8 is free) so that it's unrelated to selection, followed by 2 shorts for the coordinates, and another for the keyboard modifiers, mouse buttons, wheel direction etc.

The ioctl_console(2) manpage says "Ioctl's are undocumented Linux internals, liable to be changed without warning." I don't know whether that's true, I'm not familiar with kernel developing practices. That being said, the old mode could still be supported for a couple of years along with the new one.

Once done, gpm could catch up and start using these revised ioctl parameters, thus hopefully arrive to feature parity with its current features and today's popular graphical terminal emulators.

Roadmap

I hope that if there's a proof-of-concept gpm implementation using the new kernel features, kernel developers would probably quickly approve the kernel patch that expands the interface, fixes the overflow in 1000 mode, adds support for the 1006 format (including reporting the released button), adds support for the 1002 and 1003 tracking extensions, adds support for wheel scroll events and the missing modifier.

Stable kernels are released quite frequently, about every 2 months. Distributions also tend to ship pretty new kernels. gpm wouldn't have to wait long until it could start shipping the new design.

In order for distributions to pick up the newest version, it would probably need to release a new 1.20 and a new 1.99.x too. Or, even better: I think that after this architectural change it'll deserve to be called 2.0.

(I would even go as far as considering to deprecate and eventually remove the current separate library, header files, public interface. Not sure if gpm-root would still require it. Regular apps won't and shouldn't.)

Once distributions start shipping gpm 2.0, apps and the ncurses library could begin to clean up their source and remove direct gpm dependency. Some apps that have a hardwired list of terminals supporting mouse would need to add linux to that list. As stated in the aforementioned 18 year old patch, the linux terminfo entry could also add an entry for mouse support. Until these apps are updated, they would of course happily use the old interface, there wouldn't be any outage.

Outro

Now, we'd only need someone enthusiastic enough to push this through. :-)

I'm really wondering, how come basically nothing changed in the last 18 years? Is the current state considered "good enough" by most users? Is it that the console is either used as a fallback, should the graphical system be inaccessible, e.g. during a disaster recovery; or it's mainly used by power users; in either of these two cases mouse support isn't important?

Did I miss anything? Is there a fundamental problem with the approach I'm endorsing? Would it have downsides, regressions in some aspects that I don't foresee?

I hope I could help by giving an overview of the current state and how I think it should ideally look like, and maybe somebody will take care of this. (Maybe it's the complexity and hence the challenge that'll inspire someone to do this!) Or maybe this issue will stay here unresolved for another 18+ years... We'll see. :-)

gcc -I. -I/tmp/work/src/gpm/src -DHAVE_CONFIG_H -include headers/config.h -Wall -DSYSCONFDIR=""/etc"" -DSBINDIR=""/usr/sbin"" -D_GNU_SOURCE -O2 -pipe -O2 -pipe -c -o prog/gpm-root.o prog/gpm-root.c
/tmp/work/src/gpm/src/prog/gpm-root.y: In function 'postmenu':
/tmp/work/src/gpm/src/prog/gpm-root.y:1030:32: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
#define PUTS(s,f,b) for(curr2=s;curr2;PUTC((curr2++),f,b))
^
/tmp/work/src/gpm/src/prog/gpm-root.y:1045:10: note: in expansion of macro 'PUTS'
PUTS(draw->title,draw->head,draw->back);
^~~~
/tmp/work/src/gpm/src/prog/gpm-root.y:1030:32: warning: pointer targets in assignment differ in signedness [-Wpointer-sign]
#define PUTS(s,f,b) for(curr2=s;curr2;PUTC((curr2++),f,b))
^
/tmp/work/src/gpm/src/prog/gpm-root.y:1053:10: note: in expansion of macro 'PUTS'
PUTS(item->name,draw->fore,draw->back); i+=strlen(item->name);
^~~~
/tmp/work/src/gpm/src/prog/gpm-root.y: In function 'main':
/tmp/work/src/gpm/src/prog/gpm-root.y:1200:4: warning: implicit declaration of function '__sigemptyset'; did you mean 'sigemptyset'? [-Wimplicit-function-declaration]
__sigemptyset(&childaction.sa_mask);
^~~~~~~~~~~~~
sigemptyset
gcc -L/tmp/work/src/gpm/src -lm -o prog/gpm-root prog/gpm-root.o lib/libgpm.so.2
prog/gpm-root.o: In function main': gpm-root.c:(.text.startup+0x1fe): undefined reference to __sigemptyset'

the Makefile.in files contain a lot of hand written logic to deal with dependency info and dist targets (among other things). it would be nicer to convert it all to automake (and Makefile.am files) to get all this for free. it would also fix out-of-tree builds which currently don't work (e.g. run mkdir build && cd build && ../configure && make and watch it fail).

any concerns before embarking on this cleanup ?

Yeah .. last one was in 2012 so it was quite long time ago :p

Source code is

if((fp = fopen(GPM_NODE_PID, "r")) != NULL) {
fscanf(fp, "%d", &old_pid);
if (kill(old_pid,0) == -1) {
gpm_report(GPM_PR_INFO,GPM_MESS_STALE_PID, GPM_NODE_PID);
unlink(GPM_NODE_PID);
} else /* we are really running, exit asap! /
gpm_report(GPM_PR_OOPS,GPM_MESS_ALREADY_RUN, old_pid);
}
/ now try to sign ourself */
if ((fp = fopen(GPM_NODE_PID,"w")) != NULL) {

So if the first fopen succeeds, then there seems to be a missing call to fclose.

With sys-libs/gpm-1.20.7-r3 (Funtoo ebuild), I can use the clickpad on a Lenovo ThinkPad E540 (kernel support is RMI4) with types ps2, imps2, exps2: apparently all work the same, but there's no "soft" button support, only the hard (click) button and tapping work.
Indeed, this kind of touchpad, identified as follows...

52: PS/2 00.0: 10500 PS/2 Mouse
  [Created at input.249]
  Unique ID: AH6Q.KF1c0xgbUt4
  Hardware Class: mouse
  Model: "Synaptics TM2722-001"
  Vendor: 0x06cb 
  Device: "Synaptics TM2722-001"
  Compatible to: int 0x0210 0x0001
  Device File: /dev/input/mice (/dev/input/mouse0)
  Device Files: /dev/input/mice, /dev/input/mouse0, /dev/input/event14
  Device Number: char 13:63 (char 13:32)
  Driver Info #0:
    Buttons: 1
    Wheels: 0
    XFree86 Protocol: explorerps/2
    GPM Protocol: exps2
  Config Status: cfg=new, avail=yes, need=no, active=unknown

...has 3 soft buttons, configurable under Xorg/libinput on the top and bottom edges. How to do the same with GPM? It looks like the Synaptics-specific conf file /etc/gpm/gpm-syn.conf is ignored: all the pad area is available to the pointer and for tapping, but no "corner tap action" is enabled...

With -t synps2, GPM shows only a fixed cursor. Cf. debug logs gpm-synps2.log and gpm-exps2.log

I tried building gpm from git with -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing in CFLAGS / LDFLAGS. It failed to build with the following error:

gcc  -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wl,--defsym=__gentoo_check_ldflags__=0 -L/tmp/gpm/src  -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -o gpm mice.o twiddler.o synaptics.o daemon/add_mouse.o daemon/init_mice.o daemon/reset_mice.o daemon/build_argv.o daemon/disable_paste.o daemon/do_client.o daemon/do_selection.o daemon/get_console_size.o daemon/get_data.o daemon/getmousedata.o daemon/gpm.o daemon/gpm-killed.o daemon/header.o daemon/main.o daemon/old_main.o daemon/open_console.o daemon/check_kill.o daemon/gpm_exited.o generic/isodigit.o generic/getsym.o daemon/processspecial.o daemon/processconn.o daemon/processmouse.o daemon/processrequest.o daemon/selection_copy.o daemon/selection_paste.o daemon/cmdline.o daemon/loadlut.o daemon/find_mouse_by_name.o daemon/usage.o daemon/check_uniqueness.o daemon/startup.o daemon/wait_text.o report.o tools.o   -lm
/tmp/gpm/src/headers/daemon.h:175:25: error: type of ‘cinfo’ does not match original declaration [-Werror=lto-type-mismatch]
  175 | extern Gpm_Cinfo       *cinfo[MAX_VC+1];
      |                         ^
daemon/gpm.c:96:12: note: array types have different bounds
   96 | Gpm_Cinfo *cinfo[MAX_VC+1];
      |            ^
daemon/gpm.c:96:12: note: ‘cinfo’ was previously declared here
lto1: some warnings being treated as errors
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:85: gpm] Error 1

See also: https://bugs.gentoo.org/885323

I didn't find any info about this.

$ make install: fails with "/usr/bin/install: cannot stat './doc/gpm.info'"

When compiling with makeinfo installed, the gpm.texinfo to gpm.info log entry:
if [ "/usr/bin/makeinfo" != "no" ]; then /usr/bin/makeinfo --no-split ./doc/gpm.texinfo -o ./doc/gpm.info; fi

When compiling without makeinfo installed, the gpm.texinfo to gpm.info log entry:
if [ "no" != "no" ]; then no --no-split ./doc/gpm.texinfo -o ./doc/gpm.info; fi

Would you consider possibly adding an eli5* section in the README about
how gpm and, say, ncurses communicate? Is it via unix signals, like SIGINT
or SIGWINCH? Over ports, like ftp or http? Or is it based on something
else? Escape codes? How does either gpm or ncurses (whichever is right) know what terminal is currently active, (if it is escape
codes?) in order to send the escape codes to the right terminal?

• Explain Like I'm 5 (Reddit-speak for explaining things in an
  easy-for-a-layperson-to-understand way)

On a gentoo system where almost everything is compiled, circular dependency requires manual intervention of administrator.

I just turned off gpm in ncurses so that I won't have to manually turn gpm off and on in ncurses.

Conceptually, gpm shouldn't need to know about ncurses. Is there a way to make gpm unaware of ncurses?

• Create & upload new key for gpm
• Include musl patch [#30]
• Sign new release
• Publish checksums/signatures for earlier releases (request from mike glover)
• Maybe move code to code.ungleich.ch? Supporting IPv6?