First draft HID over I2C support (Mouse only)

[marc.priggemeyer_gmail.com]

Summary

Important: Use sysutils/iichid!!

Support for Human Interface Devices over I2C.

There are a couple of points to keep in mind:

Important notes:

1. Currently iichid only supports mouse devices and therefore creates /dev/ims*.
2. I use moused with settings in rc.conf like this: moused_port="/dev/ims0"
3. I tried a few approaches to identify and attach an iichid device by querying ACPI directly from the iichid module. That failed on two details: parent association (in general HID over I2C devices appear below ACPI0 in NewBus but it is necessary to have them below the iicbus*/iic* nodes, moving these node in NewBus failed for me with a panic) and also interrupt handling (apparently, interrupts must be handled by the nodes the IRQs are assigned to (i.e. the node below ACPI0). Trying to attach to an IRQ from another node (i.e. a node below iicbus*/i2c*) fails)
4. acpi_iichid creates a iichid node below the identifiable iicbus
5. acpi_iichid enques a task either on interrupt or timeout and delegates retrieval of reports to iichid by callback
6. iichid_load="YES" and acpi_iichid_load="YES" in loader.conf should work now without crash.

Stalled:

1. Please refer to the changes I made to usbhid.h and usbhid.c, since I moved the generic hid functionality out of those files into two new ones. The long term aim would be to create a HID abstraction layer (called HID Caps) that will provide a general interface to HID capabilities and functions through the device tree. It will help to make it easier to use Human Interface Devices on different busses without the need of pulling USB into the kernel configuration. This is work in progress and, for now, independent of the I2C over HID support.

Test Plan

Load acpi_iichid and make sure to have an I2C controller driver (e.g. ig4) loaded beforehand. acpi_iichid should require iicbus and iichid as dependencies.

After loading you should see something like this (That is the output on my Dell Latitude 5480):
iichid_acpi0: <HID over I2C (ACPI)> irq 51 on acpi0
iichid_acpi0: descriptor register address is 20
iichid_acpi0: parent device is "\134_SB_.PCI0.I2C1"
iichid0: <HID over I2C> at addr 0x2c on iicbus1
iichid0: ADDR 0x2c REG 0x20
iichid0: 3 buttons and [XYZT] coordinates ID=1
iichid0: 3 buttons and [XYZT] coordinates ID=1
iichid0: determined (len=81) and described (len=83) input report lengths mismatch
iichid_acpi0: added iichid0 ADDR 0x2c REG 0x20 to iicbus1
iichid_acpi0: allocated irq at 0xfffff80004a46600 and rid 0
iichid_acpi0: successfully setup interrupt

vmstat -i should show statistics on interrupt handling.

Since interrupt resource acquisition is not always possible (in case of GPIO interrupts) acpi_iichid now supports a sampling_mode.
Set dev.acpi_iichid.#.sampling_rate to a value greater then 0 to activate sampling. A value of 0 is possible but will not reset the callout and, thereby, disable further report requests.
Do not set the sampling_rate value too high as it may result in periodical lags of cursor motion

• e.g. 100 is the achievable rate in interrupt mode on my laptop, but is too high in sampling mode
• rates between 30 and 60 samples per second appear to be a good tradeoff on my system.
• 20 is too low on my machine

Another minor addition is a sysctl to invert the mouse wheel direction. Set dev.iichid.#.invert_scroll to test.

[marc.priggemeyer_gmail.com]

#1

In D16698#452086, @markj wrote:

The acpi_iichid driver needs to be rewritten. It should be a child of the iic bus, not the acpi bus. I've started working on this.

I will submit to the more experienced developers on this point, for completeness I would still like to include my findings here:

• The I2C Bus is not enumerable, which means that the driver won't be attached automatically if it is a child of iicbus.
• The specification of HID over I2C explicitly states that devices should be included in the ACPI tables for proper identification, therefore a driver implemented as a child of ACPI will be attached.
• My workaround was to implement the driver as part of the ACPI structure that identifies the relevant parameters and attaches the actual device below the iicbus.
• A more elaborate explanation to the why is included in point 3 under the important notes in my initial description.
• Thanks for picking this issue up, I am looking forward to see the correct implementation.

#2
One major issue I still see here is a structural one: HID code is currently maintained as part of the USB implementation (since it was initially specified to be part of USB).

#3
The crash people are experiencing during boot with acpi_iichid_load="YES" in /boot/loader.conf:
Do you also include iichid_load="YES"? I don't experience crashes on my system, but I will try this evening to replicate that.

Unfortunately I do not have much time to spend on this at the moment.

[markj]

In D16698#452171, @marc.priggemeyer_gmail.com wrote:

#1

In D16698#452086, @markj wrote:

The acpi_iichid driver needs to be rewritten. It should be a child of the iic bus, not the acpi bus. I've started working on this.

I will submit to the more experienced developers on this point, for completeness I would still like to include my findings here:

• The I2C Bus is not enumerable, which means that the driver won't be attached automatically if it is a child of iicbus.

The trick is to use the DEVICE_IDENTIFY(9) method to walk the child nodes of the ACPI node associated with the iicbus device. This can be done with AcpiWalkNamespace(), for instance. Then you can force the instantiation of a acpi_iicbus device.

I'm not sure yet about the interrupt problem you described in the code review description, I'll try to get that bit working this coming week.

• The specification of HID over I2C explicitly states that devices should be included in the ACPI tables for proper identification, therefore a driver implemented as a child of ACPI will be attached.
• My workaround was to implement the driver as part of the ACPI structure that identifies the relevant parameters and attaches the actual device below the iicbus.
• A more elaborate explanation to the why is included in point 3 under the important notes in my initial description.
• Thanks for picking this issue up, I am looking forward to see the correct implementation.

#2
One major issue I still see here is a structural one: HID code is currently maintained as part of the USB implementation (since it was initially specified to be part of USB).

Yes, they will require some work to merge. However, I don't think it should block this driver from being committed.

Do you have a license header for iichid.c?

[marc.priggemeyer_gmail.com]

In D16698#452186, @markj wrote:

Do you have a license header for iichid.c?

Actually, no. What would be the source for the default for FreeBSD? 2-clause from here (https://www.freebsd.org/internal/software-license.html)?

In D16698#452186, @markj wrote:

The trick is to use the DEVICE_IDENTIFY(9) method to walk the child nodes of the ACPI node associated with the iicbus device. This can be done with AcpiWalkNamespace(), for instance. Then you can force the instantiation of a acpi_iicbus device.

Sounds right. Acutally, I fumbled through that acpica code and collected what looked right. Do you have any pointer to the handbook or other documentation suitable as reference material?

I just looked into Microsoft's HID over I2C specification document again. Section 8.2 deals with "Host Initiated Power Optimizations" (HIPO). There, sleep and on are explicitly stated as modes that the host should take care of:
Quote: [1]

The HOST is responsible for optimizing the power of the overall system and the DEVICE. This method of power optimization is to be used when the HOST wishes to provide power optimization notifications to devices.
The following power states are defined for HIPO and are not to be confused with vendor specific DIPO states.

• ON
• SLEEP

Section 7.2.8 specifies the SET_POWER command, so the DEVMETHODs device_suspend and device_resume should implement sleep and wakeup transitions for the human interface device. In addition, the device is not required to respond to the SET_POWER command, so it could be implemented fairly easy. Probably something like this (untested):

static int
iichid_write_register(device_t dev, uint8_t* cmd, int cmdlen)
{
	uint16_t addr = iicbus_get_addr(dev);
	struct iic_msg msgs[] = {
	     { addr << 1, IIC_M_WR, cmdlen, cmd },
	};

	return (iicbus_transfer(dev, msgs, nitems(msgs)));
}

static int
iichid_set_power(device_t dev, struct i2c_hid_desc* hid_desc, bool sleep)
{
	struct iichid_softc* sc;
	sc = device_get_softc(dev);

	mtx_assert(&sc->lock, MA_OWNED);

	uint16_t cmdreg = htole16(hid_desc->wCommandRegister);

	uint8_t power_state = 0; //default on
	if( sleep )
		power_state = 1; //sleep	

	uint8_t cmd[] = {cmdreg & 0xff, cmdreg >> 8, power_state, 0x08};  //0x08, 4 reserved bits plus opcode (4 bit)
	int cmdlen    = 4;

	mtx_unlock(&sc->lock);

	int error = iichid_write_register(dev, cmd, cmdlen);

	mtx_lock(&sc->lock);

	return error;
}

[1] http://download.microsoft.com/download/7/d/d/7dd44bb7-2a7a-4505-ac1c-7227d3d96d5b/hid-over-i2c-protocol-spec-v1-0.docx

[marc.priggemeyer_gmail.com]

Hmm, I think I did not intend to create a new diff. Should I reupload, or can it be merged?

sys/modules/acpi/acpi_iichid/Makefile

5

Will the acpi module be removed and code integrated into sys/modules/i2c?

[markj]

In D16698#452204, @marc.priggemeyer_gmail.com wrote:

Hmm, I think I did not intend to create a new diff. Should I reupload, or can it be merged?

Please reupload the full diff.

In D16698#452198, @marc.priggemeyer_gmail.com wrote:

In D16698#452186, @markj wrote:

Do you have a license header for iichid.c?

Actually, no. What would be the source for the default for FreeBSD? 2-clause from here (https://www.freebsd.org/internal/software-license.html)?

FreeBSD 2-clause is the preferred license for new files. I noticed that iichid.h appears to be from OpenBSD (which is perfectly fine), so it wasn't clear to me if iichid.c was also derived from OpenBSD or if it was written from scratch.

[fbsd_opal.com]

In D16698#452198, @marc.priggemeyer_gmail.com wrote:

I just looked into Microsoft's HID over I2C specification document again. Section 8.2 deals with "Host Initiated Power Optimizations" (HIPO). There, sleep and on are explicitly stated as modes that the host should take care of:
Quote: [1]

The HOST is responsible for optimizing the power of the overall system and the DEVICE. This method of power optimization is to be used when the HOST wishes to provide power optimization notifications to devices.
The following power states are defined for HIPO and are not to be confused with vendor specific DIPO states.

• ON
• SLEEP

Section 7.2.8 specifies the SET_POWER command, so the DEVMETHODs device_suspend and device_resume should implement sleep and wakeup transitions for the human interface device. In addition, the device is not required to respond to the SET_POWER command, so it could be implemented fairly easy. Probably something like this (untested):

static int
iichid_write_register(device_t dev, uint8_t* cmd, int cmdlen)

static int
iichid_set_power(device_t dev, struct i2c_hid_desc* hid_desc, bool sleep)

I put in that code and added suspend and resume functions to invoke it.

Firstly, the mtx_assert() fails and causes a panic.

Removing the mtx_assert() and so also the mtx_unlock() and mtx_lock() runs ok, but doesn't help with the problem of the mouse still needing resetting after resume.

[marc.priggemeyer_gmail.com]

I reuploaded the full patch with a sysctl (power_state) added.
Setting

sysctl dev.iichid.0.power_state=1

or any other value not 0, will send the human interface device to sleep. Setting

sysctl dev.iichid.0.power_state=0

will wake it up again.

device_suspend and device_resume was also added, but I could not test it sufficiently, because suspend/resume does not work on my laptop as of yet.

[wulf]

I wrote a driver for I2C MT touchscreens https://github.com/wulf7/iichid which is heavily based on the code in this review.
It does not require dedicated ACPI module at all and has some I2C/HID layers separation which is missed in current review.
So I think it may have sense to join efforts and codebases

[markj]

In D16698#452631, @wulf wrote:

I wrote a driver for I2C MT touchscreens https://github.com/wulf7/iichid which is heavily based on the code in this review.
It does not require dedicated ACPI module at all and has some I2C/HID layers separation which is missed in current review.
So I think it may have sense to join efforts and codebases

Oh, nice. Your iichid_identify() method is basically identical to what I wrote. You're right, it does not strictly require a separate module, it just seemed cleaner to have a generic acpi_iichid bus.

I think it would be best to try and base the ims driver on top of your code. Are you interested in trying to integrate them?

[wulf]

In D16698#452632, @markj wrote:

Oh, nice. Your iichid_identify() method is basically identical to what I wrote. You're right, it does not strictly require a separate module, it just seemed cleaner to have a generic acpi_iichid bus.

I don't object to acpi_iichid module existence. It just adds an extra requirements for module load order which I was not able to solve quickly.

I think it would be best to try and base the ims driver on top of your code. Are you interested in trying to integrate them?

Yes, I am going to submit this code to the project when it will be ready, so it is better to have it insync with ims

[nikola.lecic_anthesphoria.net]

Many thanks for your efforts! My laptop: Asus Zenbook 14 UX410UFR with 12.0-RELEASE. After kldload ig4 iic acpi_iichid the device works after being probed with i2c -v -s -f /dev/iic1 (thanks fbsd_opal.com). My /var/log/messages:

Jul 15 01:55:03 thorium kernel: ig4iic_pci0: <Intel Sunrise Point-LP I2C Controller-0> mem 0xef238000-0xef238fff at device 21.0 on pci0
Jul 15 01:55:03 thorium kernel: ig4iic_pci0: Using MSI
Jul 15 01:55:03 thorium kernel: iicbus0: <Philips I2C bus> on ig4iic_pci0
Jul 15 01:55:03 thorium kernel: ig4iic_pci1: <Intel Sunrise Point-LP I2C Controller-1> mem 0xef237000-0xef237fff at device 21.1 on pci0
Jul 15 01:55:03 thorium kernel: ig4iic_pci1: Using MSI
Jul 15 01:55:03 thorium kernel: iicbus1: <Philips I2C bus> on ig4iic_pci1
Jul 15 01:55:03 thorium kernel: ig4iic_pci2: <Intel Sunrise Point-LP I2C Controller-2> mem 0xef236000-0xef236fff at device 21.2 on pci0
Jul 15 01:55:03 thorium kernel: ig4iic_pci2: Using MSI
Jul 15 01:55:03 thorium kernel: iicbus2: <Philips I2C bus> on ig4iic_pci2
Jul 15 01:55:03 thorium kernel: warning: KLD '/boot/kernel/iic.ko' is newer than the linker.hints file
Jul 15 01:55:03 thorium kernel: iic0: <I2C generic I/O> on iicbus0
Jul 15 01:55:03 thorium kernel: iic1: <I2C generic I/O> on iicbus1
Jul 15 01:55:03 thorium kernel: iic2: <I2C generic I/O> on iicbus2
Jul 15 01:55:03 thorium kernel: acpi_iichid0: <HID over I2C (ACPI)> irq 109 on acpi0
Jul 15 01:55:03 thorium kernel: acpi_iichid0: descriptor register address is 1
Jul 15 01:55:03 thorium kernel: acpi_iichid0:  - irq: 109
Jul 15 01:55:03 thorium kernel: acpi_iichid0: parent device is "\_SB_.PCI0.I2C1"
Jul 15 01:55:03 thorium kernel: iichid0: <HID over I2C> at addr 0x15 on iicbus1
Jul 15 01:55:03 thorium kernel: iichid0: ADDR 0x15 REG 0x1
Jul 15 01:55:03 thorium kernel: iichid0: 2 buttons and [XYZT] coordinates ID=1
Jul 15 01:55:03 thorium syslogd: last message repeated 1 times
Jul 15 01:55:03 thorium kernel: acpi_iichid0: added iichid0 ADDR 0x15 REG 0x1 to iicbus1
Jul 15 01:55:03 thorium kernel: acpi_iichid0: allocated irq at 0xfffff80107e06500 and rid 0
Jul 15 01:55:03 thorium kernel: acpi_iichid0: successfully setup interrupt

ig4 breaks suspend for me (which works just fine without it). After acpiconf -s3 laptop hangs on ttyv1 with quickly blinking mouse cursor and these lines:

<6>[drm] GPU HANG: ecode 9:1:0xfffffffe, reason: Hang on bcs0, action: reset 
drmn0: Failed to idle engines, declaring wedged!

For now, I solved this problem by adding kldunload ig4 in /etc/rc.suspend and all commands activating touchpad in /etc/rc.resume. With this hack, I have working touchpad after resume, which is very nice.

My questions:

1. I compiled this driver with EVDEV support (https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092). How can I make use of it? I see no difference with and without this patch.

2. With this in /etc/rc.conf:

moused_flags=" -V -a 0.8 -A 1.0 -U 4 -L 1.5"
moused_port="/dev/ims0"

and this in /etc/X11/xorg.d/mouse.conf:

Section "InputClass"
    Identifier "Touchpad"
    Option "Device" "/dev/ims0"
EndSection

I have only left button working (no right click, no two-finger scrolling). Any suggestions?

3. moused_flags=" -V -a 0.8 -A 1.0 -U 4 -L 1.5" gives horrible results; it's almost impossible to click on the right place, and drag-and-drop is very hard to achieve. Any suggestions how to improve these flags?

4. Does anybody have better solution to ig4 problem? Update: deprecated question. I missed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238037.

[marc.priggemeyer_gmail.com]

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

Many thanks for your efforts! My laptop: Asus Zenbook 14 UX410UFR with 12.0-RELEASE. After kldload ig4 iic acpi_iichid the device works after being probed with i2c -v -s -f /dev/iic1 (thanks fbsd_opal.com). My /var/log/messages:

Could you post the full output of the i2c -v -s -f /dev/iic1 command? I just checked the implementation and i2c either uses START/STOP or reads a byte to perform a scan per address. On my laptop (using ig4), I get the following output and I think it looks similar on yours.

dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
Hardware may not support START/STOP scanning; trying less-reliable read method.
Scanning I2C devices on /dev/iic1: 2c

Since ig4 does not implement iicbus_start and iicbus_stop functions, it issues a write on the bus. Question is: does running i2c trigger an event (that results in the touchpad working again) on the device itself or within ig4.
Possibility 1: Controller reset helps.
I2CRSTCARD is issued to the iicbus driver.

Possibility 2: Testing if START/STOP works will trigger said event (thats basically the same as possibility 1 with another configuration if iicbus_start is not implemented)
Within iicioctl() the I2CSTART command issues iicbus_request_bus and iicbus_release_bus once iicbus_start returned an error.

Possibility 3: reading from the device helps
I2CRDWR is issued and reads one byte from the devices address.

I would like to ask you to test all of them (suspend does not work on my computer):
You can download the attached file {F4862417}and just compile it cc main.cpp, afterwards run the program a.out with the path to the iic device (e.g. /dev/iic1) as the first parameter, the test to run as the second parameter (decimal) and the address of your touchpad on the i2c bus as the third parameter (hex), so basically something like this (given your dmesg output indicates the address of you touchpad is 0x15 and it's located on iicbus1):

#test 1: reset controller (I2CRSTCARD)
./a.out /dev/iic1 1 0x15

#test 2: issue start and stop conditions (I2CSTART)
./a.out /dev/iic1 2 0x15

#test 3: issue a read of 1 byte (I2CRDWR)
./a.out /dev/iic1 3 0x15

#scan (just like i2c -v -l -f /dev/iic1)
./a.out /dev/iic1 0 0x15

So after resume, when your touchpad does not work, run the above commands in that order and verify in between if the touchpad works again.

sys/dev/iicbus/input/iichid.c

2

I took some code form sys/dev/usb/input/ums.c that handles the HID reports, how to take that into account?

[nikola.lecic_anthesphoria.net]

In D16698#454685, @marc.priggemeyer_gmail.com wrote:

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

Many thanks for your efforts! My laptop: Asus Zenbook 14 UX410UFR with 12.0-RELEASE. After kldload ig4 iic acpi_iichid the device works after being probed with i2c -v -s -f /dev/iic1 (thanks fbsd_opal.com). My /var/log/messages:

Could you post the full output of the i2c -v -s -f /dev/iic1 command? I just checked the implementation and i2c either uses START/STOP or reads a byte to perform a scan per address. On my laptop (using ig4), I get the following output and I think it looks similar on yours.

dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
Hardware may not support START/STOP scanning; trying less-reliable read method.
Scanning I2C devices on /dev/iic1: 2c

Here it is:

# i2c -v -s -f /dev/iic1
dev: /dev/iic1, addr: 0x0, r/w: r, offset: 0x00, width: 8, count: 1
Hardware may not support START/STOP scanning; trying less-reliable read method.
Scanning I2C devices on /dev/iic1: 15 77

Since ig4 does not implement iicbus_start and iicbus_stop functions, it issues a write on the bus. Question is: does running i2c trigger an event (that results in the touchpad working again) on the device itself or within ig4.
Possibility 1: Controller reset helps.
I2CRSTCARD is issued to the iicbus driver.

Possibility 2: Testing if START/STOP works will trigger said event (thats basically the same as possibility 1 with another configuration if iicbus_start is not implemented)
Within iicioctl() the I2CSTART command issues iicbus_request_bus and iicbus_release_bus once iicbus_start returned an error.

Possibility 3: reading from the device helps
I2CRDWR is issued and reads one byte from the devices address.

I would like to ask you to test all of them (suspend does not work on my computer):
You can download the attached file {F4862417}and just compile it cc main.cpp, afterwards run the program a.out with the path to the iic device (e.g. /dev/iic1) as the first parameter, the test to run as the second parameter (decimal) and the address of your touchpad on the i2c bus as the third parameter (hex), so basically something like this (given your dmesg output indicates the address of you touchpad is 0x15 and it's located on iicbus1):

#test 1: reset controller (I2CRSTCARD)
./a.out /dev/iic1 1 0x15

#test 2: issue start and stop conditions (I2CSTART)
./a.out /dev/iic1 2 0x15

#test 3: issue a read of 1 byte (I2CRDWR)
./a.out /dev/iic1 3 0x15
#scan (just like i2c -v -l -f /dev/iic1)
./a.out /dev/iic1 0 0x15

So after resume, when your touchpad does not work, run the above commands in that order and verify in between if the touchpad works again.

The touchpad needs scan to start working not just after resume, but on boot as well (after loading all necessary modules). Here is the output. Suspend done, with ig4 kldunload'ed. Resumed. kldload ig4 by hand. Touchpad doesn't work, any movement produces

Jul 16 19:34:56 thorium kernel: iichid0: no data received

The a.out output:

# ./a.out /dev/iic1 1 0x15
reset returned 0
test finished
# ./a.out /dev/iic1 2 0x15
I2CSTART failed, will not I2CSTOP (-1)
test finished
# ./a.out /dev/iic1 3 0x15
read: 0x0
test finished

At this moment, after third test, touchpad is working again.

# ./a.out /dev/iic1 0 0x15
.................... 0x15 ................................................................................................. 0x77  0x78 ......
#

And please tell me if it's possible at all at this moment to get this touchpad behave like a normal touchpad? Some people reported that synaptics driver does some job for them, but not in my case. In other words -- is there any xorg driver for it, or we are doomed to moused and it's crude functionality for now?

[nikola.lecic_anthesphoria.net]

... please note that I edited my last post; touchpad is working again after test #3.

[val_packett.cool]

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

1. I compiled this driver with EVDEV support (https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092). How can I make use of it? I see no difference with and without this patch.

If there's a new device in /dev/input, it is working. You can run libinput debug-events to see the input events. To consume evdev devices from xorg, use xf86-input-libinput. There were patches for autodetection (one adding evdev autodetection to the devd backend, another switching to the udev backend with libudev-devd). The devd one might have been merged?? (I don't follow Xorg, I use Wayland exclusively)

[nikola.lecic_anthesphoria.net]

In D16698#454859, @greg_unrelenting.technology wrote:

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

1. I compiled this driver with EVDEV support (https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092). How can I make use of it? I see no difference with and without this patch.

If there's a new device in /dev/input, it is working. You can run libinput debug-events to see the input events. To consume evdev devices from xorg, use xf86-input-libinput. There were patches for autodetection (one adding evdev autodetection to the devd backend, another switching to the udev backend with libudev-devd). The devd one might have been merged?? (I don't follow Xorg, I use Wayland exclusively)

Thanks; I thought that kldload evdev was enough; but kernel with EVDEV_SUPPORT was needed. Now I have /dev/input, but two-finger tapping, two-finger scrolling etc. still don't generate any events. And, obviously, the device is recognized as a mouse. Does anyone have ideas/knowledge about the cause of this situation? Is it possible to get full touchpad functionality with this hardware? In details:

# sysctl -a | grep evdev
kern.features.evdev_support: 1
kern.features.evdev: 1
device  evdev
kern.evdev.sysmouse_t_axis: 1
kern.evdev.rcpt_mask: 12

(last two parameters changed by me; with rcpt_mask=24 mouse touchpad doesn't work under xorg).

% libinput debug-events
-event0   DEVICE_ADDED     System keyboard multiplexer       seat0 default group1  cap:k
-event1   DEVICE_ADDED     System mouse                      seat0 default group2  cap:p left scroll-nat scroll-button
-event2   DEVICE_ADDED     AT keyboard                       seat0 default group3  cap:k
-event3   DEVICE_ADDED     HID over I2C                      seat0 default group4  cap:p left scroll-nat scroll-button
...

and

# libinput list-devices
Device:           System keyboard multiplexer
Kernel:           /dev/input/event0
[...]

Device:           System mouse
Kernel:           /dev/input/event1
[...]

Device:           AT keyboard
Kernel:           /dev/input/event2
[...]

Device:           HID over I2C
Kernel:           /dev/input/event3
Group:            4
Seat:             seat0, default
Capabilities:     pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   button
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   flat *adaptive
Rotation:         n/a

However, only movements and simple clicks generate events. Anyway, I added this to xorg.conf:

Section "InputDevice"
    Identifier      "Touchpad1"
    Driver          "libinput"
    Option          "Device" "/dev/input/event3"
    Option          "Tapping" "on"
    Option "ClickMethod" "clickfinger"
    Option "NaturalScrolling" "true"
    Option "ScrollMethod" "twofinger"
EndSection

From Xorg.0.log:

[ 10809.080] (II) Using input driver 'libinput' for 'Touchpad1'
[ 10809.080] (**) Option "CorePointer"
[ 10809.080] (**) Touchpad1: always reports core events
[ 10809.080] (**) Option "Device" "/dev/input/event3"
[ 10809.081] (II) event3  - HID over I2C: is tagged by udev as: Mouse
[ 10809.082] (II) event3  - HID over I2C: device is a pointer
[ 10809.082] (II) event3  - HID over I2C: device removed
[ 10809.082] (**) Option "NaturalScrolling" "true"
[ 10809.082] (**) Option "ScrollMethod" "twofinger"
[ 10809.082] (II) XINPUT: Adding extended input device "Touchpad1" (type: MOUSE, id 7)
[ 10809.082] (EE) libinput: Touchpad1: Failed to set scroll to twofinger
[ 10809.082] (**) Option "AccelerationScheme" "none"
[ 10809.082] (**) Touchpad1: (accel) selected scheme none/0
[ 10809.082] (**) Touchpad1: (accel) acceleration factor: 2.000
[ 10809.082] (**) Touchpad1: (accel) acceleration threshold: 4
[ 10809.082] (II) event3  - HID over I2C: is tagged by udev as: Mouse
[ 10809.082] (II) event3  - HID over I2C: device is a pointer
[ 10809.082] (EE) libinput: Touchpad1: Failed to set scroll to twofinger

[val_packett.cool]

In D16698#455093, @nikola.lecic_anthesphoria.net wrote:

In D16698#454859, @greg_unrelenting.technology wrote:

In D16698#454202, @nikola.lecic_anthesphoria.net wrote:

1. I compiled this driver with EVDEV support (https://gist.github.com/johalun/3c67a678e740b82512cec52bfe926092). How can I make use of it? I see no difference with and without this patch.

If there's a new device in /dev/input, it is working. You can run libinput debug-events to see the input events. To consume evdev devices from xorg, use xf86-input-libinput. There were patches for autodetection (one adding evdev autodetection to the devd backend, another switching to the udev backend with libudev-devd). The devd one might have been merged?? (I don't follow Xorg, I use Wayland exclusively)

Thanks; I thought that kldload evdev was enough; but kernel with EVDEV_SUPPORT was needed.

hm. EVDEV_SUPPORT enables evdev in "legacy" drivers like psm, ums, ukbd etc. I'm not sure why @johalun added ifdefs for that here, this is a new driver :)

Now I have /dev/input, but two-finger tapping, two-finger scrolling etc. still don't generate any events. And, obviously, the device is recognized as a mouse. Does anyone have ideas/knowledge about the cause of this situation? Is it possible to get full touchpad functionality with this hardware? In details:

It's possible, just not done — looks like the patch is called "… (Mouse only)" for a reason.

What these touchpads use for actual touchpad functionality over HID is (most likely) the Microsoft Precision protocol.

We have the wmt driver but right now it's *touchscreen*-only and (of course) USB-only.

[nikola.lecic_anthesphoria.net]

In D16698#455200, @greg_unrelenting.technology wrote:

hm. EVDEV_SUPPORT enables evdev in "legacy" drivers like psm, ums, ukbd etc. I'm not sure why @johalun added ifdefs for that here, this is a new driver :)

Well, without EVDEV_SUPPORT enabled kernel there is no /dev/input. And libinput driver obviously communicates with this touchpad.

It's possible, just not done — looks like the patch is called "… (Mouse only)" for a reason.

What these touchpads use for actual touchpad functionality over HID is (most likely) the Microsoft Precision protocol.

We have the wmt driver but right now it's *touchscreen*-only and (of course) USB-only.

I see. Sigh. Anyway, some people from this thread reported that two finger scrolling *does* work, including @johalun himself in his announcement:

If I do two finger horizontal scroll I don't get any event callbacks at all while I do for vertical. Could this be something that has to be enabled by sending some command to the device?

[johalun]

hm. EVDEV_SUPPORT enables evdev in "legacy" drivers like psm, ums, ukbd etc. I'm not sure why @johalun added ifdefs for that here, this is a new driver :)

EVDEV is still optional and the driver won't compile without the #ifdefs if it's not enabled. Just recently I think it has been enabled by default.

[nikola.lecic_anthesphoria.net]

In D16698#455259, @johalun wrote:

EVDEV is still optional and the driver won't compile without the #ifdefs if it's not enabled. Just recently I think it has been enabled by default.

@johalun, would you be kind to scroll three posts up and give your verdict about Asus Zenbook 14's touchpad? I posted a lot of output there. Is iichid driver with your evdev patch capable of making it fully functional touchpad, or I'm doomed to simple mouse functionality for now? It would be nice to have at least two finger scrolling; you mentioned earlier that it's possible.

[wulf]

In D16698#455200, @greg_unrelenting.technology wrote:

We have the wmt driver but right now it's *touchscreen*-only and (of course) USB-only.

I have half-completed (it is working for me!) WIP port of wmt for i2c bus https://github.com/wulf7/iichid.
It is relatively easy (~20-30 LOC) to add support for MS-precision protocol touchpads to it but according to some docs enclosed with Darwin driver https://github.com/alexandred/VoodooI2C/blob/master/Documentation/Satellites.md it wont help as many models of touchpads uses proprietary protocol in absolute mode.

[wulf]

In D16698#455238, @nikola.lecic_anthesphoria.net wrote:

I see. Sigh. Anyway, some people from this thread reported that two finger scrolling *does* work, including @johalun himself in his announcement:

If I do two finger horizontal scroll I don't get any event callbacks at all while I do for vertical. Could this be something that has to be enabled by sending some command to the device?

This driver like ums supports only relative mouse protocol. So it is up to touchpad firmware to support any gestures. OS driver or userland applications just do not have enough information as finger coords or count to support doublefinger scroll or multifinger taps.

[wulf]

OS driver or userland applications just do not have enough information as finger coords or count to support doublefinger scroll or multifinger taps.

I wrote a simple util to dump report descriptor from I2C HID device

fetchdesc.c3 KBDownload

.
It accepts 3 input parameters: iic device path, i2c bus address and i2c HID register and prints report descriptor of given I2C device on stdout. This report descriptor can be further analyzed with any tool (e.g. web-based http://eleccelerator.com/usbdescreqparser/) to examine HID device capabilities.

[nikola.lecic_anthesphoria.net]

In D16698#455403, @wulf wrote:

OS driver or userland applications just do not have enough information as finger coords or count to support doublefinger scroll or multifinger taps.

I wrote a simple util to dump report descriptor from I2C HID device

fetchdesc.c3 KBDownload

.
It accepts 3 input parameters: iic device path, i2c bus address and i2c HID register and prints report descriptor of given I2C device on stdout. This report descriptor can be further analyzed with any tool (e.g. web-based http://eleccelerator.com/usbdescreqparser/) to examine HID device capabilities.

Great! In my case (Asus Zenbook 14):

# ./fetchdesc /dev/iic1 0x15 1
HID descriptor:

wHIDDescLength:      30
bcdVersion:          0x0100
wReportDescLength:   356
wReportDescRegister: 0x0002
wInputRegister:      0x0003
wMaxInputLength:     16
wOutputRegister:     0x0004
wMaxOutputLength:    0
wCommandRegister:    0x0005
wDataRegister:       0x0006
wVendorID:           0x04f3
wProductID:          0x309c
wVersionID:          0x0001

Report descriptor:

05 01 09 02 A1 01 85 01  09 01 A1 00 05 09 19 01  
29 02 15 00 25 01 75 01  95 02 81 02 95 06 81 03  
05 01 09 30 09 31 09 38  15 81 25 7F 75 08 95 03  
81 06 05 0C 0A 38 02 95  01 81 06 75 08 95 03 81  
03 C0 C0 05 0D 09 05 A1  01 85 04 09 22 A1 02 15  
00 25 01 09 47 09 42 95  02 75 01 81 02 75 01 95  
02 81 03 95 01 75 04 25  0F 09 51 81 02 05 01 15  
00 26 80 0C 75 10 55 0E  65 13 09 30 35 00 46 90  
01 95 01 81 02 46 13 01  26 96 08 26 96 08 09 31  
81 02 05 0D 15 00 25 64  95 03 C0 55 0C 66 01 10  
47 FF FF 00 00 27 FF FF  00 00 75 10 95 01 09 56  
81 02 09 54 25 7F 95 01  75 08 81 02 05 09 09 01  
25 01 75 01 95 01 81 02  95 07 81 03 09 C5 75 08  
95 04 81 03 05 0D 85 02  09 55 09 59 75 04 95 02  
25 0F B1 02 85 07 09 60  75 01 95 01 15 00 25 01  
B1 02 95 0F B1 03 06 00  FF 06 00 FF 85 06 09 C5  
15 00 26 FF 00 75 08 96  00 01 B1 02 85 0D 09 C4  
15 00 26 FF 00 75 08 95  04 B1 02 85 0C 09 C6 96  
8A 02 75 08 B1 02 85 0B  09 C7 95 80 75 08 B1 02  
C0 05 0D 09 0E A1 01 85  03 09 22 A1 00 09 52 15  
00 25 0A 75 10 95 01 B1  02 C0 09 22 A1 00 85 05  
09 57 09 58 15 00 75 01  95 02 25 03 B1 02 95 0E  
B1 03 C0 C0

Parsed:

0x05, 0x01,        // Usage Page (Generic Desktop Ctrls)
0x09, 0x02,        // Usage (Mouse)
0xA1, 0x01,        // Collection (Application)
0x85, 0x01,        //   Report ID (1)
0x09, 0x01,        //   Usage (Pointer)
0xA1, 0x00,        //   Collection (Physical)
0x05, 0x09,        //     Usage Page (Button)
0x19, 0x01,        //     Usage Minimum (0x01)
0x29, 0x02,        //     Usage Maximum (0x02)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x01,        //     Logical Maximum (1)
0x75, 0x01,        //     Report Size (1)
0x95, 0x02,        //     Report Count (2)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x06,        //     Report Count (6)
0x81, 0x03,        //     Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x01,        //     Usage Page (Generic Desktop Ctrls)
0x09, 0x30,        //     Usage (X)
0x09, 0x31,        //     Usage (Y)
0x09, 0x38,        //     Usage (Wheel)
0x15, 0x81,        //     Logical Minimum (-127)
0x25, 0x7F,        //     Logical Maximum (127)
0x75, 0x08,        //     Report Size (8)
0x95, 0x03,        //     Report Count (3)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x0C,        //     Usage Page (Consumer)
0x0A, 0x38, 0x02,  //     Usage (AC Pan)
0x95, 0x01,        //     Report Count (1)
0x81, 0x06,        //     Input (Data,Var,Rel,No Wrap,Linear,Preferred State,No Null Position)
0x75, 0x08,        //     Report Size (8)
0x95, 0x03,        //     Report Count (3)
0x81, 0x03,        //     Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0xC0,              //   End Collection
0xC0,              // End Collection
0x05, 0x0D,        // Usage Page (Digitizer)
0x09, 0x05,        // Usage (Touch Pad)
0xA1, 0x01,        // Collection (Application)
0x85, 0x04,        //   Report ID (4)
0x09, 0x22,        //   Usage (Finger)
0xA1, 0x02,        //   Collection (Logical)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x01,        //     Logical Maximum (1)
0x09, 0x47,        //     Usage (0x47)
0x09, 0x42,        //     Usage (Tip Switch)
0x95, 0x02,        //     Report Count (2)
0x75, 0x01,        //     Report Size (1)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x75, 0x01,        //     Report Size (1)
0x95, 0x02,        //     Report Count (2)
0x81, 0x03,        //     Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x01,        //     Report Count (1)
0x75, 0x04,        //     Report Size (4)
0x25, 0x0F,        //     Logical Maximum (15)
0x09, 0x51,        //     Usage (0x51)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x01,        //     Usage Page (Generic Desktop Ctrls)
0x15, 0x00,        //     Logical Minimum (0)
0x26, 0x80, 0x0C,  //     Logical Maximum (3200)
0x75, 0x10,        //     Report Size (16)
0x55, 0x0E,        //     Unit Exponent (-2)
0x65, 0x13,        //     Unit (System: English Linear, Length: Centimeter)
0x09, 0x30,        //     Usage (X)
0x35, 0x00,        //     Physical Minimum (0)
0x46, 0x90, 0x01,  //     Physical Maximum (400)
0x95, 0x01,        //     Report Count (1)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x46, 0x13, 0x01,  //     Physical Maximum (275)
0x26, 0x96, 0x08,  //     Logical Maximum (2198)
0x26, 0x96, 0x08,  //     Logical Maximum (2198)
0x09, 0x31,        //     Usage (Y)
0x81, 0x02,        //     Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x0D,        //     Usage Page (Digitizer)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x64,        //     Logical Maximum (100)
0x95, 0x03,        //     Report Count (3)
0xC0,              //   End Collection
0x55, 0x0C,        //   Unit Exponent (-4)
0x66, 0x01, 0x10,  //   Unit (System: SI Linear, Time: Seconds)
0x47, 0xFF, 0xFF, 0x00, 0x00,  //   Physical Maximum (65534)
0x27, 0xFF, 0xFF, 0x00, 0x00,  //   Logical Maximum (65534)
0x75, 0x10,        //   Report Size (16)
0x95, 0x01,        //   Report Count (1)
0x09, 0x56,        //   Usage (0x56)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x09, 0x54,        //   Usage (0x54)
0x25, 0x7F,        //   Logical Maximum (127)
0x95, 0x01,        //   Report Count (1)
0x75, 0x08,        //   Report Size (8)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x09,        //   Usage Page (Button)
0x09, 0x01,        //   Usage (0x01)
0x25, 0x01,        //   Logical Maximum (1)
0x75, 0x01,        //   Report Size (1)
0x95, 0x01,        //   Report Count (1)
0x81, 0x02,        //   Input (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x95, 0x07,        //   Report Count (7)
0x81, 0x03,        //   Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x09, 0xC5,        //   Usage (0xC5)
0x75, 0x08,        //   Report Size (8)
0x95, 0x04,        //   Report Count (4)
0x81, 0x03,        //   Input (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position)
0x05, 0x0D,        //   Usage Page (Digitizer)
0x85, 0x02,        //   Report ID (2)
0x09, 0x55,        //   Usage (0x55)
0x09, 0x59,        //   Usage (0x59)
0x75, 0x04,        //   Report Size (4)
0x95, 0x02,        //   Report Count (2)
0x25, 0x0F,        //   Logical Maximum (15)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x85, 0x07,        //   Report ID (7)
0x09, 0x60,        //   Usage (0x60)
0x75, 0x01,        //   Report Size (1)
0x95, 0x01,        //   Report Count (1)
0x15, 0x00,        //   Logical Minimum (0)
0x25, 0x01,        //   Logical Maximum (1)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x95, 0x0F,        //   Report Count (15)
0xB1, 0x03,        //   Feature (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x06, 0x00, 0xFF,  //   Usage Page (Vendor Defined 0xFF00)
0x06, 0x00, 0xFF,  //   Usage Page (Vendor Defined 0xFF00)
0x85, 0x06,        //   Report ID (6)
0x09, 0xC5,        //   Usage (0xC5)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x96, 0x00, 0x01,  //   Report Count (256)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x85, 0x0D,        //   Report ID (13)
0x09, 0xC4,        //   Usage (0xC4)
0x15, 0x00,        //   Logical Minimum (0)
0x26, 0xFF, 0x00,  //   Logical Maximum (255)
0x75, 0x08,        //   Report Size (8)
0x95, 0x04,        //   Report Count (4)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x85, 0x0C,        //   Report ID (12)
0x09, 0xC6,        //   Usage (0xC6)
0x96, 0x8A, 0x02,  //   Report Count (650)
0x75, 0x08,        //   Report Size (8)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x85, 0x0B,        //   Report ID (11)
0x09, 0xC7,        //   Usage (0xC7)
0x95, 0x80,        //   Report Count (-128)
0x75, 0x08,        //   Report Size (8)
0xB1, 0x02,        //   Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0xC0,              // End Collection
0x05, 0x0D,        // Usage Page (Digitizer)
0x09, 0x0E,        // Usage (0x0E)
0xA1, 0x01,        // Collection (Application)
0x85, 0x03,        //   Report ID (3)
0x09, 0x22,        //   Usage (Finger)
0xA1, 0x00,        //   Collection (Physical)
0x09, 0x52,        //     Usage (0x52)
0x15, 0x00,        //     Logical Minimum (0)
0x25, 0x0A,        //     Logical Maximum (10)
0x75, 0x10,        //     Report Size (16)
0x95, 0x01,        //     Report Count (1)
0xB1, 0x02,        //     Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0xC0,              //   End Collection
0x09, 0x22,        //   Usage (Finger)
0xA1, 0x00,        //   Collection (Physical)
0x85, 0x05,        //     Report ID (5)
0x09, 0x57,        //     Usage (0x57)
0x09, 0x58,        //     Usage (0x58)
0x15, 0x00,        //     Logical Minimum (0)
0x75, 0x01,        //     Report Size (1)
0x95, 0x02,        //     Report Count (2)
0x25, 0x03,        //     Logical Maximum (3)
0xB1, 0x02,        //     Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0x95, 0x0E,        //     Report Count (14)
0xB1, 0x03,        //     Feature (Const,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
0xC0,              //   End Collection
0xC0,              // End Collection

// 356 bytes

[nikola.lecic_anthesphoria.net]

In D16698#455371, @wulf wrote:

In D16698#455200, @greg_unrelenting.technology wrote:

We have the wmt driver but right now it's *touchscreen*-only and (of course) USB-only.

I have half-completed (it is working for me!) WIP port of wmt for i2c bus https://github.com/wulf7/iichid.

@wulf, please explain how to test this driver. Should I just compile new iichid.ko (running make in the input directory), leaving all other modules built from the source of this thread? Should I remove evdev support from the kernel? Can you please share your xorg configuration?

[wulf]

In D16698#455438, @nikola.lecic_anthesphoria.net wrote:

Parsed:

0x05, 0x0D,        // Usage Page (Digitizer)
0x09, 0x05,        // Usage (Touch Pad)
0xA1, 0x01,        // Collection (Application)
0x85, 0x04,        //   Report ID (4)
0x09, 0x22,        //   Usage (Finger)
0xA1, 0x02,        //   Collection (Logical)

It looks like multitouch HID report descriptor.
I am not sure if your touchpad sends such reports out of box.
You can uncomment line 609 from iichid.c

//      device_printf(sc->dev, "id: %d\n", id);

and than look at ids it printfing.
For your touchpad "1" means relative mouse report and "4" means absolute touchpad report
"4" is required for "MS precission touchpad" to work

[wulf]

In D16698#455451, @nikola.lecic_anthesphoria.net wrote:

@wulf, please explain how to test this driver. Should I just compile new iichid.ko (running make in the input directory),

just unpack it at your $HOME. Than

make && sudo kldload ./iichid.ko

leaving all other modules built from the source of this thread?

drivers from this review should be at least unloaded from kernel. There is no need to revert D16698 patch. Just don't try to kldload both modules in between reboots.

Should I remove evdev support from the kernel?

No need. It links with evdev unconditionally

Can you please share your xorg configuration?

I do not have any specific xorg.conf options. Any evdev-awared autoconfiguration backend should work out of box. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 for example.

[nikola.lecic_anthesphoria.net]

In D16698#455669, @wulf wrote:

In D16698#455451, @nikola.lecic_anthesphoria.net wrote:

@wulf, please explain how to test this driver. Should I just compile new iichid.ko (running make in the input directory),

just unpack it at your $HOME. Than

make && sudo kldload ./iichid.ko

[...]

@wulf, thanks! Ok, after kldloading new iichid.ko (with just ig4 already loaded) I got this:

Jul 20 16:15:25 thorium kernel: acpi_iichid0: <HID over I2C (ACPI)> irq 109 on acpi0
Jul 20 16:15:25 thorium kernel: imt0:   ACPI Hardware ID  : ELAN1200
Jul 20 16:15:25 thorium kernel: imt0:   IICbus addr       : 0x15
Jul 20 16:15:25 thorium kernel: imt0:   HID descriptor reg: 0x01
Jul 20 16:15:25 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(0)
Jul 20 16:15:25 thorium kernel: imt0: HID command I2C_HID_CMD_RESET
Jul 20 16:15:25 thorium kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 356
Jul 20 16:15:25 thorium kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 05 0c 0a 38 02 95 01 81 06 75 08 95 03 81 03 c0 c0 05 0d 09 05 a1 01 85 04 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 75 01 95 02 81 03 95 01 75 04 25 0f 09 51 81 02 05 01 15 00 26 80 0c 75 10 55 0e 65 13 09 30 35 00 46 90 01 95 01 81 02 46 13 01 26 96 08 26 96 08 09 31 81 02 05 0d 15 00 25 64 95 03 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09 09 01 25 01 75 01 95 01 81 02 95 07 81 03 09 c5 75 08 95 04 81 03 05 0d 85 02 09 55 09 59 75 04 95 02 25 0f b1 02 85 07 09 60 75 01 95 01 15 00 25 01 b1 02 95 0f b1 03 06 00 ff 06 00 ff 85 06 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 85 0d 09 c4 15 00 26 ff 00 75 08 95 04 b1 02 85 0c 09 c6 96 8a 02 75 08 b1 02 85 0b 09 c7 95 80 75 08 b1 02 c0 05 0d 09 0e a1 01 85 03 09 22 a1 00 09 52 15 00 25 0a 75 10 95 01 b1 02 c0 09 22 a1 00 85 05 09 57 09 58 15 00 75 01 95 02 25 03 b1 02 95 0e b1 03 c0 c0
Jul 20 16:15:25 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)
Jul 20 16:15:25 thorium kernel: iicbus1: <unknown card> at addr 0x15

Unlike with previous driver, I don't see /dev/input/event3 (HID over IIC) anymore. Just this:

Device:           System mouse
Kernel:           /dev/input/event1
Group:            2
Seat:             seat0, default
Capabilities:     pointer 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      n/a
Scroll methods:   button
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   flat *adaptive
Rotation:         n/a

You can uncomment line 609 from iichid.c

//      device_printf(sc->dev, "id: %d\n", id);

and than look at ids it printfing.
For your touchpad "1" means relative mouse report and "4" means absolute touchpad report
"4" is required for "MS precission touchpad" to work

Hm, I don't see such a line anywhere.

Any evdev-awared autoconfiguration backend should work out of box.

Sorry for my xorg illiteracy, but I couldn't get touchpad working after kldload ./iichid.ko in any way... :(

How to proceed? New iichid.ko dmesg looks promising, I'd say. :)

[wulf]

In D16698#455794, @nikola.lecic_anthesphoria.net wrote:

Unlike with previous driver, I don't see /dev/input/event3 (HID over IIC) anymore.

That is expected as it ignored any touchpads

I added some basic touchpad support (surface touches only, no buttons) so you can try it again
Unfortunately, it is untested.

[nikola.lecic_anthesphoria.net]

In D16698#455907, @wulf wrote:

In D16698#455794, @nikola.lecic_anthesphoria.net wrote:

Unlike with previous driver, I don't see /dev/input/event3 (HID over IIC) anymore.

That is expected as it ignored any touchpads

I added some basic touchpad support (surface touches only, no buttons) so you can try it again
Unfortunately, it is untested.

Great, it's now seen as a touchpad; its capabilities detected. Here are my new dmesg/logs etc. The only problem -- the device is still dead; it generates nothing with libinput debug-events, and no events in xev.

Jul 21 16:03:55 thorium kernel: acpi_iichid0: <HID over I2C (ACPI)> on acpi0
Jul 21 16:03:55 thorium kernel: imt0:   ACPI Hardware ID  : ELAN1200
Jul 21 16:03:55 thorium kernel: imt0:   IICbus addr       : 0x15
Jul 21 16:03:55 thorium kernel: imt0:   HID descriptor reg: 0x01
Jul 21 16:03:55 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(0)
Jul 21 16:03:55 thorium kernel: imt0: HID command I2C_HID_CMD_RESET
Jul 21 16:03:55 thorium kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 356
Jul 21 16:03:55 thorium kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 05 0c 0a 38 02 95 01 81 06 75 08 95 03 81 03 c0 c0 05 0d 09 05 a1 01 85 04 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 75 01 95 02 81 03 95 01 75 04 25 0f 09 51 81 02 05 01 15 00 26 80 0c 75 10 55 0e 65 13 09 30 35 00 46 90 01 95 01 81 02 46 13 01 26 96 08 26 96 08 09 31 81 02 05 0d 15 00 25 64 95 03 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09 09 01 25 01 75 01 95 01 81 02 95 07 81 03 09 c5 75 08 95 04 81 03 05 0d 85 02 09 55 09 59 75 04 95 02 25 0f b1 02 85 07 09 60 75 01 95 01 15 00 25 01 b1 02 95 0f b1 03 06 00 ff 06 00 ff 85 06 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 85 0d 09 c4 15 00 26 ff 00 75 08 95 04 b1 02 85 0c 09 c6 96 8a 02 75 08 b1 02 85 0b 09 c7 95 80 75 08 b1 02 c0 05 0d 09 0e a1 01 85 03 09 22 a1 00 09 52 15 00 25 0a 75 10 95 01 b1 02 c0 09 22 a1 00 85 05 09 57 09 58 15 00 75 01 95 02 25 03 b1 02 95 0e b1 03 c0 c0
Jul 21 16:03:55 thorium kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 356
Jul 21 16:03:55 thorium kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 05 0c 0a 38 02 95 01 81 06 75 08 95 03 81 03 c0 c0 05 0d 09 05 a1 01 85 04 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 75 01 95 02 81 03 95 01 75 04 25 0f 09 51 81 02 05 01 15 00 26 80 0c 75 10 55 0e 65 13 09 30 35 00 46 90 01 95 01 81 02 46 13 01 26 96 08 26 96 08 09 31 81 02 05 0d 15 00 25 64 95 03 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09 09 01 25 01 75 01 95 01 81 02 95 07 81 03 09 c5 75 08 95 04 81 03 05 0d 85 02 09 55 09 59 75 04 95 02 25 0f b1 02 85 07 09 60 75 01 95 01 15 00 25 01 b1 02 95 0f b1 03 06 00 ff 06 00 ff 85 06 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 85 0d 09 c4 15 00 26 ff 00 75 08 95 04 b1 02 85 0c 09 c6 96 8a 02 75 08 b1 02 85 0b 09 c7 95 80 75 08 b1 02 c0 05 0d 09 0e a1 01 85 03 09 22 a1 00 09 52 15 00 25 0a 75 10 95 01 b1 02 c0 09 22 a1 00 85 05 09 57 09 58 15 00 75 01 95 02 25 03 b1 02 95 0e b1 03 c0 c0
Jul 21 16:03:55 thorium kernel: imt0: <ELAN1200> at addr 0x15 irq 109 on iicbus1
Jul 21 16:03:55 thorium kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 356
Jul 21 16:03:55 thorium kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 05 0c 0a 38 02 95 01 81 06 75 08 95 03 81 03 c0 c0 05 0d 09 05 a1 01 85 04 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 75 01 95 02 81 03 95 01 75 04 25 0f 09 51 81 02 05 01 15 00 26 80 0c 75 10 55 0e 65 13 09 30 35 00 46 90 01 95 01 81 02 46 13 01 26 96 08 26 96 08 09 31 81 02 05 0d 15 00 25 64 95 03 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09 09 01 25 01 75 01 95 01 81 02 95 07 81 03 09 c5 75 08 95 04 81 03 05 0d 85 02 09 55 09 59 75 04 95 02 25 0f b1 02 85 07 09 60 75 01 95 01 15 00 25 01 b1 02 95 0f b1 03 06 00 ff 06 00 ff 85 06 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 85 0d 09 c4 15 00 26 ff 00 75 08 95 04 b1 02 85 0c 09 c6 96 8a 02 75 08 b1 02 85 0b 09 c7 95 80 75 08 b1 02 c0 05 0d 09 0e a1 01 85 03 09 22 a1 00 09 52 15 00 25 0a 75 10 95 01 b1 02 c0 09 22 a1 00 85 05 09 57 09 58 15 00 75 01 95 02 25 03 b1 02 95 0e b1 03 c0 c0
Jul 21 16:03:55 thorium kernel: imt0: 15 contacts and [C]. Report range [0:0] - [3200:2198]
Jul 21 16:03:55 thorium kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 2 (type 3, len 1)
Jul 21 16:03:55 thorium kernel: imt0: response: 04 00 02 05
Jul 21 16:03:55 thorium kernel: imt0: 5 feature report contactsimt0: HID command I2C_HID_CMD_GET_REPORT 6 (type 3, len 256)
Jul 21 16:03:55 thorium kernel: imt0: response: 03 01 06 fc 28 fe 84 40 cb 9a 87 0d be 57 3c b6 70 09 88 07 97 2d 2b e3 38 34 b6 6c ed b0 f7 e5 9c f6 c2 2e 84 1b e8 b4 51 78 43 1f 28 4b 7c 2d 53 af fc 47 70 1b 59 6f 74 43 c4 f3 47 18 53 1a a2 a1 71 c7 95 0e 31 55 21 d3 b5 1e e9 0c ba ec b8 89 19 3e b3 af 75 81 9d 53 b9 41 57 f4 6d 39 25 29 7c 87 d9 b4 98 45 7d a7 26 9c 65 3b 85 68 89 d7 3b bd ff 14 67 f2 2b f0 2a 41 54 f0 fd 2c 66 7c f8 c0 8f 33 13 03 f1 d3 c1 0b 89 d9 1b 62 cd 51 b7 80 b8 af 3a 10 c1 8a 5b e8 8a 56 f0 8c aa fa 35 e9 42 c4 d8 55 c3 38 cc 2b 53 5c 69 52 d5 c8 73 02 38 7c 73 b6 41 e7 ff 05 d8 2b 79 9a e2 34 60 8f a3 32 1f 09 78 62 bc 80 e3 0f bd 65 20 08 13 c1 e2 ee 53 2d 86 7e a7 5a c5 d3 7d 98 be 31 48 1f fb da af a2 a8 6a 89 d6 bf f2 d3 32 2a 9a e4 cf 17 b7 b8 f4 e1 33 08 24 8b c4 43 a5 e5 24 c2
Jul 21 16:03:55 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)
Jul 21 16:03:55 thorium kernel: imt0: IRQ allocation failed. Fallback to sampling.
...
Jul 21 16:06:11 thorium kernel: imt0: iichid device open
Jul 21 16:06:11 thorium kernel: imt0: imt0: HID command I2C_HID_CMD_SET_POWER(0)
Jul 21 16:06:11 thorium kernel: iichid device close
Jul 21 16:06:11 thorium kernel: imt0: iichid device open
Jul 21 16:06:11 thorium kernel: imt0: successfully setup callout
...

Jul 21 16:07:08 thorium kernel: imt0: iichid device close
Jul 21 16:07:08 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)
Jul 21 16:07:08 thorium kernel: imt0: tore callout down

sysctl's:

# sysctl -a | grep iic
irq17: ig4iic_pci1:33 @cpu0(domain0): 479263
irq18: ig4iic_pci2:35 @cpu0(domain0): 0
dev.iic.2.%parent: iicbus2
dev.iic.2.%pnpinfo:
dev.iic.2.%location: addr=0
dev.iic.2.%driver: iic
dev.iic.2.%desc: I2C generic I/O
dev.iic.1.%parent: iicbus1
dev.iic.1.%pnpinfo:
dev.iic.1.%location: addr=0
dev.iic.1.%driver: iic
dev.iic.1.%desc: I2C generic I/O
dev.iic.0.%parent: iicbus0
dev.iic.0.%pnpinfo:
dev.iic.0.%location: addr=0
dev.iic.0.%driver: iic
dev.iic.0.%desc: I2C generic I/O
dev.iic.%parent:
dev.imt.0.%parent: iicbus1
dev.acpi_iichid.0.%parent: acpi0
dev.acpi_iichid.0.%pnpinfo: _HID=ELAN1200 _UID=1
dev.acpi_iichid.0.%location: handle=\_SB_.PCI0.I2C1.ETPD
dev.acpi_iichid.0.%driver: acpi_iichid
dev.acpi_iichid.0.%desc: HID over I2C (ACPI)
dev.acpi_iichid.%parent:
dev.iicbus.2.frequency: 100000
dev.iicbus.2.%parent: ig4iic_pci2
dev.iicbus.2.%pnpinfo:
dev.iicbus.2.%location:
dev.iicbus.2.%driver: iicbus
dev.iicbus.2.%desc: Philips I2C bus
dev.iicbus.1.frequency: 100000
dev.iicbus.1.%parent: ig4iic_pci1
dev.iicbus.1.%pnpinfo:
dev.iicbus.1.%location:
dev.iicbus.1.%driver: iicbus
dev.iicbus.1.%desc: Philips I2C bus
dev.iicbus.0.frequency: 100000
dev.iicbus.0.%parent: ig4iic_pci0
dev.iicbus.0.%pnpinfo:
dev.iicbus.0.%location:
dev.iicbus.0.%driver: iicbus
dev.iicbus.0.%desc: Philips I2C bus
dev.iicbus.%parent:
dev.ig4iic_pci.2.%parent: pci0
dev.ig4iic_pci.2.%pnpinfo: vendor=0x8086 device=0x9d62 subvendor=0x1043 subdevice=0x1e30 class=0x118000
dev.ig4iic_pci.2.%location: slot=21 function=2 dbsf=pci0:0:21:2 handle=\_SB_.PCI0.I2C2
dev.ig4iic_pci.2.%driver: ig4iic_pci
dev.ig4iic_pci.2.%desc: Intel Sunrise Point-LP I2C Controller-2
dev.ig4iic_pci.1.%parent: pci0
dev.ig4iic_pci.1.%pnpinfo: vendor=0x8086 device=0x9d61 subvendor=0x1043 subdevice=0x1e30 class=0x118000
dev.ig4iic_pci.1.%location: slot=21 function=1 dbsf=pci0:0:21:1 handle=\_SB_.PCI0.I2C1
dev.ig4iic_pci.1.%driver: ig4iic_pci
dev.ig4iic_pci.1.%desc: Intel Sunrise Point-LP I2C Controller-1
dev.ig4iic_pci.0.%parent: pci0
dev.ig4iic_pci.0.%pnpinfo: vendor=0x8086 device=0x9d60 subvendor=0x1043 subdevice=0x1e30 class=0x118000
dev.ig4iic_pci.0.%location: slot=21 function=0 dbsf=pci0:0:21:0 handle=\_SB_.PCI0.I2C0
dev.ig4iic_pci.0.%driver: ig4iic_pci
dev.ig4iic_pci.0.%desc: Intel Sunrise Point-LP I2C Controller-0
dev.ig4iic_pci.%parent:

libinput says:

-event0   DEVICE_ADDED     System keyboard multiplexer       seat0 default group1  cap:k
-event1   DEVICE_ADDED     System mouse                      seat0 default group2  cap:p left scroll-nat scroll-button
-event2   DEVICE_ADDED     AT keyboard                       seat0 default group3  cap:k
-event3   DEVICE_ADDED     ELAN1200                          seat0 default group4  cap:pg  size 103x71mm tap(dl off) left scroll-nat scroll-2fg-edge dwt-on

and

Device:           ELAN1200
Kernel:           /dev/input/event3
Group:            4
Seat:             seat0, default
Size:             103x71mm
Capabilities:     pointer gesture
Tap-to-click:     enabled
Tap-and-drag:     enabled
Tap drag lock:    disabled
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   *two-finger edge
Click methods:    none
Disable-w-typing: enabled
Accel profiles:   none
Rotation:         n/a

Xorg log:

[   506.771] (II) Using input driver 'libinput' for 'Touchpad1'
[   506.771] (**) Option "CorePointer"
[   506.771] (**) Touchpad1: always reports core events
[   506.771] (**) Option "Device" "/dev/input/event3"
[   506.773] (II) event3  - ELAN1200: is tagged by udev as: Mouse Touchpad
[   506.773] (II) event3  - ELAN1200: device is a touchpad
[   506.773] (II) event3  - ELAN1200: device removed
[   506.773] (**) Option "Tapping" "on"
[   506.773] (**) Option "TappingDrag" "true"
[   506.773] (**) Option "NaturalScrolling" "true"
[   506.773] (**) Option "ScrollMethod" "twofinger"
[   506.773] (**) Option "HorizontalScrolling" "true"
[   506.773] (II) XINPUT: Adding extended input device "Touchpad1" (type: TOUCHPAD, id 6)
[   506.773] (**) Option "AccelerationScheme" "none"
[   506.773] (**) Touchpad1: (accel) selected scheme none/0
[   506.773] (**) Touchpad1: (accel) acceleration factor: 2.000
[   506.773] (**) Touchpad1: (accel) acceleration threshold: 4
[   506.774] (II) event3  - ELAN1200: is tagged by udev as: Mouse Touchpad
[   506.774] (II) event3  - ELAN1200: device is a touchpad

xinput:

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Touchpad1                                 id=6    [slave  pointer  (2)]
⎜   ↳ sysmouse                                  id=8    [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ kbdmux                                    id=7    [slave  keyboard (3)]

[wulf]

In D16698#455908, @nikola.lecic_anthesphoria.net wrote:

The only problem -- the device is still dead;

I fixed one bug, so try one more time

it generates nothing with libinput debug-events, and no events in xev.

libinput debug-events is not the right tool to debug evdev. evemu-record from devel/evemu port is better

[nikola.lecic_anthesphoria.net]

In D16698#456090, @wulf wrote:

In D16698#455908, @nikola.lecic_anthesphoria.net wrote:

The only problem -- the device is still dead;

I fixed one bug, so try one more time

Sorry, no difference.

it generates nothing with libinput debug-events, and no events in xev.

libinput debug-events is not the right tool to debug evdev. evemu-record from devel/evemu port is better

evemu-record (device still dead, no events generated after that):

# EVEMU 1.3
# Kernel: 12.0-RELEASE
# Input device name: "ELAN1200"
# Input device ID: bus 0x18 vendor 0x4f3 product 0x309c version 0x01
# Size in mm: 103x70
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#     Event code 15 (SYN_MAX)
#   Event type 1 (EV_KEY)
#     Event code 325 (BTN_TOOL_FINGER)
#     Event code 328 (BTN_TOOL_QUINTTAP)
#     Event code 330 (BTN_TOUCH)
#     Event code 333 (BTN_TOOL_DOUBLETAP)
#     Event code 334 (BTN_TOOL_TRIPLETAP)
#     Event code 335 (BTN_TOOL_QUADTAP)
#   Event type 3 (EV_ABS)
#     Event code 0 (ABS_X)
#       Value        0
#       Min          0
#       Max       3200
#       Fuzz         0
#       Flat         0
#       Resolution  31
#     Event code 1 (ABS_Y)
#       Value        0
#       Min          0
#       Max       2198
#       Fuzz         0
#       Flat         0
#       Resolution  31
#     Event code 47 (ABS_MT_SLOT)
#       Value        0
#       Min          0
#       Max          4
#       Fuzz         0
#       Flat         0
#       Resolution   0
#     Event code 53 (ABS_MT_POSITION_X)
#       Value        0
#       Min          0
#       Max       3200
#       Fuzz         0
#       Flat         0
#       Resolution  31
#     Event code 54 (ABS_MT_POSITION_Y)
#       Value        0
#       Min          0
#       Max       2198
#       Fuzz         0
#       Flat         0
#       Resolution  31
#     Event code 57 (ABS_MT_TRACKING_ID)
#       Value        0
#       Min          0
#       Max         15
#       Fuzz         0
#       Flat         0
#       Resolution   0
# Properties:
#   Property  type 0 (INPUT_PROP_POINTER)
N: ELAN1200
I: 0018 04f3 309c 0001
P: 01 00 00 00 00 00 00 00
B: 00 0b 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 20 e5 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 02 00 00 00 00 00 00 00 00
B: 03 03 00 00 00 00 80 60 02
B: 04 00 00 00 00 00 00 00 00
B: 05 00 00 00 00 00 00 00 00
B: 11 00 00 00 00 00 00 00 00
B: 12 00 00 00 00 00 00 00 00
B: 14 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
A: 00 0 3200 0 0 31
A: 01 0 2198 0 0 31
A: 2f 0 4 0 0 0
A: 35 0 3200 0 0 31
A: 36 0 2198 0 0 31
A: 39 0 15 0 0 0

[wulf]

In D16698#456096, @nikola.lecic_anthesphoria.net wrote:

Sorry, no difference.

I enabled debugging output in imt.c so please:

1. Update sources
2. make && sudo kldload ./iichid.ko
3. sudo sysctl hw.imt.debug=6
4. sudo evemu-record /dev/input/event<touchpad unit number>
5. Do a touch for half an second
6. Post dmesg output starting form first imt0: line

evemu-record output is unneeded

[nikola.lecic_anthesphoria.net]

In D16698#456208, @wulf wrote:

In D16698#456096, @nikola.lecic_anthesphoria.net wrote:

Sorry, no difference.

I enabled debugging output in imt.c so please:

1. Update sources
2. make && sudo kldload ./iichid.ko
3. sudo sysctl hw.imt.debug=6
4. sudo evemu-record /dev/input/event<touchpad unit number>
5. Do a touch for half an second
6. Post dmesg output starting form first imt0: line

Ok; after evemu-record /dev/input/event3 I get:

Jul 23 02:19:56 thorium kernel: imt0: iichid device open
Jul 23 02:19:56 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(0)
Jul 23 02:19:56 thorium kernel: imt0: successfully setup callout

Touching/pressing/doing anything with touchpad produces absolutely nothing.
After Ctrl+C'ing evemu-record I get

Jul 23 02:20:17 thorium kernel: imt0: iichid device close
Jul 23 02:20:17 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)
Jul 23 02:20:17 thorium kernel: imt0: tore callout down

[wulf]

In D16698#456379, @nikola.lecic_anthesphoria.net wrote:

Touching/pressing/doing anything with touchpad produces absolutely nothing.

Ouuuch. I forgot one important thing! ig4.ko must be fixed before this driver get used. I am sorry.

Just add following snippet to ig4iic_pci_methods array in /usr/src/sys/dev/ichiic/ig4_pci.c and rebuild kernel or ig4.ko

/* Bus interface */
DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr),
DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
DEVMETHOD(bus_set_resource, bus_generic_rl_set_resource),
DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),

[nikola.lecic_anthesphoria.net]

In D16698#457552, @wulf wrote:

In D16698#456379, @nikola.lecic_anthesphoria.net wrote:

Touching/pressing/doing anything with touchpad produces absolutely nothing.

Ouuuch. I forgot one important thing! ig4.ko must be fixed before this driver get used. I am sorry.

Just add following snippet to ig4iic_pci_methods array in /usr/src/sys/dev/ichiic/ig4_pci.c and rebuild kernel or ig4.ko

/* Bus interface */
DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
DEVMETHOD(bus_teardown_intr, bus_generic_teardown_intr),
DEVMETHOD(bus_alloc_resource, bus_generic_alloc_resource),
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
DEVMETHOD(bus_adjust_resource, bus_generic_adjust_resource),
DEVMETHOD(bus_set_resource, bus_generic_rl_set_resource),
DEVMETHOD(bus_get_resource, bus_generic_rl_get_resource),

All done, no difference, nothing happens with evemu-record. :(

[wulf]

In D16698#457728, @nikola.lecic_anthesphoria.net wrote:

All done, no difference, nothing happens with evemu-record. :(

What is in your dmesg log? Please post it including device attachment part

[nikola.lecic_anthesphoria.net]

In D16698#457750, @wulf wrote:

In D16698#457728, @nikola.lecic_anthesphoria.net wrote:

All done, no difference, nothing happens with evemu-record. :(

What is in your dmesg log? Please post it including device attachment part

Here it is.

# kldload ./ig4.ko (new one):

Jul 28 15:19:07 persephone kernel: warning: KLD '/boot/kernel/iicbus.ko' is newer than the linker.hints file
Jul 28 15:19:07 persephone kernel: ig4iic_pci0: <Intel Sunrise Point-LP I2C Controller-0> mem 0xef238000-0xef238fff at device 21.0 on pci0
Jul 28 15:19:07 persephone kernel: ig4iic_pci0: Using MSI
Jul 28 15:19:07 persephone kernel: iicbus0: <Philips I2C bus> on ig4iic_pci0
Jul 28 15:19:07 persephone kernel: ig4iic_pci1: <Intel Sunrise Point-LP I2C Controller-1> mem 0xef237000-0xef237fff at device 21.1 on pci0
Jul 28 15:19:07 persephone kernel: ig4iic_pci1: Using MSI
Jul 28 15:19:07 persephone kernel: iicbus1: <Philips I2C bus> on ig4iic_pci1
Jul 28 15:19:07 persephone kernel: ig4iic_pci2: <Intel Sunrise Point-LP I2C Controller-2> mem 0xef236000-0xef236fff at device 21.2 on pci0
Jul 28 15:19:07 persephone kernel: ig4iic_pci2: Using MSI
Jul 28 15:19:07 persephone kernel: iicbus2: <Philips I2C bus> on ig4iic_pci2

# kldload ./iichid.ko

Jul 28 15:19:59 persephone kernel: acpi_iichid0: <HID over I2C (ACPI)> irq 109 on acpi0
Jul 28 15:19:59 persephone kernel: imt0:   ACPI Hardware ID  : ELAN1200
Jul 28 15:19:59 persephone kernel: imt0:   IICbus addr       : 0x15
Jul 28 15:19:59 persephone kernel: imt0:   HID descriptor reg: 0x01
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(0)
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_CMD_RESET
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 356
Jul 28 15:19:59 thorium kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 05 0c 0a 38 02 95 01 81 06 75 08 95 03 81 03 c0 c0 05 0d 09 05 a1 01 85 04 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 75 01 95 02 81 03 95 01 75 04 25 0f 09 51 81 02 05 01 15 00 26 80 0c 75 10 55 0e 65 13 09 30 35 00 46 90 01 95 01 81 02 46 13 01 26 96 08 26 96 08 09 31 81 02 05 0d 15 00 25 64 95 03 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09 09 01 25 01 75 01 95 01 81 02 95 07 81 03 09 c5 75 08 95 04 81 03 05 0d 85 02 09 55 09 59 75 04 95 02 25 0f b1 02 85 07 09 60 75 01 95 01 15 00 25 01 b1 02 95 0f b1 03 06 00 ff 06 00 ff 85 06 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 85 0d 09 c4 15 00 26 ff 00 75 08 95 04 b1 02 85 0c 09 c6 96 8a 02 75 08 b1 02 85 0b 09 c7 95 80 75 08 b1 02 c0 05 0d 09 0e a1 01 85 03 09 22 a1 00 09 52 15 00 25 0a 75 10 95 01 b1 02 c0 09 22 a1 00 85 05 09 57 09 58 15 00 75 01 95 02 25 03 b1 02 95 0e b1 03 c0 c0
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 356
Jul 28 15:19:59 thorium kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 05 0c 0a 38 02 95 01 81 06 75 08 95 03 81 03 c0 c0 05 0d 09 05 a1 01 85 04 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 75 01 95 02 81 03 95 01 75 04 25 0f 09 51 81 02 05 01 15 00 26 80 0c 75 10 55 0e 65 13 09 30 35 00 46 90 01 95 01 81 02 46 13 01 26 96 08 26 96 08 09 31 81 02 05 0d 15 00 25 64 95 03 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09 09 01 25 01 75 01 95 01 81 02 95 07 81 03 09 c5 75 08 95 04 81 03 05 0d 85 02 09 55 09 59 75 04 95 02 25 0f b1 02 85 07 09 60 75 01 95 01 15 00 25 01 b1 02 95 0f b1 03 06 00 ff 06 00 ff 85 06 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 85 0d 09 c4 15 00 26 ff 00 75 08 95 04 b1 02 85 0c 09 c6 96 8a 02 75 08 b1 02 85 0b 09 c7 95 80 75 08 b1 02 c0 05 0d 09 0e a1 01 85 03 09 22 a1 00 09 52 15 00 25 0a 75 10 95 01 b1 02 c0 09 22 a1 00 85 05 09 57 09 58 15 00 75 01 95 02 25 03 b1 02 95 0e b1 03 c0 c0
Jul 28 15:19:59 thorium kernel: imt0: <ELAN1200> at addr 0x15 irq 109 on iicbus1
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 356
Jul 28 15:19:59 thorium kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 02 15 00 25 01 75 01 95 02 81 02 95 06 81 03 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 05 0c 0a 38 02 95 01 81 06 75 08 95 03 81 03 c0 c0 05 0d 09 05 a1 01 85 04 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 75 01 95 02 81 03 95 01 75 04 25 0f 09 51 81 02 05 01 15 00 26 80 0c 75 10 55 0e 65 13 09 30 35 00 46 90 01 95 01 81 02 46 13 01 26 96 08 26 96 08 09 31 81 02 05 0d 15 00 25 64 95 03 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 09 56 81 02 09 54 25 7f 95 01 75 08 81 02 05 09 09 01 25 01 75 01 95 01 81 02 95 07 81 03 09 c5 75 08 95 04 81 03 05 0d 85 02 09 55 09 59 75 04 95 02 25 0f b1 02 85 07 09 60 75 01 95 01 15 00 25 01 b1 02 95 0f b1 03 06 00 ff 06 00 ff 85 06 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 85 0d 09 c4 15 00 26 ff 00 75 08 95 04 b1 02 85 0c 09 c6 96 8a 02 75 08 b1 02 85 0b 09 c7 95 80 75 08 b1 02 c0 05 0d 09 0e a1 01 85 03 09 22 a1 00 09 52 15 00 25 0a 75 10 95 01 b1 02 c0 09 22 a1 00 85 05 09 57 09 58 15 00 75 01 95 02 25 03 b1 02 95 0e b1 03 c0 c0
Jul 28 15:19:59 thorium kernel: imt0: 15 contacts and [C]. Report range [0:0] - [3200:2198]
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 2 (type 3, len 1)
Jul 28 15:19:59 thorium kernel: imt0: response: 04 00 02 05
Jul 28 15:19:59 thorium kernel: imt0: 5 feature report contacts
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 6 (type 3, len 256)
Jul 28 15:19:59 thorium kernel: imt0: response: 03 01 06 fc 28 fe 84 40 cb 9a 87 0d be 57 3c b6 70 09 88 07 97 2d 2b e3 38 34 b6 6c ed b0 f7 e5 9c f6 c2 2e 84 1b e8 b4 51 78 43 1f 28 4b 7c 2d 53 af fc 47 70 1b 59 6f 74 43 c4 f3 47 18 53 1a a2 a1 71 c7 95 0e 31 55 21 d3 b5 1e e9 0c ba ec b8 89 19 3e b3 af 75 81 9d 53 b9 41 57 f4 6d 39 25 29 7c 87 d9 b4 98 45 7d a7 26 9c 65 3b 85 68 89 d7 3b bd ff 14 67 f2 2b f0 2a 41 54 f0 fd 2c 66 7c f8 c0 8f 33 13 03 f1 d3 c1 0b 89 d9 1b 62 cd 51 b7 80 b8 af 3a 10 c1 8a 5b e8 8a 56 f0 8c aa fa 35 e9 42 c4 d8 55 c3 38 cc 2b 53 5c 69 52 d5 c8 73 02 38 7c 73 b6 41 e7 ff 05 d8 2b 79 9a e2 34 60 8f a3 32 1f 09 78 62 bc 80 e3 0f bd 65 20 08 13 c1 e2 ee 53 2d 86 7e a7 5a c5 d3 7d 98 be 31 48 1f fb da af a2 a8 6a 89 d6 bf f2 d3 32 2a 9a e4 cf 17 b7 b8 f4 e1 33 08 24 8b c4 43 a5 e5 24 c2
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)
Jul 28 15:19:59 thorium kernel: imt0: allocated irq at 0xfffff8030b2daa00 and rid 0
Jul 28 15:19:59 thorium kernel: imt0: successfully setup interrupt
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 3 (type 3, len 2)
Jul 28 15:19:59 thorium kernel: imt0: response: 05 00 03 00 00
Jul 28 15:19:59 thorium kernel: imt0: HID command I2C_HID_CMD_SET_REPORT 3 (type 3, len 2): 03 00

# sysctl hw.imt.debug=6

hw.imt.debug: 0 -> 6

# evemu-record /dev/input/event3

Jul 28 15:22:00 thorium kernel: imt0: iichid device open
Jul 28 15:22:00 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(0)

Touching -- nothing happens. Ctrl+C:

Jul 28 15:22:26 thorium kernel: imt0: iichid device close
Jul 28 15:22:26 thorium kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)

[zarychtam_plan-b.pwste.edu.pl]

Updated D16698 builds and runs fine on 12-STABLE though it still lacks resume support.

I must admit I wasn't able to test https://github.com/wulf7/iichid. The module didn't work for me:

Jul 28 18:20:49 bsdondell kernel: acpi_iichid0: <HID over I2C (ACPI)> irq 51 on acpi0
Jul 28 18:20:49 bsdondell kernel: imt0: ACPI Hardware ID : DELL0817
Jul 28 18:20:49 bsdondell kernel: imt0: IICbus addr : 0x2C
Jul 28 18:20:49 bsdondell kernel: imt0: HID descriptor reg: 0x20
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_SET_POWER(0)
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_RESET
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 339
Jul 28 18:20:49 bsdondell kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 95 05 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 09 38 95 01 81 06 05 0c 0a 38 02 81 06 c0 c0 05 0d 09 05 a1 01 85 08 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 95 01 75 03 25 05 09 51 81 02 75 01 95 03 81 03 05 01 15 00 26 af 04 75 10 55 0e 65 11 09 30 35 00 46 e8 03 95 01 81 02 26 7b 02 46 12 02 09 31 81 02 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 05 0d 09 56 81 02 09 54 25 05 95 01 75 08 81 02 05 09 09 02 09 03 25 01 75 01 95 02 81 02 95 06 81 03 05 0d 85 09 09 55 75 08 95 01 25 05 b1 02 06 00 ff 85 0a 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 c0 06 01 ff 09 01 a1 01 85 03 09 01 15 00 26 ff 00 75 08 95 1b 81 02 85 04 09 02 95 1b 81 02 85 05 09 03 95 07 b1 02 85 06 09 04 81 02 c0 06 02 ff 09 01 a1 01 85 07 09 02 95 86 75 08 b1 02 c0 05 0d 09 0e a1 01 85 0b 09 22 a1 02 09 52 15 00 25 0a 75 08 95 01 b1 02 c0 09 22 a1 00 85 0c 09 57 09 58 75 01 95 02 25 01 b1 02 95 06 b1 03 c0 c0
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 339
Jul 28 18:20:49 bsdondell kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 95 05 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 09 38 95 01 81 06 05 0c 0a 38 02 81 06 c0 c0 05 0d 09 05 a1 01 85 08 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 95 01 75 03 25 05 09 51 81 02 75 01 95 03 81 03 05 01 15 00 26 af 04 75 10 55 0e 65 11 09 30 35 00 46 e8 03 95 01 81 02 26 7b 02 46 12 02 09 31 81 02 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 05 0d 09 56 81 02 09 54 25 05 95 01 75 08 81 02 05 09 09 02 09 03 25 01 75 01 95 02 81 02 95 06 81 03 05 0d 85 09 09 55 75 08 95 01 25 05 b1 02 06 00 ff 85 0a 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 c0 06 01 ff 09 01 a1 01 85 03 09 01 15 00 26 ff 00 75 08 95 1b 81 02 85 04 09 02 95 1b 81 02 85 05 09 03 95 07 b1 02 85 06 09 04 81 02 c0 06 02 ff 09 01 a1 01 85 07 09 02 95 86 75 08 b1 02 c0 05 0d 09 0e a1 01 85 0b 09 22 a1 02 09 52 15 00 25 0a 75 08 95 01 b1 02 c0 09 22 a1 00 85 0c 09 57 09 58 75 01 95 02 25 01 b1 02 95 06 b1 03 c0 c0
Jul 28 18:20:49 bsdondell kernel: imt0: <DELL0817> at addr 0x2c irq 51 on iicbus1
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_REPORT_DESCR at 0x2 with size 339
Jul 28 18:20:49 bsdondell kernel: imt0: HID report descriptor: 05 01 09 02 a1 01 85 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 95 05 81 01 05 01 09 30 09 31 15 81 25 7f 75 08 95 02 81 06 09 38 95 01 81 06 05 0c 0a 38 02 81 06 c0 c0 05 0d 09 05 a1 01 85 08 09 22 a1 02 15 00 25 01 09 47 09 42 95 02 75 01 81 02 95 01 75 03 25 05 09 51 81 02 75 01 95 03 81 03 05 01 15 00 26 af 04 75 10 55 0e 65 11 09 30 35 00 46 e8 03 95 01 81 02 26 7b 02 46 12 02 09 31 81 02 c0 55 0c 66 01 10 47 ff ff 00 00 27 ff ff 00 00 75 10 95 01 05 0d 09 56 81 02 09 54 25 05 95 01 75 08 81 02 05 09 09 02 09 03 25 01 75 01 95 02 81 02 95 06 81 03 05 0d 85 09 09 55 75 08 95 01 25 05 b1 02 06 00 ff 85 0a 09 c5 15 00 26 ff 00 75 08 96 00 01 b1 02 c0 06 01 ff 09 01 a1 01 85 03 09 01 15 00 26 ff 00 75 08 95 1b 81 02 85 04 09 02 95 1b 81 02 85 05 09 03 95 07 b1 02 85 06 09 04 81 02 c0 06 02 ff 09 01 a1 01 85 07 09 02 95 86 75 08 b1 02 c0 05 0d 09 0e a1 01 85 0b 09 22 a1 02 09 52 15 00 25 0a 75 08 95 01 b1 02 c0 09 22 a1 00 85 0c 09 57 09 58 75 01 95 02 25 01 b1 02 95 06 b1 03 c0 c0
Jul 28 18:20:49 bsdondell kernel: imt0: 5 contacts and [C]. Report range [0:0] - [1199:635]
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 9 (type 3, len 1)
Jul 28 18:20:49 bsdondell kernel: imt0: response: 04 00 09 05
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 10 (type 3, len 256)
Jul 28 18:20:49 bsdondell kernel: imt0: response: 03 01 0a fc 28 fe 84 40 cb 9a 87 0d be 57 3c b6 70 09 88 07 97 2d 2b e3 38 34 b6 6c ed b0 f7 e5 9c f6 c2 2e 84 1b e8 b4 51 78 43 1f 28 4b 7c 2d 53 af fc 47 70 1b 59 6f 74 43 c4 f3 47 18 53 1a a2 a1 71 c7 95 0e 31 55 21 d3 b5 1e e9 0c ba ec b8 89 19 3e b3 af 75 81 9d 53 b9 41 57 f4 6d 39 25 29 7c 87 d9 b4 98 45 7d a7 26 9c 65 3b 85 68 89 d7 3b bd ff 14 67 f2 2b f0 2a 41 54 f0 fd 2c 66 7c f8 c0 8f 33 13 03 f1 d3 c1 0b 89 d9 1b 62 cd 51 b7 80 b8 af 3a 10 c1 8a 5b e8 8a 56 f0 8c aa fa 35 e9 42 c4 d8 55 c3 38 cc 2b 53 5c 69 52 d5 c8 73 02 38 7c 73 b6 41 e7 ff 05 d8 2b 79 9a e2 34 60 8f a3 32 1f 09 78 62 bc 80 e3 0f bd 65 20 08 13 c1 e2 ee 53 2d 86 7e a7 5a c5 d3 7d 98 be 31 48 1f fb da af a2 a8 6a 89 d6 bf f2 d3 32 2a 9a e4 cf 17 b7 b8 f4 e1 33 08 24 8b c4 43 a5 e5 24 c2
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)
Jul 28 18:20:49 bsdondell kernel: imt0: IRQ allocation failed. Fallback to sampling.
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 11 (type 3, len 1)
Jul 28 18:20:49 bsdondell kernel: imt0: response size 2 != expected length 4
Jul 28 18:20:49 bsdondell kernel: imt0: response report id 0 != 11
Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_SET_POWER(1)
Jul 28 18:20:49 bsdondell kernel: device_attach: imt0 attach returned 6

[wulf]

In D16698#457802, @zarychtam_plan-b.pwste.edu.pl wrote:

Updated D16698 builds and runs fine on 12-STABLE though it still lacks resume support.

I must admit I wasn't able to test https://github.com/wulf7/iichid. The module didn't work for me:

Jul 28 18:20:49 bsdondell kernel: imt0: IRQ allocation failed. Fallback to sampling.

You should patch ig4 as of my comment at "Sat, Jul 27, 12:23 PM". Otherwise you wont get IRQs working. The driver can work without interrupts sometimes but not reliably due to skipping of some release events.

Jul 28 18:20:49 bsdondell kernel: imt0: HID command I2C_HID_CMD_GET_REPORT 11 (type 3, len 1)
Jul 28 18:20:49 bsdondell kernel: imt0: response size 2 != expected length 4
Jul 28 18:20:49 bsdondell kernel: imt0: response report id 0 != 11

I have added ability to ignore "Input Mode report" read errors to the driver so you can try it again.

[wulf]

In D16698#457762, @nikola.lecic_anthesphoria.net wrote:

Here it is.

Attach phase looks good now

Try to replace iichid_set_power() and iichid_reset() subroutine bodies in iichid.c with return(0);

[nikola.lecic_anthesphoria.net]

In D16698#457847, @wulf wrote:

In D16698#457762, @nikola.lecic_anthesphoria.net wrote:

Here it is.

Attach phase looks good now

Try to replace iichid_set_power() and iichid_reset() subroutine bodies in iichid.c with return(0);

You mean

int
iichid_set_power(device_t dev, bool enable)
{
  return(0);
}
int
iichid_reset(device_t dev)
{
  return(0);
}

? Done, and again, no difference. :( After evemu-record, expectedly, just:

kernel: imt0: iichid device open

[wulf]

In D16698#457858, @nikola.lecic_anthesphoria.net wrote:

In D16698#457847, @wulf wrote:

then comment out imt_set_input_mode() call in imt_attach() subroutine (imt.c) and insert printf("something\n"); into iichid_intr() sub (iichid.c)
If it print something on the console when you touching trackpad surface?

[nikola.lecic_anthesphoria.net]

In D16698#457872, @wulf wrote:

In D16698#457858, @nikola.lecic_anthesphoria.net wrote:

In D16698#457847, @wulf wrote:

then comment out imt_set_input_mode() call in imt_attach() subroutine (imt.c) and insert printf("something\n"); into iichid_intr() sub (iichid.c)
If it print something on the console when you touching trackpad surface?

Yes! :) It prints "something".

[wulf]

In D16698#457877, @nikola.lecic_anthesphoria.net wrote:

In D16698#457872, @wulf wrote:

In D16698#457858, @nikola.lecic_anthesphoria.net wrote:

In D16698#457847, @wulf wrote:

then comment out imt_set_input_mode() call in imt_attach() subroutine (imt.c) and insert printf("something\n"); into iichid_intr() sub (iichid.c)
If it print something on the console when you touching trackpad surface?

Yes! :) It prints "something".

It should print continuously if you'd move your finger

If it still prints something if you uncomment imt_set_input_mode() call in imt_attach() subroutine (imt.c)?

[nikola.lecic_anthesphoria.net]

In D16698#457878, @wulf wrote:

In D16698#457877, @nikola.lecic_anthesphoria.net wrote:

In D16698#457872, @wulf wrote:

In D16698#457858, @nikola.lecic_anthesphoria.net wrote:

In D16698#457847, @wulf wrote:

then comment out imt_set_input_mode() call in imt_attach() subroutine (imt.c) and insert printf("something\n"); into iichid_intr() sub (iichid.c)
If it print something on the console when you touching trackpad surface?

Yes! :) It prints "something".

It should print continuously if you'd move your finger

Yes, it prints "something" continuously; a single touch generates >25 "something"s.

If it still prints something if you uncomment imt_set_input_mode() call in imt_attach() subroutine (imt.c)?

Yes, it still prints.

[wulf]

In D16698#457882, @nikola.lecic_anthesphoria.net wrote:

Yes, it still prints.

Ok. than uncomment pair of debugging printfs in iichid_event_task(). They lie several lines below iichid_intr() sub.
If you get one line with hex data per "something", post it here

[nikola.lecic_anthesphoria.net]

In D16698#457883, @wulf wrote:

In D16698#457882, @nikola.lecic_anthesphoria.net wrote:

Yes, it still prints.

Ok. than uncomment pair of debugging printfs in iichid_event_task(). They lie several lines below iichid_intr() sub.
If you get one line with hex data per "something", post it here

If you mean these lines:

device_printf(sc->dev, "no data received\n");

and

DPRINTF(sc, "%*D\n", actual, sc->ibuf, " ");

then I get just this (a single touch):

Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 2 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 4 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium syslogd: last message repeated 1 times
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 3 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 2 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium syslogd: last message repeated 1 times
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 5 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 3 times
Jul 29 02:01:08 thorium kernel: imt0: no data received

[wulf]

In D16698#457884, @nikola.lecic_anthesphoria.net wrote:

In D16698#457883, @wulf wrote:

In D16698#457882, @nikola.lecic_anthesphoria.net wrote:

Yes, it still prints.

Ok. than uncomment pair of debugging printfs in iichid_event_task(). They lie several lines below iichid_intr() sub.
If you get one line with hex data per "something", post it here

If you mean these lines:

device_printf(sc->dev, "no data received\n");

and

DPRINTF(sc, "%*D\n", actual, sc->ibuf, " ");

then I get just this (a single touch):

Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 2 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 4 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium syslogd: last message repeated 1 times
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 3 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 2 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium syslogd: last message repeated 1 times
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 5 times
Jul 29 02:01:08 thorium kernel: imt0: no data received
Jul 29 02:01:08 thorium kernel: something
Jul 29 02:01:08 thorium syslogd: last message repeated 3 times
Jul 29 02:01:08 thorium kernel: imt0: no data received

One read per 3-5 interrupts...

try to replace 'IG4_CTL_SPEED_STD' string in /usr/src/sys/dev/ichiic/ig4_iic.c file with digit '6' than rebuild and reload ig4.ko . I think ig4.ko does not support skylakes well enough

[nikola.lecic_anthesphoria.net]

try to replace 'IG4_CTL_SPEED_STD' string in /usr/src/sys/dev/ichiic/ig4_iic.c file with digit '6' than rebuild and reload ig4.ko .

Done. First, loading ig4 now creates a bit different messages (irq... part).

Jul 29 02:54:26 thorium kernel: warning: KLD '/boot/kernel/iicbus.ko' is newer than the linker.hints file
Jul 29 02:54:26 thorium kernel: ig4iic_pci0: <Intel Sunrise Point-LP I2C Controller-0> mem 0xef238000-0xef238fff irq 16 at device 21.0 on pci0
Jul 29 02:54:26 thorium kernel: ig4iic_pci0: Using MSI
Jul 29 02:54:26 thorium kernel: iicbus0: <Philips I2C bus> on ig4iic_pci0
Jul 29 02:54:26 thorium kernel: ig4iic_pci1: <Intel Sunrise Point-LP I2C Controller-1> mem 0xef237000-0xef237fff irq 17 at device 21.1 on pci0
Jul 29 02:54:26 thorium kernel: ig4iic_pci1: Using MSI
Jul 29 02:54:26 thorium kernel: iicbus1: <Philips I2C bus> on ig4iic_pci1
Jul 29 02:54:26 thorium kernel: ig4iic_pci2: <Intel Sunrise Point-LP I2C Controller-2> mem 0xef236000-0xef236fff irq 18 at device 21.2 on pci0
Jul 29 02:54:26 thorium kernel: ig4iic_pci2: Using MSI
Jul 29 02:54:26 thorium kernel: iicbus2: <Philips I2C bus> on ig4iic_pci2

However, loading iichid.ko doesn't go well:

Jul 29 03:00:32 thorium kernel: acpi_iichid0: <HID over I2C (ACPI)> on acpi0
Jul 29 03:00:32 thorium kernel: imt0:   ACPI Hardware ID  : ELAN1200
Jul 29 03:00:32 thorium kernel: imt0:   IICbus addr       : 0x15
Jul 29 03:00:32 thorium kernel: imt0:   HID descriptor reg: 0x01
Jul 29 03:00:32 thorium kernel: imt0: could not retrieve HID descriptor from the device: 3

[wulf]

In D16698#457886, @nikola.lecic_anthesphoria.net wrote:

However, loading iichid.ko doesn't go well:

Jul 29 03:00:32 thorium kernel: acpi_iichid0: <HID over I2C (ACPI)> on acpi0
Jul 29 03:00:32 thorium kernel: imt0:   ACPI Hardware ID  : ELAN1200
Jul 29 03:00:32 thorium kernel: imt0:   IICbus addr       : 0x15
Jul 29 03:00:32 thorium kernel: imt0:   HID descriptor reg: 0x01
Jul 29 03:00:32 thorium kernel: imt0: could not retrieve HID descriptor from the device: 3

Could you send me your DSDT table with email? It is too big to be posted here. It can be obtained with

# acpidump -dt

[nikola.lecic_anthesphoria.net]

In D16698#457967, @wulf wrote:

Could you send me your DSDT table with email? It is too big to be posted here. It can be obtained with

# acpidump -dt

Sure, done.

[wulf]

Hi @marc.priggemeyer_gmail.com,

I wrote iicbus(4) extension which performs ACPI-based enumeration of I2C devices connected to a controller. It is not limited to HID devices and fires at iicbus attach stage.

The extension walks through ACPI children of I2C controller and for each device found it:

1. Creates iicbus child device
2. Adds I2C address to ivars
3. Adds ACPI-handle to iicbus-child ivars, so you can evaluate acpi_get_handle(dev); on iicbus child
4. Copies all newbus resources from corresponding ACPIbus-hosted device to I2Cbus-hosted one.

It effectively makes a copy of existing ACPI device on top of I2C bus.
It should also fix ig4 bug that brokes allocation of interrupts on ig4 children (Only partially tested yet, I have access only to GPIO devices now)

I think using of this extension should eliminate nasty ACPI<->I2C devices interaction that is found in the patch from current review.
iicbus(4) extension support in my driver (for reference): https://github.com/wulf7/iichid/commit/6f5c3d3eb008848ab9d18e1dcf8fd35ca80e517e

Patch could be found here: https://people.freebsd.org/~wulf/acpi_iicbus.patch

[imp]

In D16698#461247, @wulf wrote:

Hi @marc.priggemeyer_gmail.com,

I wrote iicbus(4) extension which performs ACPI-based enumeration of I2C devices connected to a controller. It is not limited to HID devices and fires at iicbus attach stage.

The extension walks through ACPI children of I2C controller and for each device found it:

1. Creates iicbus child device
2. Adds I2C address to ivars
3. Adds ACPI-handle to iicbus-child ivars, so you can evaluate acpi_get_handle(dev); on iicbus child
4. Copies all newbus resources from corresponding ACPIbus-hosted device to I2Cbus-hosted one.

It effectively makes a copy of existing ACPI device on top of I2C bus.
It should also fix ig4 bug that brokes allocation of interrupts on ig4 children (Only partially tested yet, I have access only to GPIO devices now)

I think using of this extension should eliminate nasty ACPI<->I2C devices interaction that is found in the patch from current review.
iicbus(4) extension support in my driver (for reference): https://github.com/wulf7/iichid/commit/6f5c3d3eb008848ab9d18e1dcf8fd35ca80e517e

Patch could be found here: https://people.freebsd.org/~wulf/acpi_iicbus.patch

I like the looks of this patch (though I'd delete the HAVE_ACPI_IIC sections entirely, I think). However, I've not yet tested either of these patch sets / changes on my new laptop that needs them.

We really have three problems that we need to solve:

(1) iichid
(2) how to get the acpi stuff to automatically add iichid devices
(3) How to cope with resume and resets not being quite right for the ig4.

Would we make better progress with we split those three issues up into their own reviews?

[wulf]

In D16698#464917, @imp wrote:

We really have three problems that we need to solve:

(1) iichid
(2) how to get the acpi stuff to automatically add iichid devices

iichid device is a child of acpi bus also, so it can be rephrased as "how to get the acpi stuff to automatically add acpi device with given CID"

(3) How to cope with resume and resets not being quite right for the ig4.

It is not clear which reset is mentioned:

1. IG4 controller reset (set designware specific parameters like timing counters and so on)
2. iicbus reset - FIFO flushing, setting of symbol speed and slave address
3. I2C hid device reset - performed with special I2C command

If it is mentioned in context of @johalun suspend/resume patch, then most probably it misses iicbus reset as it is performed by ig4 driver in a lazy way at a start of next xfer. sc->slave_valid bool variable should be reset to trigger it and I do not see that in @johalun resume method.

Would we make better progress with we split those three issues up into their own reviews?

I would split it into next parts:

1. ig4
   • suspend/resume - i have patches working for me.
   • I2C polling support - needed for sc/vt compatible keyboard drivers and for ability to run I2C transfers from interrupt handler, done, need testing
   • KPI for control of polling - it is a subject to discussion
2. iicbus
   • acpi-based children enumeration, done
   • I2C ACPI region handler - not strictly necessary, can be taken from DragonflyBSD
3. gpio interrupts support - it is very welcome as HID-device polling is not working well with touch devices due to 'stuck touch' problem caused by losing of 'finger up' packets - not started, can be workarounded with nasty kludges
4. iichid - mostly done, needs support for attaching of child devices
5. hidbus implementation - required to share same hid drivers between usb and i2c backends and to support multireport devices, not started, not strictly necessary just now
6. imt - almost done, needs debugging
7. ims - ?

I hope a big ig4 patch will be ready in week or two for test and review

[imp]

sys/dev/iicbus/input/acpi_iichid.c

113 ↗

(On Diff #59553)

This is wrong...
ACPI_ID_PROBE(device_get_parent(dev), dev, acpi_iichid_ids,NULL) > 0
is what I had to use. It returns a probe value, not a pointer. And there's a void * last argument that needs to be filled in.

[imp]

I built this on -current and got an insta-panic when trying to lock a null spin lock in attach...

[rozhuk.im-gmail.com]

Panic on kldload acpi_iichid in iichid_read()->cv_wait_sig().
FreeBSD 12.1 amd64 @ Asus 505z

[wulf]

sys/dev/iicbus/input/iichid.c

700

report descriptor should be fetched and checked for belonging to relative mouse here. It is a bad idea to attach mouse driver to touchscreen or accelerometer

816

return (ENXIO); /* Or you will get double free on the next iichid_detach(dev); */

825

return (ENXIO); /* Or you will get attached but nonfunctional driver on error */

832

Last parameter should be i rather than 0. Otherwise pointer speed will be MS_INFO_MAX times faster

[wulf]

sys/dev/iicbus/input/iichid.c

832

this line should be:

ms_hid_parse(dev, rdesc, len, &sc->info[i], i);

And I was wrong about

will be MS_INFO_MAX times faster

[wulf]

sys/dev/iicbus/input/iichid.c

146

iichid_fetch_buffer() should not be used here as it writes 2 extraneous bytes of InputRegister address before doing a read. That locks up some I2C devices

See hid-over-i2c-protocol-spec-v1-0.docx, page 24. "Figure 5: Input Report Retrieval".

P.S. Found by Greg V

[rozhuk.im-gmail.com]

kernel trap 22 with interrupts disabled
panic: spin locks can only use msleep_spin
cpuid = 7 time = 1569790352
KDB: stack backtrace:
#0 0xffffffff805da3fd at kdb_backtrace+0x6d
#1 0xffffffff80594fed at vpanic+0x19d
#2 0xffffffff80594e43 at panic+0x43
#3 0xffffffff8057df32 at unlock_spin+0x12
#4 0xffffffff8053f577 at _cv_wait_sig+0x127
#5 0xffffffff81d1dace at iichid_read+0x8e
#6 0xffffffff804b690a at devfs_read_f+0xda
#7 0xffffffff805f4752 at kern_readv+0x92
#8 0xffffffff805f46b4 at sys_read+0x84
#9 0xffffffff808451d8 at amd64_syscall+0x218
#10 0xffffffff80821270 at fast_syscall_common+0x101

https://github.com/wulf7/iichid - works ok.

[imp]

sys/dev/iicbus/input/acpi_iichid.c

3 ↗

(On Diff #59553)

Project's template no longer has this line.

sys/dev/iicbus/input/iichid.c

688–691

Remove this. It's impossible.

695–699

This is bogus. device driver isn't ever NULL, and you should never check the parent device type. newbus handles that stuff...

815

This is bogus. You should print the error before calling detach.

824

Same as above.

841

This is too late... If you follow the error path and call detach, sc->lock is uninitialized there.

874–875

This is impossible. You don't need to test for this.

879–886

Several problems here...
First, this locking protocol can't possibly work... You signal the other threads, but don't wait for them to exit before destroying the lock.
Second, you lock and unlock and then test to see if is initialized. That is the wrong order. Just destroy the lock unconditionally.
You'll need some kind of reference count and need to wait for it to drop to 0 to be safe...

[imp]

So with the suggested changes, I'm not able to get very far with the patches in this review. With wulf's code I'm able to get the device probed. With this code, I see the following:

iichid0: <HID over I2C> at addr 0x15 irq 80 on iicbus0
iichid0: ADDR 0x15 REG 0x0
iichid0: could not retrieve report descriptor from device: -1
iichid0: determined (len=2) and described (len=65280) input report lengths mismatch
iichid1: <HID over I2C> at addr 0xa irq 42 on iicbus1
iichid1: ADDR 0xa REG 0x0
iichid1: determined (len=61) and described (len=64) input report lengths mismatch
iichid2: <HID over I2C> at addr 0x5c on iicbus2
iichid2: ADDR 0x5c REG 0x0
iichid2: could not retrieve report descriptor from device: -1
iichid2: determined (len=2) and described (len=0) input report lengths mismatch

[val_packett.cool]

In D16698#478767, @imp wrote:

So with the suggested changes, I'm not able to get very far with the patches in this review. With wulf's code I'm able to get the device probed. With this code, I see the following

Is this code still really considered? wulf's repo is currently actively developed (now even includes the long-awaited and very necessary "HID bus" abstraction), this was last updated in August.

data point: I'm using wulf's code on my Pixelbook, multi-touch works great for both the touchpad and touchscreen.

[imp]

In D16698#478805, @greg_unrelenting.technology wrote:

In D16698#478767, @imp wrote:

So with the suggested changes, I'm not able to get very far with the patches in this review. With wulf's code I'm able to get the device probed. With this code, I see the following

Is this code still really considered? wulf's repo is currently actively developed (now even includes the long-awaited and very necessary "HID bus" abstraction), this was last updated in August.

data point: I'm using wulf's code on my Pixelbook, multi-touch works great for both the touchpad and touchscreen.

I'll switch over. Someone else reported success with this code to me, but I've been unable to make a go of it.

[marc.priggemeyer_gmail.com]

Thanks for the remarks. I'd suggest to stop riding a dead horse and make the switch altogether. It has been pointed out previously that the separation of ACPI and HID over I2C code like it was done here, especially the interrupt handling, was ill-conceived.
Abstraction of HID code was initially considered, but not implemented on my part. Since wulf has already done these things and even has the multitouch part working, switching over is the most sensible thing. This code here was intended to be a first draft and has served its purpose.

[wulf]

In D16698#478901, @marc.priggemeyer_gmail.com wrote:

Thanks for the remarks. I'd suggest to stop riding a dead horse and make the switch altogether.

This driver still has some advantages over mine. It supports 12.0-release, sysmouse(8) protocol and it does not require ig4 patching. So, I would prefer it for non-HID trackpads like some Synaptics models. Al least for now.

[zarychtam_plan-b.pwste.edu.pl]

I don't know if comments to this review are still relevant, but I'd like to report that this driver built on recent 12.1-STABLE can work fine after resume. To enable suspend/resume support the module acpi_iichid has to be unloaded and loaded again which can be done for instance with the help of rc.{suspend,resume} scripts.

[KOT_MATPOCKuH.Ru]

I'm using patches from this review for last two years.
Please apply this patch to FreeBSD base code.

[marc.priggemeyer_gmail.com]

In D16698#568171, @KOT_MATPOCKuH.Ru wrote:

I'm using patches from this review for last two years.
Please apply this patch to FreeBSD base code.

Are you having issues with sysutils/iichid or wulf's respository? He fixed serious issues and provided a HID layer that you should stick to.

[KOT_MATPOCKuH.Ru]

In D16698#568211, @marc.priggemeyer_gmail.com wrote:

Are you having issues with sysutils/iichid or wulf's respository? He fixed serious issues and provided a HID layer that you should stick to.

Oops. I'm not found nothing about port in this review.
sysutils/iichid works for me. Thanks You!