minigbm: rework flag API

We've been back and forth on the semantics of the flag API many
times, and the current situation is confusing.

Change the drivers so every combination defines a distinct type of
buffer. That means if the same format is in the combination list three
times, the tiling or format modifiers of one of those combinations must
be different from the other two.

Let's add a priority variable in struct supported_combination that
breaks ties. For example, if a consumer specifies BO_USE_TEXTURE,
we of course can texture from both linear and tiled buffers, but
because a tiled buffer's priority is greater, it will be chosen.

If a consumer specifies BO_USE_TEXTURE | BO_USE_SW_WRITE_OFTEN, the
tiled combination won't have the BO_USE_SW_WRITE_OFTEN flag and the
linear combination will be chosen.

We expect drivers to modify the combinations after querying KMS.
This is clunky using linked lists, so get rid of list.h and use arrays.

BUG=chromium:616275
TEST=all the following compiles:

emerge-cyan minigbm/arc-cros-gralloc
emerge-oak minigbm/arc-cros-gralloc
emerge-veyron_minnie-cheets minigbm/arc-cros-gralloc
emerge-peach_pi minigbm
emerge-nyan_big minigbm
emerge-jadeite minigbm

Tested with gbmtest on cyan, checked if Chrome boots

Change-Id: Ib3fccf6f0cb86c8ded45924297df3c06f8e49271
Reviewed-on: https://chromium-review.googlesource.com/448252
Commit-Ready: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

1 files changed, 1 insertions, 2 deletions

diff --git a/gbm.c b/gbm.c
index 6ad32ce..89726dd 100644
--- a/gbm.c
+++ b/gbm.c
@@ -42,8 +42,7 @@ gbm_device_is_format_supported(struct gbm_device *gbm,
 
 	drv_usage = gbm_convert_flags(usage);
 
-	return drv_is_combination_supported(gbm->drv, format, drv_usage,
-					    DRM_FORMAT_MOD_NONE);
+	return (drv_get_combination(gbm->drv, format, drv_usage) != NULL);
 }
 
 PUBLIC struct gbm_device *gbm_create_device(int fd)