06-04-2021, 10:59 PM
(This post was last modified: 06-04-2021, 11:23 PM by dsimic.)
I've just updated the keyboard firmware and the touchpad firmware on my first-batch ISO PineBook Pro, using the community updater, and the two steps went as expected. Strangely, something inside the laptop produced a hissing sound until the second step got completed; the sound was there before and after power cycling the laptop, upon the completion of the first step. I wonder what was the source of the hissing sound? The keyboard controller IC?
I've also completed the third, flash-kb step, which unfortunately caused the Fn + NumLock key combination to stop working. The green LED still turned on and off as a result of depressing the Fn + NumLock key combination, but the respective "numpad" keys still produced letters instead of numbers with the green LED illuminated. I haven't attempted to debug that; instead, I've repeated the two steps, ending up with the latest unpatched version of the keyboard firmware.
In this state, my ISO PineBook Pro should have the same keyboard firmware and the same touchpad firmware as the ISO PineBook Pros that were made in the last batch, if any ISO variants were actually made in the last batch. Unfortunately, the firmware update made no improvements to the touchpad, i.e. the touchpad is still laggy and experiences the same initial delay as before the firmware update. 
As a note, the value of the " Synaptics Noise Cancellation" paramater remained at " 0, 0" all the time.
Edit: The initial delay is also easily noticeable when using the touchpad on the virtual console, using gpm. However, it's also rather easy to not notice the delay, especially after using the touchpad for some time, because the human brain seems to keep trying to "weed out" such short delays or time shifts, in an effort to present a coherent image of the surroundings. 
06-05-2021, 12:13 AM
(This post was last modified: 06-05-2021, 12:13 AM by KC9UDX.)
I thought the Numlock behaviour that you describe was an intentional feature. I seem to recall reading that you have to hold Fn to get numbers all the time because the author of the new firmware didn't like the standard Numlock functionality. This was the sole reason I never used that firmware.
I'm not using the Synaptics driver (it's not available for NetBSD currently). I did finally get round to documenting the settings I use in KDE (v4) to make the touchpad most usable:
Code: Pointer acceleration: 10.0x
Pointer threshold: 6 pixels
Double click interval: 400 msec
Drag start time: 500 msec
Drag start distance: 1pixel
Mouse wheel scrolls by: 3 lines
Mouse wheel emulation does not currently work, so that setting isn't relevant for me.
My touchpad recently has devolped a new problem making it all but unusable. I may have to tweak the settings again but I'm not sure that will help. What it does now is detect every touch as a double-tap. So every movement is drag or select.
06-05-2021, 12:30 AM
(This post was last modified: 06-05-2021, 03:32 AM by dsimic.
Edit Reason: Word choice
)
(06-05-2021, 12:13 AM)KC9UDX Wrote: I thought the Numlock behaviour that you describe was an intentional feature. I seem to recall reading that you have to hold Fn to get numbers all the time because the author of the new firmware didn't like the standard Numlock functionality. This was the sole reason I never used that firmware.
If that's the case, such a design (or patching) decision is rather unreasonable. Why should a widely available feature be killed without even being documented as no longer available?  At least the NumLock LED shouldn't be illuminated if the goal was to kill the NumLock feature. The best is to leave the NumLock feature avaiable for anyone who wants to use it.
(06-05-2021, 12:13 AM)KC9UDX Wrote: My touchpad recently has devolped a new problem making it all but unusable. I may have to tweak the settings again but I'm not sure that will help. What it does now is detect every touch as a double-tap. So every movement is drag or select.
That's really weird. What could be the reason for such behavior?
By the way, Manjaro ARM doesn't enable taps by default, and I've left it that way. I've actually figured out that the taps were one of the deal breakers for me when it comes to using touchpads in general. I cannot stand the possibility to produce unintentional clicks.
06-05-2021, 12:56 AM
(This post was last modified: 06-05-2021, 01:29 AM by KC9UDX.)
I couldn't agree more about the Numlock. It was documented here, in one of the early threads about custom keyboard firmware. If I find it, I'll post a link.
I'm leaning toward a dead spot in the touchpad causing my problem. I haven't proven it, but it seems like it doesn't happen if I avoid the upper right portion. I'll have to look if there's a way to disable taps. The only thing worse than this is mouse "gestures".
@ dsimic I found it. It's here, right in the first post:
https://forum.pine64.org/showthread.php?...t=firmware
(06-05-2021, 12:56 AM)KC9UDX Wrote: I couldn't agree more about the Numlock. It was documented here, in one of the early threads about custom keyboard firmware. If I find it, I'll post a link.
I found it. It's here, right in the first post:
https://forum.pine64.org/showthread.php?...t=firmware
Killing the NumLock that way was a very, very poor choice. On the plus side, at least it was somewhat documented.
Creating fancy, custom keyboard layouts and maps becomes bad only when such layouts are showed down everybody's throat. Those fancy layouts can and surely will exist, but they should exist as an option, not as the only choice that's available.
(06-05-2021, 12:56 AM)KC9UDX Wrote: I'm leaning toward a dead spot in the touchpad causing my problem. I haven't proven it, but it seems like it doesn't happen if I avoid the upper right portion. I'll have to look if there's a way to disable taps.
If there's a dead spot on the touchpad, disabling the taps should make the double-tap issue go away.
(06-05-2021, 12:56 AM)KC9UDX Wrote: The only thing worse than this is mouse "gestures".
Yuck, mouse gestures are downright scary to me. Who knows how the algorithm is going to recognize the gesture? It's like some kind of Russian roulette.
(06-04-2021, 06:23 PM)dsimic Wrote: I'll try to boot Manjaro + KDE Plasma on my first-batch ISO PineBook Pro, and we'll see what happens when the settings you've described are applied. I'll also make sure that the keyboard firmware is updated to the latest available community version, and I'll make sure that the touchpad firmware is updated to the latest available proprietary version. I've been putting that off because of the associated risk of bricking.
I would really love to see a lag-free touchpad as the result.
As I already wrote earlier, I've updated the keyboard firmware and the touchpad firmware on my ISO PineBook Pro to the latest unpatched proprietary versions.
After booting Manjaro ARM KDE Plasma from a microSD card (it looks nice, by the way), I can confirm that the touchpad settings you've decsribed are available. However, sadly, changing the vertical and horizontal "Noise Cancellation" settings from 8 to 0 made no noticeable improvements to the touchpad. It still experiences the original issue, i.e. the delay upon the initial finger movement.
dsimic,
I tried to run your requested code below in Konsole, and got nothing, no reply just a new line.
[root@pbp b]# dmesg | grep -i input
[root@pbp b]#
Not sure whats up. Its a bit of a bummer, these settings don't seem to be working on yours and I am sure others PBP's. Only thing I can think to add is mine is an ANSI keyboard layout version.
Edit: Actually, your PineBook Pro can provide us with some interesting information, very easily and with absolutely zero risk. Could you, please, run the following command on your PineBook Pro and provide the resulting output in your response:
Code: dmesg | grep -i input
The names of the input devices, visible in the command's output, should allow us to know whether the factory-flashed keyboard firmware in your PineBook Pro is the patched community version or the original proprietary version.
Hwell... This is a problem with using NetBSD, I guess: Too much uptime. I hadn't rebooted in over two months, apparently. Embarrassingly, a reboot solved my everything's-a-double-click problem.
(06-06-2021, 09:53 PM)BCB Wrote: I tried to run your requested code below in Konsole, and got nothing, no reply just a new line.
[root@pbp b]# dmesg | grep -i input
[root@pbp b]#
Not sure whats up.
You're probably running with the audit enabled, which fills up the kernel ring buffer and hides the kernel boot messages. The easiest way to go around that would be to reboot your PineBook Pro and run the command immediately after the reboot.
(06-06-2021, 09:53 PM)BCB Wrote: Its a bit of a bummer, these settings don't seem to be working on yours and I am sure others PBP's. Only thing I can think to add is mine is an ANSI keyboard layout version.
The touchpad firmware is the same for both variants of the PineBook Pro (ANSI and ISO), which means that the touchpad should behave the same regardless of the variant. I also have an ANSI PineBook Pro, but I'm not willing to update the firmware on it, at least not yet. If I manage to create a patched version of the keyboard firmware that leaves the keyboard at its "stock-like" behavior, I might give it a try; see this post for further information.
(06-06-2021, 11:50 PM)KC9UDX Wrote: Hwell... This is a problem with using NetBSD, I guess: Too much uptime. I hadn't rebooted in over two months, apparently. Embarrassingly, a reboot solved my everything's-a-double-click problem.
The good news is that your touchpad is fine. 
Hi all,
Had a go with the reboot and
Code: dmesg | grep -i input
Sure enough that did it. Here is the output I received from that command
[b@pbp ~]$ dmesg | grep -i input
[ 2.689502] input: HAILUCK CO.,LTD USB KEYBOARD as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.0/0003:258A:001E.0001/input/input0
[ 2.754551] hid-generic 0003:258A:001E.0001: input,hidraw0: USB HID v1.10 Keyboard [HAILUCK CO.,LTD USB KEYBOARD] on usb-fe3a0000.usb-1/input0
[ 2.791818] input: HAILUCK CO.,LTD USB KEYBOARD Mouse as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input1
[ 2.792312] input: HAILUCK CO.,LTD USB KEYBOARD Touchpad as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input2
[ 2.792986] input: HAILUCK CO.,LTD USB KEYBOARD System Control as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input3
[ 2.856298] input: HAILUCK CO.,LTD USB KEYBOARD Consumer Control as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input4
[ 2.856743] input: HAILUCK CO.,LTD USB KEYBOARD Wireless Radio Control as /devices/platform/fe3a0000.usb/usb3/3-1/3-1:1.1/0003:258A:001E.0002/input/input5
[ 2.857407] hid-multitouch 0003:258A:001E.0002: input,hiddev96,hidraw1: USB HID v1.10 Mouse [HAILUCK CO.,LTD USB KEYBOARD] on usb-fe3a0000.usb-1/input1
[ 3.070383] input: gpio-key-lid as /devices/platform/gpio-key-lid/input/input6
[ 3.071657] input: gpio-key-power as /devices/platform/gpio-key-power/input/input7
[ 6.898567] input: rockchip,es8316-codec Headphones as /devices/platform/es8316-sound/sound/card0/input8
[ 9.392843] input: USB Camera: USB Camera as /devices/platform/fe3c0000.usb/usb2/2-1/2-1.2/2-1.2:1.0/input/input9
[b@pbp ~]$
Not sure how helpful it is, but there it is, the info on a trackpad that is working fairly well. Hopefully it helps, and if there is anything else I can do just let me know.
Thanks,
Bcbrett
|
