Foreword: Please allow me to rant a bit, as the results of my "investigations" for the past days have not been very inspiring, to say the least. This thread is both a rant and a plea for help, specially from people who are familiar with the Linux kernel.
Short Summary: It seems that the optical mouse that I am currently using right now will no longer work with kernel versions higher than 2.6.15-23. This incudes 2.6.16, 2.6.17, and even Ubuntu's own 2.6.15-25.
Background Story:
May 2006: SymphonyOS 2006-05 Beta was released. I was always curious about this little project so I decided to try it out, since it came in a Live CD. However, my mouse didn't work. Thinking that since this was a beta version, it might be due to some problems with the OS itself. I decided not to pursue the matter further.
June 2006: Dapper Drake was released. A few days after it's official release, a kernel update was made available in order to address some security issues with the default installed kernel. This update installs the 2.6.15-25 kernel. The upgrade was successful, but my mouse didn't work. I posted this problem several times, and even filed my first ever bug report. There were others who had problems with the upgrades as well, and I was hoping my problem would be similarly solved in a few days. I was not that fortunate. While almost everybody else's problems got solved little by little, mine began to gather dust.Defeated, I resigned myself to just use the 2.6.15-23 kernel for the meantime, hoping that a future kernel upgrade would be more promising.
July 2006: I began playing around with VMWare Server from the Ubuntu repositories. Out of a blue, I decided to give SymphonyOS one more try using VMWare. To my surprise, the mouse worked. Then, suddenly getting some inspiration from nowhere, I decided to type uname -r in the terminal. I then discovered that it was using the 2.6.16 kernel. I began to think that my mouse problems was, in some way, related to the kernel version that is being used by the distro. Prompted by this, I started looking for Live CD distros that were using the latest Linux kernels, in the hope of discovering whether this is really an Ubuntu only problem, a Debian only problem, or really a basic kernel problem. These were the distributions I tried and the kernel versions they were using:
The results of my "investigations": Only SimplyMEPIS 6 and Ubuntu using the 2.6.15-23 kernel was able to make my mouse work, confirming that it was indeed a kernel issue. I took a further step by testing these distros again, using a previous but currently-not-working-properly mouse (non-optical, still used the mouse ball, or whatever it's called). It was a mouse from a company called UniTek (serial number UM 1018, I think). And it worked. All of them worked. So based on these, I concluded that the latest versions of the kernel, and possibly (but hopefully not) future versions of the kernel cannot detect my current mouse. It fails in this aspect of hardware detection.
So this is a problem with the kernel, the very heart and soul of a GNU/Linux OS. Then my problem begins on how I could probably "solve" this.
Possible solutions:
1. Compile my own version of the kernel, again hoping that a customized kernel would solve the problem. But then, would that mean I would have to compile everytime there's a new kernel version that comes out or everytime a patch is released? I didn't pick Slackware for a reason...
2. Buy a new mouse. This optical mouse is a generic PS/2 mouse, which I was able to buy from a very respectable local dealer for just around US$ 3.00 (rough conversion for our local currency). The dealer is a respectable one, but it doesn't really specializes in computer hardware/peripherals. Branded mice, like those from Logictech or A4 or Genius cost 4 times as much as the one I'm using. For someone out of work, that's qutie a big cost. I was hoping to save some cash in order to upgrade my system's memory or buy a tablet (not a Tablet PC!), but of course a mouse takes priority. But my dilemma is this: even if I were to buy a new, branded, mouse, what assurance do I have that something like this would not happen in the future? I mean, I have a perfectly working mouse under the present and past versions of the kernel, and now there's a possibility that it will not/never work in future versions. How do I know that it won't happen again with another mouse?
3. Third option would just to switch to BSD... Or if worse comes to worst, even back to Windows...
This incident has left me very sad (to put it mildly), a bit disappointed, and confused. I was led to believe that Linux is supposed to be compatible with a large number of non-Windows specific devices. I also thought that newer kernel versions accomodated/supported more and more hardware and not actually remove already supported hardware.
Then again, this might be a bug, or might be a very, very personal bug, something that only I have the misfortune of experiencing, which makes my situation all the more depressing. If it's a bug that I and only I have experienced, then the possibility of it being fixed, just for me, would be nil. And I wouldn't really be able to know if it's a kernel bug unless I file a bug report, right? Which brings me to the problem of filing a bug report for the Linux kernel. In my 7 months of using Linux, I have filed only one bug report, and even that was a disaster, IMO. Filing a bug report on a very busy and professional place like the kernel might be a task that may be beyond me.
This is why my future is uncertain. I'm not sure how to proceed. I have big plans for my Linux experience, but now they're all put into a temporary hiatus because of this.
I'd appreciate any help, input, comments, criticism, whatever. This hasn't been a very good day for me...
P.S. I'm attaching dmesg outputs from the test runs I made (continued in a second post). There are two sets per distro, one with a working mouse using my old mouse, and one with a non-working mouse using my current mouse. The dmesg for Ubuntu with a working mouse is using kernel 2.6.15-23, while the one with no working mouse is 2.6.16-25. If anyone with the know-how in deciphering these cryptic lines could take the time to read some of them, I'd be truly, truly grateful.
Btw, it seems that a common line in all the dmesg with non-working mice is
Short Summary: It seems that the optical mouse that I am currently using right now will no longer work with kernel versions higher than 2.6.15-23. This incudes 2.6.16, 2.6.17, and even Ubuntu's own 2.6.15-25.
Background Story:
May 2006: SymphonyOS 2006-05 Beta was released. I was always curious about this little project so I decided to try it out, since it came in a Live CD. However, my mouse didn't work. Thinking that since this was a beta version, it might be due to some problems with the OS itself. I decided not to pursue the matter further.
June 2006: Dapper Drake was released. A few days after it's official release, a kernel update was made available in order to address some security issues with the default installed kernel. This update installs the 2.6.15-25 kernel. The upgrade was successful, but my mouse didn't work. I posted this problem several times, and even filed my first ever bug report. There were others who had problems with the upgrades as well, and I was hoping my problem would be similarly solved in a few days. I was not that fortunate. While almost everybody else's problems got solved little by little, mine began to gather dust.Defeated, I resigned myself to just use the 2.6.15-23 kernel for the meantime, hoping that a future kernel upgrade would be more promising.
July 2006: I began playing around with VMWare Server from the Ubuntu repositories. Out of a blue, I decided to give SymphonyOS one more try using VMWare. To my surprise, the mouse worked. Then, suddenly getting some inspiration from nowhere, I decided to type uname -r in the terminal. I then discovered that it was using the 2.6.16 kernel. I began to think that my mouse problems was, in some way, related to the kernel version that is being used by the distro. Prompted by this, I started looking for Live CD distros that were using the latest Linux kernels, in the hope of discovering whether this is really an Ubuntu only problem, a Debian only problem, or really a basic kernel problem. These were the distributions I tried and the kernel versions they were using:
Ubuntu 6.06 LTS (Debian-based) kernel 2.6.15-23 and 2.6.15-25
SymphonyOS (Debian-based) kernel 2.6.16
KNOPPIX 5.0.1 (Debian-based) kernel 2.6.17
SimplyMEPIS 6 beta 3 (Ubuntu-based) kernel 2.6.15-22
Berry Linux (Fedora Core-based) kernel 2.6.16
GoblinX mini (Slackware-based) kernel 2.6.16.12
SymphonyOS (Debian-based) kernel 2.6.16
KNOPPIX 5.0.1 (Debian-based) kernel 2.6.17
SimplyMEPIS 6 beta 3 (Ubuntu-based) kernel 2.6.15-22
Berry Linux (Fedora Core-based) kernel 2.6.16
GoblinX mini (Slackware-based) kernel 2.6.16.12
So this is a problem with the kernel, the very heart and soul of a GNU/Linux OS. Then my problem begins on how I could probably "solve" this.
Possible solutions:
1. Compile my own version of the kernel, again hoping that a customized kernel would solve the problem. But then, would that mean I would have to compile everytime there's a new kernel version that comes out or everytime a patch is released? I didn't pick Slackware for a reason...
2. Buy a new mouse. This optical mouse is a generic PS/2 mouse, which I was able to buy from a very respectable local dealer for just around US$ 3.00 (rough conversion for our local currency). The dealer is a respectable one, but it doesn't really specializes in computer hardware/peripherals. Branded mice, like those from Logictech or A4 or Genius cost 4 times as much as the one I'm using. For someone out of work, that's qutie a big cost. I was hoping to save some cash in order to upgrade my system's memory or buy a tablet (not a Tablet PC!), but of course a mouse takes priority. But my dilemma is this: even if I were to buy a new, branded, mouse, what assurance do I have that something like this would not happen in the future? I mean, I have a perfectly working mouse under the present and past versions of the kernel, and now there's a possibility that it will not/never work in future versions. How do I know that it won't happen again with another mouse?
3. Third option would just to switch to BSD... Or if worse comes to worst, even back to Windows...
This incident has left me very sad (to put it mildly), a bit disappointed, and confused. I was led to believe that Linux is supposed to be compatible with a large number of non-Windows specific devices. I also thought that newer kernel versions accomodated/supported more and more hardware and not actually remove already supported hardware.
Then again, this might be a bug, or might be a very, very personal bug, something that only I have the misfortune of experiencing, which makes my situation all the more depressing. If it's a bug that I and only I have experienced, then the possibility of it being fixed, just for me, would be nil. And I wouldn't really be able to know if it's a kernel bug unless I file a bug report, right? Which brings me to the problem of filing a bug report for the Linux kernel. In my 7 months of using Linux, I have filed only one bug report, and even that was a disaster, IMO. Filing a bug report on a very busy and professional place like the kernel might be a task that may be beyond me.
This is why my future is uncertain. I'm not sure how to proceed. I have big plans for my Linux experience, but now they're all put into a temporary hiatus because of this.
I'd appreciate any help, input, comments, criticism, whatever. This hasn't been a very good day for me...
P.S. I'm attaching dmesg outputs from the test runs I made (continued in a second post). There are two sets per distro, one with a working mouse using my old mouse, and one with a non-working mouse using my current mouse. The dmesg for Ubuntu with a working mouse is using kernel 2.6.15-23, while the one with no working mouse is 2.6.16-25. If anyone with the know-how in deciphering these cryptic lines could take the time to read some of them, I'd be truly, truly grateful.
Btw, it seems that a common line in all the dmesg with non-working mice is
psmouse.c: Failed to enable mouse on isa0060/serio1
Comment