Re: [PATCH RFC 0/8] Input: atmel_mxt_ts - raw data via debugfs

[Henrik Rydberg]

>> I understand that the current controller and firmware you are working on
>> is not suitable for actual processing and the data rate is only useful
>> for diagnostic. This does not mean however that we can't use the same
>> high-speed interface for both diagnostic and processing, if such
>> interface is available. And given that there is desire to do some of the
>> host-side processing I'd prefer to standardize on interface that is
>> suitable for both instead of stuffing driver-specific bits into debugfs.

[snip]

> All that said, my hope is that there is room for both APIs so we can retain some
> simple console accessible debug API that works with typical shell commands,
> (cat, hexdump, sed, awk) to support simple testing, while the high performance
> userspace processing API gets what it needs too, which I would think should
> include some low-latency means of getting input events back into the kernel
> without needing uinput.

The notion of a simple high-speed input interface is surely attractive, but
perhaps the mismatch in scope says something important here.

For high-speed io, there are several subsystems that can be used as-is: video,
sound and iio for instance. The last one has matured through industrial beating,
and is now heavily used for bidirectional io (adding Jonathan).

But for the input subsystem, the versatile io device stands in juxtaposition to
the generic userland interface, which is the essence of the objection here.
Input devices and their capabilities should be easily enumerable and
recognizable. An ad-hoc debug interface is not.

So if we see an interest to incorporate high-speed io nodes in the world of
enumerable input devices, maybe it can be as easy as tucking some property and
control ioctls on top a device node driven by any or all of the mentioned
subsystems. It ought to be even simpler to use than debufs. You should certainly
be able to use it as you describe.

Henrik