VirtualHere Xbox One Wireless controller odd behaviour

Submitted by therist on #1

Hi

I setup the virtualhere through a Raspberry Pi 2 server, by using vhusbdarmpi2. Everything works nice, and my xbox controller works also. The odd behavior is with vibrations. When something has to vibrate shortly in-game, the vibrations continue long after the moment has passed, even after going in to the game menus.

Any suggestions?

For now I have turned them off, but I would like to play and use the vibrations of the controller.

Submitted by Michael on Thu, 2016/09/29 - 21:14

#2

Im not sure, virtualhere just passes whatever signal it receives from the xbox controller. I assume this works ok directly connected?

Submitted by therist on Sat, 2016/10/01 - 07:38

#3

It works perfectly when it is connected directly. When connected through raspberry pi, the vibrations are very odd, but I just noticed also that the four lights indicating which position the controller has (1-4) are blinking for too long, up to 5 min. When connected directly they blink for couple of seconds only, and take up a position (always 1, I don't have second controller).

Submitted by Michael on Sat, 2016/10/01 - 20:37

#4

OK, im wondering if perhaps a local driver like xboxdrv is installed on the pi and thats inteferring with it before virtualhere gets control.

Can you do this

1. Unplug everything USB from the pi
2. Stop the virtualhere server on the pi
3. Edit the server config.ini file and add the line
ClaimPorts=1
4. Start the virtualhere server on the pi again
5. Plug in the xbox controller into the pi
6. Try using it via virtualhere.

ClaimPorts=1 tells virtualhere, to stop any other drivers binding to the xbox controller locally on the pi before virtualhere gets control

Submitted by AmbientMike on Sat, 2017/03/11 - 06:34

#5

I am having exactly the same problem on my new Pi 3 running stock Raspbian. My Xbox 360 wireless receiver possess through from my Pi server to my Windows 10 client. When the controller connects to the receiver the 4 green lights flash for a very long and if, in a game, the rumble starts it takes a very long time to stop and that is not normal (especially as it's mainly only FIFA I play).

I've tried adding the ClaimPorts line to the config file and this seems to make no difference. Does anyone have any other suggestions?

Submitted by AmbientMike on Sat, 2017/03/11 - 07:39

#6

Incidentally the 360 receiver works perfectly via my Steam link and VirtualHere client so it makes sense that the problem is linked to the Pi server (doesn't it?).

Submitted by Michael on Mon, 2017/03/13 - 11:01

#7

I think this might be the old full speed device bug thats been in raspbian for quite a while (since jessie) wheezy was ok... Does it say "Full speed device" in syslog when you connect the controller to the pi?

Submitted by AmbientMike on Tue, 2017/03/14 - 05:47

#8

[ 188.604606] usb 1-1.3: new full-speed USB device number 6 using dwc_otg
[ 189.114604] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
[ 189.260674] usb 1-1.3: New USB device found, idVendor=045e, idProduct=0291
[ 189.260689] usb 1-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0

Is this good or bad?

I think it may also have something to do with the xpad driver not releasing the port. When trying to run the user mode xboxdrv driver I get the following...

sudo xboxdrv --detach-kernel-driver

[ERROR] USBController::on_read_data(): USB read failure: 32: LIBUSB_TRANSFER_ERROR

After a few attempts it eventually seems to release and hand control over to the xboxdrv.

I'll see if blacklisting the xpad kernel driver makes any difference...

Submitted by Michael on Tue, 2017/03/14 - 08:07

#9

I think it probably is this kernel bug, there is not much that can be done until its fixed in raspbian.

Submitted by Michael on Thu, 2017/03/16 - 09:17

#11

Ok thats surprising, i guess its not the jessie kernel bug. The steamlink virtualhere server is identical to the pi virtualhere server (the steamlink build is optimized for the A9 cortex cpu used in the link) So i still think its the kernel but i dont know where the problem might be. Are both the steamlink and the pi connected over ethernet and not wifi? Im wondering if it could be some network latency issue if they are over wifi only. The steamlink has 2T2R wifi whereas the pi is only a 1T1R wifi with bad range. Perhaps the x360 is less tolerant with slightly increased transmission latency..

Submitted by AmbientMike on Thu, 2017/03/16 - 20:21

#12

Both the SteamLink and pi are connected via wired Ethernet (I don't use Wi-Fi unless I absolutely have to) . I suspect (via my experience with xboxdrv on the pi) that the issue is probably with the pi not releasing the USB port in a timely fashion so the error that I'm seeing with the flashing controller being a pi issues as opposed to a VirtualHere issue.

Presumably when you use "ClaimPorts=1" it simply instructs the server to do it but doesn't actually stop or retry if the claim fails? Is there a way to force the USB port to release before running the server?

Submitted by Michael on Fri, 2017/03/17 - 08:53

#13

I dont think its related to the pi xboxdrv as this is fully disconnected before virtualhere takes control so it wouldnt interfere with the transmission. Since it works with the steamlink im certain is a raspbian specific issue but i dont know what it might be unfortunately...

I dont think claimports would be useful. ClaimPorts basically tells the linux kernel not to configure the device before virtualhere gets it. It selects configuration 1 which i think is probably a valid configuration anyway so it doesnt matter if the kernel selects this config initiallly before virtualhere gets a hold.

You could always blacklist the xboxdrv if you think its causing trouble. (http://askubuntu.com/questions/110341/how-to-blacklist-kernel-modules)