According to the stack trace in #3, the error seems to occur when set_motion calls XGetFeedbackControl.
From man XGetFeedbackControl:
A BadMatch error will be generated if the requested device does not support feedbacks. Whether or not a given device supports feedbacks can be determined by examining the information returned by the XOpenDevice request. For those devices that support feedbacks, XOpenDevice will return an XInputClassInfo structure with the input_class field equal to the constant FeedbackClass (defined in the file XI.h).
Since set_motion (from the gnome-settings-daemon source file gsd-mouse-manager.c) does not perform this check before calling XGetFeedbackControl, that is probably the problem.
According to "xinput list --long" the harddisk is a keyboard with mouse buttons(!):
--------------------------------------------------------------------------------
Western Digital My Book id=9 [slave keyboard (3)]
Reporting 1 classes:
Class originated from: 9. Type: XIButtonClass
Buttons supported: 20
Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra" "Button Forward" "Button Back" "Button Task" "Button 8" "Button 9" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown"
--------------------------------------------------------------------------------
This probably explains why the problem occurs in a mouse handling function.
To fix the problem, we just have to check if the device supports feedbacks before calling XGetFeedbackControl. See attached patch for the gnome-settings-daemon package.
I don't know very much about X programming, so the patch needs review from someone who knows what they're doing. It seems to work nicely for me so far, though.
According to the stack trace in #3, the error seems to occur when set_motion calls XGetFeedbackCon trol.
From man XGetFeedbackCon trol:
A BadMatch error will be generated if the requested device does not support feedbacks. Whether or not a given device supports feedbacks can be determined by examining the information returned by the XOpenDevice request. For those devices that support feedbacks, XOpenDevice will return an XInputClassInfo structure with the input_class field equal to the constant FeedbackClass (defined in the file XI.h).
Since set_motion (from the gnome-settings- daemon source file gsd-mouse- manager. c) does not perform this check before calling XGetFeedbackCon trol, that is probably the problem.
According to "xinput list --long" the harddisk is a keyboard with mouse buttons(!): ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- --- ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ---
-------
Western Digital My Book id=9 [slave keyboard (3)]
Reporting 1 classes:
Class originated from: 9. Type: XIButtonClass
Buttons supported: 20
Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra" "Button Forward" "Button Back" "Button Task" "Button 8" "Button 9" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown"
-------
This probably explains why the problem occurs in a mouse handling function.
To fix the problem, we just have to check if the device supports feedbacks before calling XGetFeedbackCon trol. See attached patch for the gnome-settings- daemon package.
I don't know very much about X programming, so the patch needs review from someone who knows what they're doing. It seems to work nicely for me so far, though.