Announcement

Collapse
No announcement yet.

QEMU 4.1 Released With Many ARM, MIPS & x86 Additions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SystemCrasher
    replied
    Originally posted by mifritscher View Post
    Emulation of a MJPEG network camera is fairly simple - and can be used by most video software. Or, if you have an usb camera, you can simply use usb-passthrough.
    I can imagine he wants more or less persuading "camera" that would be used by programs that want just "camera". Just because I doubt someone would think of virtual devices if all they need is "network stream". In *nix ffmpeg or vlc can craft network stream of nearly any possible protocol/codec/container at which point virtual device sounds really excessive. But, say, video-calls software wouldn't readily take network stream as "camera" - it would need something more persuading. At which point I can understand idea of virtual device.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by SystemCrasher View Post
    Closest I know would be something like https://github.com/umlaeute/v4l2loopback - but it isn't about qemu. Its a Linux kernel module exposing "fake" V4L2 camera, capable of arbitrary output. If that combo isn't ok for your use case (Linux, custom kernel module, Linux apps) - sorry.
    Nice! Will try using it. Thanks.

    Leave a comment:


  • mifritscher
    replied
    Emulation of a MJPEG network camera is fairly simple - and can be used by most video software. Or, if you have an usb camera, you can simply use usb-passthrough.

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by tildearrow View Post
    I have a question. Is it possible to simulate a camera on QEMU?
    Closest I know would be something like https://github.com/umlaeute/v4l2loopback - but it isn't about qemu. Its a Linux kernel module exposing "fake" V4L2 camera, capable of arbitrary output. If that combo isn't ok for your use case (Linux, custom kernel module, Linux apps) - sorry.

    I can also imagine more or less "hardware" solution that is far more universal in this regard. Some piece of hardware (microcontroller, hardcore mode, or Linux SBC capable of being usb-gadget, easier) can pretend it's just another USB camera, while actual output isn't taken from matrix. Say, I expose self a fake usb-ethernet and usb-serial adapters from SBCs - and software readily assumes its newtork card for the real. If I remember there is also usb-uvc gadget module, doing, guess what. So it seems one can try putting Linux on usb-otg capable SBC and then expose "uvc webcam" out of it. Something like https://github.com/jdonald/uvc-gadget and around. Some Pi and similar SBCs can do it as long as they have usb-otg capable port, to operate as "device" (camera in this case). It can imply some adventure, but result would be more or less hardware "camera" sending whatever you want.
    Last edited by SystemCrasher; 18 August 2019, 11:41 AM.

    Leave a comment:


  • muncrief
    replied
    Originally posted by tuxd3v View Post

    And you are only focused in Software..

    .....
    In the past you needed the hardware, and it was very difficult, you messed up on some registers, or ports.. and you are done..by another board..

    ....
    Oh wow, I'm a retired embedded systems designer and I didn't know that. I just did a quick check and it looks like I could even replace my old Zedboard with it. That's ultra cool!

    Those things, and most development boards, are very fragile. I used to regularly buy multiple ones because I'm very lazy and clumsy. I'd set up cardboard harnesses, balance things on books, etc., and generally surround myself with an octopus of wires. So I was always yanking out cables and such. Especially after days and weeks of working 14 hours a day

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by muncrief View Post
    QEMU with KVM finally made using Windows with Linux completely seamless for me. Though I don't need Windows for many things, primarily Band in a Box for myself and debugging things for others, it was always a pain to dual boot into it and leave Linux completely behind for hours or days.

    But with GPU and USB passthrough I simply run Windows on another monitor or TV while using Linux, and amazingly my own rough benchmarks consistently show a minor 4% overhead for the VM. It's truly amazing.
    And you are only focused in Software..

    Now turn the table,
    And be developing for ARM,MIPS,RISC-V, in your platform of choice!!
    Using neon simd,sma simd, graphics and such..

    In the past you needed the hardware, and it was very difficult, you messed up on some registers, or ports.. and you are done..by another board..

    Now you can develop your workflows, in a virtualized environment,
    Prepare your code, for real hardware, and only then switch to the target devices, for last optimisations..

    Nowadays everybody can develop for ARM,MIPS,RISC-V, without having the hardware for it..
    You can even run code from your native architecture, in the foreign one( this is what people do, when creating a distro for a foreign {ARM,MIPS,RISC-V} arch, but they are working in a x86 native platform ).. It's indeed truly amazing!

    Leave a comment:


  • muncrief
    replied
    QEMU with KVM finally made using Windows with Linux completely seamless for me. Though I don't need Windows for many things, primarily Band in a Box for myself and debugging things for others, it was always a pain to dual boot into it and leave Linux completely behind for hours or days.

    But with GPU and USB passthrough I simply run Windows on another monitor or TV while using Linux, and amazingly my own rough benchmarks consistently show a minor 4% overhead for the VM. It's truly amazing.

    Leave a comment:


  • Britoid
    replied
    Originally posted by s_j_newbury View Post
    Which is a shame as in theory it should be possible to re-use gallium-nine to provide D3D9 support. As for performance, it 's less than native, but probably sufficient for most things short of AAA games.
    It would probably be easier to provide a Vulkan pass through (which is already in the works afaik) and have a DXVK-based driver. Would avoid having to send DirectX to the host.

    Imho Gallum-Nine is dead.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by schmidtbag View Post
    Otherwise, you need a virtual driver for a camera. I'm not sure if one exists.
    Exactly what I mean. I'm pretty sure it exists to some extent, due to the Android Emulator being based on QEMU and being able to show a checkerboard when I open the camera app.

    Leave a comment:


  • s_j_newbury
    replied
    Originally posted by timofonic View Post

    Dof a this mean not need to use nasty PCI passtrought, VirtualGL for OpenGL or Wine-based Direct3D emulation? Can it reach native or near-native 2D and 3D rendering so able to run high end software such as videogames?
    VirGL itself is not exactly new, but it lacks a complete Windows driver AFAIK. There's a basic virtio-gpu driver for Windows10, but I don't believe anybody has written a Direct3D driver for it (or ported the Mesa Gallium VirGL). Unfortunately, again AFAIK there isn't even a driver for <Windows 10, which is a shame as in theory it should be possible to re-use gallium-nine to provide D3D9 support. As for performance, it 's less than native, but probably sufficient for most things short of AAA games.

    Leave a comment:

Working...
X