1 files changed, 51 insertions, 0 deletions
diff --git a/results/classifier/118/graphic/1689003 b/results/classifier/118/graphic/1689003
new file mode 100644
index 00000000..9f66697c
--- /dev/null
+++ b/results/classifier/118/graphic/1689003
@@ -0,0 +1,51 @@
+graphic: 0.836
+performance: 0.828
+semantic: 0.779
+device: 0.775
+architecture: 0.747
+peripherals: 0.733
+permissions: 0.728
+network: 0.715
+ppc: 0.714
+files: 0.706
+mistranslation: 0.683
+debug: 0.680
+PID: 0.676
+register: 0.668
+socket: 0.661
+user-level: 0.648
+kernel: 0.615
+vnc: 0.611
+risc-v: 0.570
+i386: 0.569
+hypervisor: 0.560
+x86: 0.547
+VMM: 0.546
+TCG: 0.512
+boot: 0.511
+assembly: 0.471
+virtual: 0.465
+arm: 0.431
+KVM: 0.424
+
+USB passthrough should not fail if SET CONFIGURATION fails
+
+QEMU's USB passthrough was not working for my new smartphone.
+
+While analyzing the problem, I found out that a SET CONFIGURATION Request was NACKed by the USB device (probably because a SET CONFIGURATION request was already sent from the host to the device).
+
+So I wrote a simple program to fake a successful call to libusb_set_configuration and did an LD_PRELOAD on this program before starting qemu, and it worked.
+
+Looking at QEMU's code in host-libusb.c, I can see that QEMU does not try to claim the interface if its call to libusb_set_configuration fails.
+
+I think QEMU should try to claim the device anyway even if libusb_set_configuration fails.
+
+I did my tests against QEMU 2.6.2, but as I can see from the source code, this problem should happen on all versions.
+
+The attached simple program, compiled as a library, loaded by LD_PRELOAD before starting QEMU, avoids the problem by faking success of libusb_set_configuration(), as a workaround.
+
+The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
+If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Thank you and sorry for the inconvenience.
+
+[Expired for QEMU because there has been no activity for 60 days.]
+