Bug 98770

Created attachment 128060 [details]
/proc/bus/input/devices

Created attachment 128061 [details]
evtest

Created attachment 128062 [details]
xev

Created attachment 128063 [details]
xmodmap -pp

I previously reported a Linux kernel bug [0] " ELAN 3320KD-3100 'Smart-Pad' not supported (in Asus T300CHI) "

[0] https://bugzilla.kernel.org/show_bug.cgi?id=117601

(In reply to Tj from comment #0)
> I've taken a brief look at the libinput source code and wonder if a udev
> hwdb quirk to recognise this as an Elantech device might be all that is
> needed?

nope, the hwdb quirks are generally for userspace only. In this case the problem is that the kernel doesn't send the right sequence to initialize the touchpad and this isn't something we can fix in userspace. Until that's done, there isn't much we can do in libinput. The same would likely be true for the touchscreen too.

I'll leave this bug open for Benjamin if he wants to track it here but this is something that should be tracked in the kernel bugzilla.

Could you attach a full dmesg of 4.9-rcX?
Also, could you attach the full output of hid-recorder (http://bentiss.github.io/hid-replay-docs/) when touching the touchpad a little bit so I can have an idea of what is in the firmware?

I don't have big hopes on this bug because if there is nothing obvious in the hid-recorder log, that means the touchpad is using a proprietary mode under Windows. And we would need someone to reverse engineer it if this were the case.

Created attachment 128095 [details]
dmesg v4.9rc4 T300CHI

Thanks for the response. Logs being attached now.

As for the reverse engineering I have started on that (done a lot of it in the last 10 years!) but I may need some guidance on the specifics of what to look for with regard to how input sub-systems work at the low level.

I'm currently annotating the ACPI DSDT in case there are some Device/Methods which might give some additional clues (as you'll notice acpi_osi= is used here and causes several devices to show up that don't with a default OSI).

I also have the Windows Asus/Elan Tech Touchpad driver installer package extracted and am looking at it (basically AsusHID.sys) - will have more time to do some decent IDA analysis with it later.

I'm guessing work needs to be done on the kernel driver side and have been getting familiar with the drivers/input/mouse/asus-* code in case some additions to the WMI device probes is where we need to start.

Created attachment 128096 [details]
hid-recorder log

(In reply to Tj from comment #8)
> I'm currently annotating the ACPI DSDT in case there are some Device/Methods
> which might give some additional clues (as you'll notice acpi_osi= is used
> here and causes several devices to show up that don't with a default OSI).

The DSDT won't be of any help here. It's a bluetooth keyboard, so everything happens in the bluetooth and HID communication.

> 
> I also have the Windows Asus/Elan Tech Touchpad driver installer package
> extracted and am looking at it (basically AsusHID.sys) - will have more time
> to do some decent IDA analysis with it later.

No need to reverse engineer the source. You just need to dump the early traces of the bluetooth communication when the Windows driver starts talking to the device.

> 
> I'm guessing work needs to be done on the kernel driver side and have been
> getting familiar with the drivers/input/mouse/asus-* code in case some
> additions to the WMI device probes is where we need to start.

One thing that might be worth having a look at is if the current WIP driver for some Asus touchpads wouldn't work for you.
The WIP is https://github.com/vlasenko/hid-asus-fte-dkms and the similarities between your descriptor and this driver are big. The original kernel bug is https://bugzilla.kernel.org/show_bug.cgi?id=120181

However, we would need to enhance the driver a little bit or your keyboard will get disabled once the driver is started :)

So you might want to have a look first at their user space driver: https://github.com/redmcg/FTE1001
This might tell us if your touchpad is compatible and if you need to get involved in the development process of hid-asus.

Thanks, Reverse engineering is required since there is no Windows installation on the PC (unless another user with a dual-boot comes along).

I'll play about with the FTE driver now.

I believe we are working on the similar device here:
- kernel space driver
https://github.com/vlasenko/hid-asus-fte-dkms
- user space driver
https://github.com/redmcg/FTE1001
- magic packet searching
https://github.com/vlasenko/zenbook-touchpad-i2c
- protocol sniffing
https://github.com/ain101/drivers-input-touchscreen-FTS_driver/blob/master/doc/sniff/logic%20analyzer/win%20boot%20after%20grub%202.csv

Yeah, that's what we attempted first - to reverse engineer AsusHID.sys from Asus Smart Gesture drivers, without much success though. But then Frederik Wenigwieser has soldered logic analyzer and sniffed communication between Window driver and TouchPad device. Which has opened us the possibility to find "magic" packet used to switch TouchPad from Mouse-mode to MultiTouch mode:

static int asus_start_multitouch(struct hid_device *hdev) {
	unsigned char buf[] = { FEATURE_REPORT_ID, 0x00, 0x03, 0x01, 0x00 };
	int ret = hid_hw_raw_request(hdev, FEATURE_REPORT_ID, buf, sizeof(buf),
			HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
	if (ret != sizeof(buf)) {
		hid_err(hdev, "Failed to start multitouch: %d\n", ret);
		return ret;
	}

	return 0;
}

I wonder whether this packet works for your device to start sending multi-touch events. I guess the simplest way to find this out is to try Brendan McGrath userspace driver, with minor changes:
https://github.com/redmcg/FTE1001

Regards,
Victor

(In reply to Tj from comment #8)
> Created attachment 128095 [details]
> dmesg v4.9rc4 T300CHI
> 
> Thanks for the response. Logs being attached now.
> 
> As for the reverse engineering I have started on that (done a lot of it in
> the last 10 years!) but I may need some guidance on the specifics of what to
> look for with regard to how input sub-systems work at the low level.
> 
> I'm currently annotating the ACPI DSDT in case there are some Device/Methods
> which might give some additional clues (as you'll notice acpi_osi= is used
> here and causes several devices to show up that don't with a default OSI).
> 
> I also have the Windows Asus/Elan Tech Touchpad driver installer package
> extracted and am looking at it (basically AsusHID.sys) - will have more time
> to do some decent IDA analysis with it later.
> 
> I'm guessing work needs to be done on the kernel driver side and have been
> getting familiar with the drivers/input/mouse/asus-* code in case some
> additions to the WMI device probes is where we need to start.

Created attachment 128103 [details] [review]
hid-asus-fte patch to recognise Bluetooth Touchpad

The attached patch at least allows hid-asus-fte to recognise the ASUS T300CHI DOCKING device although it fails to initialise it. I'm not surprised at that though as this is an 'ElanTech' device, not FocalTech.

It may be the ElanTech needs its own version of the driver.

[12214.139968] hid-asus-fte 0005:0B05:8502.0015: unknown main item tag 0x0
[12214.140048] input: Asus FTE TouchPad as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:512/0005:0B05:8502.0015/input/input50
[12214.140536] hid-asus-fte 0005:0B05:8502.0015: input,hidraw0: BLUETOOTH HID v0.01 Keyboard [ASUS T300CHI DOCKING] on 34:02:86:fc:ad:59

(In reply to Tj from comment #13)
> Created attachment 128103 [details] [review] [review]
> hid-asus-fte patch to recognise Bluetooth Touchpad
> 
> The attached patch at least allows hid-asus-fte to recognise the ASUS
> T300CHI DOCKING device although it fails to initialise it. I'm not surprised
> at that though as this is an 'ElanTech' device, not FocalTech.

Thanks for testing it. The keyboard is expected to not be working because the current hid-asus-fte simply ignores everything but the multitouch touchpad reports.

Could you attach a hid-recorder output of the touch events once hid-asus-fte is in use? This way, we will be able to see if the device switches to multitouch or stick to single touch.

> 
> It may be the ElanTech needs its own version of the driver.
> 
> [12214.139968] hid-asus-fte 0005:0B05:8502.0015: unknown main item tag 0x0

That's expected for bluetooth devices.

> [12214.140048] input: Asus FTE TouchPad as
> /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:512/
> 0005:0B05:8502.0015/input/input50
> [12214.140536] hid-asus-fte 0005:0B05:8502.0015: input,hidraw0: BLUETOOTH
> HID v0.01 Keyboard [ASUS T300CHI DOCKING] on 34:02:86:fc:ad:59

Seems like the driver binds correctly.

Created attachment 128104 [details]
hid-recorder log using asus-fte (multitouch events detected!)

Looks like something useful is happening because I believe I see multitouch events in the hid-recorder log.

The events correspond to:

Left button press and release
Right button press and release
Slide left and right (one finger)
Slide up and down (one finger)
Slide left and right (two fingers)
Slide up and down (two fingers)
Slide left and right (three fingers)
Slide up and down (three fingers)
Slide left and right (four fingers)
Slide up and down (four fingers)

Forgot to mention I tried the FTE1001 userspace driver but didn't seem to get any response. Not sure what I was supposed to expect but ensured it was linked to the correct /dev/hidraw? node, etc.

Good news, you won't need to install Windows or try to reverse engineer the Windows blob. As you can see on the hid-recorder, the incoming reports are different from what they used to be. Which means, we successfully switch to the hid-multitouch reporting mode:

The reports used to be of size 5 on the report ID 0x06, and they are now of size 15 on the report ID 0x5D.

The current WIP also uses the report ID 0x5d, meaning that the chip in the other Asus is the same (or that Asus politely asked Elan to conform to their protocol).

The actual data differs a little bit, and this is why the driver is not working directly. Your device reports 15 bytes while the I2C one reports 28.
Also yours reports only 3 bytes per touch, while the I2C one reports 5: it reports pressure and does palm detection in addition to X and Y. Yours might report only X and Y.

It looks like Victor and the others are really reactive and I think I'll let them integrate your device in their code. Please raise an issue on https://github.com/vlasenko/hid-asus-fte-dkms, and attach the latest hid-recorder logs so they can find a way to integrate your device into their driver.

I'll keep around to give advice when they are needed.

Thanks Benjamin.

I'm already hacking on the asus-fte driver to handle this Asus/ElanTech device in addition to the FTE. Once I have it working I'll raise an issue and send Victor a pull request.

Many thanks for your rapid and very helpful responses; it is such a pleasure after the frequent frustrations of dealing with closed-source and closed minds!

I found another driver already in the kernel tree which is using the report ID 0x5D
for multi-touch support. It is an ElanTech driver: drivers/input/mouse/elan_i2c_core.c

But the format of the 0x5D report in this driver is slightly different to the one we're using in the hid-asus-fte-dkms driver. However:
- the first byte of the report; and
- the first three bytes of information for each contact

appears to be the consistent across all three devices (defining just the x and y locations).

As Benjamin has pointed out - it looks like your driver supports 4 contacts and each contact uses just the first three bytes of information for each contact.

I did look at the elan_i2c_core.c and related code earlier. It does seem to differ significantly from the Asus devices, and I noticed it has Asus-specific detection functions to apparently deal with differences in firmwares.

I've re-factored the asus-fte module with per-device data structures to contain all the values that were hard-coded. Tomorrow I shall tweak the Elan-specific values to try to get the OS responding to the input events properly.

Anyhope ?

i've searched a lot regarding this problem :) 

i hope @TJ finds a way :)

Unfortunately I've not had time to complete the modifications and additions since my last comment. I keep meaning to (it's a real pain not having the functionality). I'll try to put a block of time aside in the next month to focus on it and get my head back into the code.

(In reply to Tj from comment #22)
> Unfortunately I've not had time to complete the modifications and additions
> since my last comment. I keep meaning to (it's a real pain not having the
> functionality). I'll try to put a block of time aside in the next month to
> focus on it and get my head back into the code.

Great... waiting for you to save our live :)

Hi, any update? According to TJ's comment he was able to put the touchpad in multitouch status, but nothing happened after that and I haven't been able to reproduce his steps. Any way to contribute?

I have similar issues about the Asus T300CHI touchpad with no scrolling functionality. I am usinf Ubuntu 16.04 and still have windows 10 installed. Anything I can help contribute to although my skills are basic?

Created attachment 137089 [details]
wireshark logs of bluetooth communication with and without the ASUS driver

I did some more digging, and confirmed that the Asus driver sends additional commands to the device on Windows to enable the multitouch capabilities.

I've also did a packet dump on windows of the device communications with the OS (without ASUS driver, with ASUS driver, and then testing gesture and mouse commands).

I can confirm that the driver indeed sends additional commands. I've tried sending them by hand to the device descriptor but it did not trigger the mutlitouch events :/

Attaching the bluetooth dump, maybe this will help someone.

I can confirm that the touchpad multitouch works since the 4.15 kernel (installed from here http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.15/)! No blacklisting nesesery. Tested with Ubuntu 16.04.

For more advanced gestures you can additionally use this https://github.com/bulletmark/libinput-gestures (also tested, works)

Sadly, no fluid pinch-to-zoom gesture (only works as a button press simulation, but I don't think any linux touchpad has this)

(In reply to er453r from comment #28)
> Sadly, no fluid pinch-to-zoom gesture (only works as a button press
> simulation, but I don't think any linux touchpad has this)

It's available in the wayland stack but not Xorg. GNOME on Wayland + GTK apps should support pinch-to-zoom. And if you run libinput debug-events on the commandline you'll find that the pinch gestures should be detected - the libinput-gestures tool hooks on top of it after all.

That aside, can you please attach an evemu-record of a pinch interaction. Good to have for the archives here, thanks.

Created attachment 137235 [details]
4.15 ketnel pinch interaction

Added the log, most of it are pinching interactions.

And you where right, libinput debug-events indeed correctly show the gesture as pinch, only no xorg app supports it.

I've looked how is pinch-to-zoom handled from the screen digitizer (which works correctly in xorg apps - Chromimium for example) - but it only emits multiple touch events, which are probably then interpreted by the apps as pinching gesture.

I upgraded distributions to 17.10. still only has basic touchpad functionality. However 17.10 works much better generally with t300chi.

Closing this bug, there isn't much we can do for the userspace, afaict from comment 31 at least the libinput bits work correctly.