Opened 15 years ago
Last modified 4 years ago
#4527 new enhancement
mouse doesn't seem to accelerate much even at maximum setting
Reported by: | Kev | Owned by: | korli |
---|---|---|---|
Priority: | normal | Milestone: | R1.1 |
Component: | Servers/input_server | Version: | R1/alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
I dual-boot BeOS and Haiku now, and I can't seem to figure out how to get the mouse to feel the same in both places.
In BeOS, I have the mouse speed set at the second tick from "slow", and acceleration just beyond one tick from "fast". This allows single-pixel precision if I move the mouse slowly, as well as hitting any corner of the screen by moving at a medium to medium fast pace.
In Haiku I put the speed to the fastest one that still allows single-pixel movements (I think it's somewhere in the middle) and max out the acceleration, and still the acceleration is too slow, so in order to not be snapping my wrist a lot I have to put the speed faster than single-pixel, which is annoying when you're doing something like selecting text with the mouse on a web page that uses a font where the letter I is one pixel wide.
Is there some way to make it behave exactly like R5?
Change History (19)
comment:1 by , 15 years ago
Summary: | mouse doesn't feel like BeOS → mouse doesn't seem to accelerate much even at maximum setting |
---|
comment:2 by , 15 years ago
It seems to depend on the mouse. If I connect my usb mouse, the settings that are comfortable with the notebook's touchpad are totally off for the mouse: it's accelerating like mad! I almost can't navigate to the Mouse prefs to turn it down a little.
comment:3 by , 15 years ago
Good point. But...well...BeOS on the same machine with the same mouse works well, so there must be a way. How does your notebook/mouse setup fare under R5?
follow-up: 5 comment:4 by , 15 years ago
I doubt it would boot... :)
And I don't doubt what you're seeing with your setup. I just wanted to point out that it's not a general Haiku shortcoming. IIRC, stippi also mentioned somewhere that in the future it may be possible that different input hardware could use their own settings. That would be nice, meaning one could switch between touchpad and mouse without having to change settings.
comment:5 by , 15 years ago
Replying to humdinger:
I doubt it would boot... :)
And I don't doubt what you're seeing with your setup. I just wanted to point out that it's not a general Haiku shortcoming. IIRC, stippi also mentioned somewhere that in the future it may be possible that different input hardware could use their own settings. That would be nice, meaning one could switch between touchpad and mouse without having to change settings.
Oh...right. :)
But I disagree, how is it not a general shortcoming? There exists no option currently that makes it behave well. Wouldn't a higher maximum solve that? (The default could be lower, perhaps, and that would help situations like yours...but these two things aren't mutually exclusive.)
comment:6 by , 15 years ago
But I disagree, how is it not a general shortcoming?
I meant, this is something not everyone is affected by. Of course I agree that the situation should be corrected somehow. I rely on our formidable coders to come up with something. :)
comment:8 by , 15 years ago
Oddly, the acceleration seems to work much better (although I'd say still not quite fast enough) while dragging an icon (but not while dragging nothing, to create a selection box) on the desktop. Should I maybe file that as a separate bug? I don't think the mouse rate should change at all just because you're dragging something.
comment:9 by , 15 years ago
That feeling must be rooted in your own perception; the mouse acceleration code is completely independent from any action. Another thought: have you checked if CPU load improves mouse acceleration as well? :-)
comment:10 by , 15 years ago
Certainly is a good trick on myself, then...it seems really noticeable to me. I thought maybe it was because in one case I was pressing on the button, so I might be using more force on the mouse, but again, there's a difference between dragging a selection box and dragging an icon.
comment:11 by , 15 years ago
I guess you're right, the CPU meter does go sky-high during dragging, it must be purely lag, then.
follow-up: 14 comment:12 by , 12 years ago
Perception is important, but it's also a bit of a usability issue. Granted my system is a bit old, it's a Sempron 3100+ with 512 MB, but it's actually quite difficult to do what I normally do when it comes to the web browser: I don't like it in fullscreen mode necessarily because I still use the titlebar to send the window to the back via right-click, but I do like it to take up as much of the screen as possible. The maximize button doesn't do it for me, because the scrollbar is then a few pixels away from the edge, so I can't scroll without looking directly at the scrollbar, which I find an annoying diversion while in the middle of reading a sentence. So I normally do this: hit maximize, drag the window to (-7,-7) or so using the title bar, then drag the resizer in the lower-right corner from as high and left as I can down as far right and as low as I can. The second part is easy. The first part is very difficult because precise movements while dragging are much less smooth in Haiku than BeOS still, on the same system.
comment:14 by , 12 years ago
Replying to Kev:
The maximize button doesn't do it for me, because the scrollbar is then a few pixels away from the edge, so I can't scroll without looking directly at the scrollbar, which I find an annoying diversion while in the middle of reading a sentence.
This is getting a bit off-topic, but Stephan has complained about the above on other systems and I think Haiku should avoid this too. The default "maximize" algorithm should maybe take the size of the window border into account and at least move the right border off the screen so that we can benefit from Fitt's Law for the scrollbar. It might even be nice just to move all the borders outside the screen with the exception of the top border and the tab, to maximize the space for the actual web pages. If this doesn't make sense in general it could at least be done in WebPositive.
If this sounds good, I can create an enhancement for Web+ and implement it at some point.
comment:15 by , 12 years ago
I think it makes sense in any app that has a vertical scroll bar, and the close button makes sense in any app that you'd want to maximize. E.g. Windows (up to 7, anyway) when maximized you can throw the cursor up to the upper-right and click (except apps like Chrome that try to look extra fancy but break this, instead.) But that would mean changing the graphics a bit in the corner, which I have to admit doesn't look as nice nor would be consistent with the other corner.
Either way, this acceleration lag happens in less-intensive apps like StyledEdit as well, and presents the same difficulty there. What did BeOS do more efficiently to make this happen?
comment:16 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|
comment:18 by , 7 years ago
I think the problem with mouse acceleration is that we don't take input resolution (DPI/CPI) into account, and so if the USB HID has some ridiculous DPI outside of the norm, then it will either appear ridiculously fast or ridiculously slow. PulkoMandy has mentioned similar issues with some of his mice...
comment:19 by , 4 years ago
Milestone: | R1 → R1.1 |
---|
Or even if not exactly, just increase the maximum acceleration by a factor of two or three. If I move the mouse slowly or quickly it almost doesn't seem to make a difference.
BTW it's a USB mouse.