summaryrefslogtreecommitdiff
path: root/src/cam/drm.cpp
AgeCommit message (Collapse)Author
2022-10-20Move test applications to src/apps/Laurent Pinchart
The cam and qcam test application share code, currently through a crude hack that references the cam source files directly from the qcam meson.build file. To prepare for the introduction of hosting that code in a static library, move all applications to src/apps/. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-09-28cam: drm: Skip DRM devices not capable of mode settingLaurent Pinchart
The DRM helper picks the first DRM card that it can open. On platforms that have a standalone GPU, this risks selecting a device corresponding to the GPU instead of the display controller. Fix this by skipping devices that don't support the KMS mode setting API. Some legacy display controllers would be skipped as well, but libcamera doesn't run on those systems anyway. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-09cam: drm: Add support for test-only commitsLaurent Pinchart
Test-only commits are used to test a commit without applying any modification to the device. This will be used by the KMS sink to test feature support. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-06-19cam: drm: Support /dev/dri cards other than 0Eric Curtin
Existing code is hardcoded to card0. Since recent fedora upgrades, we have noticed on more than one machine that card1 is present as the lowest numbered device, could theoretically be higher. This technique tries every file starting with card and continue only when we have successfully opened one. These devices with card1 as the lowest device were simply failing when they do not see a /dev/dri/card0 file present. Reported-by: Ian Mullins <imullins@redhat.com> Tested-by: Ian Mullins <imullins@redhat.com> Signed-off-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-05-23cam: event_loop: Rename addEvent to addFdEventEric Curtin
With the addition of addTimerEvent, the naming of addEvent is specific to the management of an fd, while the naming is generic. Update the name to make the naming scheme consistent in specifying the type of event to be added. Signed-off-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-12-04libcamera: base: shared_fd: Rename fd() to get()Laurent Pinchart
For consistency with UniqueFD, rename the fd() function to get(). Renaming UniqueFD::get() to fd() would have been another option, but was rejected to keep as close as possible to the std::shared_ptr<> and std::unique_ptr<> APIs. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07cam: drm: Avoid importing the same dmabuf multiple timesLaurent Pinchart
When creating a DRM frame buffer, the dmabufs for the planes are imported as GEM objects. For multi-planar formats, all planes may use the same dmabuf, which results in multiple imports. This doesn't cause any issue at import time, as DRM detects this situation and returns the same GEM object. However, when destroying the frame buffer, the same GEM object ends up being closed multiple times, which generates an error. Fix this by avoiding multiple imports of the same dmabuf for the same frame buffer. While the issue may theoretically occur with identical dmabufs for different frame buffers, this is quite unlikely and is thus not addressed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07cam: drm: Set per-plane offsets when creating DRM frame bufferLaurent Pinchart
Now that libcamera supports per-plane offsets, pass the values to drmModeAddFB2(). The KMS sink in cam is now capable of rendering multi-planar formats. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07cam: drm: Support per-plane stride valuesLaurent Pinchart
The stride is not always identical for all planes for multi-planar formats. Semi-planar YUV formats without horizontal subsampling often have a chroma stride equal to twice the luma stride, and tri-planar YUV formats with a 1/2 horizontal subsampling often have a chroma stride equal to half the luma stride. This isn't correctly taken into account when creating a DRM frame buffer, as the same stride is set for all planes. libcamera doesn't report per-plane stride values yet, but uses chroma strides that match the above description for all currently supported platforms. Calculation the chrome strides appropriately in the KMSSink class, and pass them to DRM::createFrameBuffer(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-05cam: Add DRM helper classesLaurent Pinchart
To prepare for viewfinder operation through the DRM/KMS API, add a set of helper classes that encapsulate the libdrm functions. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>