On Sat, Nov 17, 2012 at 1:44 AM, Markus Grabner <[email protected]> wrote: > On Friday 16 November 2012 07:05:09 Stefan Hajnoczi wrote: >> On Thu, Nov 15, 2012 at 11:38 PM, Markus Grabner <[email protected]> > 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 ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Line6linux-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/line6linux-devel
