Hi,

On 2/9/21 4:16 PM, Alexander Kobel wrote:

Hi,

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

quoted

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.

quoted

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

quoted

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.

quoted

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.

quoted

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

quoted

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.

Ok, so it seems that they kept the thinkpad 10 kbd bits (mostly) with
1 keyboard interface using the usb boot kbd interface (so that it will
also work inside the BIOS) and a second interface for multimedia-keys +
the mouse emulation of the thinkpad 10 touchpad, those are interfaces
1 and 2, except that they removed the mouse emulation as they added a
new proper multi-touch capable touchpad as interface 3; and that one
also handles the pointing stick I believe.

So yes 2 bound to hid-generic, 1 bound to hid-multitouch seems to be
correct.

quoted

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.
z
###

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.

Ok, so there still is an output-report number 9 on the second interface,
which probably still controls the LEDS but its descriptors are subtly
different. Although different in a good way I guess because the thinkpad
10 dock descriptor describes the 2 bytes in the output report as being
in the range of 0-1 which is not how they are actually used.

So I think that the code for the Thinkpad 10 ultrabook keyboard as
Lenovo calls it, should also work on the X1 tablet thin keyboard.

I've prepared a set of patches which enable the tp10ubkbd code on
the X1 tablet thin keyboard. But beware as mentioned before there is a
tiny chance that sending the wrong command somehow puts the kbd in
firmware update mode. I believe that trying the tp10ubkbd code is safe,
esp. since this is using a 2 byte large output report and using that
for fw-updating would be a bit weird. Still there is a small risk
(there always is when poking hw) so I will leave it up to you if
you are willing to try this.

Here is how I test this (note you will need to adjust the paths a bit) :

Toggle the 2 mute LEDs:

[root@localhost ~]# echo 1 > /sys/class/leds/0003:17EF:6062.000E:amber:micmute/brightness
[root@localhost ~]# echo 0 > /sys/class/leds/0003:17EF:6062.000E:amber:micmute/brightness
[root@localhost ~]# echo 1 > /sys/class/leds/0003:17EF:6062.000E:amber:mute/brightness
[root@localhost ~]# echo 0 > /sys/class/leds/0003:17EF:6062.000E:amber:mute/brightness

Check Fnlock LED state (toggle on kbd by pressing Fn + Esc) :

[root@localhost ~]# cat /sys/bus/hid/devices/0003:17EF:6062.000E/fn_lock
1
[root@localhost ~]# cat /sys/bus/hid/devices/0003:17EF:6062.000E/fn_lock
0

Change Fnlock state from within Linux:

[root@localhost ~]# echo 1 > /sys/bus/hid/devices/0003:17EF:6062.000E/fn_lock
[root@localhost ~]# echo 0 > /sys/bus/hid/devices/0003:17EF:6062.000E/fn_lock

(The Led on the kbd should update; and the F## key behavior should change)

Regards,

Hans