keyboard and touchpad
khumarahn opened this issue · comments
This is an issue to track a couple of problems with the keyboard and touchpad. I'll attempt to do something about them, but it may take long time before I start, and then I am new to all this.
- Touchpad is very sensitive. Too sensitive to my taste, there are many accidental clicks. Need to understand how to decrease the sensitivity or disable tap clicks. I could not find a configurable option with xinput. Is there an AVR chip to program?
- When the lid is closed, it presses on the keyboard, for instance on the Delete key. I had a file deleted this way, lots of screenshots taken, many escapes pressed, etc. It was really confusing. How to temporarily disable the keyboard (and the touchpad, just in case) when the lid is closed?
this is what the screen looks like if I carry the laptop to work
I wrote a script for handling keyboard and display when the lid is closed/open. It turned out to be very simple. One has to have the acpid daemon running, and create two files:
/etc/acpi/events/lid:
event=button/lid.*
action=/etc/acpi/actions/lid.sh %e
and /etc/acpi/actions/lid.sh:
#!/bin/bash
# TODO: what if the laptop boots with the lid closed?
# probably, the keyboard and the lcd would be still enabled
# "open" or "close"
action="${@: -1}"
# usb bus id of keyboard+touchpad device
kbd="1-1.4"
# power for the lcd
lcd=/sys/class/backlight/lcd0/bl_power
lcd_off=1
lcd_on=0
case "${action}" in
open)
logger -t "acpi_lid:" "lid open, enabling usb ${kbd}, turning on lcd"
echo "${kbd}" > /sys/bus/usb/drivers/usb/bind
echo "${lcd_on}" > "${lcd}"
;;
close)
logger -t "acpi_lid:" "lid closed, disabling usb ${kbd}, turning off lcd"
echo "${kbd}" > /sys/bus/usb/drivers/usb/unbind
echo "${lcd_off}" > "${lcd}"
;;
*)
logger -t "acpi_lid:" "unknown option ${action}"
;;
esac
It seems to work. It depends on the usb bus id of the keyboard+touchpad and the lcd brightness control location. Are these likely to change with time? Am I doing this right?
For some reason, the Fn+F1 button sends the acpi poweroff signal instead of the sleep signal. Can this be changed?
Teres 1 slowly becomes actually usable for me. I plan to share my configs, or the system image, when I am done.
I need to figure out how to configure the touchpad. It is way too sensitive to taps, and very hard to scroll with two fingers. Is there any documentation for noobs here?
For example, what are the parameters
bool tap_enabled = true;
#define DRAGTIME 8
#define MINPRESS 3
#define min_CLICK_MS CLICK_MS-MINPRESS
uint8_t presstime;
#define DRAG_ENABLED 1
#define TP_LOCK 20
#define TAP_ENABLED 1
uint8_t time_zero;
uint8_t time_one;
uint8_t time_two;
uint8_t time_pressed;
#define PRETAP 3
#define CLICK_MS 8
uint8_t MR_B_REQ = 0;
#define TOUCH_TO 8
uint16_t startposX=0xffff;
uint16_t startposY=0xffff;
bool itsDone = false;
And how to compile the keyboard files and flash them?
About compilation: https://github.com/d3v1c3nv11/TERES-KBD-RELEASE.git
On how to update: https://github.com/d3v1c3nv11/TERES-KBD-RELEASE/tree/master/upgrade
Thanks, I will look at it.
I only now realized the the battery charge "percent" is reported as /sys/class/power_supply/battery/capacity. Maybe, this works better than the crude linear voltage approximation? I wrote another patch for lxde lxpanel: https://pastebin.com/AVwXS40n
Not yet clear how to estimate time to discharge, but this is secondary.
Lxde works mostly very well... the only problem I have is the volume regulation with alsa (I didn't install pulseaudio).
About Sleep button:
New firmware released. To upgrade follow instruction in Readme.
https://github.com/d3v1c3nv11/TERES-KBD-RELEASE/tree/master/upgrade
I am not on ubuntu... Is it possible to make the updater static?
# ./update
./hid_bootloader_cli: error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory
I will install the avr toolchain and build the updater in any case, but this takes time.
The problem with libusb-0.1.so-4 was solved by installation of libusb-compat, the upgrade went through.
I updated the keyboard firmware and made some test. With acpi_listen I get:
Fn+f1: nothing
Fn+f2: nothing
Fn+f3: nothing
Fn+f4: button/volumedown VOLDN 00000080 00000000 K
Fn+f5: button/volumeup VOLUP 00000080 00000000 K
Fn+f6: button/mute MUTE 00000080 00000000 K
Fn+f7: video/brightnessdown BRTDN 00000087 00000000 K
Fn+f8: video/brightnessup BRTUP 00000086 00000000 K
Fn+f9: nothing
Fn+f10: nothing
Fn+f11: nothing
Fn+f12: nothing
In X, with xev, I see:
Fn+f1: keycode 200 (keysym 0x1008ffb0, XF86TouchpadOn)
Fn+f2: keycode 186 (keysym 0x1008ff79, XF86ScrollDown)
Fn+f3: keycode 248 (keysym 0x0, NoSymbol)
Fn+f4: keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume)
Fn+f5: keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume)
Fn+f6: keycode 121 (keysym 0x1008ff12, XF86AudioMute)
Fn+f7: keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown)
Fn+f8: keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp)
Fn+f9: keycode 133 (keysym 0xfe08, ISO_Next_Group)
Fn+f10: keycode 127 (keysym 0xff13, Pause)
Fn+f11: keycode 118 (keysym 0xff63, Insert)
It seems, f4-f12 are OK except maybe the ISO_Next_Group (what the hell is that!). F1-f3 may need some attention. I'd expect an acpi suspend event on f1, where there was an acpi shutdown event before. Also, the keycodes are strange.
In our image keycodes reported by xev, evtest, etc., are result of codes generated by keyboard firmware as defined here ...ckickme..., then is transcoded by hidkbd driver ...clickme... then changed by ...hwdb... to be reported to system right as labeled. You are free to change each of those elements to get the right codes for the linux distro you're using
Is this really an issue with our image and firmware? Should i consider it solved?
Thanks for the explanation!
I don't know with what the issue is, and I did not look deep. I just checked Fn+f1 on the stock ubuntu, and it is just the same as above. There is no sleep event, and suspend does not happen.
I think the issue with the key mapping is not a big one, even though it would be good to do it properly. A bigger problem is the sensitivity of the touchpad. I would appreciate a hint here. I did not find any obvious clues and did not have time to investigate.
Oooops, sorry. I forgot to change the hwdb, my bad. There is an acpi suspend event on stock ubuntu now! I will investigate.
Suspend works! I make a mistake in KEYBOARD_KEY_70071=suspend. Suspend issue is closed, many thanks!
Finally!
Hey, I think it is early to close this issue. It was created for two things: sensitivity of the touchpad and that the lid presses on the keyboard. It is totally great to get the suspend button to work, but it wasn't the focus.