Re: Support for X1 tablet keyboard (was Re: [PATCH] platform/x86: thinkpad_acpi: handle HKEY 0x4012, 0x4013 events)

Hi,

On 2/8/21 11:17 AM, Hans de Goede wrote:

On 2/7/21 6:55 PM, Alexander Kobel wrote:

quoted

<snip>
I'll go off and try to improve.

So Nitin has been kind enough to provide us with some docs for this,
please see me reply to Nitin's email and lets continue this part of this mail
thread there.

Right. I have the other patch ready, thanks to your great help. I'm
waiting for Nitin's okay whether / how much info I can copy from the
reference sheet to source code comments. Once I have that confirmation,
I will post the revised patch.

<snip>

quoted

Finally, I mentioned some open ends already on a post to ibm-acpi-devel
at https://sourceforge.net/p/ibm-acpi/mailman/message/37200082/; this
very question is among them.
I will start tackling the SW_TABLET_MODE event issue first, but if Mark
and Nitin can already hint about the keyboard shortcuts, it'd be highly
appreciated.

I think I might be able to help there, a couple of months ago I bought
a second-hand thinkpad-10 tablet which also has a USB attached keyboard.

In hindsight I guess I could have asked Mark and Nitin for some more info,
but I went on autopilot and just ran hexdump -C on the /dev/hidraw node
to see which events all the keys send.

And I fired up an usb-sniffer under Windows to figure out the audio-leds,
since I'm used to just figure these things out without help from the vendor :)

Yeah, why take the boring route if you know how to do all the work on
your own... ;-)

See the recent commits here for my work on this:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/hid/hid-lenovo.c

Thanks, very helpful.

So on the ibm-acpi list message you said that the kbd sends the following:

type 4 (EV_MSC), code 4 (MSC_SCAN), value c0001
type 1 (EV_KEY), code 240 (KEY_UNKNOWN), value 1

For the Fn-keys, does it send the same MSC_SCAN code for *all* the
non-working Fn-keys ?

Correct. And I can confirm that /dev/hidraw1 lets me distinguish between
the keys.

If so then it seems that this is very much like the thinkpad 10 kbd dock
which also does this, see the lenovo_input_mapping_tp10_ultrabook_kbd()
function in drivers/hid/hid-lenovo.c .

If I have that right, then I think we should be able to get the
Fn keys to work without too much trouble. You could try hacking up
drivers/hid/hid-lenovo.c a bit:

(Not yet there, but will investigate.)

1. Add an entry to the lenovo_devices array like this:

	/*
	 * Note bind to the HID_GROUP_GENERIC group, so that we only bind to the keyboard part,
	 * while letting hid-multitouch.c handle the touchpad and trackpoint.
	 */
        { HID_DEVICE(BUS_USB, HID_GROUP_GENERIC,
                     USB_VENDOR_ID_LENOVO,
                     USB_DEVICE_ID_LENOVO_X1_TAB),

2. Add the following entry to the switch-case in lenovo_input_mapping() :

        case USB_DEVICE_ID_LENOVO_X1_TAB:
                return lenovo_input_mapping_tp10_ultrabook_kbd(hdev, hi, field,
                                                               usage, bit, max);

And then build hid-lenovo.c and modprobe it.

After the modprobe to:

ls -l /sys/bus/hid/devices/0003:17EF:60A3.*/driver

This should show 2 devices (I guess) with one being bound to hid-lenovo
and 1 being bound to hid-multitouch.

So far (without patching hid-lenovo), 2 bound to hid-generic and 1 to
hid-multitouch.

If this works some of your Fn + F# keys will now hopefully start doing
something, you can play around with modifying lenovo_input_mapping_tp10_ultrabook_kbd
to make it do the right thing for your kbd.

###

About LED support, just enabling the LED support bits for the
USB_DEVICE_ID_LENOVO_TP10UBKBD handling for now might work fine,
but there is a tiny chance that sending the wrong command somehow puts
the kbd in firmware update mode, I had that happen once with a Logitech
kbd which did not seem to have any kind of handshake / passcode to avoid
accidental fw updates (*).

If you can give me a dump of the hid-descriptors for your keyboard,
then I can check if that the LEDs might work the same way too (or not).

The easiest way to get a dump is to run the following command as root:

cat /sys/kernel/debug/hid/0003:17EF:60A3.*/rdesc > rdesc

And then attach rdesc to your next email.

Please find this one attached already now.
In case it helps, the * expands to 0057 0058 0059 on my system.


Thanks,
Alex

Regards,

Hans





*) Luckily it at least had a separate firmware-bootlader mode in which it
was stuck now, so with some cmdline magic to force an upgrade the Windows
fw installer could still fix it.