Spontaneous numlock

[ab1jx]

I updated once a couple months ago I think. The one where you can't type anything at the end so you hve to ssh in to reboot. I didn't mind having the keys not working really until the caps lock came on with no way to turn it off. I'll load up some SD carf with Manjaro when it happens more often., I seem to go through new SD cards like water but I've got half a dozen little ARM machines that use them, plus phones and cameras.

[dsimic]

I hear you, having CapsLock turned on forcedly is very annoying; effectively, your hands become completely tied.

Let's try to do some debugging using your current setup, if you agree...  First, we should check how is the automatic suspending of the keyboard, as a USB device, currently configured on your PineBook Pro.  You can check that using the following command:

Code:

cat /sys/bus/usb/devices/3-1/*/power/control /sys/bus/usb/devices/3-1*/*/power/control

If any of those is currently set to "auto", please disable the auto-suspend and see if the issues go away.  Many USB devices do not implement that feature correctly and misbehave when suspended randomly.  The reconfiguration could be done using the following command:

Code:

for knob in /sys/bus/usb/devices/3-1/*/power/control /sys/bus/usb/devices/3-1*/*/power/control ; do echo on > $knob ; done

Also, the next time the issues happen, please try to manually suspend and resume the keyboard, as a USB device, and see if that changes the status of NumLock or CapsLock.  It could be done using the following commands, through a remote login, of course:

Code:

for knob in /sys/bus/usb/devices/3-1/*/power/control /sys/bus/usb/devices/3-1*/*/power/control ; do echo suspend > $knob ; done
for knob in /sys/bus/usb/devices/3-1/*/power/control /sys/bus/usb/devices/3-1*/*/power/control ; do echo on > $knob ; done

As a note, "3-1" in the commands above is the ID of the keyboard as a USB device, which should be the same on your PineBook Pro.

Edit: I've updated the commands to cover all USB endpoints.  By the way, I also occasionally have some weird issues with the trackpad, which sometimes seems to stop recognizing button clicks or two-finger gestures, and typing anything on the keyboard seems to restore the trackpad to its normal state.  I'll also disable the auto-suspend, as described above, and see if this issue goes away.

[ab1jx]

Hmm, later, I just thought of a workaround.  In DOS at least you can programatically turn those locks on and off.  I could figure out how to do it, write a script or program that does it, give it a name that doesn't need one of those keys and put it in my path.  Next time it comes on I  run my program. 

Like I made spoff and spon to turn the laptop speakers on and off when you have headphones plugged in by running

Code:

amixer -q -c0 cset numid=28 on &> /dev/null

or

Code:

amixer -q -c0 cset numid=28 0 &> /dev/null

I'm pretty sure auto-suspend isn't set up, sounds awful.  When my trackpad freezes I slap it.  Just try to hit it with at least 4 fingers at once. I don't know if it's a bad connection or if the flood of trackpad events flushes some queue.  i haven't had to do it in a month or so.

[dsimic]

Hmm, later, I just thought of a workaround.  In DOS at least you can programatically turn those locks on and off.  I could figure out how to do it, write a script or program that does it, give it a name that doesn't need one of those keys and put it in my path.  Next time it comes on I run my program. 

Turning the CapsLock and NumLock off from the command line is a very good idea for a workaround (hint: you can use "xdotool key Caps_Lock", for example).  However, please also try disabling the USB auto-suspend for the keyboard, it's highly likely to be the actual culprit.

Like I made spoff and spon to turn the laptop speakers on and off when you have headphones plugged in by running...

Do you still need to use that workaround for turning the built-in speakers on and off when the headphones are plugged in or out?  That's already handled by the Linux kernel driver for the PineBook Pro's audio codec, so no userspace workarounds should be needed.

I'm pretty sure auto-suspend isn't set up, sounds awful. When my trackpad freezes I slap it.  Just try to hit it with at least 4 fingers at once. I don't know if it's a bad connection or if the flood of trackpad events flushes some queue.  i haven't had to do it in a month or so.

Actually, the Linux kernel turns the USB auto-suspend feature on for all connected USB devices, as a power-saving measure, excluding the quirky USB devices that are well-known to not implement that feature correctly.  The trackpad could very well be quirky, requiring the auto-suspend to be disabled.

[ab1jx]

dumpkeys shows numlock as Num_Lock, keycode 69, I set up a /usr/local/bin/cl script that toggles it and tested it. Oops, L is one of the keys affected so I renamed to nn.

The speakers don't switch booted this way, they do if I use mrfixit.

This auto-suspend sounds like the power-saving feature wifi cards have. I've never seen the whole laptop suspend, maybe just the touchpad does. I'd like to eventually have hibernate (full memory to drive and complete power off) working but I haven't pursued it yet since I'm still booting from sd cards. I made a partition for it on my nvme drive. If I hit Fn-Esc/Z something happens for a few seconds but it comes right back to normal, it's evidently not working.

Is there a tool for dealing with usb auto-suspend? The touchpad acts up maybe once a month and always when I'm using it so it's not timing out I don't think. tlp?

[dsimic]

The speakers don't switch booted this way, they do if I use mrfixit.

That's because the variant of Debian you're using has an old, incomplete device tree file for the PineBook Pro.  The enabling and disabling of the built-in speakers is performed by the ALSA SoC layer, it just needs to be told to do so using the device tree.  You could simply grab rk3399-pinebook-pro.dts (together with its dependencies) from the Linux kernel source, compile it using dtc, and put the compiled version into /boot.

By the way, I also used MrFixit's Debian on my PineBook Pro for some time, but it worked rather poorly.  The 4.4 kernel it shipped with was a real mess that crashed almost regularly after a few hours of uptime.

This auto-suspend sounds like the power-saving feature wifi cards have.  I've never seen the whole laptop suspend, maybe just the touchpad does.  I'd like to eventually have hibernate (full memory to drive and complete power off) working but I haven't pursued it yet since I'm still booting from sd cards.  I made a partition for it on my nvme drive.  If I hit Fn-Esc/Z something happens for a few seconds but it comes right back to normal, it's evidently not working.

As far as I know, suspending to RAM works, but the desired hibernation to disk doesn't work yet on the PineBook Pro.  I haven't experimented too much with that myself, though.  You can initiate the suspending to RAM using this:

Code:

echo deep > /sys/power/mem_sleep
echo mem > /sys/power/state

More information about the system sleep states is available here.

Is there a tool for dealing with usb auto-suspend?

What would you actually like to accomplish?

[ab1jx]

OK, I did apt-get install dtc, fetched the dts file from https://git.kernel.org/pub/scm/linux/ker...ok-pro.dts and put it in my /boot directory then ran dtc on it.  I got:

Code:

Error: rk3399-pinebook-pro.dts:9.1-9 syntax error
FATAL ERROR: Unable to parse input tree

Is that because I don't have the other files?  Where do I get those? Not a very good error message. I was missing includes, I copied them in, same error. No line number, no missing file name, nothing.

If this is a compiled binary describing a laptop that 1000s of people have got, shouldn't it be possible to download a dtb file? I can maybe steal one from a Manjaro image, or Armbian.

[dsimic]

I agree, that error message is rather unusable.  What is the version of dtc you used?  It could be that dtc is too old and unable to parse the .dts input file correctly.

You can find compiled .dtb files in the current Manjaro ARM Linux kernel package, for example.  However, now I'm concerned that the current .dtb file might also be too new for the version of Linux kernel you're running.

[ab1jx]

That's quite likely, it's DTC 1.0.0. I should have built this from the source link. The date on the installed DTB is Jan 14, 2021 but that's just a file date.

[dsimic]

As a note, dtc is currently at version 1.6.0, and the initial 1.0.0 release from 2014 is really outdated.