Asus A7N8X-X: USB mouse CPU drain...

[Luposian]

When I first switched from my Via chipset motherboard (which had horrible CPU usage; upwards of 50%, every time I moved the mouse) to the Asus A7N8X-X, I was amazed that my CPU usage was night non-existent, when moving the mouse. Nothing (even GLTeapot) showed any loss in speed, when moving the mouse.

This was about a year or so ago. I was not having this problem when I was having the audio issue with this system about 7 months ago (​http://dev.haiku-os.org/ticket/5414).

Now, I try out the latest builds, and this exact same system now shows about a 15-20% CPU usage when moving the mouse. It's a small increase, but GLTeapot slows down quite noticably as long as I'm moving the mouse.

I assume this is because, as Haiku progresses, older chipsets get left behind and are either no longer properly coded for or are otherwise ignored during improvement cycles.

If my assumption is incorrect, I'd appreciate clarification as to what is causing this. I no longer have a modern computer (this Athlon XP 2000+ system is it; had to sell QuadSlacker for family reasons and my Athlon 64 X2 system is being used at our church for audio work) and was hoping Haiku improvements would not result in older system "deprovements", performance-wise.

[luroh]

Just a thought, are you using the same mouse as a year ago?

[Luposian]

Replying to luroh:

Just a thought, are you using the same mouse as a year ago?

Yes. Same exact Logitech USB Trackman Marble. Dunno how even a different mouse would affect things, tho. Isn't a USB mouse a USB mouse, regardless if it's an actual mouse or trackball (which is, essentially, nothing more than an upside-down mouse)?

[stargatefan]

Try a ps2 mouse. See if that helps ? I have a pc with the same chipset and a similar motherboard. No problems but I use a ps2 mouse.

[mmlr]

Replying to Luposian:

Replying to luroh:

Just a thought, are you using the same mouse as a year ago?

Yes. Same exact Logitech USB Trackman Marble. Dunno how even a different mouse would affect things, tho. Isn't a USB mouse a USB mouse, regardless if it's an actual mouse or trackball (which is, essentially, nothing more than an upside-down mouse)?

It can be quite a big difference. Not every mouse has the same resolution for example, many vendors also simply do things a bit differently. How often a report to process is sent can also be quite different from model to model and vendor to vendor. So a USB mouse is far from a USB mouse. They use the same interface so that they can be supported by the same unified driver, but how they use the freedom the HID protocol allows for is entirely up to the implementor (if you generate 10 reports with 1px move at a time or if you generate a single report with a 10px move may generate the same effect on-screen, but the processing overhead is obviously different).

Overall the HID driver has been reworked a few times, I don't really remember the timeframe though. It's easily possible that the new framework is more resource hungry with that specific device you have. On the other hand the framework is far more flexible and able to support many more devices now, so...

To identify the issue at hand you could attach the hid reports that are dumped to /tmp so the polling frequency can be checked for example.

[Luposian]

I've noticed that if I use a 3rd party USB 2.0 card (Belkin, I believe), on my Pentium II system in Haiku, my CPU usage drops significantly whenever I move the mouse. In other words, if CPU usage is at 50% normally (using onboard USB), it drops to 25% or less, when plugged into the card. I assumed this meant that a certain onboard chipset (that handles USB) simply wasn't being properly supported, hence the CPU overhead.

Concerning a mouse/trackball updating (sending reports?), how could a device send 1 report after a 10px (pixels, right?) move of the mouse pointer? Wouldn't that look like a single jump of 10px onscreen? Shouldn't the device simply stream the movement data as the mouse is being moved?

If you could explain (in accurate, but simplified terms) how the Haiku HID driver and a given USB mouse/trackball communicate, that would help me understand things a bit better.

My thinking is that the HID driver simply asks "any data?" every few milliseconds or whatever. The device simply sends what data it had, but only when the mouse is moved or a button pressed/held, etc.

Is this how Haiku and a device does things or... ?

[Luposian]

Ok, I finally got around to testing out a different USB mouse. It's a USB Kensington ball mouse. When I plugged it in, after unplugging the Logitech Trackman Marble, I was shocked to see I went from using 25% CPU (Pulse shows 20 "bars", so 5 bars (which were lit green) = 25%), to less than 1% (Pulse showed nothing, but the little CPU indicator at the leaf menu/task bar was blipping a single little purple line).

But that wasn't what shocked me most. No, the BIG surprise came when I unplugged the Kensington and plugged the Logitech back in... it was showing the SAME amount of CPU usage... which was next to nothing!

So, as I understand it, this is simply a USB initialization thing... if you unplug the USB mouse/trackball and plug it back in, the CPU usage issue goes away! I will reboot and test this theory (with just the Logitech).

[Luposian]

Yup! Just rebooted and tried it. That is all you have to do... unplug the mouse/trackball and plug it back in and the CPU usage issue is gone! Now, just for extra information, I am using my Haiku CD (R38968) in Live CD mode. Anyone know if this issue is resolved in later Revisions of Haiku and/or if this is just a "bug" when using the CD in Live CD mode?

[Luposian]

With Haiku R40271, I noticed Live CD USB mouse performance has changed (only about 10% (two bars lit) CPU usage whenever the Logitech is moved, according to Pulse) and unplugging/replugging USB has no affect. Not sure if this would change on a HD install. However, this means that now there is higher actual, inalterable, CPU use when moving the Logitech vs. before (in R38968) when uplugging/replugging would drop this usage to a negligible amount (less than 5% (not even one bar was lit), according to Pulse).

[mmlr]

That the usage was inconsistent was caused by the uninitialized interval member. Therefore uninitialized memory was used leading to more or less random intervals being used (hence the inconsistency). This was fixed in hrev39904. Since then the advertised (by the device) interval is properly used. The 10% usage is then what results from using the interval suggested by the device vendor. So this one is fixed at hrev39904 as the behaviour now is the intended one.