Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keyboard and touchpad #8

Closed
khumarahn opened this issue Nov 5, 2017 · 16 comments
Closed

keyboard and touchpad #8

khumarahn opened this issue Nov 5, 2017 · 16 comments
Labels
bug Confirmed bugs or reports that are very likely to be bugs feedback General feedback more than bug reports or feature requests

Comments

@khumarahn
Copy link
Contributor

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?
@khumarahn
Copy link
Contributor Author

img_20171106_104546
this is what the screen looks like if I carry the laptop to work

@khumarahn
Copy link
Contributor Author

khumarahn commented Nov 7, 2017

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?

@khumarahn
Copy link
Contributor Author

For some reason, the Fn+F1 button sends the acpi poweroff signal instead of the sleep signal. Can this be changed?

@khumarahn
Copy link
Contributor Author

khumarahn commented Nov 9, 2017

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;

in https://github.com/OLIMEX/DIY-LAPTOP/blob/master/SOFTWARE/A64-TERES/TERES-KBD-RELEASE/TERES-HID/KeyboardMouse.h ?

And how to compile the keyboard files and flash them?

@DanKoloff
Copy link
Contributor

@khumarahn
Copy link
Contributor Author

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).

@d3v1c3nv11
Copy link
Contributor

d3v1c3nv11 commented Nov 10, 2017

About Sleep button:

New firmware released. To upgrade follow instruction in Readme.

https://github.com/d3v1c3nv11/TERES-KBD-RELEASE/tree/master/upgrade

@khumarahn
Copy link
Contributor Author

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.

@khumarahn
Copy link
Contributor Author

The problem with libusb-0.1.so-4 was solved by installation of libusb-compat, the upgrade went through.

@khumarahn
Copy link
Contributor Author

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.

@d3v1c3nv11
Copy link
Contributor

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?

@khumarahn
Copy link
Contributor Author

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.

@khumarahn
Copy link
Contributor Author

Oooops, sorry. I forgot to change the hwdb, my bad. There is an acpi suspend event on stock ubuntu now! I will investigate.

@khumarahn
Copy link
Contributor Author

Suspend works! I make a mistake in KEYBOARD_KEY_70071=suspend. Suspend issue is closed, many thanks!

@d3v1c3nv11
Copy link
Contributor

Finally!

@khumarahn
Copy link
Contributor Author

khumarahn commented Nov 13, 2017

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.

@d3v1c3nv11 d3v1c3nv11 reopened this Nov 14, 2017
@jcstaudt jcstaudt added bug Confirmed bugs or reports that are very likely to be bugs feedback General feedback more than bug reports or feature requests labels May 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bugs or reports that are very likely to be bugs feedback General feedback more than bug reports or feature requests
Projects
None yet
Development

No branches or pull requests

5 participants