[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1486768] Re: BlackMagic USB3 video capture returns onl
From: |
Steinar H. Gunderson |
Subject: |
[Qemu-devel] [Bug 1486768] Re: BlackMagic USB3 video capture returns only blank frames in Windows (xHCI issue) |
Date: |
Mon, 18 Dec 2017 10:10:10 -0000 |
I haven't tried this in a long time, and I already managed to do what I
wanted to do (which was to write a free Linux driver :-) ). I guess you
can close this; not because I believe it's fixed, but because it's not
that important to me anymore.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1486768
Title:
BlackMagic USB3 video capture returns only blank frames in Windows
(xHCI issue)
Status in QEMU:
Incomplete
Bug description:
Hi,
I've got an Intensity Shuttle USB3; it's a HDMI video capture card. It
doesn't have any Linux drivers, so I'm trying to get it to work in a
Windows 10 guest inside QEMU. I'm running latest git as of today
(2015-08-20). I use this command line:
sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096
-acpitable file=/sys/firmware/acpi/tables/MSDM -drive
file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev
tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0
-monitor stdio -device nec-usb-xhci,id=xhci -device usb-
host,bus=xhci.0,vendorid=0x1edb,productid=0xbd3b -usbdevice tablet
(I will add that the seemingly logical “host:1edb:bd3b,bus=xhci.0” did
_not_ add the device at all. I don't know why, probably some parser
issue?)
The card is properly detected, and the driver thinks everything is
fine, running on the virtualized USB3 host and all. Looking at usbmon,
there's lots of isochronous frames during capture, and they reach the
host (looking at USBpcap on the Windows 10 side). However, the driver
refuses to capture any video—all frames become black in all
applications I try (well, Media Express seems to hardly store any
frames at all in the .avi). However, audio is captured without a
hitch. Curiously enough, no dropped frames are reported. There's no
sign of CPU shortage; both host and guest seem to be happy around 20%
of one core.
I am fairly certain this is an issue with the xHCI driver in QEMU,
because if I give it the entire USB controller via VT-d, it works
flawlessly, with video and all. For reference, here's the associated
command line I use for that (after I've unbound it from the Linux
system):
sudo x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 2 -m 4096
-acpitable file=/sys/firmware/acpi/tables/MSDM -drive
file=/home/sesse/windows.raw,if=virtio,format=raw -cpu host -netdev
tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0
-monitor stdio -usbdevice tablet -device pci-assign,host=00:14.0
I can get USB pcap logs from both sides if you want, but they are huge
(gigabytes) since the data rate is so high.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1486768/+subscriptions