Anybody working on line6?

Stefan Hajnoczi stefanha at gmail.com
Fri Jun 27 04:41:02 UTC 2014


On Fri, Jun 27, 2014 at 1:39 AM, Greg KH <gregkh at linuxfoundation.org> wrote:
> On Tue, Jun 24, 2014 at 10:12:03PM +0800, Stefan Hajnoczi wrote:
>> On Tue, Jun 24, 2014 at 9:52 PM, Greg KH <gregkh at linuxfoundation.org> wrote:
>> > On Tue, Jun 24, 2014 at 11:54:10AM +0800, Stefan Hajnoczi wrote:
>> >> On Tue, Jun 24, 2014 at 4:23 AM, Kristina Martšenko
>> >> <kristina.martsenko at gmail.com> wrote:
>> >> > I'm helping Greg do a bit of cleanup in the staging tree. I noticed that
>> >> > nobody seems to have worked towards moving line6 out of staging in over
>> >> > a year. Are there any plans to clean it up and move it out soon? Because
>> >> > otherwise we're going to have to delete the driver, as we don't want
>> >> > staging to become a permanent place for unfinished code.
>> >>
>> >> I do not have time to resume the work and am moving to new hardware in
>> >> a few weeks.
>> >
>> > Do you know of anyone else using this hardware on Linux?
>>
>> Markus Grabner is the maintainer and still the best person to involve.
>>
>> People have popped up from time to time on the line6linux-devel
>> mailing list but no one has stuck around:
>> http://sourceforge.net/p/line6linux/mailman/line6linux-devel/
>>
>> >> It's a shame since the driver is in a pretty good position for further
>> >> cleanups and a move out of staging/.  There's not that much left to do
>> >> but the rate of progress at the moment is zero.
>> >
>> > If the code is "almost" ready to move, what do you think is left to do?
>>
>> 1. Run checkpatch.pl again to make sure there are no coding style
>> issues remaining.
>>
>> 2. Audit remaining sysfs attributes and drop them where possible.  I
>> killed off the easy ones which just sent MIDI messages that userspace
>> can send just as easily.  Now only the weird ones are left:
>>
>> drivers/staging/line6/pcm.c:static DEVICE_ATTR_RW(impulse_volume);
>> drivers/staging/line6/pcm.c:static DEVICE_ATTR_RW(impulse_period);
>> drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(device_id);
>> drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(firmware_version);
>> drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(serial_number);
>> drivers/staging/line6/toneport.c:static DEVICE_ATTR(led_red, S_IWUSR |
>> S_IRUGO, line6_nop_read,
>> drivers/staging/line6/toneport.c:static DEVICE_ATTR(led_green, S_IWUSR
>> | S_IRUGO, line6_nop_read,
>>
>> Are sysfs attributes appropriate userspace ABIs for these parameters?
>> Should ioctls be used instead?
>
> Are these even needed at all?  Do people care about them?

Probably not.

> serial number
> and firmware version seems trivial and not needed.  leds should use the
> led kernel interface instead.  device_id is not needed as that's in the
> sysfs "name" already.

Most users probably care about audio and MIDI only.  The sysfs
attributes are probably not needed.

The serial number and firmware version would be used for firmware
upgrades but I wouldn't recommend trying that anyway.  They can be
added back later, if someone wants to develop and test a firmware
upgrade tool (and brick their device).

> So that leaves impulse_volume and period.  What are these?  Are there
> any MIDI interfaces that use them?

There is an impulse response test built into the driver.  It's a
compile-time option that is disabled by default.  It can be used to
analyze signal processing and latency from the device.

I asked Markus whether we can drop this and do it in userspace.  Due
to the buffering in some devices, it is only possible to do this
correctly in the kernel driver.  There is a line6linux-devel email
thread about it:
http://comments.gmane.org/gmane.comp.audio.line6linux.devel/171

If this is the last hurdle to getting the driver out of staging, then
I think the impulse response feature should be dropped from the
driver.  It can be added back later (if necessary).

Stefan


More information about the devel mailing list