I can confirm this. But only when using the new evdev driver in xorg.

The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 433 error_code 2 request_code 116 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[1134418369,000,xklavier.c:XklStartListen/]     The backend does not require
manual layout management - but it is provided by the application

gnome 2.12.2
xorg-x11 7.0.0 rc3

control-center-2.12.2
xorg-x11 7.0.0 rc3
using evdev mouse driver

The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 1743 error_code 2 request_code 116 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[1134457810,000,xklavier.c:XklStartListen/]     The backend does not require
manual layout management - but it is provided by the application

Created attachment 55931 [details]
Strace output

Here is my strace output

Created attachment 56178 [details] [review]
make configure_button_layout cope with unusual button mappings

I debugged this a bit and found it is caused by configure_buttons_layout in gnome-settings-daemon/gnome-settings-mouse.c expecting physical buttons 1 and 3 to always be mapped to logical buttons 1 and 3 (or the reverse of that). This is apparently not the case when using the evdev driver. To reproduce it without using the evdev driver you can do something like "xmodmap -e 'pointer = 1 3 2 4 5 6'" (swap the right and middle mouse button) before running gnome-settings-daemon. The attached patch attempts to fix it. It should no longer cause BadValue errors, but I cannot guarantee the new logic will always make sense.

Exactly the same problem here with a Logitech MX700 using the evdev driver on a Xorg 7.0 with a Gnome 2.13.4 on an Ubuntu Dapper Drake.

stgraber@athlon:~$ gnome-settings-daemon --version
Gnome gnome-settings-daemon 2.13.4

stgraber@athlon:~$ X -version
X Window System Version 6.99.99.904 (7.0.0 RC 4)
Release Date: 14 December 2005
X Protocol Version 11, Revision 0, Release 6.99.99.904

I get this, also. I'll try the patch and report back.

Hey, thanks! It appears to work here. (At least enough for gnome-settings-daemon to run and not crash.)

I'm using dapper drake and evdev. 
Gsd no longer crashes with the patch, i can log into gnome again, gconfd gets started, etc.
Great :)

Created attachment 57319 [details] [review]
Better patch for unusual button mappings

The previous patch had a stupid bug in it: it confused "logical" buttons (counting from 1) and "physical" buttons (counting from 0) in the first sanity check. This probably caused it to do nothing for people with a fairly normal default mapping (if they had their mouse configured right handed this would have "worked") while for people with a weirder button setup it would have done Bad Things to the mapping.

Please test this new patch even if the previous patch seemed to work.

Thanks for the patches. Setting the settings/target for next GNOME it's a common user complain

After applying Marien Zwart's patch g-s-d still crashed when evdev was in use here. Marien guided me in obtaining useful debug logs which show inconsistent mappings from physical to logical mouse buttons.

     Breakpoint 1, configure_button_layout (
     
         buttons=0x80e7f78 "\001\003\002\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\001*", n_buttons=32,

         left_handed=0) at gnome-settings-mouse.c:44
      44        right_button = MIN (n_buttons, 3);

Here, not only are the first three buttons are out of order ( 1 3 2 ) but also both 1 and 32 are mapped to the same physical button, leading to XSetDeviceButtonMapping returning BadValue for the inconsistent map.

I tried to find out what buttons was set to initially and apparently (did I debug this correctly?) XGetDeviceButtonMapping returns 

     (gdb) p buttons
     $1 = (guchar *) 0x80edf60 "\220\222cï¿¿\220ï¿¿\r\bstyle: hintfull\n "
     (gdb) p n_buttons
     $2 = 170

after the first call. Apparently this initial map get mangled into

     (gdb) p buttons
     $3 = (
          guchar *) 0x80edf60  
     "\001\003\002\004\005\006\a\b\t\n\v\f\r\016\017\020intfull\n "
     (gdb) p n_buttons
     $4 = 32

one step later, while finally the array buttons becomes

     (gdb) p buttons
     $11 = (
          guchar *) 0x80efca0  
     "\001\003\002\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037\001*"

which causes BadValue. Of note (?) are special (or Unicode?) chars and strings in the buttons array occuring initially.

The Mouse reports the following device info in /proc/bus/input/devices

     I: Bus=0003 Vendor=045e Product=0095 Version=0419
     N: Name="Microsoft Microsoft IntelliMouse� Explorer"
     P: Phys=usb-0000:00:1d.0-1/input0
     S: Sysfs=/class/input/input1
     H: Handlers=mouse0 event1
     B: EV=7
     B: KEY=1f0000 0 0 0 0 0 0 0 0
     B: REL=1c3

and output from "evtest"

     $ evtest /dev/input/intellimouse
     Input driver version is 1.0.0
     Input device ID: bus 0x3 vendor 0x45e product 0x95 version 0x419
     Input device name: "Microsoft Microsoft IntelliMouse� Explorer"
     Supported events:
       Event type 0 (Sync)
       Event type 1 (Key)
         Event code 272 (LeftBtn)
         Event code 273 (RightBtn)
         Event code 274 (MiddleBtn)
         Event code 275 (SideBtn)
         Event code 276 (ExtraBtn)
       Event type 2 (Relative)
         Event code 0 (X)
         Event code 1 (Y)
         Event code 6 (HWheel)
         Event code 7 (Dial)
         Event code 8 (Wheel)

     
----gdb log (please check this for mistakes)--------
(gdb) break XGetDeviceButtonMapping
Function "XGetDeviceButtonMapping" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (XGetDeviceButtonMapping) pending.
(gdb) start --sync
Breakpoint 2 at 0x8051b69: file factory.c, line 22.
Starting program: /usr/bin/gnome-settings-daemon --sync
[Thread debugging using libthread_db enabled]
[New Thread -1225770080 (LWP 23961)]
Breakpoint 3 at 0xb7727766
Pending breakpoint "XGetDeviceButtonMapping" resolved

+ Trace 65276

The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
   (Details: serial 1164 error_code 2 request_code 148 minor_code 29)
   (Note to programmers: normally, X errors are reported asynchronously;
    that is, you will receive the error a while after causing it.
    To debug your program, run it with the --sync command line
    option to change this behavior. You can then get a meaningful
    backtrace from your debugger if you break on the gdk_x_error()  
function.)
[1137233374,000,xklavier.c:XklStartListen/]     The backend does not  
require manual layout management - but it is provided by the application
Program exited with code 01.
(gdb)

Created attachment 58336 [details]
g-s-d backtrace

I have a relatively "normal" setup (Logitech MX-300, right-hand) and this patch did not work for me either.

I have an MX-1000 and it didn't work. Running the latest versions of Xorg 7 (modular) with evdev.

Was this fixed in time for the last 2.12.x release? Are there any known workarounds for those of us that have to use evdev to get our input devices working right?

Jeremy: the patch does not work for you?

Had some time to patch & reinstall, after working around another unrelated issue today. The patch seems to be working great. Thanks.

How come the patch works for you Jeremy, but yet it does nothing for me? I will try it once more later.. Using 2.14_beta1

There's apparently quite a lot of people who still have problems with my patch. Since everything works fine here with it it is either a different problem or I'm overlooking something simple (which is entirely possible :) Could those who still have problems try the following:

- Generate a backtrace with gdb, as per the instructions it prints out
- In gdb look at the "XSetPointerMapping ()" function and figure out with what arguments it gets called.
- Look at (break on) "XGetPointerMapping" and figure out what it is setting the button map to.

Trying to provide more information as per Marien's request.
XsetPointerMapping() and XGetPointerMapping() aren't executed until the crash?
I that a valid construal?

$ gdb gnome-settings-daemon
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) start --sync
Breakpoint 1 at 0x80518a1: file factory.c, line 22.
Starting program: /usr/bin/gnome-settings-daemon --sync
[Thread debugging using libthread_db enabled]
[New Thread -1225402688 (LWP 11326)]
[Switching to Thread -1225402688 (LWP 11326)]
main (argc=2, argv=0xbfcb87b4) at factory.c:22
22        gchar *restart_argv[] = { "gnome-settings-daemon", NULL, NULL };
(gdb) break XSetPointerMapping
Breakpoint 2 at 0xb76ebaa7: file ../../src/SetPntMap.c, line 46.
(gdb) break XGetPointerMapping
Breakpoint 3 at 0xb76d78da: file ../../src/GetPntMap.c, line 52.
(gdb) continue
Continuing.
[New Thread -1226949712 (LWP 11330)]
The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 1219 error_code 2 request_code 148 minor_code 29)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[1139698579,000,xklavier.c:XklStartListen/]     The backend does not require manual layout management - but it is provided by the application
Program exited with code 01.

(In reply to comment #19)
> Trying to provide more information as per Marien's request.
> XsetPointerMapping() and XGetPointerMapping() aren't executed until the crash?
> I that a valid construal?

Bah, my fault. Try breaking on XSetDeviceButtonMapping and XGetDeviceButtonMapping too.

In that case see my backtrace in comment #11...

Now to something weird. As an ambitioned Ubuntu Dapper user I just had to install Xgl+compiz yesterday and observed that using my alternate "ExplorerPS/2" entry in xorg.conf (that was previously working fine with g-s-d apart from the dead tilt wheel) the side buttons were broken by XGL/compiz. Interestingly after switching to evdev the side buttons were still dead but g-s-d didn't crash and apparently evdev works fine beacause the tilt-wheel now spews keycodes.

belshazaar, that is because XGL seems to use the old style for evdev instead of the new modular xorg evdev..

Any work being done on this? I do hope this bug is not left for post 2.14, as this is the only reason I won't be using gnome.

Yeah, I'm starting to become worried, generic X input via evdev has been crashing this for quite a few releases.

> I do hope this bug is not left for post 2.14

Seconded. =)

Hopefully this will get fixed upsteam soon. Just to add my note, the patch did work for me.

Are you using the rc version of 2.14? It isn't working for me on there.. Well it didn't. I am going to test it later tonight again.

Making this a 2.14 blocker.

Alright, as I said I would test it again, the patch seems to work this time. I think that you guys changed some code since the last time I tested it, which allowed the patch to fix the problem. (Don't know if this makes sense or not)

Apparantly the GNOME 2.14.0 tarballs are due today. Is this actually blocking it, or will 2.14.0 really go out without a fix for this?

seems the patch is not working in all cases, isn't that the case? That's why, after some discussion, we didn't include the patch in the final 2.14.0. If the patch is proven to fix it for all people that can replicate it, we can put it for the 2.14.1 release.

This bug was marked critical, and was supposed to block the 2.14.0 release, on account of just how many people's systems are rendered unusable by this. Just to be totally clear, I'm asking, are we really delaying fixing such a release-critical bug until after 2.14.0? We have a patch that corrected the problem for so many people, and some people who initially said it didn't later said that it did fix the problem. If it's not making the problem worse, and is correcting the problem for so many people, can we not get it into 2.14.0 now, and see if those who it appeared not to work for have the issue corrected when a pre-patched upstream tarball reaches them? That would be a more reliable test then trusting that each non-developer user is getting the patch applied, compiled, and subsequently installed correctly.

Even if we don't trust the patch, isn't this bug critical enough to delay the 2.14.0 release until a proper fix is available?

Just wanted to say that I tried the patch now on current CVS and running on latest Ubuntu Dapper and it works perfectly. I left (somewhat loose) instructions at the launchpad bug (https://launchpad.net/distros/ubuntu/+source/control-center/+bug/27143) for anyone running Dapper on how to test it themselves. I suppose it's pretty hard to get people to test patches when they don't know how to. =)

IMO it's very critical to have it fixed, as it blocks using more than a few buttons on a mouse, something at least I expect to be able to do in 2006.

fwiw: I am fairly certain my patch does not make matters worse (one can never be 100% certain about that, but let's say I'm about 90% certain :). 

I have only seen one gdb backtrace from someone who still had what looked like the same problem after patching (comment #11), and that backtrace did not make sense to me: it looks like XGetDeviceButtonMapping is producing data that is invalid for XSetDeviceButtonMapping, which according to their manpage is impossible.

This bug seems to hit (almost?) everyone using the evdev driver, which is new to xorg 6.9/7. Once more people start using that xorg version this bug will become more visible.

I am not much of a c programmer though, so my patch should definitely be sanity-checked by someone who is.

Comment #11 would be me then.

Over continually using XGL I forgot about the issue while the 2.14 milestone was approached (happily so in fact because buiding takes a while and my Nvidia card doesn't like vt switching as much as I do...).

So my procedure on this fully up-to-date Ubuntu Dapper Drake system:

$ apt-get source gnome-control-center
$ cd control-center-2.14.0/
$ patch -p0 < ../marien-revised.patch
<~ patching ...settings-mouse.c>
$ dpkg-buildpackage -rfakeroot -b
<no errors>
$ sudo dpkg -i ../gnome-control-center_2.14.0-0ubuntu1_i386.deb ../capplets-data_2.14.0-0ubuntu1_all.deb

$ apt-show-versions gnome-control-center
gnome-control-center/unknown uptodate 1:2.14.0-0ubuntu1
$ date
Di 14 Mär 02:38:55 CET 2006


kicked out XGL; restarted GDM: No-go.

"Der Einstellungsdämon wurde zu oft neu gestartet.

Die letzte Fehlermeldung war:

System exception: IDL:Bonobo/GeneralError:1.0 : Kindprozess gab keine Fehlermeldung aus. Ein unbekannter Störfall trat auf"

(settings-daemon restarted too often; Last message: No error report. Unknown Failure.)


and

$ gnome-settings-daemon

** (gnome-settings-daemon:31724): WARNING **: The system configuration changed - but we remain silent

The program 'gnome-settings-daemon' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 624 error_code 2 request_code 148 minor_code 29)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
�{[1142301437,000,xklavier.c:XklStartListen/]  The backend does not require mana gement - but it is provided by the application


I didn't bother to recompile with symbols and -ggdb3 as Marien taught me. I guess it will be the same story.

That's my mouse, BTW: http://www.microsoft.com/hardware/mouseandkeyboard/productdetails.aspx?pid=003 (the picture at the top, Intellimouse 4.0 with tilt wheel)

I forgot the most important: I'd vote to go ahead and commit the patch (as long as it will not be completely forgotten over time).

This is really, really, critical. It causes gnome to be pretty much unusable (gnome-settings-daemon fails to run) to anyone running the new input drivers. Shipping 2.14.0 like this I think is a mistake, this will only affect more people once it comes out and all the regular people with their spiffy mice try to play.

Seems to be critical for the people that see it, I'm not seeing it at all, as well as most people I've talked with about it, and, again, it seems to not fix it entirely for some people, while it could add new problems. So, while I really want to see this fixed, I can't just commit a patch that is not certified to fix it. At least that's what I understand from the comments.

If you come with a patch that works for everybody involved in this bug, I'll happily commit it and include it in 2.14.1 (2.14.0 is already released) or 2.14.0.1 if it's quick enough to try the inclusion in GNOME 2.14.0.

(In reply to comment #32)
> This bug was marked critical, and was supposed to block the 2.14.0 release.

The blocker state is used to mark the bug as a potential blocker for the release. It doesn't mean the release will be blocked because of it, but that people will evaluate the bug and decide if it's okay to release with it.

Of course, having a good fix in would solve the problem :-)

The problem is, given that some people have applied the patch, had no success, then reversed and had success later, I doubt everyone is installing it correctly. The only way to get this tested by "everyone" is going to be to push it to a real tarball and see if that addresses the issue for people.

Oh well.

> I doubt everyone is installing it correctly.

I made a mistake? I posted to see wherein it lies...

I think we can say with a fair certainty that there are two disparate issues at hand here. Marien wrote the patch to correct the left-handed mouse mapping problem, which does what is supposed to do.

Judging from my backtracing, granted it's correct, there's some weird interaction between x11-libs and g-s-d happening that bears no relation to the handedness.

Shouldn't this report be split and the fix to the first issue just be commited?

The patches don't fix anything to do with handedness, they fix the bug that this report is based on: "gnome-settings-daemon crashes with: 'BadValue (integer parameter out of range for operation)'" when using evdev. The patch works for me, and it really looks like it's working for most everyone with the same issue.

Rodrigo: Very interesting, you don't see it? Are you sure you set up X11 properly for evdev? I am unable to locate anyone with evdev and g-s-d working. What does running evtest on the /dev/input/eventX node give you?

the patch solves the issue for me (Ubuntu Dapper, Logitech MX1000)

Works for me: Ubuntu Dapper, Logitech Cordless Click! Plus Optical Mouse (aka Cordless Desktop LX)

Although I usually hate "works for me too" comments, it seems that the patch associated with this bug needs some "positive energy" to become accepted.

So, works for me on Slackware 10.2 with gware G using a Logitech MX1000.

I had this problem before when I upgraded to Xorg 7.0 and started using evdev.  At the time I was using gnome-2.12.  I added the patch by Marien to the gnome-2.12.3.ebuild and it solved the issue.  Now the problem is back as I upgraded to gnome-2.14.  The patch somehow stopped working for control-center-2.14.  I have a mx510 here.

>The patch somehow stopped working for control-center-2.14.

It still works for me - but I had to redo the process and reapply the process after the latest update in Dapper, as it got overwritten. Maybe it's the same for you.

So what's happening here? The patch which seems to work for virtually everybody, has been on here for over 2 months; it's missed its target, so this bug affects 2.14.0 users.

Updating to reflect that it's still impacting 2.14.0.

Ok, it looks ok to me, Seb, what do you think? Do we commit it to 2.14.1?

It works fine for a load of people so I would say to just commit it yep

Using this ebuild (Original + patch included)
https://fantoo.ru/svn/gnome-base/control-center/control-center-2.14.0-r1.ebuild

x11-base/xorg-x11-7.0-r1

g-s-d still crashes

*** Bug 336378 has been marked as a duplicate of this bug. ***

Oleg: it still crashes with the same backtrace?

So what is the actual issue that causes this problem? What exactly is it that gnome-settings-daemon doing to the mouse that it's not supposed to? What needs to be done to correct it? Does this patch do that or not? Do we need more information from the freedesktop folks about how the evdev driver works? Does this problem effect more than just the evdev driver? Does it affect the newly re-written evdev driver?
As a user I'm now officially thoroughly confused.

(In reply to comment #55)
> So what is the actual issue that causes this problem? What exactly is it that
> gnome-settings-daemon doing to the mouse that it's not supposed to? What needs
> to be done to correct it?

I'd like to repeat (part of) my comment #4:

"...expecting physical buttons 1 and 3
to always be mapped to logical buttons 1 and 3 (or the reverse of that). This
is apparently not the case when using the evdev driver. To reproduce it without
using the evdev driver you can do something like "xmodmap -e 'pointer = 1 3 2 4
5 6'" (swap the right and middle mouse button) before running
gnome-settings-daemon. "

> Does this patch do that or not?

Comment #3 again: 
"The attached patch attempts to fix it. It should no
longer cause BadValue errors, but I cannot guarantee the new logic will always
make sense."

> Do we need more information from the freedesktop folks about how the evdev 
> driver works?

Not really.

> Does this problem effect more than just the evdev driver?

As mentioned above it affects anyone with a mouse with a strangely-mapped left mouse button.

> Does it affect the newly re-written evdev driver?

I do not know.

ok, so committing this patch will make more people happy than having the old behavior, so committing it now for 2.14.1.

For people still getting crashes, please file new bugs with backtraces, so that we can deal with it.

Hey guys,

(Sorry for coming into this late, I just ran into this bug)

I wrote the code the patch in attachment 57319 [details] [review] modifies and I think patch looks good overall.  One comment though, the patch assumes the right button is mapped when going into left handed mode and assumes the left button is mapped when going into right handed mode.  If those assumptions are ever wrong, then the code will overrun the button mapping buffer by a byte (because i = n_buttons).  Since this bug report is already closed, I've filed it as bug 338254.

I'm still getting crashes from gnome-settings-daemon at startup when using evdev.  I'm using control-center-2.14.1. My mouse is a Logitech G5.

I'm also seeing this crash again, with the patch applied, but only after I login once, logout, and login again.

I just filed bug 342980, which seems to be the same problem under 2.14.1 with the patch from bug 338254 applied to it.