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

Maybe you should bump the __FreeBSD_version due to changing a structure size.

No need. hid_data is private structure

In D15070#322602, @dumbbell wrote:

I continued to use the initial patch for a few days and got several similar panics (5 in total). The three panic strings I encountered are:

• panic: mutex Giant owned at /mnt/home/dumbbell/Projects/freebsd/src/GIT/sys/kern/kern_event.c:2288
• panic: sleepq_add: td 0xfffff8001875d560 to sleep on wchan 0xffffffff836e0fc0 with sleeping prohibited
• panic: page fault
  
  The backtrace is always the same and is the one I shared earlier.

Unfortunately, it looks like backtrace of a panic in the kernel dumper. Actual panic precedes it

Sorry for bad wording. Could you start from p.1: revert only ukbd.c, kbdmux.c and atkbd.c. This should effectively revert all changes

In D15070#321033, @dumbbell wrote:

However, I got two panics:

In D15070#320905, @dumbbell wrote:

Do you have any advice to reproduce the deadlock when the patch is not applied?

ping...

Apply manpage fixes by Warren Block