Opened 14 years ago

Closed 21 months ago

Last modified 4 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/beta2
Component: Servers/input_server Version: R1/Development
Keywords: Cc: adek336@…
Blocked By: Blocking:
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 12 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 by diver, 14 years ago

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

comment:2 by axeld, 14 years ago

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

comment:3 by Adek336, 12 years ago

Cc: adek336@… added

comment:4 by Adek336, 12 years ago

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 by Adek336, 12 years ago

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.

by Adek336, 12 years ago

Attachment: mouse.1.diff added

comment:6 by Adek336, 12 years ago

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 by anevilyak, 12 years ago

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 by mmadia, 10 years ago

patch: 01

comment:9 by scottmc, 9 years ago

has this been applied yet? is it still needed?

comment:10 by axeld, 9 years ago

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 by diver, 9 years ago

It would certainly improve first time impression.

comment:12 by axeld, 9 years ago

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 by axeld, 9 years ago

patch: 10

comment:14 by diver, 9 years ago

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

comment:15 by diver, 9 years ago

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

comment:16 by axeld, 9 years ago

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 by diver, 5 years ago

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

comment:18 by vidrep, 2 years ago

Is this still valid?

comment:19 by cocobean, 2 years ago

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 by waddlesplash, 21 months ago

Resolution: fixed
Status: newclosed

comment:21 by nielx, 4 months ago

Milestone: R1R1/beta2

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

Note: See TracTickets for help on using tickets.