I know this is a common problem with several threads in various forums, but none of the advice offered seems to address my issue with this specific mouse.

I recently installed Slackware-current with the 2.6.16.18 kernel and xorg 6.9. The scroll wheel and the left/right buttons work fine as expected. No other buttons do. Using xev, I noticed the side buttons, used primarily for back and forward in a web browser, are recognized as button two. Depressing the scroll wheel, which is technically button 2, also detects as button 2.

I've tried these configurations in xorg.conf

I've also tweaked the above in various ways with no effect. I've used the xmodmap command that worked perfectly with xorg 6.8 both with these options and with others, eliminating the ButtonMapping option, altering ZAxisMapping and Buttons to the configuration that worked with 6.8 (buttons "9" and mapping "6 7"). I've also used this with no xmodmap command.

Reading the forums I decided I needed to use evdev as the driver, per advice I found both here and in a wiki somewhere. My xorg.conf looked like this:

Device "event1" was correct for this mouse, per testing done with cat /proc/event[1-9]. That is, when I issue the command cat /proc/event1 I got random characters on the screen when I moved the mouse. The evdev module is present and loaded via modprobe.

This is the truly weird part I haven't seen mentioned elsewhere. When using this configuration and issuing the startx command, the screen goes black, my monitor reports a lost signal, and the system freezes, meaning I have to hit RESET and reboot. This is the first thing I've ever done while configuring a Linux installation that caused something that drastic.

I'm two shakes away from reinstalling 10.2 and using xorg 6.8, but I'd much prefer to get this figured out if it is possible. Apparently some with this mouse are getting it to work, but following the paths I've found so far isn't working here. Any suggestions at all would be appreciated.

If it matters:

ASUS A7N8X-X mobo, AMD 2800+
1 Gig Corsair XMS memory
ATI AIW 9600XT (and the amazing thing is I got the 3d accel. working first try)
Logitech MX510 PS/2 Mouse
Logitech keyboard, generic variety

In case anyone cares ...

This doesn't appear to be a problem with Xorg 6.9 specifically, nor with the 2.6.16.x kernel.

I did a fresh install of Slackware 10.2 on a separate partition with the 2.6.13 kernel, which is what I was using before, and Xorg 6.8.2, also what I was using before. (I've been using the SuSE 10.1 distro, FWIW.) The problems were exactly the same. I also spent the time to install the 2.4.x kernel. Same issue, exactly.

The key to this seems to be that both side buttons and the middle button (depressing the scroll wheel acts as a button) are being detected as button 2. Scroll up/down are detected as buttons 6 and 7. Left click is button 1. Right click is button 3.

On my SuSE installation, the side buttons detect as 6 and 7, scroll up and down as 4 and 5. That is, all are detected as separate buttons.

Something seems to be missing that allows the buttons to be detected as their own individual buttons, but I am at a complete loss as to what it is. Any suggestions, even guesses, might be helpful and would be extremely appreciated.

I suspect the problem lies with uinput. Because the size of one of the structs for uinput changed between 2.4.x and 2.6.x kernels, devices that require uinput support so aren't likely to function properly with a binary built against 2.4.x when a 2.6.x kernel is being used.

Further experiments lead me to suspect you're correct.

My previous comments were worded somewhat incorrectly. The issue does not seem to be with the 2.6.16.18 kernel specifically, rather the 2.6.x series. Regarding the problem presenting itself "exactly" the same in the 2.4.x kernels, that was incorrect. Trying to use "evdev" causes the same problem as using evdev with 2.6.x.

However, after messing around with things for a bit with a 2.4.x kernel, I was able to use the traditional method of mapping the buttons with ZaxisMapping and an Xmodmap command to make it work as desired.

SuSE uses the 2.6.13.x kernel, and the Xmodmap method works there. I am assuming, then, that SuSE has patched the 2.6.x kernel so that this is not an issue. I ran across a less than detailed reference to a patch needed for the 2.6.x series for a similar mouse in a Debian forum, but the link to this patch was no longer valid, and no details were given as to what it contained.

Further, what I don't understand is that judging from several threads on this issue in this very forum, some people with the 2.6.x kernel are having success getting it to work. I'm also still clueless as to why using evdev crashes the system completely.

I suppose I'll stay with the 2.4.x kernel for now and press on because I have become quite addicted to using back/forward buttons.

Thanks for the input.

Never messed with the buttons, but I build boxen and always recompile the latest stable 2.6 kernel for them.

Have you tried using the .config file from the 2.6.13.x kernel that works, and compiling a 2.6.16.20 (or whatever you desire) with that .config file for Slackware? Just a thought, and easy to do. Won't take you but about 20 minutes total.

That's an interesting idea ... hadn't thought of that.

When I take up this project again tomorrow, I'll give that a try. Thanks.

The good news is that with the 2.4.x kernel and Xorg 6.9, my mouse is now working flawlessly and with better precision than I had it working under SuSE. I had to tweak the Xorg settings a bit, but just a bit.

However, the generic 2.6.x kernel series appears to be off-limits to me at this point if I want my mouse to function properly. I have looked in vein for a specific patch that might address this, and I am not knowledgeable enough to attempt such a thing myself. I have considered dropping the SuSE kernel in, then recompiling it, but I'm not sure if I'm that brave yet.

More interesting to me at this point is why using evdev as the driver causes my system to crash completely. I guessed initially it might be a conflict with the ATI drivers, since the first indication of the crash is a lost video signal. However, I tried using evdev without installing the ATI drivers and had the same issue. I also cannot find a reference to anyone else experiencing the same problem, which leads me to believe I am doing something incredibly stupid while trying to make this work. My hardware isn't exotic at all, so I doubt that's the problem, but I suppose it could be.

Anyway ... just thought I'd update it in case this might help anyone else following the same path.

You should use the SuSE kernel .config file, and new sources from Kernel.org.

These simple instructions can be followed for a quick recompile with Slackware. You should change the kernel version to match the sources you download. As of this post, 2.6.16.20 is the current stable 2.6 Linux kernel.

This will give you the choice between your present 2.4 kernel, and a 2.6 kernel with the same options you have in SuSE.

NB: SuSE does patch their kernels -- heavily. If you use Kernel.org sources and it still won't work, I'd email the Linux kernel mailing list and report it as a bug. There are many SuSE employees who are kernel maintainer/developers, and they should know what they've hacked in the SuSE kernel that's not in Kernel.org sources; if that be the case.

I have Xorg 6.8.2, kernel 2.6.10 and 10-button mouse. Everything is working fine via evdev. In my xorg.conf there are also thes lines: I suugest you to look for these settings in /proc/bus/input/devices and put them for your mouse in xorg.conf. And evdev doesn't work for me on 2.4

I should have mentioned orignally that the mouse I'm using is not a USB mouse, which may be part of the problem with using evdev.

Thanks for the suggestion.

I did this tonight, but I encountered a few other obstacles along the way that prevent me from being able to say whether it worked or not. The .config for SuSE's kernel compiles support for the ext3 file system as a module, which I only discovered after compiling it. I had no initrd in place to load it, so it failed to boot. By the time I eventually figured all this out, it was getting late, so I thought I'd just report back here on the lack of progress on my part due to my ignorance.

I learned quite a bit in the process of doing all this, though, so it wasn't a wasted effort. I'll report back once I've had time to do this properly.

Thanks again.

Oh, yes! evdev didn't work when I used PS/2. So no way but to use USB.