I'm running VirtualHere on a Beagle board, running Debian wheezy.
root@beaglebone:~# uname -a
Linux beaglebone 4.1.15-ti-rt-r43 #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 armv7l GNU/Linux
My goal is to provide access to a Samsung Galaxy S3 is connected to the Beagle via a Belkin HUB. The VirtualHere server finds the connected device. On a client PC running vhuit64, I can see the S3. When I click Use, then the UI shows the device "(in use by you)", but the message quickly changes to not in use.
On the Beagle, I see the following:
Mar 29 21:39:03 beaglebone vhusbdarm[15141]: Found High speed device [04e8:6860] "SAMSUNG, SAMSUNG_Android" at address 112
Mar 29 21:39:03 beaglebone vhusbdarm[15141]: Executed "echo '4' > /sys//devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb1/1-1/1-1.2/bConfigurationValue" for onEnumeration.04e8.6860
Mar 29 21:39:05 beaglebone kernel: usb 1-1.2: reset high-speed USB device number 30 using musb-hdrc
Mar 29 21:39:05 beaglebone vhusbdarm[15141]: Device 112 BOUND to connection 1
Mar 29 21:39:05 beaglebone kernel: usb 1-1.2: USB disconnect, device number 30
Mar 29 21:39:05 beaglebone kernel: usb 1-1.2: new high-speed USB device number 31 using musb-hdrc
Mar 29 21:39:06 beaglebone vhusbdarm[15141]: Device 112 SURPRISE UNBOUND from connection 1
Mar 29 21:39:06 beaglebone vhusbdarm[15141]: Unmanaging device 112
Mar 29 21:39:06 beaglebone kernel: usb 1-1.2: New USB device found, idVendor=04e8, idProduct=6860
Mar 29 21:39:06 beaglebone kernel: usb 1-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=4
Mar 29 21:39:06 beaglebone kernel: usb 1-1.2: Product: SAMSUNG_Android
Mar 29 21:39:06 beaglebone kernel: usb 1-1.2: Manufacturer: SAMSUNG
Mar 29 21:39:06 beaglebone kernel: usb 1-1.2: SerialNumber: 32300d89765ca0df
Mar 29 21:39:06 beaglebone kernel: cdc_acm 1-1.2:1.1: ttyACM0: USB ACM device
Mar 29 21:39:06 beaglebone org.gtk.Private.GPhoto2VolumeMonitor[713]: (process:783): GVFS-GPhoto2-WARNING **: device (null) has no BUSNUM property, ignoring
Mar 29 21:39:06 beaglebone org.gtk.Private.GPhoto2VolumeMonitor[713]: (process:783): GVFS-GPhoto2-WARNING **: device (null) has no BUSNUM property, ignoring
Mar 29 21:39:06 beaglebone org.gtk.Private.GPhoto2VolumeMonitor[713]: (process:783): GVFS-GPhoto2-WARNING **: device (null) has no BUSNUM property, ignoring
Mar 29 21:39:06 beaglebone org.gtk.Private.GPhoto2VolumeMonitor[713]: (process:783): GVFS-GPhoto2-WARNING **: device (null) has no BUSNUM property, ignoring
Mar 29 21:39:06 beaglebone vhusbdarm[15141]: Found High speed device [04e8:6860] "SAMSUNG, SAMSUNG_Android" at address 112
Mar 29 21:39:06 beaglebone vhusbdarm[15141]: Executed "echo '4' > /sys//devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb1/1-1/1-1.2/bConfigurationValue" for onEnumeration.04e8.6860
Mar 29 21:39:36 beaglebone connmand[399]: ntp: time slew -0.021040 s
On the client machine running vhuit64, I see the following in the system log:
Mar 29 14:50:37 zephyr.localdomain kernel: vhci_hcd vhci_hcd: rhport(0) sockfd(11) devid(4) speed(3) speed_str(high-speed)
Mar 29 14:50:37 zephyr.localdomain kernel: usb 5-1: new high-speed USB device number 50 using vhci_hcd
Mar 29 14:50:37 zephyr.localdomain kernel: usb 5-1: new high-speed USB device number 51 using vhci_hcd
Mar 29 14:50:37 zephyr.localdomain kernel: vhci_hcd: connection closed
Mar 29 14:50:37 zephyr.localdomain kernel: vhci_hcd: stop threads
Mar 29 14:50:37 zephyr.localdomain kernel: vhci_hcd: release socket
Mar 29 14:50:37 zephyr.localdomain kernel: vhci_hcd: disconnect device
Note that I tried to use a quirk, but this hasn't improved behavior compared to not using a quirk. Maybe I need another quirk?
.
It looks like the USB reset is causing it to drop off the bus. Did you put the onEnumeration quirk in there from some info somewhere on the internet?
Lets first try disabling the USB reset function like this, right click on the Samsung Phone in the virutalhere client and select "Custom Event Handler..." then enter
onReset.$VENDOR_ID$.$PRODUCT_ID$=then try again. That will disable the reset function (because there is nothing after the = above, no script is run and no reset command is sent)
That will probably stop it dropping from the bus.
P.S That kernel you are running is a good one from texas instruments and has very few bugs so its a good start.