Hi,
   I will thest droping those things and see what happened.
What about the " config 1 interface 1 altsetting 0 bulk endpoint 0x1 has
invalid maxpacket 64" ??? It has appear since the first time I plug my pod
with the stock kernel 4.4.

in your kernel 4.12 the if_ctrl doesn't appear? How did they implemented
the x3 then?

here is the podhd.c that come in my kernel
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/tree/sound/usb/line6/podhd.c?h=hwe-edge
and this is the one from torvalds
https://github.com/torvalds/linux/blob/master/sound/usb/line6/podhd.c

both have the x3 implementation with the ctr_if (and mention you).



On Fri, Jun 9, 2017 at 1:51 AM, Andrej Kruták <[email protected]> wrote:

> Hey,
>
> On Fri, Jun 9, 2017 at 5:35 AM, Hans Peter Möller <[email protected]>
> wrote:
> > Hi Andrej,
> >    good news!!
> > I can capture and listen from my pod.
> >
>
> Perfect!
>
>
> > I compare the lsusb from de x3 and I found that it has the same
> alternative
> > setting issue than the hd500x, which is different from hd300 (I couldn't
> get
> > one from h400 nor from h500). In x3 and 500x the altsetting is different
> for
> > audio than for data.
> > Since X3 is included in kernel 4.9, I decided to go over kernel 4.9 and
> use
> > that code which also appear to be more updated than the one here.
> >
> > In podhd.c I copy the same configuration used for X3. The .ctr_if=1 is
> the
> > difference from the others and it make the difference. This are the
> > modifications I made:
> >
> > enum {
> >     LINE6_PODHD300,
> >     LINE6_PODHD400,
> >     LINE6_PODHD500_0,
> >     LINE6_PODHD500_1,
> >     LINE6_PODX3,
> >     LINE6_PODX3LIVE,
> >     LINE6_PODHD500X
> > };
> >
> > /* table of devices that work with this driver */
> > static const struct usb_device_id podhd_id_table[] = {
> >     /* TODO: no need to alloc data interfaces when only audio is used */
> >     { LINE6_DEVICE(0x5057),    .driver_info = LINE6_PODHD300 },
> >     { LINE6_DEVICE(0x5058),    .driver_info = LINE6_PODHD400 },
> >     { LINE6_IF_NUM(0x414D, 0), .driver_info = LINE6_PODHD500_0 },
> >     { LINE6_IF_NUM(0x414D, 1), .driver_info = LINE6_PODHD500_1 },
> >     { LINE6_IF_NUM(0x414A, 0), .driver_info = LINE6_PODX3 },
> >     { LINE6_IF_NUM(0x414B, 0), .driver_info = LINE6_PODX3LIVE },
> >     { LINE6_IF_NUM(0x4159, 0), .driver_info = LINE6_PODHD500X },
> >     {}
> > };
> >
> >
> >
> >
> >     [LINE6_PODHD500X] = {
> >         .id = "PODHD500X",
> >         .name = "POD HD500x",
> >         .capabilities    = LINE6_CAP_CONTROL
> >                 | LINE6_CAP_PCM | LINE6_CAP_HWMON |
> LINE6_CAP_IN_NEEDS_OUT,
> >         .altsetting = 1,
> >         .ep_ctrl_r = 0x81,
> >         .ep_ctrl_w = 0x01,
> >         .ctrl_if = 1,
> >         .ep_audio_r = 0x86,
> >         .ep_audio_w = 0x02,
> >     },
> >
> >
> > I still get some errors/warning in dmesg, the maxpacket are the data ep
> so
> > that is data. The "receive length failed (error -11)" don't know what it
> is,
> > maybe initialization? Because it only appear this two times.
> >
> >  Here is dmesg output:
> >
> > [ 4001.944114] usb 1-3: new high-speed USB device number 11 using
> ehci-pci
> > [ 4002.063668] usb 1-3: config 1 interface 1 altsetting 0 bulk endpoint
> 0x1
> > has invalid maxpacket 64
> > [ 4002.063677] usb 1-3: config 1 interface 1 altsetting 0 bulk endpoint
> 0x81
> > has invalid maxpacket 64
> > [ 4002.064779] usb 1-3: New USB device found, idVendor=0e41,
> idProduct=4159
> > [ 4002.064785] usb 1-3: New USB device strings: Mfr=1, Product=2,
> > SerialNumber=0
> > [ 4002.064790] usb 1-3: Product: POD HD500X
> > [ 4002.064794] usb 1-3: Manufacturer: Line 6
> > [ 4002.067896] snd_usb_podhd 1-3:1.0: Line 6 POD HD500x found
> > [ 4002.069846] snd_usb_podhd 1-3:1.0: Line 6 POD HD500x now attached
> > [ 4002.577334] snd_usb_podhd 1-3:1.0: receive length failed (error -11)
> > [ 4002.579660] snd_usb_podhd 1-3:1.0: receive length failed (error -11)
> >
>
> I think this is caused by the device having different initial setup
> requirements. But it also (most likely) means that it doesn't need any
> setup. Thus drop the LIBE6_CAP_CONTROL thing, see if it still works.
>
> In addition, can you try also dropping LINE6_CAP_IN_NEEDS_OUT - and
> check whether the stand-alone recording works?
>
> Lastly, I don't see any ctrl_if in the structure? Not in 4.0 ...
> 4.12-rc kernels at least...
>
>
> > I believe this should be added to the podhd.c delivered in the kernel
> but I
> > dont know how to do that.
> >
>
> Check linux/Documentation/process/submitting-patches.rst. In short -
> just get inspired in the commit history of sound/usb/line6, create a
> similar patch (git format-patch) and send it to alsa-devel
> mailinglist.
>
> Alternatively, once you test the above, I can submit the patch on your
> behalf too.
>
>
> --
> Best regards,
>
> Andrej
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Line6linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/line6linux-devel

Reply via email to