net/freerdp: usb redirection support?

aragats

aragats

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!
 
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 ?

Code: 
# 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 ?
Code: 
ugen1.5: <vendor [B]0x13fe[/B] USB DISK 2.0> at usbus1


Tell please.
 
Last edited by a moderator:
SemFLY said:
This id without zero from begining or not else this dev ?
Click to expand...
Their documentation is really poor, e.g. the wiki page explains it as:
Code: 
/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:
Code: 
[ERROR][com.winpr.library] - LoadLibraryA: Cannot open "/usr/local/lib/freerdp2/liburbdrc-client.so"
 
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".
 
Last edited:
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:
Code: 
....
[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)
 
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.
 
Really? Here it is:
Code: 
/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)
 
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!
Code: 
$ pkg info freerdp | head -n1
freerdp-2.0.0.r4_6
Code: 
$ 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)
....
 
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:
Code: 
....
[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)
Click to expand...
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.
 
free-and-bsd said:
With the ports version sound in Windows is terribly distorted.
Click to expand...
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.
 
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.
 
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!
 
I also tried this option for bhyve():
Code: 
... -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).
 
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.
 
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.
 
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.
 
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
Click to expand...
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.
 
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.
 
You must log in or register to reply here.
Back
Top