I have two wireless mice. One is a really good mouse that served me for years until it got too beat up, and now the scroll wheel doesn’t work very well. The other is a newer HP mouse (specifically HP 280 Silent Wireless Mouse, product number 19u64AA) that is a bloody piece of shit and I hate it.
The HP mouse currently has two main issues with it. 1, it doesn’t “sleep” or turn itself off after a period of inactivity. It just stays on, even if the usb dongle is disconnected, until the battery just dies on it. 2, it’s clicking software/firmware had a fucking stroke or some shit. It only clicks on the active screen; so for example, if I have Firefox open and fullscreen, it will not click on the task bar on the bottom of my screen at all. It won’t even register that it’s hovering over something down there, it just refuses. That, and the middle click won’t work. It’s genuinely annoying, because the mouse used to work with no issues. I have no idea what caused this, and my conspiracy theory is that HP just kills mice that are alive for too long, because this is fucking horse shit. I do not recommend this fucking mouse at all for this.
What’s funny is, I tried both my previous mouse (the one with the broken scroll wheel), and my desktop’s wired mouse, and both worked excellently. No issues at all, unable to replicate the issues experienced by my HP mouse. Crawling through the journalctl logs don’t show anything wrong with any of the mice, at least not that my noob ass could tell, and the HP support page for the 280 doesn’t have a fucking user manual for it. There just doesn’t seem to be one at all, not one I can find at least.
Anyways, /rant. How can I see what’s wrong with the 280, or fix what might be wrong with it (or factory reset the mouse, if that’s a thing)? Alternatively, how can I fix my other mouse’s scroll wheel (Victsing Wireless Mouse model PC106A my beloved)?
Edit: Forgot to mention, on Linux mint 22.1 cinnamon, on an HP laptop oddly enough (you would think HP accessories would work with HP products). if you need any information, journalctl, inxi, my fucking social security number, whatever, lmk.
Edit edit (workaround found): So I reset my laptop, with the mouse still plugged in. Upon reboot, the functionality was still broken, and so was the touch pad. So I took a look at xinput list to see what was going on; my thought process was, maybe there’s some interference between the mouse and touch pad. I went through, disabling things one by one to see what it did; a number of the things listed didn’t seem to affect anything, but i found my mouse was 8 and my touchpad was 13. When I re-enabled my touch pad, suddenly everything was working as expected. I don’t know why. I tried restarting my pc again; same issue, but this time i tried disabling and reenabling my mouse, and then suddenly functionality was restored. In both cases, the order in which xinput displayed things was changed, but they were changed differently both times; I don’t know if there’s a load order that’s reflected in xinput or if it just reads things off as it finds them. Either way, for whatever reason, functionality with the mouse and touchpad have some interference when the mouse is first introduced. Though, the touchpad settings in the system settings doesn’t seem to have any effect when the 280 mouse is plugged in; its set to be disabled if there’s a mouse, which doesn’t happen. I don’t know what’s causing these issues; disabling and enabling through the terminal seems to be the only workaround. There are other devices on my xinput list, I couldn’t tell what each of them did, but disabling/reenabling them doesn’t seem to have any effect.
Here’s the output of my xinput list if anyone is curious about what I have going on:
$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ GTCH7503:00 2A94:D009 id=11 [slave pointer (2)]
⎜ ↳ SYNA32D8:00 06CB:CEE7 Touchpad id=13 [slave pointer (2)]
⎜ ↳ SYNA32D8:00 06CB:CEE7 Mouse id=12 [slave pointer (2)]
⎜ ↳ HP 285M HP 280/285 Wireless Mouse Consumer Control id=9 [slave pointer (2)]
⎜ ↳ HP 285M HP 280/285 Wireless Mouse id=8 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Video Bus id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=14 [slave keyboard (3)]
↳ Wireless hotkeys id=15 [slave keyboard (3)]
↳ HP WMI hotkeys id=16 [slave keyboard (3)]
↳ HP 285M HP 280/285 Wireless Mouse Consumer Control id=10 [slave keyboard (3)]
↳ HP 285M HP 280/285 Wireless Mouse System Control id=17 [slave keyboard (3)]```my conspiracy theory is that HP just kills mice that are alive for too long
HP is that kind of company.
My right-out-of-warranty Logitech M590 mouse lost its pairing to its USB-receiver upon booting up Windows after using the mouse in Linux for weeks out-of-warranty. I bought another one, and that too did the same the first time I booted up Windows after the warranty had expired.
Finally I searched the issue, and it’s normal. I had to install a non-default Logitech software in Windows and re-pair the apparently broken mice to their receivers. Both mice work again, except the older one’s left button is acting up a bit.
A non-asshole company would have notified me “Your mouse receiver needs an update that requires re-pairing the connection manually. Do you want to continue the update?”. And why the hell would a mouse receiver need an update when the warranty ends?
Obviously the purpose is to make the mouse appear broken with plausible deniability and bluff the customer into buying a new mouse.
probably a mostly hardware issue
The scroll wheel is an optical device. There are holes in the wheel just under the surface. The holes are very thin slots oriented almost like spokes. Then there are two pairs of infrared diodes and photo receivers. These are precision offset so that only one IR diode is shining through the slot at any given time. With this setup the direction of rotation can be determined based upon which slot goes high to low relative to the other. It can be difficult to wrap your head around how this works at first, but most rotary encoders, like sound knobs that can spin infinitely, work on this principal. If stuff like lint and dust blocks these slots or the light from the diodes gets around the wheel somehow it creates problems. The microcontroller needs sharp digital edges for this to work well.
Other than dirt and grime, mechanical buttons fail. Corrosion is common from skin moisture and stuff.
The actual chips used are extremely integrated for the camera used for the mouse movement, buttons, and scroll wheel.
In all consumer garbage, the cheap electrolytic capacitors are suspect. If one of these fail, it will cause intermittent problems. These capacitors are like mini reserves or energy buckets. When there is a big sharp current draw that causes the voltage to dip, the caps are there to smooth out that dip and provide a small reserve capacity near the likely source. Electrolytic caps have a fluid inside that, when dried out makes them stop working and act more like a resistor in most cases. When a cap has high equivalent series resistance, the respective voltage rail may go low and cause very unpredictable behaviors. Only some parts of the circuit may start to fail at these brownout voltages and then immediately resume or any number of other behaviors.
Likewise, a lithium battery may start to have issues with providing enough current and fail in a similar way causing brownout issues.
The big current draw in this instance will be the radio. All radio transmitters, even in little wireless devices like a mouse, use a ton of power in extremely short bursts. This is hard on circuit components. The efficiency is due to sending very short pulses less often, but the power required is always high.
It is likely that, if it has a lithium battery, this has gone bad from charge cycling. Charging a lithium battery requires at least two of three charging phases. If a cell is dead, a very slow trickle charge is required. The two standard phases are a constant voltage and then a constant current phase to safely charge lithium batteries. These phases require some simple feedback. If the cell is charged in the constant voltage phase, but it fails to reach the required voltage for the constant current phase, this may prevent a simple charge controller from completing the charge cycle. Most consumer junk with a lithium battery is going to have a very simple batman charge controller setup. It is likely/that the batman is not connected to any logic or digital feedback mechanism that evil HP controls. They are principally cheap bastards so overly optimizing profit over functionality is likely, like Boeing flying the doors off level corporate suite stupidity.
Along those lines, if not lithium, circuit noise would also be suspect, likely from degradation from grime and corrosion. There are often two PCBs in a mouse with some kind of connector between them. This often will be your failure point from moisture as the galvanic potential is high between the different metals in contact and mechanical stresses.
Could you explain the batman part I tried a search engine but was not illuminated
Slang for battery manager/-ment
aha! thanks :) I liked your comment a lot thank you.
update: definitely software related. unsure of cause. see edits in op.
You’re getting past my experience and into stuff I am half aware of on the periphery. I think you likely have an issue in the boot loader stuff. Like the bootloader initiates all the hardware onto handles that Linux then takes control over. IIRC Linux doesn’t implicitly trust any of this, but instead goes through it discovering what exists and where. Most touch pads on laptops are just an internal USB device, but not all. Some are actual hardware implementations. I had an old work Apple laptop that had a 40-odd-pin ribbon cable connection once – crazy.
It may be a situation where the touch pad is some oddball unique implementation or some hacked workaround specific to your machine. Check for scans of the same on linux-hardware.org and be sure to do a scan of yours too for anyone else. See if anyone has left notes or used other specific kernels. If some odd-ball thing works, it is probably in their scan. Do a GitHub search for the model. Sometimes that turns up something useful. Arch documentation is another. Gentoo has the documentation for all the low level stuff, how it works, and how to implement it in advanced tutorial form. Base Debian is the hardware hackers space. At this level of kernel configuration stuff, all distros are basically the same.
I have a less intrusive but similar issue with a RGB keyboard controller on a laptop that is outside of the kernel in unregistered memory.
