2018-07-25 12:29 GMT+02:00 Emil Velikov <emil.l.velikov@xxxxxxxxx>:
> On 20 July 2018 at 12:33, Benjamin Gaignard
> <benjamin.gaignard@xxxxxxxxxx> 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@xxxxxxxxxx>
>> ---
>>
>> 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
It was my initial thought too: I have tried to add "-a" option to
enable atomic way
of working but their is small changes to do everywhere and that add
lot of conditional tests.
Make the changes for build system isn't that complicated (see in v2)
Regards,
Benjamin
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
