After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 549267 - Mouse Preferences are not taken into use when a mouse is plugged in
Mouse Preferences are not taken into use when a mouse is plugged in
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: general
2.22.x
Other All
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
: 553587 556875 558644 559693 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-08-25 08:37 UTC by Vesa Halttunen
Modified: 2008-11-07 20:07 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
patch with complaints resolved (2.77 KB, patch)
2008-10-31 23:42 UTC, William Grant
needs-work Details | Review
patch the third (3.45 KB, patch)
2008-11-01 12:04 UTC, William Grant
committed Details | Review

Description Vesa Halttunen 2008-08-25 08:37:23 UTC
Please describe the problem:
If a (USB) mouse is unplugged from the system and plugged back in the mouse settings defined using the Mouse Preferences window (such as Acceleration and Sensitivity) are not taken into use. Default values are used instead. The user has to open the Mouse Preferences window and touch the Acceleration/Sensitivity controls in order to get the mouse functioning as preferred.

Steps to reproduce:
1. Unplug USB mouse.
2. Plug USB mouse back in.


Actual results:
The mouse pointer moves according to some default acceleration/sensitivity values.

Expected results:
The mouse pointer should move according to the acceleration/sensitivity values set using the Mouse Preferences window.

Does this happen every time?
Yes.

Other information:
This is particularly annoying when the mouse is plugged into a USB hub integrated into a monitor; when the monitor is powered off the hub is also powered off and all devices get disconnected. When the monitor is powered back on the mouse does not work as expected.
Comment 1 Jens Granseuer 2008-09-28 10:09:53 UTC
*** Bug 553587 has been marked as a duplicate of this bug. ***
Comment 2 Jens Granseuer 2008-10-19 11:22:16 UTC
*** Bug 556875 has been marked as a duplicate of this bug. ***
Comment 3 Jens Granseuer 2008-10-31 18:06:27 UTC
*** Bug 558644 has been marked as a duplicate of this bug. ***
Comment 4 William Grant 2008-10-31 23:42:23 UTC
Created attachment 121760 [details] [review]
patch with complaints resolved

I've resolved Jens' issues with my patch from bug #558644. I think I've matched all of the new code with the rest of the coding style. It now builds and works (albeit with the bug this change fixes) without HAVE_XINPUT defined.
Comment 5 Jens Granseuer 2008-11-01 11:27:35 UTC
Looks pretty good. One thing I missed in the first review is that you need to remove the filter again in _stop so that the plugin can be properly unloaded.

Regarding the HAVE_XINPUT, there already are a few #ifdef blocks in the file. If you just move the respective funtions into on of those blocks, you'd not need a new ifdef. The ifdef in _start should start in the first column.
Comment 6 William Grant 2008-11-01 12:04:57 UTC
Created attachment 121771 [details] [review]
patch the third

Oh, good catch on that filter removal. I've also reshuffled things and fixed the #ifdef indentation.
Comment 7 Jens Granseuer 2008-11-01 12:40:10 UTC
2008-11-01  Jens Granseuer  <...>
                              
        Patch by: William Grant <...>
                                                  
        * plugins/mouse/gsd-mouse-manager.c: (devicepresence_filter),
        (set_devicepresence_handler), (set_mouse_settings),
        (gsd_mouse_manager_start), (gsd_mouse_manager_stop): listen for
        X device changes, and reconfigure the mouse if necessary so that the
        settings aren't ignored when hotplugging (bug #549267)
Comment 8 Jens Granseuer 2008-11-07 20:07:31 UTC
*** Bug 559693 has been marked as a duplicate of this bug. ***