Opened 13 years ago

Closed 7 months ago

#917 closed bug (fixed)

mouse pointer does not move, when it shows up

Reported by: kaoutsis Owned by: korli
Priority: low Milestone: R1
Component: Servers/input_server Version: R1/Development
Keywords: Cc: adek336@…
Blocked By: Blocking:
Has a Patch: no Platform: x86


mouse pointer does not move, when it shows up. Of course, is working perfectly a few seconds later.

Attachments (1)

mouse.1.diff (2.8 KB) - added by Adek336 10 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 13 years ago by diver

Yes, this behavior is realy annoying and even repeats BeOS behavior. Would be realy nice if someone could fix this!

comment:2 Changed 13 years ago by axeld

Component: GeneralUser Interface/Input Server
Owner: changed from axeld to korli
Priority: normallow

comment:3 Changed 11 years ago by Adek336

Cc: adek336@… added

comment:4 Changed 10 years ago by Adek336

After running AddOnMonitor::AddOnMonitor, a message is sent every second. At one moment in time, mouse add-on initialisation is stalled up to the point when this message is received.

The patch below serves as an example: it increases the period to 10 secs, which causes the mouse to be immobilized for up to ~10 secs after boot.

On the other hand, decreasing the period to 100 msecs decreases the time the mouse doesn't move after boot a bit but it still lags for up to a second.

Index: src/kits/storage/AddOnMonitor.cpp
--- src/kits/storage/AddOnMonitor.cpp  (wersja 28658)
+++ src/kits/storage/AddOnMonitor.cpp  (kopia robocza)
@@ -22,7 +22,7 @@
   fPulseMessage = new BMessage(B_PULSE);
-  fPulseRunner = new BMessageRunner(messenger, fPulseMessage, 1000000);
+  fPulseRunner = new BMessageRunner(messenger, fPulseMessage, 10000000);
   status = fPulseRunner->InitCheck();
   if (status != B_OK) {
      fInitCheck = status;

comment:5 Changed 10 years ago by Adek336

The mouse pointer seems to be movable just right after resuming the fThread thread in MouseDevice::Start(), src/add-ons/input_server/devices/mouse/MouseInputDevice.cpp; delaying the resume also delays the moment when the mouse pointer is responsive.

Changed 10 years ago by Adek336

Attachment: mouse.1.diff added

comment:6 Changed 10 years ago by Adek336

The problem turned out to come from an unexpected place.
The patch mouse.1.diff reduces mouse initialization time from 2 secs to 1 sec after desktop initialization. The desktop also needs one second to become visible (hardware latencies) so the mouse and the desktop are available to the user at the same time.

The patch also points out three important places in the code- when a blank screen replaces the boot screen, when the blank screen is replaced with the desktop and when the mouse is finally usable.

The fix is to avoid snooze()ing in the ps2 bus manager, is this acceptable? Also could the snooze() during device_republish be removed?

time between blanking the screen and showing the desktop - 400 ms (note that it isn't visible for another 1 second because of hardware latencies)
time needed to initialize the mouse after showing the desktop - 1 second

comment:7 Changed 10 years ago by anevilyak

iirc the input_server is started by the app_server, which in turn loads the keyboard add-on. For PS/2 and USB at least, there are response timeouts required by spec, though I don't know their exact values, so the delay might relate to waiting for the device to become ready at that level. Marcus would know for sure with respect to PS/2 at least though.

comment:8 Changed 9 years ago by mmadia

Has a Patch: set

comment:9 Changed 8 years ago by scottmc

has this been applied yet? is it still needed?

comment:10 Changed 8 years ago by axeld

The problem still exists, it's just not a proper a fix; instead of reducing the pulse time, an initial message could be sent, though, although the add-on monitor should probably directly do an initial scan.

comment:11 Changed 8 years ago by diver

It would certainly improve first time impression.

comment:12 Changed 8 years ago by axeld

Version: R1/pre-alpha1R1/Development

Situation should be much better with hrev42198 and hrev42199, although the cursor can still not be moved immediately. This is roughly based on Adek336's patch/investigations, thanks!

comment:13 Changed 8 years ago by axeld

Has a Patch: unset

comment:14 Changed 8 years ago by diver

With hrev42199 in VirtualBox 4.0.8 cursor can't be moved for 2 seconds. Unfortunately almost nothing has changed here.

comment:15 Changed 8 years ago by diver

Same 2 seconds with "Enable absolute pointing device" option turned on, which uses tablet input_server add-on.

comment:16 Changed 8 years ago by axeld

It should be at least 3 seconds in hrev42197 then, but YMMV - I only tested in Qemu, and there it made a noticeable difference. But as I said, it's only an improvement, not a cure.

comment:17 Changed 4 years ago by diver

This seems to be fixed with the introduction of launch_daemon. Axel?

comment:18 Changed 12 months ago by vidrep

Is this still valid?

comment:19 Changed 11 months ago by cocobean

hrev52017 reviewed. Based on comments within this post, I think we can close this bug. Several users use the mice in Virtualbox and I use both PS/2 and USB mice with Haiku on physical hardware with no major issues now. If issue, it would be either on specialty mice (i.e. high-precision, etc.) - although that is another subject.

comment:20 Changed 7 months ago by waddlesplash

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