The camera-sharing framework provides a virtual device (vdev) that lets guest applications access and stream the display
of a camera that's connected to the host.
The framework uses components from other QNX products to interact with the camera and display its video frames.
Note:
This chapter assumes that you are already familiar with the concepts presented in the
following documentation:
The virtio-video-camera vdev is based on draft version 3 of the VirtIO-Video specification,
which is a proposed amendment to the existing VirtIO 1.1 specifications.
Camera sharing
The host manages all interactions between guests and the camera hardware:
- The hypervisor host contains the Sensor Framework components needed to work with the camera hardware.
Among these components is the Camera library, which provides an interface for using cameras connected to the host.
For details on how this library uses the other components to manage the cameras and to display their video, see below.
- To allow a guest to share a camera with the host, the VM (i.e., qvm process)
that hosts the guest must include the camera vdev (virtio-video-camera).
- To interact with the vdev, each guest runs its own camera driver that complies with the VirtIO-Video message standard.
The driver runs as a dynamic library and is loaded by the VM.
- To communicate with each other (command and control), the camera driver and the vdev use virtqueues,
which are the standard mechanism for data transport on VirtIO devices. Note that shared buffers are used for camera frames.
- On Android guests, applications use the Extended View System (EVS) framework to access and use connected cameras.
The VirtIO-Video camera driver forwards commands sent to the EVS to the vdev, which processes them.
The diagram below illustrates the interaction between guests and the camera hardware on the host system.
This interaction is managed by the
virtio-video-camera vdev, Camera library, and Sensor service on the host,
as well as
Screen.
Figure 1. Camera framework architecture
Note:
The camera-sharing framework requires additional services from other QNX products for its operation.
The Camera library and Sensor service are required in the host, so the vdev backend can interact with the hardware.
These two components must be included in the host image, which means the Sensor Framework must be installed on your
development system; for more information, see the Release Notes.
The Screen Graphics Subsystem is also required in the host, so the Sensor service can render the camera video
on the display. By default, Screen is included in a hypervisor host image.
Note:
For more information on device sharing in the
QNX Hypervisor, see the
section on
Devices in the
Understanding QNX Virtual Environments chapter
of the QNX Hypervisor
User's Guide.
Camera virtualization
When guest applications execute camera API calls, these calls are forwarded to the Camera library on the host,
which handles them. This capability, which we refer to as
camera virtualization, is supported by
the following components:
- virtio-video-camera vdev
- The virtio-video-camera vdev is a para-virtualized device that
enables camera requests from guests to be executed on the host.
This vdev runs in a hypervisor VM but doesn't emulate a hardware camera.
Instead, it forwards camera API calls received through a guest driver to the Camera library instance
on the host. It also reports the results of operations back to the guest.
- Camera library
- This library (libcamapi.so) provides applications with an interface to access cameras
connected to the hardware of the host. The interface supports functions such as starting and closing cameras,
zooming, changing the focus, etc. The Camera library uses the Sensor service to carry out these operations.
- Sensor service
- The Sensor service interacts directly with the camera hardware. The Sensor configuration file is where you must
configure the cameras that you want guest applications to use. The service also interacts with
Screen to display the camera video.