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

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

On Sat, Nov 17, 2012 at 1:44 AM, Markus Grabner <gr...@ic...> wrote:
> On Friday 16 November 2012 07:05:09 Stefan Hajnoczi wrote:
>> On Thu, Nov 15, 2012 at 11:38 PM, Markus Grabner <gr...@ic...>
> wrote:
>> > Am Donnerstag, 15. November 2012, 08:16:25 schrieb Stefan Hajnoczi:
>> I'm not sure what the best practice is, I guess we'll see when
>> submitting the patches to move the driver out of staging.
>>
>> The only problem I see with sysfs is that it's not clear to me how to
>> control file ownership.  Typically we need the 'audio' group to own
>> the attrs so regular users can read/write them.  sysfs supports
>> chmod(2)/chown(2) but I don't know whether udev(7) rules can apply
>> ownership on sysfs attributes.
> After reviewing the sysfs entries, I noticed that the MIDI mask and MIDI post
> processing flags are the only ones which do not directly translate to a
> message sent to the device, but affect driver state instead. The MIDI
> postprocessing can be moved to user space if necessary, the MIDI masks were
> introduced several years ago to make the driver play nicely with the
> rosegarden MIDI sequencer (I didn't check since then if this is still
> required). Unfortunately ioctl calls seem to be possible only for ALSA PCM
> devices, but not for ALSA MIDI devices, so we might lose this masking
> functionality if we take the ioctl approach, but I don't consider this high
> priority. The TonePort LEDs could be controlled via ioctl calls on the
> TonePort's PCM device, though :-)
>
>> > The CSV table approach discussed in Section 4.4 of the design document
>> > comes close to the self-describing data tables you mention above: all
>> > relevant relations (e.g., the mapping between USB product ids and device
>> > names, or between device parameters and corresponding MIDI byte codes)
>> > are defined and edited in CSV files, which are automatically converted to
>> > corresponding C++ code (enums, tables, maps, etc.) during the build
>> > process. The application can then use these symbols as desired, and
>> > consistently adding a new parameter to all relevant enum lists, tables,
>> > maps, etc., is as easy as adding a single row to a CSV table. The created
>> > files should contain a prominent notice that they were created
>> > automatically, with a reference to the input file (this is not yet
>> > implemented).
>> >
>> > The perl script that does all this magic (parse_data.pl) is actually the
>> > most complex piece of software in the user space code repository at this
>> > time :-)
>> Cool :).  I should try adding POD HD300 support.
> That would actually be a great test for the flexibility of the framework! The
> following steps are required:
>
> *) edit the csv-tables in
> https://line6linux.svn.sourceforge.net/svnroot/line6linux/apps/branches/qtbased/libline6comm
> according to the HD300. The table "tablecodeparam.csv" maps a MIDI byte code
> (first number in each row after "data") to the corresponding device parameter.
> I don't know if the HD300 behaves similarly (i.e., a single byte is sufficient
> to distinguish the different parameters in the MIDI message). Your USB monitor
> will tell you.
>
> *) If the MIDI message format is different from the PODxt, you need to create
> a class representing the HD300 and implement a suitable
> HD300::midiMessageReceived(). See the files "pod.hpp" and "pod.cpp" for how
> this is done for the PODxt devices.
>
> *) The shell is initialized by some hard-coded parameters in "shell.cpp",
> these need to be changed according to your system (it would be useful if the
> Stream class had a static method which lists all available devices such that
> the user can choose one -> TODO).

Thanks for the pointers.  I'll try it out this week.

Stefan