My fairly cheap mouse feels like it has little internal clicks as it is turned and, when coding events in Firefox and chrome browsers, each turn fires not only a different deltaY but a different number of events for a single wheel click. Different deltaY are easy to handle by using absolute value or simply the +/- sign, such that can get an event and set the magnitude in your code; but what controls the number of events that fire? Firefox fires about 8-10 times per wheel click.
In System Settings, the Scrolling Speed appears to change this for at least KDE applications, like Dolphin where I tried it, but not in the browsers.
Is the number of events that fire a function of my mouse or browser’s internal code/settings, or is there an OS setting that can be adjusted?
Also, switching from X11 to Wayland appears to have increased the number of events.
I’m not complaining but only trying to figure out how to make my application work for different users. It appears to depend on mouse, windowing system, and browser, such that all I can give is some generic number to input and apply to each event regardless of how many events may be fired. Such that the number could be 5 for one user and 50 for another to get the same visual scroll movement per wheel click.
I’m no expert but I have made a couple of (DIY) prototype USB mice, some time ago. They were barely more than a µc but they did work. However my memory of the details is vague.
Detents.
Some programmable mice can adjust scrolling speed, others will have a set value (probably 1, but it might vary depending on the mouse). The scrolling speed in the settings will presumably adjust how many events are seen, there may be other places but I can’t think of any atm.
It changes the scrolling rate in firefox for me.
If the number of events varies without changing anything then I would say it has to be a hardware issue.
Is your scroll wheel optical or resistive? Probably the latter if it’s cheap, if so it may be wearing out.
Have you tried cleaning it?
Have you tested with other mice?
Thank you for responding to my question. Perhaps it is a browser item that relates to my code or a problem with my code; for System Tools settings change the distance of scroll for each detent in other applications.
I’m not sure whether it is the number of events per detent or the distance per event. If it were the latter, adjusting would be easier.
With X11, chrome would send (I think) three times as many events per detent as Firefox.I was confused for awhile because I assumed one event per detent with a different deltaY per event by browser. Who would expect a detent to be more than one event? However, there is a button on my mouse that seems to remove the detent click and free rolls; so, maybe there are some signals between detents that trigger more events.
Regardless of how it all works, it appears that I need to provide a user setting the has no real label other than speed or distance or sensitivity, that can be modified to set the wheeling to some desired amount. For my code, the value is distance per event since the browsers’ deltaY are divided away but the real variable is how many events fire per mouse wheel movement, be it detents or some other hardware component that sends a signal. I cannot control that, even by throttling, because they occur so quickly. Well, I cannot really say that because I haven’t tried it. Perhaps, it could be throttled to count a new mouse wheel event no more frequently than every 50 ms or so. I throttle other events but the throttling is really how often the UI is updated and not how many events are counted. But all that is another matter separate from my specific question. Thanks again.
However, I just tried my application on another machine and one detent is one event. I don’t know–bad mouse or different mouse–but the settings are the same.
Have you tried using evtest, and/or wev (xev for X11) to see what’s being sent to the computer?
As does mine.
If you have a button to disengage the detent mechanism then it’s presumably an optical scroll wheel. You don’t normally get either on a cheap mouse, and from your description of the problem I’d assumed it was likely a non-optical encoder.
What mouse is it?
Have you opened it up to clean it? If it’s optical, you may have some dirt or hairs stuck in there.
As I said, it sounds like a hardware issue.
I’d test with other mice on the same machine, or preferably multiple machines, and clean or replace the mouse with the issue. At least you could rule out (or in) hardware failure/dirt.
Edit:
Just checked, you can get rotary encoders without detents but I haven’t seen a mouse with a detachable detent mechanism that didn’t use an optical encoder (though I haven’t really looked).
Thanks. I swapped mouses between some other machines and it is the mouse and/or the bluetooth (or whatever it’s called) piece that picks up the signal.
I can’t get it open to see if it needs cleaned–only one screw in the back which I took out but it feels that if I try to pry it apart I’ll break it.
The scrolling issue does not appear in any application other than my code and only with this mouse in my code. Thus, even if the mouse is sending more events than it should, I think it indicates that my code, working directly from the browser’s mouse wheel event, is too simple and I should try to throttle it. If Dolphin can handle my “bad” mouse sending a burst of events, so should my code.
It is a Logitech M705. If it isn’t a cheap one then it might have been a gift, because I’m pretty cheap with these things for myself. I’ve a Logitech M310 which cannot free roll apart from the detents and it works as expected, one event per detent. The bluetooth USB pieces will work only with the mouse they came with, such that I cannot test them by swapping the pairing.
Have you tried using evtest, and/or wev (xev for X11) to see what’s being sent to the computer?
There are probably more screws located under labels or plastic sliders. I’ve got a G502 and there are 5, all under plastic labels which the mouse slides on.
That’s odd.
Do you have “Hold down middle mouse and move mouse to scroll” enabled? If you do, could you be pressing the middle mouse button, or could it be wearing out and activating on it’s own (disable the option to test)?
You could use evtest to see how many events are being sent by the mouse, and compare that to what you see in your app. You could also compare what you get from other mice, to see if there’s something different that might explain it.
Not yet sure about the evtest itself but the browsers’ wheel events differ between the two mouse devices I mentioned above.
The M705 fires about 10 events per detent with a deltaY of 12.10000026… per event. The M310 fires one event with a deltaY of 132. That’s in Firefox; in Brave the events are as in FF but the deltaY are 11 and 120 respectively. Perhaps there are about 10 optical sensors between detents on the M705, such that the total deltaY for a detent is about the same between both devices.
I throttled the wheel events to two frame refreshes of a standard screen (2 of 60 refreshes per second). First, I accumulated the deltaY for the throttled events and applied them at the end of the ~33ms. That worked but I was unsure about how the deltaY may differ by browser. So, I throttled the events and applied a fixed deltaY. I’ll make the duration of throttling and the deltaY user settings that may be changed to adjust the movement.
It’s not all that important but if one part behaves poorly the reliability of the entire application is questioned; and I don’t blame anyone for that—I do the same.