Bug#500231: mouse (buttons) not properly working in gnome
Patrick Schoenfeld
Version: 2.22.2.1-1
Severity: important
File: gnome
Hi,
I'm not exactly sure if this is the right package to report the bug
against, so please reassign if appropriate.
The problem is as following:
In GNOME my mouse is not working properly. It seems that single-clicking
always results in a double-click. Because of that I need to keep the
mouse button clicked in order to access the menus and to not do things I
don't want to do, when using the desktop context menu. Changing the
double-click-interval in both possible directions did not help in any
way.
The problem is specific to GNOME, because fluxbox appearently works the
right way (tm).
I only gave this severity important, but I don't think that this is
ready for this way. GNOME is effectively unusable if this problem
exists.
Best Regards,
Patrick
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gnome-settings-daemon depends on:
ii gconf2 2.22.0-1 GNOME configuration database syste
ii libart-2.0-2 2.3.20-2 Library of functions for 2D graphi
ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit
ii libaudiofile0 0.2.6-7 Open-source version of SGI's audio
ii libbonobo2-0 2.22.0-1 Bonobo CORBA interfaces library
ii libbonoboui2-0 2.22.0-1 The Bonobo UI library
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra
ii libdbus-1-3 1.2.1-3 simple interprocess messaging syst
ii libdbus-glib-1-2 0.76-1 simple interprocess messaging syst
ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared
ii libfontconfig1 2.6.0-1 generic font configuration library
ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib
ii libgconf2-4 2.22.0-1 GNOME configuration database syste
ii libglade2-0 1:2.6.2-1 library to load .glade files at ru
ii libglib2.0-0 2.16.5-1 The GLib library of C routines
ii libgnome-desktop-2 2.22.3-1 Utility library for loading .deskt
ii libgnome2-0 2.20.1.1-1 The GNOME 2 library - runtime file
ii libgnomecanvas2-0 2.20.1.1-1 A powerful object-oriented display
ii libgnomekbd2 2.22.0-1 GNOME library to manage keyboard c
ii libgnomeui-0 2.20.1.1-1 The GNOME 2 libraries (User Interf
ii libgnomevfs2-0 1:2.22.0-4 GNOME Virtual File System (runtime
ii libgstreamer-plugins-b 0.10.19-2 GStreamer libraries from the "base
ii libgstreamer0.10-0 0.10.19-3 Core GStreamer libraries and eleme
ii libgtk2.0-0 2.12.11-3 The GTK+ graphical user interface
ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library
ii liborbit2 1:2.14.13-0.1 libraries for ORBit2 - a CORBA ORB
ii libpango1.0-0 1.20.5-2 Layout and rendering of internatio
ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a
ii libpng12-0 1.2.27-1 PNG library - runtime
ii libpopt0 1.14-4 lib for parsing cmdline parameters
ii libsm6 2:1.0.3-2 X11 Session Management library
ii libstartup-notificatio 0.9-1 library for program launch feedbac
ii libx11-6 2:1.1.5-1 X11 client-side library
ii libxi6 2:1.1.3-1 X11 Input extension library
ii libxklavier12 3.5-2 X Keyboard Extension high-level AP
ii libxml2 2.6.32.dfsg-4 GNOME XML library
ii libxrandr2 2:1.2.3-1 X11 RandR extension library
ii libxrender1 1:0.9.4-2 X Rendering Extension client libra
ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
gnome-settings-daemon recommends no packages.
gnome-settings-daemon suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Josselin Mouette
reassign 500231 xserver-xorg
forcemerge 500228 500231
thanks
Le vendredi 26 septembre 2008 à 14:21 +0200, Patrick Schoenfeld a
écrit :
> I'm not exactly sure if this is the right package to report the bug
> against, so please reassign if appropriate.
>
> The problem is as following:
> In GNOME my mouse is not working properly. It seems that single-clicking
> always results in a double-click. Because of that I need to keep the
> mouse button clicked in order to access the menus and to not do things I
> don't want to do, when using the desktop context menu. Changing the
> double-click-interval in both possible directions did not help in any
> way.
>
> The problem is specific to GNOME, because fluxbox appearently works the
> right way (tm).
>
> I only gave this severity important, but I don't think that this is
> ready for this way. GNOME is effectively unusable if this problem
> exists.
This is an issue I’ve seen reported way too many times. The X upgrade
path is seriously broken when it comes to mouse configuration. In many
cases, it leads to the configuration having two mice configured, one
listening to e.g. /dev/psaux and one to /dev/input/mice. Events are
received twice, which is why the pointer goes twice too fast, and clicks
become double-clicks.
You can easily fix your X configuration, but the upgrade should really
not do that in the first place.
Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Patrick Schoenfeld
On Fri, Sep 26, 2008 at 04:13:24PM +0200, Josselin Mouette wrote:
> This is an issue I’ve seen reported way too many times. The X upgrade
> path is seriously broken when it comes to mouse configuration. In many
> cases, it leads to the configuration having two mice configured, one
> listening to e.g. /dev/psaux and one to /dev/input/mice. Events are
> received twice, which is why the pointer goes twice too fast, and clicks
> become double-clicks.
are you sure this a X issue? Because the problem does not occur in
fluxbox.
> You can easily fix your X configuration, but the upgrade should really
> not do that in the first place.
Hm, how would the fix look like? I have exactly the same Xorg
configuration that I had before I upgraded. No two mouse configurations.
Hm.. its using /dev/input/mouse0. I'll test it with /dev/input/mice.
Best Regards,
Patrick
Patrick Schoenfeld
On Fri, Sep 26, 2008 at 05:19:49PM +0200, Patrick Schoenfeld wrote:
> are you sure this a X issue? Because the problem does not occur in
> fluxbox.
indeed it seems to be related to the Xorg configuration. In fact I had a
configuration that worked fine back in Etch and is now broken. Removing
the mouse block (and every reference) entireley, so that the autodetection code
is used, does the trick for me. The Change from /dev/input/mouse0 to
/dev/input/mice however did not work.
That seems like a regression to me. Whats wrong with the following
configuration?
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
#Option "CorePointer"
Option "Device" "/dev/input/mouse0"
Option "Protocol" "IMPS/2"
Option "ZAxisMapping" "4 5"
Option "Emulate3Buttons" "true"
EndSection
Julien Cristau
> That seems like a regression to me. Whats wrong with the following
> configuration?
>
> Section "InputDevice"
> Identifier "Configured Mouse"
> Driver "mouse"
> #Option "CorePointer"
> Option "Device" "/dev/input/mouse0"
> Option "Protocol" "IMPS/2"
> Option "ZAxisMapping" "4 5"
> Option "Emulate3Buttons" "true"
> EndSection
>
Nothing, if your mouse is actually /dev/input/mouse0 at every boot (look
at /proc/bus/input/devices)
Cheers,
Julien
Patrick Schönfeld"
> at /proc/bus/input/devices)
Well, there is and there has always been:
I: Bus=0011 Vendor=0002 Product=0006 Version=0000
N: Name="ImExPS/2 Generic Explorer Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/class/input/input5
U: Uniq=
H: Handlers=mouse0 event5
B: EV=7
B: KEY=1f0000 0 0 0 0 0 0 0 0
B: REL=143
Also udev creates devices for it:
root@teekanne:~# ls -l /dev/input/mouse0
crw-rw---- 1 root root 13, 32 6. Okt 13:33 /dev/input/mouse0
Additional, changing it to /dev/input/mice (which also exists) does
not work either..
Julien Cristau
> indeed it seems to be related to the Xorg configuration. In fact I had a
> configuration that worked fine back in Etch and is now broken. Removing
> the mouse block (and every reference) entireley, so that the autodetection code
> is used, does the trick for me. The Change from /dev/input/mouse0 to
> /dev/input/mice however did not work.
>
please provide the full config and log, not just some snippet.
it really sounds like your config was just wrong.
Thanks,
Julien
Patrick Schoenfeld
On Mon, Oct 06, 2008 at 02:59:02PM +0200, Julien Cristau wrote:
> please provide the full config and log, not just some snippet.
yes, off course I can do this. Just reproduced the problem with the old
configuration and generated the attached log file.
> it really sounds like your config was just wrong.
I may have a different 'ear' then you, but it really does not sound like
this to me ;). Well, the configuration file is attached and I can guarantee
you that this file works perfect with Debian Etch. If it now does not
work with Lenny anymore this ain't a configuration problem, but a
upgrade path problem. Because either the new auto detection code should
not cause such problems (I guess that it is responsible, because if I
understand the log right then Josselin is right that the mouse is
detected twice) or if it would really be a configuration problem that is
specific to the current Xorg version (appearently, because it worked in
Etch) then the upgrade should have updated the configuration or at a
very least should have warned me.
Best Regards,
Patrick
Patrick Schönfeld"
2008/10/6 Julien Cristau <jcri...@debian.org>:
> OK this is odd, the keyboard and mouse get added twice according to the
> log.
Well, the question is: Why?
> Why are the CorePointer and CoreKeyboard options commented out?
> Uncommenting them should fix this.
It does.
xorg.conf(5) says:
Option "Core Pointer"
When this is set, the input device is installed as the core (primary)
pointer device. There must be exactly one core
pointer. *If this option is not set here, or in the ServerLayout
section, or from the -pointer command line option,
then the first input device that is capable of being used as a
core pointer will be selected as the core pointer.*
Please note the part which has been enclosed by asterisks. According
to this the options are _not needed_ because Xorg should be able to
find it out itself and apart from this I guess that Xorg think this,
too:
(==) The core pointer device wasn't specified explicitly in the layout.
Using the first mouse device.
(==) The core keyboard device wasn't specified explicitly in the layout.
Using the first keyboard device.
After this is says:
(**) Configured Mouse: always reports core events
And as already said it worked in Etch so this is clearly a regression
(from the documented behaviour).
Best Regards,
Patrick