I suggest adding functionality to the gpm init-script and conf-file, by allowing variables to be set for a second mouse, which (if set, and if the device is present when the script is run) will be started by gpm in addition to the first mouse. If not present, init will fall back to starting only the "main" mouse. This is good for laptops, where there is a touchpad and (sometimes) also a USB mouse, etc. I've written an example patch to implement this. If I understand the bugzilla correctly, I guess I should attach the patch _after_ submitting this... so will do it that way around... :-/ An extra note: When my laptop is booted with USB mouse plugged in, udev usually registers it as /dev/input/mouse0 (and the internal touchpad as /dev/input/mouse1), yet the touchpad obviously becomes mouse0 without the USB mouse plugged in. The gpm init-script can overcome this problem with multiple mice by using a udev persistent naming rule, which the latest versions of udev thankfully now have included. :-) However, reliance on the persistent naming rule means firstly that (if this patch is used) the gpm ebuild might need to depend on a recent enough version of udev which includes the persistent naming rule, and secondly, it might be good to include a comment-line in the gpm conf-file, to explain this solution for the varying-device-name problem when using a removable mouse...
Created attachment 131469 [details, diff] Add functionality to gpm init-script to handle 1 or 2 mice (depending on presence)
Would be better to multiplex it! On Gentoo/FreeBSD we have an equivalent script called moused. On my system I link moused.psm0 to moused. If moused is invoked, it scans /dev for any mice and starts them up. If moused.psm0 is invoked it only starts up the daemon for the mouse psm0 Other examples of multiplexed scripts are our network scripts, vsftpd and openvpn.
(In reply to comment #2) > Would be better to multiplex it! > On Gentoo/FreeBSD we have an equivalent script called moused. On my system I > link moused.psm0 to moused. Sounds like a useful tool - I didn't know about it. I unfortunately have sporadic net-cafe-only access so can't download and play with it, and need to ask instead... I presume (by the looks of some online descriptions) that moused can load custom drivers per mouse (as could the patch-to-gpm approach)? Also, I had no time to search - is there an implementation of moused for linux (if not maybe my patch might be a useful interim solution for linuxers)? Maybe leaving my suggestion as a few extra (non-intrusive) lines in the init-file, and some commented lines in the conf-file may still be useful as an alternative for those who want a leaner solution anyway - by avoiding firing up an extra daemon-process? (I read some comments at http://www.semicomplete.com/projects/newpsm/ which suggest that the moused code is a bit bloated at present...?)
don't really see why using /dev/input/mice doesn't work for you. the kernel takes care of merging all mice input to that single device.
