On 2/27/2024 7:13 PM, bad sector wrote:
> On 2/25/24 08:41, Paul wrote:
>> On 2/24/2024 10:29 PM, bad sector wrote:
>>> On 2/19/24 22:36, bad sector wrote:
>>>> I'd like to nail down how my system sees my
>>>> (Roland) Boss-gx-100 guitar effects board.
>>>> It's connected via a USB cable but neither
>>>> of the commands in the subject header lists
>>>> it regardless of whether it's powered on or not.
>>>
>>>
>>> I got one more yard downfield but still no cigar.
>>>
>>> Installed a freshie Tumbleweed with only one user
>>> who is in group vboxusers. This user's home (and
>>> the vbox belonging to) are now both on the same
>>> partition instead of elsewhere with/without linking.
>>>
>>> The gx-100 usb connection in the strip below the
>>> w10 guest window is no longer ghosted so I would
>>> assume that the passthrough is good.
>>>
>>> BUT... now winblows is acting up with the annunciations
>>> seen @
>>>
>>> https://imgur.com/dYm1bf2.png
>>>
>>> "Unknown USB Device, Device Descriptor Request Failed"
>>>
>>> I don't have a realwin installed at the moment so I'll
>>> have to bring presents (usually in cases of 12/24) to
>>> someone who does, to test further.
>>
>> I don't think you can get around that, by unplugging and
>> plugging back in. As the Host gets first crack at it,
>> and only then does the Guest filter transfer control
>> to the Guest OS. This means whatever foul-up leaves it in
>> that state, is reproducible.
>>
>> The way that VirtualBox works, is it is a "USB packet
>> redirector". It does not work at the Class level.
>> Every packet for 1234:5678 should be redirected to the Guest.
>> And that would include responses to a Device Descriptor Request.
>>
>> first you make endpoints, and collecting the config space info
>> comes next. And that's what the Device Descriptor is.
>>
>> These are things you can inspect (the Device Descriptor),
>> in USBTreeView in Windows. But the complex table shown
>> as Device Descriptor, is only going to show... if it hasn't
>> failed. Like, on a friends Windows PC perhaps. Take your
>> USBTreeView with you, so you can take reference pictures
>> of what the device entry *should* look like.
>>
>> There is probably a "STOP code" in Device Manager for the
>> affected device, but going down that rabbit hole isn't going
>> to help, as this is more likely to be a VirtualBox side
>> effect than a "pure" Windows problem.
>
>
> I recovered my laptop to its w10 delivered state and DL'd this TS kit including "usbview" (the gx-100 BTW works like a charm in w10 so there are NO hardware issues). But the flood of info is a chinese jungle to me; which of these should the GX-100 usb entry in virtualbox repeat and how can one enforce that?
>
> https://transfiles.ru/yy63w
>
> (it's up for 3 days)
>

OK, it appears to have made endpoints in usbview.txt .

But this says it all. It does not follow a
USB Class specification (and that's OK because custom
devices have always existed in USB).

bDeviceClass: 0xFF -> This is a Vendor Specific Device

They're not as common as it used to be, because a
lot of custom ones have become standardized.

So the question would be, why is VirtualBox getting bent
out of shape about a custom ? It still has to bind to a driver
via its PNP numbers.

I would guess it's failing earlier than when a report like
that can be made. It's having a problem making endpoints,
at a guess.

Is it on a real USB2 port or is it using the four contact
part of a nine contact USB3 port ? I don't think the machine
I'm typing on, as an example, has "real" USB2 ports. The ports
with black tabs in the connector, those are made from
four of nine contacts on a USB3 connector.

I don't really think it is the USB port that deserves
the blame. But I don't know how to fix this.

*******

What your report does give us, is a Google search: "bDeviceClass: 0xFF virtualbox"

While a lot of the hits are problem reports, this one is a bit different bInterfaceClass 255 Vendor Specific Class

https://kicherer.org/joomla/index.php/de/blog/38-reverse-engineering-a-usb-sound-card-with-midi-interface-for-linux

I always thought that setting up endpoints, that's a hub driver or similar, function.
It's not up to a device driver to do that. The declaration in the device, should
contain anything it needs to know about endpoints. That's part of what
makes it hard to understand why that is failing.

Paul

On 2/27/24 21:09, Paul wrote:
> On 2/27/2024 7:13 PM, bad sector wrote:
>> On 2/25/24 08:41, Paul wrote:
>>> On 2/24/2024 10:29 PM, bad sector wrote:
>>>> On 2/19/24 22:36, bad sector wrote:
>>>>> I'd like to nail down how my system sees my
>>>>> (Roland) Boss-gx-100 guitar effects board.
>>>>> It's connected via a USB cable but neither
>>>>> of the commands in the subject header lists
>>>>> it regardless of whether it's powered on or not.
>>>>
>>>>
>>>> I got one more yard downfield but still no cigar.
>>>>
>>>> Installed a freshie Tumbleweed with only one user
>>>> who is in group vboxusers. This user's home (and
>>>> the vbox belonging to) are now both on the same
>>>> partition instead of elsewhere with/without linking.
>>>>
>>>> The gx-100 usb connection in the strip below the
>>>> w10 guest window is no longer ghosted so I would
>>>> assume that the passthrough is good.
>>>>
>>>> BUT... now winblows is acting up with the annunciations
>>>> seen @
>>>>
>>>> https://imgur.com/dYm1bf2.png
>>>>
>>>> "Unknown USB Device, Device Descriptor Request Failed"
>>>>
>>>> I don't have a realwin installed at the moment so I'll
>>>> have to bring presents (usually in cases of 12/24) to
>>>> someone who does, to test further.
>>>
>>> I don't think you can get around that, by unplugging and
>>> plugging back in. As the Host gets first crack at it,
>>> and only then does the Guest filter transfer control
>>> to the Guest OS. This means whatever foul-up leaves it in
>>> that state, is reproducible.
>>>
>>> The way that VirtualBox works, is it is a "USB packet
>>> redirector". It does not work at the Class level.
>>> Every packet for 1234:5678 should be redirected to the Guest.
>>> And that would include responses to a Device Descriptor Request.
>>>
>>> first you make endpoints, and collecting the config space info
>>> comes next. And that's what the Device Descriptor is.
>>>
>>> These are things you can inspect (the Device Descriptor),
>>> in USBTreeView in Windows. But the complex table shown
>>> as Device Descriptor, is only going to show... if it hasn't
>>> failed. Like, on a friends Windows PC perhaps. Take your
>>> USBTreeView with you, so you can take reference pictures
>>> of what the device entry *should* look like.
>>>
>>> There is probably a "STOP code" in Device Manager for the
>>> affected device, but going down that rabbit hole isn't going
>>> to help, as this is more likely to be a VirtualBox side
>>> effect than a "pure" Windows problem.
>>
>>
>> I recovered my laptop to its w10 delivered state and DL'd this TS kit including "usbview" (the gx-100 BTW works like a charm in w10 so there are NO hardware issues). But the flood of info is a chinese jungle to me; which of these should the GX-100 usb entry in virtualbox repeat and how can one enforce that?
>>
>> https://transfiles.ru/yy63w
>>
>> (it's up for 3 days)
>>
>
> OK, it appears to have made endpoints in usbview.txt .
>
> But this says it all. It does not follow a
> USB Class specification (and that's OK because custom
> devices have always existed in USB).
>
> bDeviceClass: 0xFF -> This is a Vendor Specific Device
>
> They're not as common as it used to be, because a
> lot of custom ones have become standardized.
>
> So the question would be, why is VirtualBox getting bent
> out of shape about a custom ? It still has to bind to a driver
> via its PNP numbers.
>
> I would guess it's failing earlier than when a report like
> that can be made. It's having a problem making endpoints,
> at a guess.
>
> Is it on a real USB2 port or is it using the four contact
> part of a nine contact USB3 port ? I don't think the machine
> I'm typing on, as an example, has "real" USB2 ports. The ports
> with black tabs in the connector, those are made from
> four of nine contacts on a USB3 connector.
>
> I don't really think it is the USB port that deserves
> the blame. But I don't know how to fix this.
>
> *******
>
> What your report does give us, is a Google search: "bDeviceClass: 0xFF virtualbox"
>
> While a lot of the hits are problem reports, this one is a bit different bInterfaceClass 255 Vendor Specific Class
>
> https://kicherer.org/joomla/index.php/de/blog/38-reverse-engineering-a-usb-sound-card-with-midi-interface-for-linux
>
> I always thought that setting up endpoints, that's a hub driver or similar, function.
> It's not up to a device driver to do that. The declaration in the device, should
> contain anything it needs to know about endpoints. That's part of what
> makes it hard to understand why that is failing.
>
> Paul

I fear that this is a Linux issue, unless I read it wrong virtualbox
just uses what Linux supplies it with and trying that in a Windows guest
bombs because it's erroneous or incomplete. It's just too bad, another
reminder for me never to buy another Roland product.