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.

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

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

In D20507#442964, @jan.kokemueller_gmail.com wrote:

This was tried some years ago, but then reverted as the probing was deemed too intrusive (see r255152 and r255210). I don't know if something changed in the meantime.

Synaptics and Elantech probe() does not depend on loader tuneables at all. Magic knock and capability queries are always performed regardless of kernel boot parameters so it cannot be called "too intrusive".
But IBM trackpoint probe() is different thing. It is performed in different ways depending on 'synaptics_support' variable value.
Browsing through the commit log shows me that there were several patches submitted by you to fix various trackpoint issues circa 2015 so it's worth trying to enable it by default again as support of this device is definitely changed since 2013.

In D20507#443152, @phascolarctos_protonmail.ch wrote:

I tested and it works. Thanks!
Unless solution 1 has some side effects for someone (I think to people using a mouse instead of a touchpad),

I doubt it can produce side effects. Albeit psm packet parser is replaced with Xorg`s one, PS/2 device recognition is still relies on in-kernel probe() function. So Xorg can not handle any PS/2 devices unknown to base system.

I think this is the solution to adopt: if we want touchpads to work out of the box, we can not ask users to start moused before xorg. Of course, they can add moused_enable="YES" to their rc.conf, but if we can make a small change to the xf86-input-mouse port it looks much easier: it affects only users of xorg and avoids to run a daemon on the system.

Better solution is to run moused from devd exactly like it is done for ums(4), but it does not work for me now.

In D20507#443112, @phascolarctos_protonmail.ch wrote:

I prefer solution 1.
If you can tell me which is the line to comment or provide a patch I can test it.

After some digging it appeared that xf86-input-mouse unconditionally enables so called "native operation level" being attached to /dev/psm0 device node. It means that it effectively replaces our kernel driver with his own PS/2 packet parser.
So we have 2 choices:

1. Forbid enabling of "native operation level" in xf86-input-mouse driver. It looks like commenting out one #define line
2. Force all touchpad users to run moused to grab /dev/psm0 device and reroute its packets via /dev/sysmouse before Xorg is started.

In D20507#443011, @phascolarctos_protonmail.ch wrote:

(written while wulf was writing his comment. Now I'm going to try his suggestions.)

In D20507#442998, @phascolarctos_protonmail.ch wrote:

I think libinput does not see my touchpad at all. Here is a log with the mouse driver installed:

Count this "accept" as "commit approval"

Given the fact that horizontal scrolling with sysmouse protocol is not supported by userland software out of boх, I joined both hor & ver sysctls into common "natural_scroll" one to not confuse users.

One more question:

Hi Nyan,
Could you upload the diff as fullcontext diff next time. See https://wiki.freebsd.org/Phabricator

git diff -U999999 other-branch > change.diff
git show -U999999 <commit-hash> > change.diff
svn diff --diff-cmd=diff -x -U999999 > change.diff`

It is not necessary to reupload current diff

I hope you won't mind if I change sysctl name from "input_id" to "id" and disable exposure of optional properties like "uniq" and "phys" if they are not set. Just to be consistent with ioctl interface.

In D18694#409332, @greg_unrelenting.technology wrote:

added missing EVDEV_UNLOCK

One thing I dislike in this patch is a native/cuse evdev handling inconsistency.
To handle native device creation one should listen for EVDEV devd events while to handle cuse devices CDEV devd events should be processed.
You can not just listen for CDEV devd events as there is a race window between cdev and sysctl creation.
I think this can be fixed with using of single sysctl node. See kern.geom.confxml or kern.geom.conftxt for example.

linux/input.h is a list of magic numbers required at build time only. It should be kept in BUILD_DEPENDS IMO.

I am AFK for now and will be for ~2 weeks

In D18694#398967, @greg_unrelenting.technology wrote:

Though I wouldn't say it's only a "deprecated" option — we're not going to require userspace uinput drivers to explicitly identify themselves..

I am objecting to EvdevProbe()-derived part (device type autodetection). It is better to add a KPI to set device type directly rather then via execution of libmagic. We have about 10 evdev drivers in source tree so it's possible to update them all. EvdevProbe()-derived part could be used as (deprecated) fallback option in that case.

I hope -1700 value is tested. It does not work for my "softbuttons bar at a bottom" laptop leaving softbutton area outside reportable region so I have to use -2200 to make it working. But "softbuttons bar at a top" touchpad should behave differently here.

Please assign hw.psm.synaptics.softbuttons_y sysctl some negative value so /dev/psm0 users get benefits from this change too.

I am unaware of any current ill effects

D17687 committed as r339917 made remaining parts of this revision senseless.

Most important parts has been committed as r339823 and r339824. They fix evdev/KDB interaction with disabling dangerous codepaths.
This way raised some objections in the past which is addressed in remaining part of the review (true lockless mode). But, I dislike this part as It introduces some complications like polling callouts. That is why it has not been committed yet.
The further plan is to wait untill r339823/r339824 MFC and than abandon this revision if no new objections raised.

Skip HID descriptor reading if WMT_IGNORE quirk is enabled.

In D15070#377715, @zeising wrote:

What is holding this from going in to the tree?

In D16721#377716, @zeising wrote:

Hi!
Is it possible to split this revision into two parts? I'd like to see the EVDEV support go in, especially the option, since that can't be done runtime. The wmt device can be loaded at runtime and doesn't need to be in the kernel, I believe.

In D15070#377715, @zeising wrote:

What is holding this from going in to the tree?

Regenerate diff after r337720

Hi Roberto,

Please, test this patch on top of unmodified wmt.c:

To make things easier I attached the patch that does p.3. and p.4.

In D16721#357529, @hselasky wrote:

So basically we only need device evdev and optinos EVDEV_SUPPORT in GENERIC?

hid_report_size() should not be used unconditionally here as it calculates total size of all input reports rather than size of one given report. I guess that something wrong with HID descriptor

Useless softc casts removed

Workaround knlist_cleardel() 'Mutex owned' assertion that happens on 'lockless' device detach.
It is caused by devfs which calls evdev_dtor() with driver's lock (Giant) already taken.

#if 1 replaced with #if __FreeBSD_version >= 1200000