An uncertain future awaits me in Linux...

[Jucato]

It's a bloody mouse! US$10. 5 pounds.

Let me see. If I were to use the figures I gave, a US$10 mouse would, what, take me 5 weeks to save up for? Not to mention the traveling expenses? Luckily I have a bit more money saved up. But just around US$ 15. You have to understand. I'm unemployed, living at home and taking care of my grandma, with very limited means of going out and buying a mouse from the nearest computer store.

If you want to maintain compatibility for every old, cheap, piece of hardware, be my guest. In the real world, no OS does that. Not Windows, not Mac, not Linux, not anything.

old - yes we should slowly start removing support for "legacy" hardware, regardless of the fact that Linux once prided itself on it's ability to run on these kinds of hardware.
cheap - of course. cheap stuff are low quality stuff. Anything you can get for a bargain price is bound to be defective in some way. How much did I pay again to get Ubuntu?

Btw, my mouse, like I said earlier, is not old. It is cheap, though. And therein probably lies the root of all my problems.

[Miguel]

OK, Fenyx.

• You have a mouse that doesn't work under certain controlable and replicable situations.
• You know exactly the make and model of your mouse
• Your issues can be traced back to the kernel
• You have dmesg outputs from different kernels and different distros.

This, for me, equates a great bug report. Send it. What's more, if you have bugzilla accounts in the other distro's (unlikely) also fill the bug report there. It doesn't get much better than what you did. IMHO, if your mouse doesn't need drivers in windows, if it uses a standard protocol on a standard PS2 connection, it should work. Today and tomorrow. Period. Come on, there is still pre-EISA hardware support on the kernel.

BTW: good luck with your grandma

[Jucato]

Thanks for the tips. I already filed a bug report in Launchpad/Malone last month when my mouse started behaving like that. After some time, however, an Ubuntu dev came by and commented that it was, in fact, an xorg bug and transferred it from "Affects: kernel" to "Affects: xorg". I just posted yesterday the additional details that I posted in this thread. I'm hoping that some Ubuntu dev would notice it again.

That was my first ever bug report in my whole life. And it, IMHO, was a disaster. I probably didn't get the words right, or didn't immediately include the needed information, or didn't even know what logs/files were needed to be attached. Let's just say that I developed a sort of bug-filing trauma. But I'm willing to learn how to file bug reports properly.

Here's the bug report I made: https://launchpad.net/distros/ubuntu...g/49996/+index

In the mean time, a new kernel update is available. I'm going to sit this one out for a while... I'd rather have a stable system, than a perfectly secure but unusable system.

[bruce89]

My mouse went haywire (had to double click all the time, and sometimes double clicked when I single clicked), so I replaced it temporarily with another one, which seems fine.

[Miguel]

After some time, however, an Ubuntu dev came by and commented that it was, in fact, an xorg bug and transferred it from "Affects: kernel" to "Affects: xorg".

Thanks again for posting your bug. This helps us all. It might be that your bug is simply a regression in Xorg. You can check this in your "beloved" logs (more info later )

That was my first ever bug report in my whole life. And it, IMHO, was a disaster. I probably didn't get the words right, or didn't immediately include the needed information, or didn't even know what logs/files were needed to be attached. Let's just say that I developed a sort of bug-filing trauma. But I'm willing to learn how to file bug reports properly.

LOL, it gets better with practice. Just don't worry, not everybody knows how to recover crashes and errors. If they need specific info from you, don't be shy to ask the commands. My first bug report was for a flight sim (Falcon 4.0) and went something like "fighters further than 30nm don't appear in your radar screen".

In the mean time, a new kernel update is available. I'm going to sit this one out for a while... I'd rather have a stable system, than a perfectly secure but unusable system.

This one will make a new entry in grub, if you wondered, so you should be more or less safe testing it. Anyway, I would trust the developer about x.org.

X.org errors and warnings

Errors are usually (i.e. always) marked with EE in the corresponding line. Similarly, warnings use WW. So instead of looking through the whole log looking for errors and warnings, you can directly filter these lines. X.org's log file is /var/log/Xorg.0.log (note zero, not o).

grep EE /var/log/Xorg.0.log
grep WW /var/log/Xorg.0.log

will only show lines containing EE or WW respectively. Everybody loves grep. It only shows lines containing a certain string of a long long file. You could try these commands in your non working distros. They might be of help.

For the kernel messages you can look at either /var/log/messages (this one is longer than a day without bread, as we say in Spain) or dmesg. It's certainly better to use dmesg, but for that you need to use what's known as a pipeline:

dmesg | grep EE
dmesg | grep "the word you want to filter"

The "|" symbol is called a pipe. It is a way to give the next program data from the previous program. So you run "grep EE" on the output of dmesg, intead of a file.

[DoctorMO]

Thats just not true at all

a pipe is a way to give the next program data from the previous program: from stdout to stdin (standard out, standard in), it doesn't use files nor paramiters.

[Miguel]

Thats just not true at all

OK, thanks for reading all that and noting my mistake. It's edited now. Is it alright now? I don't want to put those things wrong because I don't want to mislead others and because I also learn from these things.

[Jucato]

@Miguel thank you for your detailed instructions. I might try that out after I install/upgrade the new kernel. The reason I'm quite hesitant to immediately test the new kernel upgrade is because the batch of upgrades also includes upgrading linux-restricted-modules-common and nvidia-glx. If both kernel and nvidia fails to work, then I'm done for...

Btw, when should I grep the Xorg logs? After installing the new kernel or after something else?

Also, my dmesg logs don't have EE's and WW's...

[kop316]

My mouse went haywire (had to double click all the time, and sometimes double clicked when I single clicked), so I replaced it temporarily with another one, which seems fine.

Mine did that too, but there has been an update that has fixed that.

[Miguel]

Also, my dmesg logs don't have EE's and WW's...

I've noticed that too...

Btw, when should I grep the Xorg logs?

I would boot in a perfectly working kernel and then copy /var/log/Xorg.0.log to somewhere in my directory and mark it as working or whatever you prefer. Then, I would boot in a non-working kernel (if you have it installed) and then and get the new /var/log/Xorg.0.log. You gan grep WW or EE in this new log. If it isn't much of a hassle, you could submit those.

Anyway, don't bother too much. It is not nice to break your system intentionally (especially when the way you know to fix it is a reinstall) just for an error log. Although there could be interesting info in a live CD.

Maybe you are interested in looking at the differences yourself. OK. Open a terminal and maximize it (you will need the extra space). Then type

vimdiff file1 file2

You will then see half screen showing each document. If there are many lines equal, they are skipped. Lines that are different are marked purple (awful colour), and the specific different part is marked in red. To exit this program (no, I'm not joking) you must press :q (enter) and :q (enter) again.

The curious thing is that in your bug report, the only WW that appears is related to cyrilic fonts, and has nothing to do with the mouse.