-->
Adventures & experiences in contemporary technology
Last week, I kept getting a multitude of messages from Ubuntu’s crash reporting tool, Apport. So many would appear at once on reaching the desktop session during system start-up that I actually downloaded an installation ISO disk image with the intention of performing a fresh installation to rid myself of the problem. In the end, it never came to that because another remedy produced the result that I needed.
Emptying /etc/crash was a start but it did not do what I needed and I disabled Apport altogether. This meant editing its configuration file, which is named apport and is found in /etc/default/. The following command should open it up in Gedit on supplying your password:
gksudo gedit /etc/default/apport
With the file opened, look for the line with enabled=1 and change this to enabled=0. Once that is done, restart Apport as follows:
sudo restart apport
This will need your account password to be supplied before it will act and any messages should appear thereafter. Of course, I would not have done this if there was a real system problem but my Ubuntu GNOME installation was and is working smoothly so it is the remedy that I needed. The idea behind the tool is that Ubuntu developers get information on any application crashes but I find that it directs me to the Ubuntu Launchpad bug reporting website and that requires a user name and password for the information to be processed. For some reason, that is enough to stall me and I wonder if there could be a way of getting developers what they need without adding that extra manual step. Then, more information gets supplied and we get a more stable operating system in return.
On popping Ubuntu 9.10 onto a newly built PC, I noticed that the button mappings weren’t as I had expected them to be. The button just below the wheel no longer acted like a right mouse button on a conventional mouse and it really was throwing me. The cause was found to be in a file name evoluent-verticalmouse3.fdi that is found either in /usr/share/hal/fdi/policy/20thirdparty/ or /etc/hal/fdi/policy/.
So, to get things back as I wanted, I changed the following line:
<merge key=”input.x11_options.ButtonMapping” type=”string”>1 2 2 4 5 6 7 3 8</merge>
to:
<merge key=”input.x11_options.ButtonMapping” type=”string”>1 2 3 4 5 6 7 3 8</merge>
If there is no sign of the file on your system, then create one named evoluent-verticalmouse3.fdi in /etc/hal/fdi/policy/ with the following content and you should be away. All that’s need to set things to rights is to disconnect the mouse and reconnect it again in both cases.
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<deviceinfo version=”0.2″>
<device>
<match key=”info.capabilities” contains=”input.mouse”>
<match key=”input.product” string=”Kingsis Peripherals Evoluent VerticalMouse 3″>
<merge key=”input.x11_driver” type=”string”>evdev</merge>
<merge key=”input.x11_options.Emulate3Buttons” type=”string”>no</merge>
<merge key=”input.x11_options.EmulateWheelButton” type=”string”>0</merge>
<merge key=”input.x11_options.ZAxisMapping” type=”string”>4 5</merge>
<merge key=”input.x11_options.ButtonMapping” type=”string”>1 2 3 4 5 6 7 3 8</merge>
</match>
</match>
</device>
</deviceinfo>
While I may not have appreciated the sudden change, it does show how you remap buttons on these mice and that can be no bad thing. Saying that, hardware settings can be personal things so it’s best not to go changing defaults based one person’s preferences. It just goes to show how valuable discussions like that on Launchpad about this matter can be. For one, I am glad to know what happened and how to make things the way that I want them to be though I realise that it may not suit everyone; that makes me reticent about asking for such things to be made the standard settings.