mouse pointer does not move, when it shows up

[kaoutsis]

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

[diver]

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

[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 @@
      return;
   }
   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;

[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.

[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

[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.

[scottmc]

has this been applied yet? is it still needed?

[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.

[diver]

It would certainly improve first time impression.

[axeld]

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!

[diver]

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

[diver]

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

[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.

[diver]

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

[vidrep]

Is this still valid?

[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.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone