(Before you do this, make sure if you're in X/KDE/Gnome that you save and close your work, as you already mentioned that trying the volume wheel while in there may distort some of your input devices).
# echo "dmidecode > mydmilog.txt" | sudo bash
(will help us identify your laptop series in the quirk, if we get that far)
# echo "showkey -s > mykeylog.txt" | sudo bash
(For more complete information on the wheel... some of the information provided was slightly inconclusive)
Then move the wheel a single position up, followed by a single position down, and then a single up, and then a single down (try to be precise for these first ones) -- and then move it up several clicks, and then down several clicks? That program will stop logging after 10 seconds of inactivity, and will end automatically.
---
I find it strange that there is a 0,1,0,1,0,1 (total 6) in your volume up, and only a 1,0,1,0,1 (total 5) in your volume down -- also, that the volume down started at '1', vs volume up at '0'.
(To Debuggers reading this: if this is true, just a thought, the physical wheel might be a little imprecise in the scancodes that it transmits ... Getting an up-down-up-down "randomness" might generate more complete logs to try to get to the bottom of this - and i think it would really help to know exactly what and how many, or if there is some kind of variance or imprecision in the sensor - at which point we can decide what we can safely assume for the kernel quirk)
Andrew Gee: Can you run the following?
(Before you do this, make sure if you're in X/KDE/Gnome that you save and close your work, as you already mentioned that trying the volume wheel while in there may distort some of your input devices).
# echo "dmidecode > mydmilog.txt" | sudo bash
(will help us identify your laptop series in the quirk, if we get that far)
# echo "showkey -s > mykeylog.txt" | sudo bash
(For more complete information on the wheel... some of the information provided was slightly inconclusive)
Then move the wheel a single position up, followed by a single position down, and then a single up, and then a single down (try to be precise for these first ones) -- and then move it up several clicks, and then down several clicks? That program will stop logging after 10 seconds of inactivity, and will end automatically.
---
I find it strange that there is a 0,1,0,1,0,1 (total 6) in your volume up, and only a 1,0,1,0,1 (total 5) in your volume down -- also, that the volume down started at '1', vs volume up at '0'.
(To Debuggers reading this: if this is true, just a thought, the physical wheel might be a little imprecise in the scancodes that it transmits ... Getting an up-down-up-down "randomness" might generate more complete logs to try to get to the bottom of this - and i think it would really help to know exactly what and how many, or if there is some kind of variance or imprecision in the sensor - at which point we can decide what we can safely assume for the kernel quirk)
Thank you for the info thus far =D