On Thu, Jul 28, 2016 at 08:53:26PM +0200, Lars-Peter Clausen wrote:

> But our kernel frameworks are designed around application specific tasks.

> * ALSA is for audio data capture/playback
> * V4L2 is for video data capture/playback
> * DRM is for video display
> * IIO is for sensor data capture/playback

Plus as we were discussing elsewhere hwmon, power_supply, input and
probably others that aren't springing to mind right now that also
represent sensor values out to userspace.

> And this is not just hypothetical I've seen questions how to make this
> work repeatedly. And I also expect that in a time constraint environment
> people will go ahead with a custom solution where they capture audio
> data through V4L2 and just ignore all data type hints V4L2 provides and
> re-interprets the data since their specialized application knows what
> the data layout looks like.

I've also seen cases (indeed I've got one myself right now) where the
opposite case applies and it's a lot easier to put a chip into a
hardware class it wasn't really designed for because the userspace
interfaces we offer are much more appropriate for that application.  In
that case it's a chip that really wants to be hwmon but libiio is
*really* nice.

> So going forward we might have to address this by creating a more
> generic interface that allows us to exchange data between a peripheral
> and a application without assigning any kind of meaning to the data
> itself. And then have that meaning provided through side channels. E.g.
> a V4L2 device could say this over there is my data capture device and
> the data layout is the following. Similar for the other frameworks that
> allow capture/playback.

Those side channels are the most tricky bit I fear.

> This of course would be a very grand task and maybe we'll loose
> ourselves in endless discussions about the details and all the corner
> cases that need to be considered. But if we want to find a solution that
> keeps up with the current trend that the hardware landscape seems to be
> going in we might have no other choice. Otherwise I'd say it is
> inevitable that we see more and more hardware which has multiple
> drivers, each driver handling a different type of application.

It's a worthwhile goal to bring things together.  I wonder how hard
it'd be to get ALSA to interact with the v4l buffer style...