line6linux-devel — mailing list for developers of Line6 Linux software

Re: [Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation

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

On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet <lau...@gm...> wrote:
> staging: line6: driver.c
>  The semantic patch that makes this output is available
>  in scripts/coccinelle/api/memdup.cocci.
>
> Signed-off-by: Laurent Navet <lau...@gm...>
> ---
>  drivers/staging/line6/driver.c |    5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
> index f5c19b2..e1d6241 100644
> --- a/drivers/staging/line6/driver.c
> +++ b/drivers/staging/line6/driver.c
> @@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6 *line6)
>         char *buffer;
>         int retval;
>
> -       buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
> +       buffer = kmemdup(line6_request_version,
> +                       sizeof(line6_request_version), GFP_ATOMIC);
>         if (buffer == NULL) {
>                 dev_err(line6->ifcdev, "Out of memory");
>                 return -ENOMEM;
>         }
>
> -       memcpy(buffer, line6_request_version, sizeof(line6_request_version));
> -
>         retval = line6_send_raw_message_async(line6, buffer,
>                                               sizeof(line6_request_version));
>         kfree(buffer);
> --
> 1.7.10.4

Your change is fine but I'm not sure whether we should allocate memory
in the first place:

line6_send_raw_message_async() returns before the transfer is
complete.  It submits one or more URBs but I cannot see a guarantee
that the buffer is no longer needed.  It seems unsafe to kfree(buffer)
before the request is complete.

Since we already have const char line6_request_version[] we should
pass it directly without a temporary kmemdup() buffer.

Stefan

[Line6linux-devel] [PATCH] line6: Use kmemdup rather than duplicating its implementation

[Laurent N. <lau...@gm...>]

staging: line6: driver.c
 The semantic patch that makes this output is available
 in scripts/coccinelle/api/memdup.cocci.

Signed-off-by: Laurent Navet <lau...@gm...>
---
 drivers/staging/line6/driver.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/line6/driver.c b/drivers/staging/line6/driver.c
index f5c19b2..e1d6241 100644
--- a/drivers/staging/line6/driver.c
+++ b/drivers/staging/line6/driver.c
@@ -331,14 +331,13 @@ int line6_version_request_async(struct usb_line6 *line6)
 	char *buffer;
 	int retval;
 
-	buffer = kmalloc(sizeof(line6_request_version), GFP_ATOMIC);
+	buffer = kmemdup(line6_request_version,
+			sizeof(line6_request_version), GFP_ATOMIC);
 	if (buffer == NULL) {
 		dev_err(line6->ifcdev, "Out of memory");
 		return -ENOMEM;
 	}
 
-	memcpy(buffer, line6_request_version, sizeof(line6_request_version));
-
 	retval = line6_send_raw_message_async(line6, buffer,
 					      sizeof(line6_request_version));
 	kfree(buffer);
-- 
1.7.10.4

Re: [Line6linux-devel] [PATCH] staging: line6: pcm.c fix checkpatch issues

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

On Fri, Nov 30, 2012 at 11:57 AM, Laurent Navet <lau...@gm...> wrote:
> fix those checkpatch issues
> drivers/staging/line6/pcm.c:84:
>         WARNING: simple_strtoul is obsolete, use kstrtoul instead
>         call to obsolete simple_strtoul() replaced by kstrtoint()
>
> drivers/staging/line6/pcm.c:423:
>         ERROR: switch and case should be at the same indent
>         realigns comments
>
> Signed-off-by: Laurent Navet <lau...@gm...>
> ---
>  drivers/staging/line6/pcm.c |   30 ++++++++++++++++++------------
>  1 file changed, 18 insertions(+), 12 deletions(-)

Changes are fine.

In the future, please split changes into individual patches.  For example:
Patch 1 - Rename 'rv' to 'ret'
Patch 2 - Replace decprecated simple_strtoul() with kstrtoint() in
pcm_set_impulse_period()
Patch 3 - Realign comment in line6_init_pcm() switch statement

Keeping patches focussed on doing just one thing makes it easier to
revert, bisect, and review them.

Reviewed-by: Stefan Hajnoczi <ste...@gm...>

[Line6linux-devel] [PATCH] staging: line6: pcm.c fix checkpatch issues

[Laurent N. <lau...@gm...>]

fix those checkpatch issues
drivers/staging/line6/pcm.c:84:
	WARNING: simple_strtoul is obsolete, use kstrtoul instead
	call to obsolete simple_strtoul() replaced by kstrtoint()

drivers/staging/line6/pcm.c:423:
	ERROR: switch and case should be at the same indent
	realigns comments

Signed-off-by: Laurent Navet <lau...@gm...>
---
 drivers/staging/line6/pcm.c |   30 ++++++++++++++++++------------
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
index 6c1e313..17969c6 100644
--- a/drivers/staging/line6/pcm.c
+++ b/drivers/staging/line6/pcm.c
@@ -49,11 +49,11 @@ static ssize_t pcm_set_impulse_volume(struct device *dev,
 {
 	struct snd_line6_pcm *line6pcm = dev2pcm(dev);
 	int value;
-	int rv;
+	int ret;
 
-	rv = kstrtoint(buf, 10, &value);
-	if (rv < 0)
-		return rv;
+	ret = kstrtoint(buf, 10, &value);
+	if (ret < 0)
+		return ret;
 
 	line6pcm->impulse_volume = value;
 
@@ -81,7 +81,14 @@ static ssize_t pcm_set_impulse_period(struct device *dev,
 				      struct device_attribute *attr,
 				      const char *buf, size_t count)
 {
-	dev2pcm(dev)->impulse_period = simple_strtoul(buf, NULL, 10);
+	int value;
+	int ret;
+
+	ret = kstrtoint(buf, 10, &value);
+	if (ret < 0)
+		return ret;
+
+	dev2pcm(dev)->impulse_period = value;
 	return count;
 }
 
@@ -455,13 +462,12 @@ int line6_init_pcm(struct usb_line6 *line6,
 		ep_write = 0x01;
 		break;
 
-		/* this is for interface_number == 1:
-		   case LINE6_DEVID_TONEPORT_UX2:
-		   case LINE6_DEVID_PODSTUDIO_UX2:
-		   ep_read  = 0x87;
-		   ep_write = 0x00;
-		   break;
-		 */
+	/* this is for interface_number == 1:
+	case LINE6_DEVID_TONEPORT_UX2:
+	case LINE6_DEVID_PODSTUDIO_UX2:
+		ep_read  = 0x87;
+		ep_write = 0x00;
+		break; */
 
 	default:
 		MISSING_CASE;
-- 
1.7.10.4

[Line6linux-devel] staging: line6: pcm.c fix checkpatch issues

[Laurent N. <lau...@gm...>]

v2 of my previously sended patches, corrected following
dan carpenter and greg kh comments.

Regards,
Laurent.

Re: [Line6linux-devel] Impulse response test

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

On Thu, Nov 29, 2012 at 9:48 PM, Markus Grabner <gr...@ic...> wrote:
> Am Donnerstag, 29. November 2012, 21:18:11 schrieb Stefan Hajnoczi:
>> The Kconfig entry notes that doing the impulse response test inside
>> the kernel avoids buffering/latency issues but it's not clear to me
>> that this code really needs to be in the kernel.  If a userspace
>> impulse response test application uses the same buffer size as the PCM
>> USB traffic, then it should be just as good?
> This is not possible with a PCM API at least for the PODxt since subsequent
> packages in the stream vary in size

Interesting, I didn't know the buffer size can change.

Stefan

Re: [Line6linux-devel] [PATCH] staging: line6: use kstrtoint() instead of simple_strtoul()

[Dan C. <dan...@or...>]

On Thu, Nov 29, 2012 at 09:03:38PM +0100, Laurent Navet [Mali] wrote:
> From: "Laurent Navet [Mali]" <lau...@gm...>
> 
> staging: line6: pcm.c
> 	call to obsolete simple_strtoul() function is replaced
>         by kstrtoint() in pcm_set_impulse_period().
> 	Also check the return code.
> 
> Signed-off-by: Laurent Navet [Mali] <lau...@gm...>
> ---
>  drivers/staging/line6/pcm.c |    8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
> index a0ce781..876ab89 100644
> --- a/drivers/staging/line6/pcm.c
> +++ b/drivers/staging/line6/pcm.c
> @@ -81,7 +81,13 @@ static ssize_t pcm_set_impulse_period(struct device *dev,
>  				      struct device_attribute *attr,
>  				      const char *buf, size_t count)
>  {
> -	dev2pcm(dev)->impulse_period = simple_strtoul(buf, NULL, 10);
> +        int value;
> +        int rv;

This uses spaces instead of tabs.  Run scripts/checkpatch.pl over
the patch before submitting.

Put a blank line here between the declarations and the code.

I see that you copied "rv" from the other places in the file and
generally matching the context is good, but in this case I think
"rv" is non-standard.  Normally we would use "ret" or "rc".

> +        rv = kstrtoint(buf, 10, &value);
> +        if (rv < 0)
> +		return rv;

Could you fix up those small details and resend?

regards,
dan carpenter

Re: [Line6linux-devel] line6 out of staging

[Markus G. <gr...@ic...>]

Am Donnerstag, 29. November 2012, 21:09:35 schrieb Stefan Hajnoczi:
> On Thu, Nov 29, 2012 at 8:55 PM, Markus Grabner <gr...@ic...> 
wrote:
> > Am Donnerstag, 22. November 2012, 21:05:31 schrieb Stefan Hajnoczi:
> >> On Thu, Nov 22, 2012 at 10:49 AM, Stefan Hajnoczi <ste...@gm...>
> > 
> > wrote:
> >> If you'd like to help clean up the staging driver, I suggest starting
> >> with my line6-drop-sysfs-attrs branch (saves you from applying the
> >> patch emails yourself):
> >> https://github.com/stefanha/linux/tree/line6-drop-sysfs-attrs
> > 
> > Do I have to clone the entire thing, or can I somehow "switch" an existing
> > kernel tree to your version, receiving only the changes between the
> > official kernel and yours?
> 
> If you have an existing kernel git tree (linux.git or linux-next.git)
> then you have already downloaded most of the commits.
> 
> Try this to avoid downloading the majority of the kernel commit history:
> 
> $ cd linux # existing linux.git or linux-next.git tree
> $ git fetch git://github.com/stefanha/linux.git line6-drop-sysfs-attrs
> From git://github.com/stefanha/linux
>  * branch            line6-drop-sysfs-attrs -> FETCH_HEAD
> $ git checkout FETCH_HEAD
> 
> Or if you expect to fetch from my repo again in the future, add a remote:
> 
> $ cd linux # existing linux.git or linux-next.git tree
> $ git remote add stefanha git://github.com/stefanha/linux.git
> $ git fetch stefanha
> $ git checkout stefanha/line6-drop-sysfs-attrs
> 
> (Now you can fetch 'stefanha' again in the future to get new branches
> from my repo.)
Thanks, now I received 15MB into an up-to-date linux.git tree (instead of ~1GB 
for the full clone)!

	Kind regards,
		Markus

Re: [Line6linux-devel] Impulse response test

[Markus G. <gr...@ic...>]

Am Donnerstag, 29. November 2012, 21:18:11 schrieb Stefan Hajnoczi:
> I noticed the qtbased svn branch has a userspace signal generator
> tool.  Does this mean we can drop the impulse response test in the
> driver?
No, the signal generator is not related to the impulse response feature.

> The Kconfig entry notes that doing the impulse response test inside
> the kernel avoids buffering/latency issues but it's not clear to me
> that this code really needs to be in the kernel.  If a userspace
> impulse response test application uses the same buffer size as the PCM
> USB traffic, then it should be just as good?
This is not possible with a PCM API at least for the PODxt since subsequent 
packages in the stream vary in size, i.e., whatever buffer size you choose in 
your application (and when using jackd, it even has to be a power of two), it 
will require splitting or merging some data packages, making the measurement 
unreliable.

It might be possible, though, to get similar results when directly accessing 
the device via libusb (which requires unloading the Line6 driver) in an 
application with realtime privileges. I think this is not highest priority, so 
I propose to leave it as is for now and adress this issue later.

	Kind regards,
		Markus

[Line6linux-devel] Impulse response test

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

I noticed the qtbased svn branch has a userspace signal generator
tool.  Does this mean we can drop the impulse response test in the
driver?

The Kconfig entry notes that doing the impulse response test inside
the kernel avoids buffering/latency issues but it's not clear to me
that this code really needs to be in the kernel.  If a userspace
impulse response test application uses the same buffer size as the PCM
USB traffic, then it should be just as good?

Stefan

Re: [Line6linux-devel] [PATCH] staging: line6: use kstrtoint() instead of simple_strtoul()

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

On Thu, Nov 29, 2012 at 9:03 PM, Laurent Navet [Mali]
<lau...@gm...> wrote:
> From: "Laurent Navet [Mali]" <lau...@gm...>
>
> staging: line6: pcm.c
>         call to obsolete simple_strtoul() function is replaced
>         by kstrtoint() in pcm_set_impulse_period().
>         Also check the return code.
>
> Signed-off-by: Laurent Navet [Mali] <lau...@gm...>
> ---
>  drivers/staging/line6/pcm.c |    8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Stefan Hajnoczi <ste...@gm...>

Re: [Line6linux-devel] line6 out of staging

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

On Thu, Nov 29, 2012 at 8:55 PM, Markus Grabner <gr...@ic...> wrote:
> Am Donnerstag, 22. November 2012, 21:05:31 schrieb Stefan Hajnoczi:
>> On Thu, Nov 22, 2012 at 10:49 AM, Stefan Hajnoczi <ste...@gm...>
> wrote:
>> If you'd like to help clean up the staging driver, I suggest starting
>> with my line6-drop-sysfs-attrs branch (saves you from applying the
>> patch emails yourself):
>> https://github.com/stefanha/linux/tree/line6-drop-sysfs-attrs
> Do I have to clone the entire thing, or can I somehow "switch" an existing
> kernel tree to your version, receiving only the changes between the official
> kernel and yours?

If you have an existing kernel git tree (linux.git or linux-next.git)
then you have already downloaded most of the commits.

Try this to avoid downloading the majority of the kernel commit history:

$ cd linux # existing linux.git or linux-next.git tree
$ git fetch git://github.com/stefanha/linux.git line6-drop-sysfs-attrs
>From git://github.com/stefanha/linux
 * branch            line6-drop-sysfs-attrs -> FETCH_HEAD
$ git checkout FETCH_HEAD

Or if you expect to fetch from my repo again in the future, add a remote:

$ cd linux # existing linux.git or linux-next.git tree
$ git remote add stefanha git://github.com/stefanha/linux.git
$ git fetch stefanha
$ git checkout stefanha/line6-drop-sysfs-attrs

(Now you can fetch 'stefanha' again in the future to get new branches
from my repo.)

Stefan

[Line6linux-devel] [PATCH] staging: line6: use kstrtoint() instead of simple_strtoul()

[Laurent N. [Mali] <lau...@gm...>]

From: "Laurent Navet [Mali]" <lau...@gm...>

staging: line6: pcm.c
	call to obsolete simple_strtoul() function is replaced
        by kstrtoint() in pcm_set_impulse_period().
	Also check the return code.

Signed-off-by: Laurent Navet [Mali] <lau...@gm...>
---
 drivers/staging/line6/pcm.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/line6/pcm.c b/drivers/staging/line6/pcm.c
index a0ce781..876ab89 100644
--- a/drivers/staging/line6/pcm.c
+++ b/drivers/staging/line6/pcm.c
@@ -81,7 +81,13 @@ static ssize_t pcm_set_impulse_period(struct device *dev,
 				      struct device_attribute *attr,
 				      const char *buf, size_t count)
 {
-	dev2pcm(dev)->impulse_period = simple_strtoul(buf, NULL, 10);
+        int value;
+        int rv;
+        rv = kstrtoint(buf, 10, &value);
+        if (rv < 0)
+		return rv;
+
+	dev2pcm(dev)->impulse_period = value;
 	return count;
 }
 
-- 
1.7.10.4

Re: [Line6linux-devel] line6 out of staging

[Markus G. <gr...@ic...>]

Am Donnerstag, 22. November 2012, 21:05:31 schrieb Stefan Hajnoczi:
> On Thu, Nov 22, 2012 at 10:49 AM, Stefan Hajnoczi <ste...@gm...> 
wrote:
> If you'd like to help clean up the staging driver, I suggest starting
> with my line6-drop-sysfs-attrs branch (saves you from applying the
> patch emails yourself):
> https://github.com/stefanha/linux/tree/line6-drop-sysfs-attrs
Do I have to clone the entire thing, or can I somehow "switch" an existing 
kernel tree to your version, receiving only the changes between the official 
kernel and yours?

	Thanks & kind regards,
		Markus

Re: [Line6linux-devel] Opened a support ticket with Line6

[L. A. G. <agi...@sy...>]

El 28/11/2012 21:33, L. Alberto Giménez escribió:
> Hi,
>
> I've just opened a support request with Line6. I'm trying to convince the to help us
> to support their hardware on Linux.

Well, this is sad. After adding a message this morning to clarify the 
'reverse engineering stuff' as asked by Markus, now I can't see the 
support ticket anymore.

I have the ID (and the URL 
http://line6.com/account/tickets/edit/195543), but it just redirects to 
the main Support Tickets (empty) page.

There is no 'ticket history' option so I just can't see its state. It 
seems that it has been just deleted, without a mere reply.

I'm thinking of opening a new one saying that 'the old ticket 
disappeared by unknown reasons' and see how do they act, but I think 
that it is a very bad thing for a company to just neglect their users. 
Especially those that are not requesting new features or are bragging 
about when the new firmware will be released, but just want to work on 
them for themselves.

Regards everyone,
L. Alberto Gimenez

Re: [Line6linux-devel] line6 out of staging

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

On Thu, Nov 29, 2012 at 9:40 AM, "L. Alberto Giménez"
<agi...@sy...> wrote:
> El 29/11/2012 7:54, Stefan Hajnoczi escribió:
>
>>
>> Is the device plugged into a USB 2.0 port?
>>
>
> It's connected to an external hub. I don't know if that's the reason of
> lsusb not showing endpoints, but when I connect the device I get this
> message:
>
>
> [  333.697431] usb 1-2.4: new full-speed USB device number 4 using ohci_hcd
> [  333.795169] usb 1-2.4: not running at top speed; connect to a high speed
> hub
>
> I didn't know that would alter the number of endpoints that the device shows
> to the system.
>
> I use a hub just because it's easier to me to reach the hub on my desk with
> the USB cable than the rear of my computer, but I can try to connect
> directly to the root hub and see if I see any changes.

Does it work under Windows through your hub?

Stefan

Re: [Line6linux-devel] line6 out of staging

[L. A. G. <agi...@sy...>]

El 29/11/2012 7:54, Stefan Hajnoczi escribió:
>
> Is the device plugged into a USB 2.0 port?
>

It's connected to an external hub. I don't know if that's the reason of 
lsusb not showing endpoints, but when I connect the device I get this 
message:

[  333.697431] usb 1-2.4: new full-speed USB device number 4 using ohci_hcd
[  333.795169] usb 1-2.4: not running at top speed; connect to a high 
speed hub

I didn't know that would alter the number of endpoints that the device 
shows to the system.

I use a hub just because it's easier to me to reach the hub on my desk 
with the USB cable than the rear of my computer, but I can try to 
connect directly to the root hub and see if I see any changes.


Thanks,
L. Alberto Giménez

Re: [Line6linux-devel] Opened a support ticket with Line6

[L. A. G. <agi...@sy...>]

El 28/11/2012 23:30, Markus Grabner escribió:
> One thing he was curious about is how I found out the protocol by which host
> and device communicate with each other. He told me that it's ok for them if we
> use USB analyzing tools to observe the traffic (which is what I did), but
> reverse engineering the driver by inspecting the machine code is prohibited by
> the Line6 software license. Though the term "reverse engineering" is somewhat
> ambiguous, it might trigger undesired emotions in the context of asking for
> help :-)

Ahhh, I see. I used the 'reverse engineering' as the general term of 
'making something work using (in some way) a working instance and trying 
to replicate its behavior'. Didn't know that it could trigger bad feelings.

>
> I don't know if you can alter the ticket, but if you can, it might be a good
> idea to make clear that we didn't violate their license.

I've been able to "add a message" to the ticket, clarifying that when I 
referred to reverse engineering I meant using USB analyzing tools, not 
disassembling their binary code.

Hope that helps :)


Regards,
L. Alberto Giménez

Re: [Line6linux-devel] line6 out of staging

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

On Wed, Nov 28, 2012 at 9:15 PM, L. Alberto Giménez
<agi...@sy...> wrote:
> On Wed, Nov 28, 2012 at 08:34:52AM +0100, Stefan Hajnoczi wrote:
>> Please post the output of "lsusb -d 0e41:414d -v" while the device is
>> attached.  This will provide the USB capabilities of the device so we
>> can try to find the correct interface, altsetting, and endpoints.
>
> # lsusb -d 0e41:414d -v
>
> Bus 001 Device 010: ID 0e41:414d Line6, Inc.
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass          255 Vendor Specific Class
>   bDeviceSubClass       255 Vendor Specific Subclass
>   bDeviceProtocol       255 Vendor Specific Protocol
>   bMaxPacketSize0        64
>   idVendor           0x0e41 Line6, Inc.
>   idProduct          0x414d
>   bcdDevice            0.00
>   iManufacturer           1 Line 6
>   iProduct                2 POD HD500
>   iSerial                 0
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           18
>     bNumInterfaces          1
>     bConfigurationValue     1
>     iConfiguration          0
>     bmAttributes         0x40
>       (Missing must-be-set bit!)
>       Self Powered
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           0
>       bInterfaceClass       255 Vendor Specific Class
>       bInterfaceSubClass    255 Vendor Specific Subclass
>       bInterfaceProtocol    255 Vendor Specific Protocol
>       iInterface              4 User

This is weird.  There are no endpoints (bNumEndpoints is 0).  The
driver can't make use of this.

> Device Qualifier (for other device speed):
>   bLength                10
>   bDescriptorType         6
>   bcdUSB               2.00
>   bDeviceClass          255 Vendor Specific Class
>   bDeviceSubClass       255 Vendor Specific Subclass
>   bDeviceProtocol       255 Vendor Specific Protocol
>   bMaxPacketSize0        64
>   bNumConfigurations      1
> Device Status:     0x0001
>   Self Powered

Is the device plugged into a USB 2.0 port?

Stefan

Re: [Line6linux-devel] Opened a support ticket with Line6

[Markus G. <gr...@ic...>]

Am Mittwoch, 28. November 2012, 21:33:03 schrieb L. Alberto Giménez:
> Hi,
> 
> I've just opened a support request with Line6. I'm trying to convince the to
> help us to support their hardware on Linux.
Thanks for initiating this! I have one comment on the text:

> Currently there is a reverse-engineered driver that works with old hardware
> (latest supported POD is the HD300), but it doesn't support all features,
> and it's quite hard to support new devices.
Quite a while ago when Line6 noticed that a Linux driver is being developed 
for their hardware, they contacted me (yes, the other way round :-), and I had 
a brief conversation with a developer who provided some useful information. 
Unfortunately this guy doesn't seem to work at Line6 now, at least I didn't 
get a response when I tried to contact him again later.

One thing he was curious about is how I found out the protocol by which host 
and device communicate with each other. He told me that it's ok for them if we 
use USB analyzing tools to observe the traffic (which is what I did), but 
reverse engineering the driver by inspecting the machine code is prohibited by 
the Line6 software license. Though the term "reverse engineering" is somewhat 
ambiguous, it might trigger undesired emotions in the context of asking for 
help :-)

I don't know if you can alter the ticket, but if you can, it might be a good 
idea to make clear that we didn't violate their license.

	Kind regards,
		Markus

[Line6linux-devel] Opened a support ticket with Line6

[L. A. G. <agi...@sy...>]

Hi,

I've just opened a support request with Line6. I'm trying to convince the to help us
to support their hardware on Linux.

The full text is:


----------- 8< -------------------------------------------------
Hi,

I'm a happy POD HD 500 user, but my main operating system at home is Linux. In order
to use the full power of your awesome device, I'm forced to use a Windows operating
system.

I set up a poll for all HD users (http://line6.com/support/polls/1158), and as you
can see even with a relatively small sample, there's a good part of your customers
that would like to see their hardware supported under Linux systems.

I'm not asking that you do the work. That's the greatness of a community-driven
development model like Linux. There is a group of people willing to write the drivers
for you. Even an Edit 500-like software to take all the possible advantage of the
device.

But we need specs to be able to write a quality driver. Please think about it. A good
driver for Linux, at zero cost for you guys. There's even a generic "Driver Project"
that is coordinated by a key Kernel maintainer (please see
http://www.linuxdriverproject.org) if you want your hardare to be supported in Linux
but you don't know where to begin.

The Driver Project aims to work with the manufacturers in a good-for-you-good-for-us
relationship (the kernel developers write drivers for you and you will have a part of
your customers happier than ever).

Currently there is a reverse-engineered driver that works with old hardware (latest
supported POD is the HD300), but it doesn't support all features, and it's quite hard
to support new devices.

Please, think about it. You can be the first top-notch professional music hardware
company that has its hardware supported in Linux out of the box. It may not mean a
lot for you now, but a lot of companies have embraced Linux and it was a very
positive step for them.

Please reply with any concerns you may have and we will see how can we tackle it so
your customers as well as you guys are satisfied with the solution.


Regards,
L. Alberto
----------- >8 -------------------------------------------------


I know that chances are that it gets ignored, but as my father always says, "you
already have the 'no'. It can't get any worse by asking".

And I think that we should tell all the Linux users that have a Line6 device to tell
them what they think. If we don't move, we will have no results. If we move and we
are ignored... well... we would have tried at least :)

So... hoping to get my hands dirty, but still not losing the hope that they may help
in the future.


Regards,
-- 
L. Alberto Giménez
JabberID agi...@ja...
GnuPG key ID 0x3BAABDE1

Re: [Line6linux-devel] line6 out of staging

[L. A. G. <agi...@sy...>]

On Wed, Nov 28, 2012 at 08:34:52AM +0100, Stefan Hajnoczi wrote:
> 
> Has the HD 500 ever worked with the driver?  AFAIK support for HD 500
> is incomplete.

I don't know, it's the first time I try it out in Linux. I have the hardware and it
would be awesome to help to add support for HD500 for Linux :)

 
> Please post the output of "lsusb -d 0e41:414d -v" while the device is
> attached.  This will provide the USB capabilities of the device so we
> can try to find the correct interface, altsetting, and endpoints.

# lsusb -d 0e41:414d -v

Bus 001 Device 010: ID 0e41:414d Line6, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x0e41 Line6, Inc.
  idProduct          0x414d 
  bcdDevice            0.00
  iManufacturer           1 Line 6
  iProduct                2 POD HD500
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           18
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x40
      (Missing must-be-set bit!)
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              4 User
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

> 
> If you want to play with this yourself, try editing the switch
> statements in driver.c:line6_probe() to use the interface, altsetting,
> and endpoint information from the lsusb output.  This is just
> guesswork, if you want to be sure then you need to capture USB traffic
> from the Line6 Edit software to see how the Windows driver talks to
> the device.

Well, yes, I want to play :) But I have a very limited knowledge of USB kernel (and
ALSA) development. I need to read some kernel documents and try to understand the
code!

So, whare do you recommend me to begin with?

On the other hand, I can begin to submit checkpatch fixes so I get comfortable with
the code.

In the kernel configuration, I didn't activate the debug options because i read in
the list that they were to be obsoleted for general-purpose facilities (usbmon, etc).
Would you recommend to activate those options anyway?


Best regards,
-- 
L. Alberto Giménez
JabberID agi...@ja...
GnuPG key ID 0x3BAABDE1

Re: [Line6linux-devel] line6 out of staging

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

On Tue, Nov 27, 2012 at 9:54 PM, L. Alberto Giménez
<agi...@sy...> wrote:
> On Tue, Nov 27, 2012 at 06:26:42AM +0100, Stefan Hajnoczi wrote:
>> On Mon, Nov 26, 2012 at 9:39 PM, L. Alberto Giménez
>> <agi...@sy...> wrote:
>> > I'm currently compiling the drop-sysfs branch. I have an HD 500 device, so I will
>> > give feedback about if it works 'out of the box' or not.
>>
>> Thanks for trying it out.  On the HD 500 there should be no change in
>> behavior from before.
>
> OK, so I compiled the cleanup branch, enabled the staging line6 driver (not the debug
> options since I saw in the mailing list messages that the kernel/user space apps
> already have debugging capabilities).
>
> The module loads fine, but the device won't work:
>
> [  333.697431] usb 1-2.4: new full-speed USB device number 4 using ohci_hcd
> [  333.795169] usb 1-2.4: not running at top speed; connect to a high speed hub
> [  333.805144] usb 1-2.4: New USB device found, idVendor=0e41, idProduct=414d
> [  333.805147] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [  333.805149] usb 1-2.4: Product: POD HD500
> [  333.805151] usb 1-2.4: Manufacturer: Line 6
> [  334.284407] line6usb: module is from the staging directory, the quality is
> unknown, you have been warned.
> [  334.284986] line6usb 1-2.4:1.0: Line6 POD HD500 found
> [  334.284989] usb 1-2.4: selecting invalid altsetting 1
> [  334.284991] line6usb 1-2.4:1.0: set_interface failed
> [  334.284996] line6usb: probe of 1-2.4:1.0 failed with error -22
>
> aplay -l doesn't show anything but my regular sound card information  and alsamixer
> won't show any POD related control.
>
> usb-devices output:
> T:  Bus=01 Lev=02 Prnt=03 Port=03 Cnt=01 Dev#=  7 Spd=12  MxCh= 0
> D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
> P:  Vendor=0e41 ProdID=414d Rev=00.00
> S:  Manufacturer=Line 6
> S:  Product=POD HD500
> C:  #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
> I:  If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
>
> Any idea?

Has the HD 500 ever worked with the driver?  AFAIK support for HD 500
is incomplete.

Please post the output of "lsusb -d 0e41:414d -v" while the device is
attached.  This will provide the USB capabilities of the device so we
can try to find the correct interface, altsetting, and endpoints.

If you want to play with this yourself, try editing the switch
statements in driver.c:line6_probe() to use the interface, altsetting,
and endpoint information from the lsusb output.  This is just
guesswork, if you want to be sure then you need to capture USB traffic
from the Line6 Edit software to see how the Windows driver talks to
the device.

Stefan

Re: [Line6linux-devel] line6 out of staging

[L. A. G. <agi...@sy...>]

On Tue, Nov 27, 2012 at 06:26:42AM +0100, Stefan Hajnoczi wrote:
> On Mon, Nov 26, 2012 at 9:39 PM, L. Alberto Giménez
> <agi...@sy...> wrote:
> > I'm currently compiling the drop-sysfs branch. I have an HD 500 device, so I will
> > give feedback about if it works 'out of the box' or not.
> 
> Thanks for trying it out.  On the HD 500 there should be no change in
> behavior from before.

OK, so I compiled the cleanup branch, enabled the staging line6 driver (not the debug
options since I saw in the mailing list messages that the kernel/user space apps
already have debugging capabilities).

The module loads fine, but the device won't work:

[  333.697431] usb 1-2.4: new full-speed USB device number 4 using ohci_hcd
[  333.795169] usb 1-2.4: not running at top speed; connect to a high speed hub
[  333.805144] usb 1-2.4: New USB device found, idVendor=0e41, idProduct=414d
[  333.805147] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  333.805149] usb 1-2.4: Product: POD HD500
[  333.805151] usb 1-2.4: Manufacturer: Line 6
[  334.284407] line6usb: module is from the staging directory, the quality is
unknown, you have been warned.
[  334.284986] line6usb 1-2.4:1.0: Line6 POD HD500 found
[  334.284989] usb 1-2.4: selecting invalid altsetting 1
[  334.284991] line6usb 1-2.4:1.0: set_interface failed
[  334.284996] line6usb: probe of 1-2.4:1.0 failed with error -22

aplay -l doesn't show anything but my regular sound card information  and alsamixer
won't show any POD related control.

usb-devices output:
T:  Bus=01 Lev=02 Prnt=03 Port=03 Cnt=01 Dev#=  7 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=0e41 ProdID=414d Rev=00.00
S:  Manufacturer=Line 6
S:  Product=POD HD500
C:  #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

Any idea?


Regards,
-- 
L. Alberto Giménez
JabberID agi...@ja...
GnuPG key ID 0x3BAABDE1

Re: [Line6linux-devel] line6 out of staging

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

On Mon, Nov 26, 2012 at 9:39 PM, L. Alberto Giménez
<agi...@sy...> wrote:
> I'm currently compiling the drop-sysfs branch. I have an HD 500 device, so I will
> give feedback about if it works 'out of the box' or not.

Thanks for trying it out.  On the HD 500 there should be no change in
behavior from before.

Stefan