Bug 239915 - net/freerdp: missing libraries
Summary: net/freerdp: missing libraries
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Kyle Evans
Keywords: needs-patch
Depends on:
Reported: 2019-08-16 18:10 UTC by bergerkos
Modified: 2020-03-13 06:26 UTC (History)
3 users (show)

See Also:
w.schwarzenfeld: maintainer-feedback?

svn(1) diff against the ports tree (2.00 KB, patch)
2019-08-19 15:28 UTC, Kyle Evans
no flags Details | Diff
debug output from USB (25.91 KB, text/plain)
2019-08-28 19:18 UTC, bergerkos
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description bergerkos 2019-08-16 18:10:15 UTC
Trying to redirect USB web-camera to Windows 10 Pro host in bhyve fails because of  some libraries missing:
[20:54:29:609] [27343:0569d500] [ERROR][com.winpr.library] - LoadLibraryA: Cannot open "/usr/local/lib/freerdp2/liburbdrc-client.so"
[20:54:29:609] [27343:0569d500] [WARN][com.freerdp.addin] - Failed to load channel urbdrc [(nil)]
[20:54:29:609] [27343:0569d500] [ERROR][com.freerdp.channels.drdynvc.client] - drdynvc_virtual_channel_event_connected failed with error 1
[20:54:29:610] [27343:0569d500] [ERROR][com.freerdp.core] - drdynvc_virtual_channel_init_event_ex reported an error. Error was 1

It's FreeBSD 12.1, port version is 2.0.0.r4_3. And the library is missing, pkg info says:
Shared Libs provided:
Comment 1 bergerkos 2019-08-16 18:13:58 UTC
I'm using this command to connect:
xfreerdp -grab-keyboard /bpp:24 /w:1600 /h:960 /v:$MYHOST /u:$USER /p:$PW /clipboard /drive:home,/home/kostya /fonts /sound:sys:oss,dev:4 /microphone:sys:oss,format:1 /rfx /dvc:urbdrc,id,dev:046d:081b

Tried also this alternative insted of the last portion "/rfx /dvc:urbdrc,id,dev:046d:081b":

Connects perfectly well without it, sound and the rest of it working just fine.
Comment 2 bergerkos 2019-08-16 20:33:06 UTC
Ok, after some research I understand it that this feature depends on udev, which is not available on FreeBSD. That's why it is not even present as a configurable option. But if my understanding is correct, would it not be better to remove the mentioning of this capability from the man pages for just now? As long as it is there, somebody will bump over this and think this is a bug.
Comment 3 Kyle Evans freebsd_committer 2019-08-16 20:48:32 UTC
(In reply to bergerkos from comment #2)

I'd prefer to just make it work. =) We enable channels in the build by default with no option to disable it- I'll see what it takes to make this one work here.
Comment 4 bergerkos 2019-08-17 22:21:29 UTC
Oh thank you very much! And I didn't mention it, but I'm very thankful for your hard work in any case, whether this particular feature works or not :). As it is now, freerdp is working fine -- thanks to you. You know, we send bug reports, but I don't want it to sound like always asking without ever saying thank you :).
Comment 5 Kyle Evans freebsd_committer 2019-08-19 15:28:49 UTC
Created attachment 206702 [details]
svn(1) diff against the ports tree


Please give this patch a shot and rebuild FreeRDP with it- I'm a tad bit confused because enabling it (after fixing the build, which I've already submitted upstream and is represented here by d796920.patch:-p1 in PATCHFILES) links it into libfreerdp-client2.so.2.0.0; not spitting out a shared object for it. I suspect that I just don't understand how the channel infrastructure works and FreeRDP will DTRT with it compiled in.

This will warrant a PORTREVISION bump if it works. =)
Comment 6 bergerkos 2019-08-26 13:16:29 UTC
Ok, I've tried it. Builds ok, connects to the Win 10 desktop but gives off LIBUSB ERROR. The device (web-camera) is passed on to the guest, shows up in Windows device manager shows up as HD Logitech Camera, but is not usable by the OS.

For connection I used the one reported here:
xfreerdp -grab-keyboard /bpp:24 /w:1600 /h:960 /v:$MYHOST /u:$USER /p:$PW /clipboard /drive:home,/home/kostya /fonts /sound:sys:oss,dev:4 /microphone:sys:oss,format:1 /rfx /dvc:urbdrc,id,dev:046d:081b

In the xfreerdp command feedback it returns something like "bus:1 dev:4 no device found", "no such device in udevman" and "LIBUSB_ERROR".

Tried this with Skype app in guest, it didn't say "no camera found", but couldn't use this one.

Please, how can I increase the debug level in xfreerdp command line to get more information?
Comment 7 Kyle Evans freebsd_committer 2019-08-26 13:40:04 UTC
(In reply to bergerkos from comment #6)

Looks like you can tack on a /log-level:DEBUG to get a lot more verbosity.
Comment 8 bergerkos 2019-08-28 19:18:20 UTC
Created attachment 206988 [details]
debug output from USB

This is typical debug messages appearing on screen when trying to connect USB web-campra using command line option /usb:dbg,dev:$mydevice
Comment 9 bergerkos 2019-08-28 19:26:21 UTC
Here is my typical debug output from the combined debug command line options added to xfreerdp command:

Actually, the screen is crowded by the message about CAM subsystem that are seen in the attached debug.txt. It seems to be trying to figure out about my system-connected card-reader. But since there are no cards there, there are errors. The system itself, however, doesn't give off any errors at boot time.

But then, some of the messages seem to pertain to the device in question.

The way it shows up in the VM on the freerdp screen is this. I launch the camera app and it works as though it used the camera. The camera LED goes on and stays on. Device manager indicates the presence of the HD Logitech web-camere C310. But other applications indicate there is no such device.

I also disabled webcamd and unloaded cuse4bsd driver, all to no avail.
Comment 10 bergerkos 2019-08-28 19:31:31 UTC
Sorry for confusion! In my initial message I wrote that I redirect this web-camera to a Windows 10 Pro "host", though it is meant to read, of course, "Windows 10 Pro GUEST in bhyve". So it is Windows 10 side and FreeBSD side. I haven't tried, though, how well (whether or not) this whole thing works in Linux.
Comment 11 bergerkos 2019-08-31 22:45:01 UTC
Ok, I've just tried this on Linux, for the purity of experiment. Windows 10 Pro guest in FreeBSD bhyve, connecting from Ubuntu 18.04.

Can't tell which git version is freerdp2 package there (presumably, not the last one), but it didn't work there either. I tried the same command option as described in my previous messages, with the end result just the same: camera not found in Win 10 guest. Though it is "found" in Windows Device Manager as "working without errors" etc., which is known not to mean much on Windows...

The only difference there, debug output from 
/log-filters:com.freerdp.channels.urbdrc.client:usb:DEBUG didn't contain this recurring error message from CAM subsystem about scsi devices attached to the host. Which is, of course, FreeBSD-specific.
Comment 12 Sergey Manucharian 2019-11-18 18:40:46 UTC
I tried a couple of USB flash drives and a proprietary software dongle with the patch. 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.
Comment 13 bergerkos 2020-03-10 10:09:34 UTC
OK, maybe this is off topic. 

This compilation give a MUCH better sound than the present port version because it uses the updated sources in which the sound problem has been fixed. Or should that be moved to another PR?
Comment 14 bergerkos 2020-03-10 21:12:38 UTC
False alarm, sorry :(. All the difference in sound was due to enabling/disabling FAAD. And I'll have to pay more attention.
Comment 15 bergerkos 2020-03-13 06:26:42 UTC
Hah, tried to build the last GIT. Fails to build since Fix #5910 for USB (acb77391a2c6735040866bad40955e3aacd961a8). And somewhere between 2c210feadfca4d23daed408e25e8b467a02769e and our port version graphics got broken, so that when RDP windows opens it looks like not enough video memory.

Oh, and it doesn't build without adding mntent.h.