In D23615#518762, @koobs wrote:

should we leave it open for any version/arch, or should we limit it. If limiting, I need a list of archs for ONLY_FOR_ARCHS and OSVERSIONS we shouldn't set IGNORE for

In D23615#518766, @koobs wrote:

Fails building in 11amd64 with the following, so will at least set OSVERSION > 12* unless its expected or desirable for iichid to be test on 11:

Only 12.1+ is supported.

I recommend to disable USB backend by default and leave it as build-time option as it is not completed yet and interferes with existing USB drivers.

In D23615#518316, @lwhsu wrote:

@wulf : Do you think it's time to put this into base or let's add this as a port first?

In D22901#501848, @jhb wrote:

So it would be helpful to see an acpidump of a system with these devices.

I don't think that Assistant key should be mapped to KEY_RIGHTMETA for following reasons:

1. It is not really a meta key as it does not affect other key meanings like Shift, Alt, Ctrl and Win keys do.
2. According to https://www.win.tue.nl/~aeb/linux/kbd/scancodes-6.html, scancode of 0x58 prefixed with 0xE0 is emitted by pressing of Fn+F12 keys on Logitech and Microsoft keyboards so the best matching evdev event would be KEY_FN_F12.

In D22515#492391, @emaste wrote:

Do you think we could add all of these test cases to the tree somewhere?

• Clock registers values are calculated based on I2C protocol timing constraints and IC parameters taken from LPSS driver. Latter are still kind of magic numbers, but they are physical parameters at least.
• Interrupt handler is filter based now.

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.

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?

Finally, I made separate small kernel module ng_ubt_intel which shares object file with ng_ubt.
It inherits device methods from ng_ubt while overriding it's probe() method.
That allows move vendor-specific code out of ng_ubt and avoid code duplication the same time.
Firmware is still downloaded with libusb as I don't see any benefits from moving one-shot driver to kernelspace.

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.

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

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

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

Yes, it still prints.

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

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

In D16698#457847, @wulf wrote:

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

Here it is.

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.

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

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

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

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

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

Sorry, no difference.

I enabled debugging output in imt.c so please:

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

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

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.

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)

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

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?

In D16698#455200, @greg_unrelenting.technology wrote:

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