Suddenly (after installing Squeeze) I have to use Input Attach to use a serial mouse at
all, i.e. for GPM as well as X (GDM). So far I had thought such tricks, which only serve
to force the consumer to replace perfectly good hardware with new one, limited to
commercial operating systems. I think this policy should be reversed, especially as Input
Attach does not work reliably.

I am filing against the meta package because this behaviour persists even through kernel
package upgrades, so I take it as a matter of policy.

I'm surprised that wasn't necessary before.

https://help.ubuntu.com/community/SerialMouseHowto
[...]

The basic problem is that there is no good way to detect a serial mouse.
So you have to help the kernel.  What is the problem with Input Attach?

Ben.

Hi,

Thanks for your quick reply.

It honestly never was. Sometimes I had to set the device in the X configuration, but then
it worked fine. GPM always worked out of the box. That is why I am so upset now.

I remember sometimes being asked for the device or type of pointer.

First of all, I had to search for it when the mouse did not work. Secondly, it does not
work reliably; see Bug#630173.

Regards,

Axel Stammler

Which version of Debian were you using previously?
[...]

Please provide the following information:

- Kernel boot logs from before and after the upgrade.  The old boot log
  should still be available from one of /var/log/messages* if you
  upgraded recently.
- Configuration files for gpm and X used before the upgrade
- Contents of /etc/modules used before the upgrade

Ben.

Which version of Debian were you using previously?
[...]

Please provide the following information:

- Kernel boot logs from before and after the upgrade.  The old boot log
  should still be available from one of /var/log/messages* if you
  upgraded recently.
- Configuration files for gpm and X used before the upgrade
- Contents of /etc/modules used before the upgrade

Ben.

Hi,

Lenny (5.0.8). But I did not upgrade, I installed Squeeze from scratch, so I can't see how
there could be any problem related to the previous installation.

I installed Lenny a few months ago.

GPM was not installed on this machine then.

[...]

Indeed, and since you were not upgrading the installer could not
possibly know about your old configuration.  So it is hardly surprising
that your serial mouse was no longer configured.

Your old X configuration shows that you used the serial mouse driver in
the X server, not the kernel (which is why you did not need to use
inputattach).  You can use the same configuration now, if you like.

Ben.

Hi, Ben,

Unfortunately things are not as easy as they might seem.
the two separate screens to work. It was not a perfect setup as one screen was distorted
but I found a workaround for that.

In Squeeze, this is no longer necessary, both screens can be configured using the Monitors
menu item, and there is no distortion.

Moreover, the configuration does not work anymore as it is; it causes errors.

But even if I make it work or create a barebones X configuration file just with the
Pointer Device set to /dev/ttyS0, the pointer is not functional.

I can set the pointer device for GPM easily; if you have any hints on how to this for X,
they would be much appreciated.

This takes me back to my original point: If it was possible to use a serial mouse in the
past without installing separate software which is not available at installation time, why
was this functionality removed? If it is not possible to recognize serial pointer devices,
the installation process should include a question if no other pointer device is
discovered.

Regards,

Axel Stammler

retitle 632419 X: please ask for (serial) mouse device name at installation time if no pointer is detected
reassign 632419 xserver-xorg-input-mouse 1:1.5.0-2
severity 632419 wishlist
quit

Hi,

axst@users.sourceforge.net wrote:

What are those errors?  That might be an X bug.  (Ideally, upgrades of
any program should not break working configurations without warning.)

If this is true and xserver-xorg-input-mouse is installed, then it
would definitely be an X bug.

By this functionality do you mean X's configuration process
(xf86setup, etc)?  If someone is interested in working on that, it
might be possible to revive it, but it would have to be a separate
program, since the general approach to X installation nowadays is to
autodetect as much as possible.

The idea of a debconf prompt when installing and no pointer device is
present sounds more interesting, though it might be hard to get right.
Reassigning to the X maintainers in case someone there is interested.

Thanks for writing, and hope that helps.
Jonathan

Ideally, yes, but serial mice are enough of a corner case these days
that they're not worth the complexity.
No.  Serial mice should be switched over to inputattach to get a proper
input device that X will use.

Cheers,
Julien

Hi again,

Jonathan Nieder wrote:

Hm, /usr/share/doc/xserver-xorg-input-mouse/README.gz says:

	  The old Pointer section has been replaced by a more general
	  InputDevice section. The following is a minimal example of an
	  InputDevice section for a mouse:


	  Section "InputDevice"
[...]

That text dates back to long ago (before version 1.1.2 of the X mouse
driver at least), and the example xorg.conf you sent uses an InputDevice
section, so I assume you're doing okay there.  More to the point,
/usr/share/doc/xserver-xorg/NEWS.Debian.gz says:

	xserver-xorg (1:7.4+1) unstable; urgency=low

	  * Changes in handling of input devices

	  Starting from this version, input devices are no longer configured
	  statically in /etc/X11/xorg.conf.  Instead, input devices are detected at
	  runtime (and can be hotplugged) and configured individually.  The default
	  keyboard layout is shared with the console and is configured in
	  /etc/default/keyboard.  As a result, devices configured in xorg.conf to
	  use the mouse or kbd driver are ignored by the X server by default.

	  For more details, see:
http://who-t.blogspot.com/2008/12/evdev-xorgconf-hal-and-other-fud.html
http://who-t.blogspot.com/2008/10/new-keyboard-configuration-handling.html

and continues by explaining that one might need to disable
AutoAddDevices to keep manual configurations working.  Perhaps that
information was not shown on upgrade for some reason.

Julien Cristau wrote:

Sorry, messages crossed.  This example doesn't fall in the category I
mentioned above anyway, since the changes were documented in
NEWS.Debian.gz files.

[...]
It would also be nice to document this in the xserver-xorg-input-mouse
package description:

	Most configurations on Linux will use the evdev driver and do not
	need this package.  See the inputattach package if your mouse
	is not automatically detected by the kernel, for example because
	it is a serial mouse.

Sounds like a good idea.

Cheers,
Julien

Some sysadmins on Linux may be expecting the X "mouse" driver to get
their mouse to work.  Help them out by pointing to the tools they
can use instead:

 - xserver-xorg-input-evdev, to allow the X server to make use of
   the Linux kernel's event device interface;

 - inputattach, to make input devices (e.g., serial mice) that
   cannot be easily autodetected visible to the Linux kernel.

Text inspired by the introduction in README.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Julien Cristau wrote:
[...]

How about this?

 debian/changelog |    7 +++++++
 debian/control   |    8 +++++++-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 42342912..adc39fdb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xserver-xorg-input-mouse (1:1.7.1-2) UNRELEASED; urgency=low
+
+  * Describe relationship to xserver-xorg-input-evdev in the long
+    description.
+
+ -- Jonathan Nieder <jrnieder@gmail.com>  Thu, 07 Jul 2011 13:09:57 -0500
+
 xserver-xorg-input-mouse (1:1.7.1-1) unstable; urgency=low

   * New upstream release:
diff --git a/debian/control b/debian/control
index a40be49a..79e77d65 100644
--- a/debian/control
+++ b/debian/control
@@ -26,7 +26,13 @@ Depends:
 Provides:
  ${xinpdriver:Provides}
 Description: X.Org X server -- mouse input driver
- This package provides the driver for mouse input devices.
+ This package provides a driver for mouse input devices. It mainly used
+ on non-Linux operating systems such as BSD and Solaris. Most
+ configurations on Linux will use evdev, the kernel's event delivery
+ mechanism, and do not need this package.
+ .
+ See the inputattach package if your mouse is not automatically
+ detected by the Linux kernel, for example because it is a serial mouse.
  .
  More information about X.Org can be found at:
  <URL:http://www.X.org>

Encouraged-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jul 07, 2011 at 07:44:44PM +0200, Julien Cristau wrote:
[...]

And here's a simple patch for that.

 debian/changelog |    2 ++
 debian/control   |    2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 249ca77e..2328de65 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
 xserver-xorg-input-evdev (1:2.6.0-3) UNRELEASED; urgency=low

   * Remove obsolete .manpages.
+  * Suggest inputattach, since it can make serial-attached input devices
+    (e.g., serial mice) available through evdev.

reopen 632419
tags 632419 =

clone 632419 -1 -2
retitle -1 xf86-input-mouse: package description should explain relationship to evdev
# http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=86;bug=632419
tags -1 + patch
retitle -2 xf86-input-evdev: please "Suggests: inputattach"
reassign -2 xserver-xorg-input-evdev 1:2.6.0-3
# http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=91;bug=632419
tags -2 + patch
quit

Hi Axel,

axst@users.sourceforge.net wrote:

Thanks for a reminder!  Cloning the bug for the two subtasks that
already have patches.

If you make any progress on this (e.g., by writing a simple script to
detect the need for inputattach at some appropriate time), please feel
free to let us know.

Cheers,
Jonathan