testpat: Fix memory mapping in threaded drawing

The IFramebuffer::map() function is not thread-safe, which is why the
threaded implementation of draw_test_pattern_impl() maps all planes
before starting to draw. A typo slipped in the code, resulting in only
plane 0 being mapped. This didn't result in an immediate segfault, as
drawing operations in the worker threads map the remaining planes.
However, due to the implementation of DumbFramebuffer::map(), this can
result in the same plane being mapped multiple times, with only one of
the mapping recorded in the mapping cache. The other mappings are then
leaked, leading not only to extra memory consumption, but also to the
DRM device never being released even after the destruction of the Card
object.

Fix this.

Fixes: 40d96062a37c ("Revert "testpat: remove threaded drawing"")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
1 file changed
tree: 008ac36df12bcc75c1498796300cdef78860f55c
  1. .github/
  2. kms++/
  3. kms++util/
  4. kmscube/
  5. py/
  6. scripts/
  7. subprojects/
  8. utils/
  9. .clang-format
  10. .clang-tidy
  11. .gitignore
  12. .gitmodules
  13. .travis.yml
  14. Android.bp
  15. LICENSE
  16. meson.build
  17. meson_options.txt
  18. README.md
  19. TODO
README.md

Build Status

kms++ - C++ library for kernel mode setting

kms++ is a C++17 library for kernel mode setting.

Also included are some simple utilities for KMS and python bindings for kms++.

Utilities

  • kmstest - set modes and planes and show test pattern on crtcs/planes, and test page flips
  • kmsprint - print information about DRM objects
  • kmsview - view raw images
  • kmscube - rotating 3D cube on crtcs/planes
  • kmscapture - show captured frames from a camera on screen

Dependencies:

  • libdrm
  • Python 3.x (for python bindings)

Build instructions:

meson setup build
ninja -C build

Cross compiling instructions:

meson build --cross-file=<path-to-meson-cross-file>
ninja -C build

Here is my cross file for arm32 (where ${BROOT} is path to my buildroot output dir):

[binaries]
c = ['ccache', '${BROOT}/host/bin/arm-buildroot-linux-gnueabihf-gcc']
cpp = ['ccache', '${BROOT}/host/bin/arm-buildroot-linux-gnueabihf-g++']
ar = '${BROOT}/host/bin/arm-buildroot-linux-gnueabihf-ar'
strip = '${BROOT}/host/bin/arm-buildroot-linux-gnueabihf-strip'
pkgconfig = '${BROOT}/host/bin/pkg-config'

[host_machine]
system = 'linux'
cpu_family = 'arm'
cpu = 'arm'
endian = 'little'

Build options

You can use meson options to configure the build. E.g.

meson build -Dbuildtype=debug -Dkmscube=true

Use meson configure build to see all the configuration options and their current values.

kms++ specific build options are:

Option nameValuesDefaultNotes
pykmstrue, falsetruePython bindings
kmscubetrue, falsefalseGLES kmscube
omapenabled, disabled, autoautolibdrm-omap support

Env variables

You can use the following runtime environmental variables to control the behavior of kms++.

VariableDescription
KMSXX_DISABLE_UNIVERSAL_PLANESSet to disable the use of universal planes
KMSXX_DISABLE_ATOMICSet to disable the use of atomic modesetting
KMSXX_DEVICEPath to the card device node to use
KMSXX_DRIVERName of the driver to use. The format is either “drvname” or “drvname:idx”

Python notes

You can run the python code directly from the build dir by defining PYTHONPATH env variable. For example:

PYTHONPATH=build/py py/tests/hpd.py