Most changes has been committed with r487789

Small fix

Evdev headers now are downloaded from torvalds/linux github repository not from libevdev port
PR/196678 is excluded as it should be the part of future xorg-server update proposed by mrezny@. (I hope it will happen, better sooner than later)
devel/libevdev, devel/py-evdev, devel/evemu & x11/libinput versions are bumped
PR/219264 (x11/libwacom: install the profiles of tablets) is leaked into the patch, but it can be removed if necessary

IMO it is far beyond accepted level of uglyness. Making high-profile API depend on the compiler settings does not make the API usable. Also, does this trick work for C++ ? The union vs. padding either would not work or require even more magic for big endian arches.

I did not changed type of udata, the later would cause serious API incompatibilities.

Abandoned in favour of D10265

Finally I found out how to abandon revision after some googling. It is not very intuitive.

IMO, this driver can be written in generic way

Change is obsolete.
After some discussion with bde@ (on arch@ and private) it is turned out that nothing but Giant can be used to serialize access to I8042 ports currently.
Although it is possible to move psm softc from Giant to private mutex that would complicate things as all calls to I8042 should be done with Giant taken so psm mutex should be released at this time.

Change is obsolete.
After some discussion with bde@ (on arch@ and private) it is turned out that nothing but Giant can be used to serialize access to I8042 ports currently.

Giant-locked version of the patch.
After some discussion with bde@ (on arch@ and private) it is turned out that nothing but Giant can be used to serialize access to I8042 ports currently.
This version obsoletes part1 and part2 and can be applied to unmodified CURRENT (and 11STABLE as well).

could you email link to this review to freebsd-arch@

"evdev support part 4" -> "evdev support part 0". Part 3 is dependent on some of these changes.

Device names and product IDs of supported touchpads and trackpoints are updated to match Linux

Device names and product IDs of supported touchpads and trackpoints are updated to match Linux

Reduce default synaptics touch sensitivity to make libinput tap detection more reliable.
Remove extraneous checks for relative motion events with value = 0. It is already done inside evdev.ko

Changes are not independent (evdev depends on psm that depends on atkbdc), but there should be no errors at each step if they are applied one by one in ascending order
I had split them and created following reviews: https://reviews.freebsd.org/D10263, https://reviews.freebsd.org/D10264, https://reviews.freebsd.org/D10265 and https://reviews.freebsd.org/D10266
Last (10266) change is not split on independent parts yet. I will do that ASAP.

I will broadcast CFT of this change on current- and mobile- lists in couple of days

Yep, I was basing this change off of another driver that had a TODO there. I can actually parse it out though.

We do not provide some of ioctls (EVIOCGMASK & EVIOCSMASK) in kernel but

1. There is userspace evdev implementation in ports tree (multimedia/webcamd) that handles them
2. libevdev has some built in runtime features checks, e.g. it can query uinput protocol version (4 or 5) at runtime and choose appropriate ioctls. It currently do not have checks for EVIOC*MASK as do not wrap these services yet.
3. libevdev usually wants recent headers to compile and tries to do #2 to work on older kernels
4. Newer versions of headers contains newer event codes definitions that can be used with older kernels.
5. If some software does want check supported ioctls at compile time it always possible to replace #include <linux/input.h> with #include <dev/evdev/input.h> in sources

I suggest to change headers ports name from libevdev-headers to just evdev-headers to clear this confusion

These headers are not library interface, but a kernel one. I extract them from libevdev not from linux kernel because libevdev is main consumer, always contains updated version and have relatively small filesize.
FreeBSD have native versions of these headers located in /usr/include/dev/evdev/ but as evdev interface evolves faster than our release cycle, they have limited usage in ports system.

Do you have sample of description of absolute device obtained on Linux with evemu-record or similar tool?

In D7588#200149, @hselasky wrote:

Hi,

What tests have you done?

PR/217248 - devel/libevdev: update to 1.5.6, fix outdated and broken evdev headers (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217248) has been created

Move sed scripts for patching evdev headers to devel/libevdev and remove Mk/Uses/evdev.mk
Chase for xorg-server 1.18.4 update

Ports versions updated.
Diff rebased to current ports tree.
Not very extensively tested.

Full-context diff

Do not report leds and repeat settings changes if kern.evdev.rcpt_mask sysctl value forbids that

Copy serial line configuration black magic from xf86-input-keyboard driver to xorg-server console configuration routine.
This allows prevent interference between terminal and xorg-server screen output when xorg is configured for evdev rather than terminal keyboard input.

For reasons unclear to me FreeBSD does not use const modifier in similar cases. Grep sources for e.g. struct fileops, struct vop_vector, struct cdevsw, struct filterops declarations.

ukbd(4): D7957

1. Remove webcamd from patch as it has been commited already
2. libevdev 1.5.2->1.5.4
3. Make multimedia/v4l_compat not depending on devel/libevdev-headers. Fix couple (all?) of ports to be compileable with this change.

In D7863#163337, @hselasky wrote:

@wulf_cicgroup.ru

Have you thought about if it is better to have a MODULE_DEPEND on evdev.ko instead of all the ifdefs?

I thought of it but was stopped every time at sysmouse support as it is part of sc/vt and can not be kldloaded thus making evdev always loaded.
But I didn`t think about making sysmouse evdev support as module itself till now.

In D6998#163131, @emaste wrote:

A little note, you can use the review number by itself (e.g. just D7863) and Phabricator will automatically add the link, and also reference this review from the one mentioned.

Thanks for pointing that out.

In D6998#163107, @gonzo wrote:

Vladimir, could you submit devices' evdev patches to differential? I suggest starting with USB devs, one device per review. I talked to Hans, he's OK with reviewing them

In D6998#162251, @dumbbell wrote:

In D6998#162223, @gonzo wrote:

I guess it's time to commit this change. Jean-Sébastien would you commit it as a maintainer of all things input? Or if you don't have spare cycles I can do it myself.

I barely improved Synaptics support years ago. But I have a lot of interest in this topic.

Diff updated. It would be nice to commit https://reviews.freebsd.org/D7588 as well to allow multimedia/webcamd coexistence. 11-servers/xorg-server change can be postponed if someone thinks it too radical

Fix compiling with INVARIANTS disabled
Fix EVIOCGKEYCODE* ioctls direction
Split input.h on input.h(ioctls) and input-event-codes.h(event codes) like Linux did
Clear uinput device state after UI_DEV_DESTROY ioctl
Declare uinput as kernel module. Not kldload-able yet.
Reduce KPI(evdev.h) on API (input.h) dependence through removing struct input_absinfo from evdev_support_abs() arguments

This revision fails to compile with INVARIANTS disabled. I fixed that in my repo and I`m going to update diff in this review in hour or two with couple others minor fixes

In D6998#159709, @hselasky wrote:

If kernel drivers are supposed to supply events, then it is a problem to use an SX lock, because many drivers hold a mutex when they generate events. And locking SX after MTX is an issue. If this layer is only intended for loopback of events via user-space it is fine.

Evdev ports support is submitted for review here: https://reviews.freebsd.org/D7588

In D7588#157689, @kwm wrote:

So you have a, simple if possible, way to test the above changes?

Mk/Uses/evdev.mk evdev ARGS comments reworded
multimedia/webcamd updated to 4.8.0.4

In D7588#157689, @kwm wrote:

So you have a, simple if possible, way to test the above changes?

If you want to test above changes "in hardware" I can try to make webcamd patch to workaround "missing usb serial number" issue so it will be possible to attach webcamd to usb keyboards and mouses. Webcamd interface should exactly match its in-kernel counterpart since v.4.8.0.2

In D7588#157689, @kwm wrote:

So you have a, simple if possible, way to test the above changes?

Remove leaked file

In D6998#155829, @hselasky wrote:

I've now updated the SVN version of webcamd with the input.h and ioctl.h patches you've provided.

Thank you!

In D6998#155649, @hselasky wrote:

I understand what you mean. Could you change the Linux IOCTL header file in your webcamd patch instead of redirecting the IOCTLs in the IOCTL handler? I think then you only need to add code for the generic VOID IOCTL copy-in of the argument and you can keep the IOCTL of type VOID?

In D6998#155552, @kmacy wrote:

I don't understand this restriction. cxgb(9) and other drivers I've worked on are perfectly capable of handling nested copyins.

Would it be better to integrate this driver by way of the linuxkpi where this isn't considered a problem?

In D6998#155480, @wulf_cicgroup.ru wrote:

In D6998#155472, @hselasky wrote:

Can this be changed so we avoid patching webcamd?

Just now webcamd should return EFAULT on these ioctls
After switching outer headers to use IOWINT they should return EINVAL or something similar
And after both patching webcamd and switching to IOWINT they should start to work

So with avoiding of patching you would not make things worse

In D6998#155472, @hselasky wrote:

Can this be changed so we avoid patching webcamd?

In D6998#155472, @hselasky wrote:

What is the motivation behind using IOWINT() for FreeBSD IOCTLs and IOW(xxx, int) for Linux ones. Does this mean we are not binary compatible with Linux? Can this be changed so we avoid patching webcamd?

In D6998#154695, @hselasky wrote:

In D6998#154695, @hselasky wrote:

@adrian

I need to patch webcamd and figure out how I can dynamically detect if this EVDEV driver is loaded or not.

Committing this AS-IS will break /usr/ports/multimedia/webcamd which many people use.

Ooops. Forgot to attach evdev_private.h

• split evdev.h header on public and private parts
• make debug messages configurable on config stage as Adrian suggested
• uinput locking reworked (userspace calls are fully serialized now)
• some small fixes like EV_EOF/POLLHUP on revoked/detached device

In D6998#154470, @adrian wrote:

What's it been tested on/with ?

In D6998#147849, @hselasky wrote:

When your /dev/uinput device closes, does it wakeup the children devices and make them return an error?

Yes it does wakeup and than returns ENODEV on every file operation like Linux does
Case I false-reported happened with cuse-backed devices not with uinput ones

In D6998#147849, @hselasky wrote:

When your /dev/uinput device closes, does it wakeup the children devices and make them return an error? That might be the problem. Or is the xorg-event driver not checking read() / poll() for errors. Detach needs to work. Can you investigate?

In D6998#147567, @hselasky wrote:

cuse bug: Can you see if any devices have opened /dev/input handles to evdevs using fstat? There should be no bug there.

In D6998#146760, @hselasky wrote:

Can you propose a patch for webcamd to use the kernel's /dev/input/eventX layer?

Done

Implements passing events from user to userspace drivers like webcamd via uinput interface

In D6998#147328, @hselasky wrote:

In D6998#146955, @hselasky wrote:

Thank you for your patch. I'll see if I can give it a spin.

Thank you too. I tried it and it found it working (after some fixes).

In D6998#146797, @emaste wrote:

Next time please upload with full context -- see https://wiki.freebsd.org/CodeReview. For git, it's just git diff -U9999, for svn svn diff --diff-cmd=diff -x -U999999. No need to re-upload now just to include the context but please do so if/when you have other changes to upload in this review.

In D6998#146760, @hselasky wrote:

Can you propose a patch for webcamd to use the kernel's /dev/input/eventX layer?

Many people are using it on their desktops, so this must work smoothly.

Could you try following patch? http://195.170.219.74/webcamd-20160628.patch
It is compile tested only due to lack of webcam-supported hardware so it can do something other than intended. It should create both cuse-cdev as /dev/input/webcamdXX and its uinput alter-ego as /dev/input/eventXX

In D6998#146718, @hselasky wrote:

Are you aware about the following PR and attached patches:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678

In D6998#146721, @hselasky wrote:

Can you propose a solution how webcamd and kernel's evdev can co-exist in /dev/input? For example

Use different node names? eventXX for userspace bsdeventYY for the kernel?

Best solution is to use uinput interface instead of cuse

In D6998#146685, @hselasky wrote:

Hi,

Did you test that your implementation does not interfere with /usr/ports/multimedia/webcamd

It tries to choose next device unit number if make_dev returned EEXISTS but real coexistence has not been tested
Is webcamd able to create dummy event device? Is webcamd supports a case when /dev/input/ already populated?

and the V4L linux compat files?

Both (reviewed and v4linux) headers can not be #included at one time, but they are compatible.
Really, I use patched V4L linux compat headers for userland evdev stack parts to ease of porting not headers from this review:
http://195.170.219.74/evdev-ports-20160628.diff

Remove some leaked lines