[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#588566: xserver-xorg-input-all: For amd64 should depend on xserver-xorg-input-kbd and xserver-xorg-input-mouse



On 2010-07-09 19:32+0100 Julien Cristau wrote:

On Fri, Jul  9, 2010 at 11:04:19 -0700, Alan W. Irwin wrote:

Package: xserver-xorg-input-all
Version: 1:7.5+6
Severity: normal

The default hot plugging X input system implemented using evdev
did not detect my serial mouse so I turned hot plugging off using

Option          "AutoAddDevices"        "False"
Option          "AutoEnableDevices"     "False"

in the ServerFlags section of xorg.conf with corresponding InputDevice
sections that load the kbd and mouse drivers.

However, the result was a complete freeze because
xserver-xorg-input-kbd and xserver-xorg-input-mouse were not installed
by default by xserver-xorg-input-all.  The issue was resolved by
installing those drivers, but wouldn't it be better to have them
installed by default for the benefit of those like me with hardware
where the evdev approach does not work?

Of course, if xserver-xorg-input-mouse and/or xserver-xorg-input-kbd
interfere with evdev, that is a different story, but I don't think
they affect it at all unless the user specifically is requesting kbd
and mouse drivers as I outlined above.

Can't you use inputattach to turn your serial mouse into an input
device, which can then be picked up by evdev?

Possibly, but I don't know how to do that.  There appears to be a lot
of churn in how X handles input now (Ubuntu has dropped HAL for
example) so there are lots of differences between distros and all
general X input advice has to taken with a grain of salt since it may
only apply to certain distros.  Given the churn, I think you will see
the appeal of the tried-and-true mouse driver approach for me.

For what it is worth, here is the configuration that works for me with
that serial mouse:

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "Mouseman"
        Option      "Device" "/dev/ttyS0"
        Option          "Buttons"               "3"
        Option          "Emulate3Buttons"       "off"
        # Desperate workaround to turn off wheel part of mouse which makes
        # middle clicking extremely unreliable.
        Option          "ZAxisMapping"  "8 9"
EndSection

I have included that ZAxisMapping option because that is what I have,
but it is not really necessary for that particular mouse (bought in
1996 from logitech and still going strong!).

Of course, I assume the legacy mouse driver will not be supported
indefinitely so I am willing to learn about inputattach if that
actually works for the above mouse (and can be configured statically so
I don't have to worry about it each time I run startx).

So if you can recommend a good web reference for inputattach whose
advice is applicable to Debian, I would be willing to give it a try.
But even if that turns out to be a success for me, it may not work for
others with legacy mouse hardware.  Thus, I think the dependency issue
for xserver-xorg-input-all continues to be a valid concern so long as
you are still offering the xserver-xorg-input-kbd and
xserver-xorg-input-mouse packages that historically have worked so
well for a huge variety of hardware for the case where the user is not
concerned about hot plugging.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



Reply to: