[pve-devel] applied-series: [PATCH v4 0/4] Fix #2343 Spice USB3 support

[Aaron Lauterer]

Now that it can be saved without enabling USB3 I found another issue :/

If I save a USB3 dev or port passthrough without USB3 enabled, it is 
done so as expected. Once I open the edit dialog of that device again 
the USB3 checkbox is checked again on load. This means that the form is 
changed and the OK and Reset buttons get enabled.

A small problem but still annoying because one might not want to change 
anything in the end and out of muscle memory still clicks the now 
enabled OK button and saves the changes which enable USB3.

On 9/23/19 5:11 PM, Thomas Lamprecht wrote:
> On 9/23/19 4:23 PM, Aaron Lauterer wrote:
>> I did some short tests with the latest commits and there is the following problem:
>>
>> Adding a USB3 device or port will result in such an error msg:
>> --------
>> Parameter verification failed. (400)
>>
>> usb1: invalid format - duplicate key in comma-separated list property: usb3
>> --------
>>
>> The parameter send in the API request is:
>> --------
>> usb1: host=090c:1000,usb3=1,usb3=1
>> --------
>>
>> Without looking into the code it looks to me that when selecting a USB3 capable device to pass through, the checkbox is checked but the `usb3=1` parameter is handled by the dropdown components / callback functions.
>>
>> Now with the latest changes the checkbox is not disabled anymore in this situation and thus it's value added to the API request.
>>
>> When I uncheck the USB3 checkbox after selecting a device / port I can save the changes and `usb3=1` is set.
> 
> Thanks for testing this. Fixed by removing the use of getUSBValue() here as
> we know also allow to pass a USB3 device through as USB2, so the speed
> detection in the method may not be correct anymore.
> 
> While previously this was handled by the "if (!/usb3/.test(val) ..."
> check, Dominik thinks that it's only there because when he implemented this,
> USB3 devices were required to be passed-through as USB3.
> I re-tested passing a USB3 through as USB2 and it worked here, so I think
> we really can remove this constrain.
> 
>>
>> Regards,
>> Aaron
>>
>>