[PATCH libdrm] tests/modetest: Add modetest_atomic tool

Emil Velikov emil.l.velikov at gmail.com
Wed Jul 25 10:29:45 UTC 2018


On 20 July 2018 at 12:33, Benjamin Gaignard
<benjamin.gaignard at linaro.org> wrote:
> This is a modetest like tool but using atomic API.
>
> With modetest_atomic it is mandatory to specify a mode ("-s")
> and a plane ("-P") to display a pattern on screen.
>
> "-v" does a loop swapping between two framebuffers for each
> active planes.
>
> modetest_atomic doesn't offer cursor support
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at linaro.org>
> ---
>
> The code is based on modetest and keep most of it infrastructure
> like arguments parsing, finding properties id from their name,
> resources dumping or the general way of working.
> It duplicates modetest code but adding compilation flags or
> conditional tests everywhere in modetest would have made it
> more complex and unreadable.
>
> Creating modetest_atomic could allow to test atomic API without
> need to use "big" frameworks like weston, drm_hwcomposer or igt
> with all their dependencies.
> kmscube could also be used to test atomic API but it need EGL.
>
> It have been tested (only) on stm driver with one or two planes
> actived.
>
>  tests/modetest/Makefile.am       |   13 +-
>  tests/modetest/Makefile.sources  |    7 +
>  tests/modetest/modetest_atomic.c | 1546 ++++++++++++++++++++++++++++++++++++++

Quick diff/grep/wc exercise shows that ~10% of modetest_atomic.c is new code.
I agree that modetest.c is getting kind of big and messy. How about
instead of duplicating it, we flesh out the legacy vs atomic codepaths
into helpers in separate files?

It will result in [c]leaner code, only one executable
installed/packaged and less build system changes.

What do you think?
Emil


More information about the dri-devel mailing list