# net/freerdp: usb redirection support?



## aragats (Jan 31, 2017)

Is it possible to get it working? Currently net/freerdp is compiled without usb redirection. It seems to depend on udev: adding it manually to the Makefile causes errors about UDEV_INCLUDE_DIR not found.

Are there any possible work-arounds?

Thanks for ideas!


----------



## Michael Duller (Dec 9, 2018)

aragats did you find a way to get USB redirection working on FreeBSD?


----------



## SemFLY (Nov 15, 2019)

Hi ))

FreeBSD 12.0 Release
freerdp 2.0.0.r4_5 - pkg ins freerdp

Connect to Win10Pro from RDP protocol

From manual info xfreerdp()

Use this key
/usb:id,dev......

How in FreeBSD get id and dev or another solution for get id and dev ?


```
# dmesg
ugen1.5: <vendor 0x13fe USB DISK 2.0> at usbus1
umass0 on uhub3
umass0: <vendor 0x13fe USB DISK 2.0, class 0/0, rev 2.00/1.00, addr 5> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0xc100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: < USB DISK 2.0 PMAP> Removable Direct Access SPC-4 SCSI device
da0: Serial Number 070194271B272255
da0: 40.000MB/s transfers
da0: 7398MB (15151104 512 byte sectors)
da0: quirks=0x3<NO_SYNC_CACHE,NO_6_BYTE>
```

This *id* without zero from beginning or not else this dev ?

```
ugen1.5: <vendor [B]0x13fe[/B] USB DISK 2.0> at usbus1
```


Tell please.


----------



## aragats (Nov 15, 2019)

SemFLY said:


> This *id* without zero from begining or not else this *dev* ?


Their documentation is really poor, e.g. the wiki page explains it as:
	
	



```
/usb:id,<usbid> : Redirect usb device <usbid>. Usbid is a string like dev:054c:0268
```
which doesn't make much sense since doesn't include the USB bus and device ID on the bus (you may have several devices with the same product/vendor IDs).

However, the problem in FreeBSD is different: as I mentioned in the OP, net/freerdp won't compile with USB redirection support, that was long time ago though, haven't tried recently.

[EDIT] The packaged version of net/freerdp fails with:
	
	



```
[ERROR][com.winpr.library] - LoadLibraryA: Cannot open "/usr/local/lib/freerdp2/liburbdrc-client.so"
```


----------



## free-and-bsd (Nov 18, 2019)

I've filed a PR some time ago. Some work was done in that direction by the port maintainer and some patches can be applied. As I mentioned there, however, trying to forward a web-camera didn't work for me even under Linux. So how should I expect it to work in FreeBSD?

Yes, "documented" in this particular case seems to mean "some groundwork has been laid, so the feature may be possible now or in the future" but not "supported and working".


----------



## aragats (Nov 18, 2019)

I tried a couple of USB flash drives and a proprietary software dongle with the patch provided in the PR 239915 (opened by free-and-bsd).
They do not appear in Windows 10 Device Manager.

E.g. with `/usb:dbg,dev:04b9:0300` I'm getting the following messages:
	
	



```
....
[INFO][com.freerdp.channels.drdynvc.client] - Loading Dynamic Virtual Channel urbdrc
[ERROR][com.freerdp.channels.urbdrc.client] - error processing arguments
[WARN][com.freerdp.channels.urbdrc.client] - bus:0 dev:0 not exist in udevman
[INFO][com.freerdp.channels.urbdrc.client] - VID: 0x04B9, PID: 0x0300
[DEBUG][com.freerdp.channels.urbdrc.client] - UDEVMAN device registered.
....
```
(I added this comment to the PR)


----------



## free-and-bsd (Mar 3, 2020)

Well... I gave up hope it would work any time in the future. Devs don't seem to be very enthusiastic about it, you know. I finally solved that by (it's _off topic_ though) upgrading my machine to Intel Xeon e5 2690(used) with X79 huananzhi Chinese motherboard (they are dirt-cheap at Aliexpress ). Used PCI passthrough for my NIC and USB3.0 bus and connected my USB webcam there.
Just virtio-net is maddening slow... or is it only me?
Just for the record, since you seem to be using net/freerdp to that end, here is my command line that works well for things including multimedia:
`xfreerdp -grab-keyboard /bpp:24 /w:1600 /h:960 /v:DESKTOP-QWERT123 /u:my_user /p:'my_pass' /network:auto /dvc:video,sys:oss /gfx-h264:avc444 /clipboard /fonts /sound:sys:oss,dev:4 /microphone:sys:oss,format:1`
Some guides recommend using /video option for better video performance, but it crashes the session after 10-20 seconds.


----------



## aragats (Mar 3, 2020)

free-and-bsd said:


> ... /gfx-h264 ...


I don't see this option in xfreerdp().


----------



## free-and-bsd (Mar 3, 2020)

Really? Here it is:

```
/geometry                Geometry tracking channel
    +gestures                Enable Consume multitouch input locally
    /gfx[:RFX|AVC420|AVC444]    RDP8 graphics pipeline (experimental)
    /gfx-h264[:AVC420|AVC444]    RDP8.1 graphics pipeline using H264 codec
    +gfx-progressive         Enable RDP8 graphics pipeline using progressive codec
    +gfx-small-cache         Enable RDP8 graphics pipeline using small cache mode
    +gfx-thin-client         Enable RDP8 graphics pipeline using thin client mode
    +glyph-cache             Enable Glyph cache (experimental)
```


----------



## free-and-bsd (Mar 3, 2020)

```
$ pkg info freerdp
freerdp-2.0.0.r4_6
```


----------



## aragats (Mar 3, 2020)

I thought that the man page is being generated based on the actual options enabled. By default (I guess) *openh264* is disabled. I enabled and rebuilt it, but it's still not there!

```
$ pkg info freerdp | head -n1
freerdp-2.0.0.r4_6
```


```
$ man xfreerdp
....
       /geometry
           Geometry tracking channel
       +gestures
           Consume multitouch input locally (default:off)
       /gfx[:RFX]
           RDP8 graphics pipeline (experimental)
       +gfx-progressive
           RDP8 graphics pipeline using progressive codec (default:off)
       +gfx-small-cache
           RDP8 graphics pipeline using small cache mode (default:off)
       +gfx-thin-client
           RDP8 graphics pipeline using thin client mode (default:off)
       +glyph-cache
           Glyph cache (experimental) (default:off)
....
```


----------



## free-and-bsd (Mar 3, 2020)

Try `xfreerdp --help`
I mean, something is wrong with that program, really   Features are stated but not present and vice versa.


----------



## free-and-bsd (Mar 10, 2020)

aragats said:


> I tried a couple of USB flash drives and a proprietary software dongle with the patch provided in the PR 239915 (opened by free-and-bsd).
> They do not appear in Windows 10 Device Manager.
> 
> E.g. with `/usb:dbg,dev:04b9:0300` I'm getting the following messages:
> ...


BTW, this build achieves yet another goal: it improves remote sound quality dramatically. With the ports version sound in Windows is terribly distorted. This build, however, used latest sources where this is fixed. Discovered that by coincidence.


----------



## aragats (Mar 10, 2020)

free-and-bsd said:


> With the ports version sound in Windows is terribly distorted.


I never noticed that until I tried a Skype conference call in a bhyve guest (Windows 10) in a lower-performing system: it was really bad.
In my main box (Xeon E5-1650v3, 32GB RAM, SSDs) everything is working fine even with the ports version.


----------



## free-and-bsd (Mar 10, 2020)

Well my machine is like yours (except that mine has Xeon E5-2690). Still I had this problem with the ports version of net/freerdp yet not in this latest src version. 
Just today tried the standard ports version (recent update) and had this hissing + interruptions not only in Skype sessions, but with sound in general. Put it short, sounded like poorly isolated wire/poor contact that would cause abnormal noises in analogue sound equipment.
Right away I tried the net/freerdp version compiled with these patches — voila, sound back to normal. 
But evidently, not everyone has this problem.


----------



## free-and-bsd (Mar 11, 2020)

OK, I was mistaken and you were right. This sound problem was not due to port version. It was effected by enabling/disabling FAAD compile option in net/freerdp. It's fine with FAAD=YES and poor with NO.
Interesting, isn't it!


----------



## aragats (Mar 11, 2020)

I also tried this option for bhyve():
	
	



```
... -s 9,hda,play=/dev/dsp,rec=/dev/dsp ...
```
But the sound quality is below average, still could be used as a backup option in case if only the framebuffer can be used (no RDP).


----------



## free-and-bsd (Mar 11, 2020)

With /sound:sys,oss... etc AND FAAD + FFMPEG enabled thé sound here is just excellent. Much better than VMplayer gives me.

And generally, with good hardware and correct bhyve options we beat VMware finally. I've switched to bhyve completely.

Will try yet the last GIT for FreeRDP to check how they improved things with USB forwarding. The one dated January 8 had horrible video quality. So I couldn't even test anything else.


----------



## aragats (Mar 11, 2020)

free-and-bsd said:


> check how they improved things with USB forwarding


I ended up with a PCIe USB controller I specially installed to pass-trough to bhyve. With older bhyve versions it didn't work for the (in)famous "not page aligned" issue.


----------



## free-and-bsd (Mar 12, 2020)

Ha, so did I. Because the USB3.0 controller hosted by the motherboard is based on VIA VL805 and is too buggy for passthrough, so I used an expansion PCIe card based on NEC chipset. No problems ever since.
Still, as they still keep working on this functionality, it's interesting how far they have advanced.


----------



## free-and-bsd (Mar 21, 2020)

Looks like bhyve development people are working on implementing USB redirection in bhyve itself, like it is possible in VMware without any VT-d. Would be nice.


----------



## aragats (Mar 22, 2020)

free-and-bsd said:


> Looks like bhyve development people are working on implementing USB redirection in bhyve itself, like it is possible in VMware without any VT-d


That's good news! I used to use USB passthrough in Virtual Box. It works, however, USB by its nature is very sensitive to timing specs. Even a tiny overhead may affect the functionality. Although, that time such overhead helped me finding USB3/2 incompatibities in several XHCI controllers (mostly in HP laptops). Before revealing that, we thought the firmware of the device we were developing and selling that time, has an untraceable bug.


----------



## free-and-bsd (Mar 22, 2020)

Here is that post from freebsd-virtualizaiton mailing list:


			USB device passthrough implementation


----------



## aragats (Mar 22, 2020)

They're talking about a user-space implementation, which may be not optimal. As I said, it may not be able to provide accurate timing which is essential for high/full/super speed devices.


----------



## Phishfry (Mar 22, 2020)

aragats said:


> I ended up with a PCIe USB controller I specially installed to pass-through to bhyve


This is the best answer in my opinion. I use 3 of those NEC chip USB3 adapters. One for each VM that needs reliable USB.


----------

