Opened 8 years ago

Closed 2 years ago

#7802 closed bug (fixed)

Bug involving optical mouse

Reported by: ddavid123 Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Mouse/PS2 Version: R1/Development
Keywords: mouse, desktop Cc: jscipione
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

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!

Attachments (3)

syslog (188.1 KB) - added by diver 8 years ago.
ps2_standard_mouse.patch (1.4 KB) - added by brunexgeek 7 years ago.
Suggested "fix" for message "ps2: strange mouse data, x-delta ###, trying resync"
0001-PS-2-bus-manager-check-all-valid-values.patch (1.5 KB) - added by jscipione 5 years ago.
Patch which checks from -256 to 255 instead of -100 to 100. Verified that this fixes the problem on vbox on hrev47470

Download all attachments as: .zip

Change History (24)

comment:1 Changed 8 years ago by diver

FWIW, I can reproduce it in VirtualBox.

comment:2 Changed 8 years ago by 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!

Changed 8 years ago by diver

Attachment: syslog added

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by 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

Last edited 8 years ago by ddavid123 (previous) (diff)

comment:5 Changed 7 years ago by brunexgeek

I have the same problem using the git commit https://github.com/haiku/haiku/commit/d3f77ddee320d0795e516d316b1fc7e0b85c905e. This is in VirtualBox too.

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.

Last edited 7 years ago by brunexgeek (previous) (diff)

Changed 7 years ago by brunexgeek

Attachment: ps2_standard_mouse.patch added

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

comment:6 Changed 7 years ago by brunexgeek

Has a Patch: set

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by anevilyak

Component: User InterfaceDrivers/Mouse/PS2
Owner: changed from stippi to marcusoverhagen
Status: newassigned
Version: R1/alpha3R1/Development

comment:9 Changed 7 years ago by marcusoverhagen

Owner: changed from marcusoverhagen to nobody

comment:10 Changed 7 years ago by 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.

comment:11 Changed 6 years ago by mmadia

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

comment:12 Changed 6 years ago by 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.

comment:13 Changed 6 years ago by 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.

Changed 5 years ago by jscipione

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

comment:14 Changed 5 years ago by jscipione

Cc: jscipione added

comment:15 Changed 5 years ago by jscipione

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

comment:16 Changed 3 years ago by jscipione

Resolution: fixed
Status: assignedclosed

Patch applied in hrev50506

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

comment:17 Changed 3 years ago by marcusoverhagen

Resolution: fixed
Status: closedreopened

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.

comment:18 Changed 3 years ago by 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.

comment:19 Changed 2 years ago by waddlesplash

Should this ticket be closed then?

comment:20 Changed 2 years ago by 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.

comment:21 Changed 2 years ago by waddlesplash

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.