I've noticed that my mouse behaves funny just after booting.

This is what happens:

Immediately after booting and logging in to windomaker drags are not recognised as drags, instead they're recognised as the first click of a double click. A second attempt to drag the same window results in the window rolling up (which is the correct double click behaviour).

If I log into Gnome immediately after booting, drags work ok but normal clicks are not recognised properly. Some clicks seem to 'get lost'.

The funniest thing about all this is that it stops about 3 minutes after the initial boot and after that everything is fine.

I'm pretty sure it's not X related because if I boot to run level 3, wait 3 minutes and then do an init 5 (X) everything is fine. however booting to runlevel 1 and then going to run level 5 after 3 minutes does show the funny behaviour, which indicates it's not a hardware thing.

So it must be something loaded in runlevel 3 that causes the problems. I'm going to try to rule out various components in a one at a time manner. But maybe someone here can say: 'Aha! I know what that is'.

I'm running SuSE 7.3 with kernel 2.4.16, PS/2 mouse, nothing unusual.

Thanks for any suggestions

Con

Try removing gpm from bootup if it is started.

chkconfig --level 345 gpm off
service gpm stop

Regards,
Peter

>Try removing gpm from bootup if it is started.

I was pretty sure that the gpm wasn't the problem but I checked anyway.
gpm was only loaded in runlevels 2 and 3 so I removed that too (No gpm anywhere). but the problem remains.

I also tried not loading the sound and hot plugging subsystems (USB) and removed my sound card but that didn't help either.

Any other ideas.

Ok,
here's a long shot... (I use RH 7.2)
Get kudzu to re-detect the mouse.
This will mean removing the mouse config from "/etc/sysconfig/hwconf", and removing the "/dev/mouse" link, shutting down X & xdm, "init 3".
Run kudzu again and afterwards run mouseconfig.

Otherwise I suspect you will need to try a serial mouse or another PS/2 mouse, just to clear up that question.
Regards,
Peter.

You can also try changing the device in your X config to /dev/psaux instead of /dev/mouse (which is normally a sym link to psaux anyway).

I had actually stopped looking for a solution to this problem but then I discovered the cause by chance.

I used to use ISDN to access my ISP but recently I got DSL and I noticed that the problem disappeared.

Then I remembered that I used to use the ISDN feature to synchronize the system time. So I did a connect and disconnect via ISDN to set the system time and there was my mouse problem again!

My hardware clock was running a couple of minutes fast, and setting the system time to a couple of minutes ago obviously confuses the mouse click timing until the system time catches up with some stored time stamp.

I've known that setting back the time causes problems with version control systems but I'd actually call it a bug that setting the time affects mouse behaviour.

Now I just have to find out why the system doesn't set the hardware clock to the system time on shutdown. I get a message saying that it's setting the hardware clock (without error messages) but it doesn't seem to happen.

Thanks for all the suggestions.