Re: [Line6linux-devel] Status of line6 staging cleanup

[Stefan H. <ste...@gm...>]

On Thu, Nov 15, 2012 at 1:11 AM, Markus Grabner <gr...@ic...> wrote:
> On Wednesday 14 November 2012 08:45:24 Stefan Hajnoczi wrote:
>> The sysfs attributes involve MIDI commands and some state.  If we
>> leave this to userspace then the kernel driver can focus on PCM and
>> MIDI I/O.  The code will become much smaller and simpler because we
>> can drop all the peeking into MIDI buffers and the housekeeping that
>> goes along with that.
>>
>> Letting userspace handle MIDI means that line6linux development
>> becomes accessible to a wider group of developers - people not
>> comfortable with C or driver hacking.  It encourages people to explore
>> their devices and contribute code.
> I agree with all of that. Let me point to a document which I started to write
> a year ago when we first briefly discussed this:
>
> https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/doc/design.tex
>
> The sysfs attributes are ugly, but very convenient for development and
> testing. I don't want to remove them without having a similarly convenient
> replacement, that's why I started to write some code according to the ideas
> discussed in the abovementioned document. Feel free to comment on this!
>
> One particular question is how to best control the driver's behaviour (e.g.,
> the midi masks) from user mode. I can imagine at least two methods:
> *) using ioctl() calls
> *) defining a virtual MIDI device for communication with the driver
>
> Are there more options, and what would be considered best practise in this
> case?

Either ioctl() or sysfs is okay.  ioctl() is very easy for C/C++
applications to use if they already have a file descriptor.  For
human-readable data sysfs is nicer since it can be accessed easily
from a shell session.  The challenge with sysfs is locating the device
directory, but this could be done given the ALSA device numbers.

The design document you posted looks sane and well thought out.  I
think the main "meat" of the library will be the data tables for each
supported device.  Ideally the library code would not hard-code names
(e.g. amp1_gain, wah_position) but instead use self-describing data
tables.  The advantage here is that developers can easily add new
tweak parameters by modifying the data tables.  The only piece of
software that needs to understand the parameter names is the GUI, and
even there we could try to use a data-driven approach.

In other words, the library doesn't need enums for all possible
parameters.  Instead you could say line6_set_param(dev,
"master_volume", 0x40), which looks up "master_volume" in the device's
data table.  That produces a MIDI message (PC, CC, or SysEx).

When the device sends MIDI messages to the host in response to the wah
pedal, for example, the library uses the data table to translate from
the MIDI message to event_param_changed(dev, "wah_position", 0x7f).

The design document doesn't cover whether to make the library stateful
or not.  A stateless library simply transmits and receives events on
behalf of the application.  A stateful library keeps a "current value"
stored for every parameter in the data table so that the application
can retrieve it quickly.  My feeling is that a stateless library is a
good thing but there is a risk that applications will duplicate code,
so we'd have to watch out if we find ourselves reimplementing the same
state code in multiple applications.

A small detail that came to mind: transmitting MIDI should be
asynchronous just like receiving MIDI is.  The reason for this is that
sending large commands (e.g. restoring saved presets) should not block
the GUI.

Is there code to implement this design?

Stefan