Bug involving optical mouse

[ddavid123]

I am using R1 Alpha 3. When I move the mouse side to side very fast(cursor moves from one side of screen to other) the context menu pops up as if I had clicked the right mouse button. Also it appears that I am clicking the left mouse button because it appears I am trying to highlight part of the desktop. I am doing neither! When I move the mouse up and down very fast nothing happens.

This is not a serious bug in my opinion, just need to stop moving my mouse so fast!

[diver]

FWIW, I can reproduce it in VirtualBox.

[axeld]

I assume this is a PS/2 mouse? Because this is an intrinsic problem of the ISA bus, and happens whenever the mouse overwrites its packet data. I've seen this mostly on Windows so far, though, when the system didn't keep up with the interrupts fast enough.

Does the original problem appear in emulation or on real hardware?

And in general, ddavid123, it's always helpful to add information about your setup when filing a bug report. But thanks anyway!

[diver]

This is in VirtualBox with hrev42415.

When moving the mouse side to side very fast it freezes sometimes. When it happens this thread disappears: input_server->Extended Ps/2 Mouse 1 watcher
When it reappears 2 seconds later mouse is usable again. This is probably due to this lines:

KERN: ps2: hot plugin of input/mouse/ps2/intelli_0
KERN: ps2: device input/mouse/ps2/intelli_0 still active, republishing...
KERN: ps2: ps2_standard_mouse_disconnect input/mouse/ps2/intelli_0
KERN: Mouse device exiting, General system error
KERN: ps2: devfs_unpublish_device input/mouse/ps2/intelli_0, status = 0x00000000
KERN: ALPS not supported: 10 00 64
KERN: ps2: probe_mouse Extended PS/2 mouse found
KERN: ps2: devfs_publish_device input/mouse/ps2/intelli_0, status = 0x00000000

If I continue moving my mouse it either randomly clicks or scrolls wheel up. Or freeze.

[ddavid123]

Yes, my mouse is a PS/2 mouse. My system is a clean install of Haiku Alpha 3 with the SATdecorator enabled. I have enabled "show folder location in title tab", "Single window navigation", "List folders first", and "Enable type-ahead filtering" in Windows setting in Tracker preferences. I am running Haiku Alpha 3 on bare metal and in VirtualBox

[brunexgeek]

I have the same problem using the git commit ​https://github.com/haiku/haiku/commit/d3f77ddee320d0795e516d316b1fc7e0b85c905e.

While moving the cursor this message appears in the syslog

KERN: ps2: strange mouse data, x-delta 255, trying resync
KERN: ps2: strange mouse data, x/y overflow, trying resync
KERN: ps2: bad mouse data, trying resync

If I keep moving, the cursor freezes and the following messages appear

KERN: ps2: hot plugin of input/mouse/ps2/intelli_0
KERN: ps2: device input/mouse/ps2/intelli_0 still active, republishing...
KERN: ps2: ps2_standard_mouse_disconnect input/mouse/ps2/intelli_0
KERN: Mouse device exiting, General system error
KERN: ps2: devfs_unpublish_device input/mouse/ps2/intelli_0, status = 0x00000000
KERN: ALPS not supported: 10 00 64
KERN: ps2: probe_mouse Extended PS/2 mouse found
KERN: ps2: devfs_publish_device input/mouse/ps2/intelli_0, status = 0x00000000

Another symptom I noticed was that the CPU usage increases by about 25% while I move the cursor.

[brunexgeek]

Suggested "fix" for message "ps2: strange mouse data, x-delta ###, trying resync"

[brunexgeek]

I looked at the code (ps2_standard_mouse.cpp) and I noticed that the message about the "strange mouse data" appears because there is a logic that limits the maximum delta at 100. I made a small change that silently adjust every delta beyond the threshold.

[brunexgeek]

In the file ps2_dev.cpp there is the following code (function ps2_dev_handle_int)

if (data == 0x00 && dev->history[1].data == 0xaa
   && (dev->history[0].time - dev->history[1].time) < 50000) {

I think this is because of the mouse reset detection, but I don't understand why the mouse are reseting when I move the cursor fastly to any direction.

[mmadia]

Can anyone comment on this patch? It applies cleanly to master and compiles fine with x86-gcc2 and x86-gcc4

[korli]

I'm unsure the capping to 100 is really needed. Valid values seem to be between 255 and -256. This test was probably done because strange values would indicate we lost sync with the packet.

[marcusoverhagen]

The original code was a workaround to detect lost bytes (some problem with active multiplexing), and is probably misbehaving on large fast movements.

The patch however, looks broken.

[jscipione]

Patch which checks from -256 to 255 instead of -100 to 100. Verified that this fixes the problem on vbox on hrev47470

[jscipione]

Does the above patch appear to be a proper way to fix this bug?

[jscipione]

Patch applied in hrev50506

verified that it fixes the bug, no more messages to syslog and no more spurious right clicks in vmware

[marcusoverhagen]

The applied patch is stupid. The original code used a byte received from that mouse, then was sign extended it, and checked that the distance reported wasn't too big (range -100 to 100) to filter out invalid packets.

Now the check allows all possible values to pass the check. This is not useful.

[pulkomandy]

Removed the check completely in hrev50513. The PS/2 protocol does not limit the range of deltas the mouse can send, it seems this limit was introduced because the driver was somehow missing packets from the mouse and losing sync. I hope the situation in the Kernel has improved since the early days and this is not needed anymore (for the few people still using PS/2 mouses - even PS/2 touchpads use a different codepath). We can still detect the desynchronization by testing for the 4th bit of the first byte, which must be always 1.

[waddlesplash]

Should this ticket be closed then?

[jscipione]

The ticket should be closed, tested that there are no spurious right clicks in vmware. Unless somebody comes with a mouse that doesn't work right, I'm pretty sure we can do without this check.