From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021218 Description of problem: The working configuration for my mouse is this: $ cat /etc/sysconfig/mouse FULLNAME="Generic - 3 Button Mouse (serial)" MOUSETYPE="Microsoft" XEMU3="no" XMOUSETYPE="generic3" DEVICE=/dev/ttyS1 OPTIONS="-t imps2 -m /dev/input/mice -M" When I run redhat-config-mouse within the X Window System, it preselects "Generic > 3 Button Mouse (serial)". So far so good. When I click "OK" without clicking the "Serial devices" button and without choosing the correct serial device there, it always activates /dev/ttyS0 instead of /dev/ttyS1. That is a trap. It should not alter my configuration unless I tell it to do so. Internally it selects "/dev/ttyS0 (COM1 under DOS)" as a starting value in the "Serial devices" sub-dialog. It should take the current DEVICE from /etc/sysconfig/mouse. Worse, even if I choose /dev/ttyS1 in the "Serial devices" dialog and exit with "OK", it kills my mouse in X by restarting gpm: $ redhat-config-mouse Shutting down console mouse services: [ OK ] Starting console mouse services: [ OK ] Effectively, within X, redhat-config-mouse always (!) kills my mouse and I need to fix it from text mode. Running redhat-config-mouse (or redhat-config-mouse --device /dev/ttyS1) in text mode also restarts gpm, but repairs the non-working mouse in my current X session. Version-Release number of selected component (if applicable): 1.0.2-10 How reproducible: Always
Right. This happens in both GUI and TUI modes, but it should be fixed in redhat-config-mouse-1.0.3-1, which should appear in Rawhide in the next day or so. QA, please verify.
With redhat-config-mouse-1.0.3-1, if I click "OK" without going into the "Serial Devices" selection, I get the following traceback: Traceback (most recent call last): File "/usr/lib/python2.2/site-packages/rhpl/firstboot_gui_window.py", line 83, in okClicked if self.apply(): File "/usr/share/redhat-config-mouse/mouse_gui.py", line 338, in apply port = self.deviceStore.get_value(iter, 1) TypeError: iter must be a GtkTreeIter
Oops, I didn't test that case. Try again with redhat-config-mouse-1.0.3-2.
I'm still seeing the same traceback with 1.0.4-1 (latest in Beehive at the moment.)
I must be losing my mind. I think I've fixed it for real this time with redhat-config-mouse-1.0.4-2. Sorry for the problems.
There is a stack of 64 bugs that have been in Modified state for a long period of time. I am closing these as Rawhide now. If you find that the issue is not fixed, please reopen this report.
Let me add my bit of QA then. ;o) It no longer kills the current mouse h/w configuration, *but* now it creates a bad configuration file silently. My working config: $ cat /etc/sysconfig/mouse FULLNAME="Generic - 3 Button Mouse (serial)" MOUSETYPE="Microsoft" XEMU3="no" XMOUSETYPE="Microsoft" DEVICE=/dev/ttyS1 Update the tool to most recent version from Raw Hide: $ rpm -q redhat-config-mouse redhat-config-mouse-1.0.6-2 I start it, enter root password. It preselects "3 Button Mouse (serial)" which looks fine. I click "OK" without touching anything else. As explained earlier, it chooses the wrong serial device internally: $ cat /etc/sysconfig/mouse FULLNAME="Generic - 3 Button Mouse (serial)" MOUSETYPE="Microsoft" XEMU3="no" XMOUSETYPE="Microsoft" DEVICE=/dev/ttyS0 Therefore, next time I would reboot or restart X, my mouse wouldn't work any longer. I run redhat-config-mouse again, open the "Serial devices" dialog, change from ttyS0 to ttyS1 and leave with OK. That creates a good config file. Conclusion: Upon starting the tool, it should preselect the DEVICE= found in /etc/sysconfig/mouse and NOT change it unless it performs working h/w device detection or if the users tells it to use a different device.
Ok, should be fixed in redhat-config-mouse-1.0.11. Thanks for your report.