This enables us to check for overlay planes which are located 'below' the primary plane.
Since the alpha value only has an effect when creating surfaces with an alpha-pixelformat this doesn't affect the regular XRGB8888 primary surface.
Signed-off-by: Tobias Jakobi tjakobi@math.uni-bielefeld.de --- tests/modetest/buffers.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c index 7e214e8..30ac033 100644 --- a/tests/modetest/buffers.c +++ b/tests/modetest/buffers.c @@ -423,13 +423,13 @@ fill_smpte_rgb16(const struct rgb_info *rgb, unsigned char *mem, MAKE_RGBA(rgb, 0, 0, 192, 255), /* blue */ }; const uint16_t colors_middle[] = { - MAKE_RGBA(rgb, 0, 0, 192, 255), /* blue */ - MAKE_RGBA(rgb, 19, 19, 19, 255), /* black */ - MAKE_RGBA(rgb, 192, 0, 192, 255), /* magenta */ - MAKE_RGBA(rgb, 19, 19, 19, 255), /* black */ - MAKE_RGBA(rgb, 0, 192, 192, 255), /* cyan */ - MAKE_RGBA(rgb, 19, 19, 19, 255), /* black */ - MAKE_RGBA(rgb, 192, 192, 192, 255), /* grey */ + MAKE_RGBA(rgb, 0, 0, 192, 127), /* blue */ + MAKE_RGBA(rgb, 19, 19, 19, 127), /* black */ + MAKE_RGBA(rgb, 192, 0, 192, 127), /* magenta */ + MAKE_RGBA(rgb, 19, 19, 19, 127), /* black */ + MAKE_RGBA(rgb, 0, 192, 192, 127), /* cyan */ + MAKE_RGBA(rgb, 19, 19, 19, 127), /* black */ + MAKE_RGBA(rgb, 192, 192, 192, 127), /* grey */ }; const uint16_t colors_bottom[] = { MAKE_RGBA(rgb, 0, 33, 76, 255), /* in-phase */ @@ -547,13 +547,13 @@ fill_smpte_rgb32(const struct rgb_info *rgb, unsigned char *mem, MAKE_RGBA(rgb, 0, 0, 192, 255), /* blue */ }; const uint32_t colors_middle[] = { - MAKE_RGBA(rgb, 0, 0, 192, 255), /* blue */ - MAKE_RGBA(rgb, 19, 19, 19, 255), /* black */ - MAKE_RGBA(rgb, 192, 0, 192, 255), /* magenta */ - MAKE_RGBA(rgb, 19, 19, 19, 255), /* black */ - MAKE_RGBA(rgb, 0, 192, 192, 255), /* cyan */ - MAKE_RGBA(rgb, 19, 19, 19, 255), /* black */ - MAKE_RGBA(rgb, 192, 192, 192, 255), /* grey */ + MAKE_RGBA(rgb, 0, 0, 192, 127), /* blue */ + MAKE_RGBA(rgb, 19, 19, 19, 127), /* black */ + MAKE_RGBA(rgb, 192, 0, 192, 127), /* magenta */ + MAKE_RGBA(rgb, 19, 19, 19, 127), /* black */ + MAKE_RGBA(rgb, 0, 192, 192, 127), /* cyan */ + MAKE_RGBA(rgb, 19, 19, 19, 127), /* black */ + MAKE_RGBA(rgb, 192, 192, 192, 127), /* grey */ }; const uint32_t colors_bottom[] = { MAKE_RGBA(rgb, 0, 33, 76, 255), /* in-phase */
Don't assume that a plane supports any kind of pixelformat but do a check first.
v2: Simplify the format check. Signed-off-by: Tobias Jakobi tjakobi@math.uni-bielefeld.de --- tests/modetest/modetest.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index 7f0c1cc..29d4c34 100644 --- a/tests/modetest/modetest.c +++ b/tests/modetest/modetest.c @@ -969,6 +969,18 @@ page_flip_handler(int fd, unsigned int frame, } }
+static bool format_support(const drmModePlanePtr ovr, uint32_t fmt) +{ + unsigned int i; + + for (i = 0; i < ovr->count_formats; ++i) { + if (ovr->formats[i] == fmt) + return true; + } + + return false; +} + static int set_plane(struct device *dev, struct plane_arg *p) { drmModePlane *ovr; @@ -999,7 +1011,7 @@ static int set_plane(struct device *dev, struct plane_arg *p)
for (i = 0; i < dev->resources->plane_res->count_planes && !plane_id; i++) { ovr = dev->resources->planes[i].plane; - if (!ovr) + if (!ovr || !format_support(ovr, p->fourcc)) continue;
if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id)
Hi Tobias
On 12 May 2015 at 21:17, Tobias Jakobi tjakobi@math.uni-bielefeld.de wrote:
Don't assume that a plane supports any kind of pixelformat but do a check first.
v2: Simplify the format check. Signed-off-by: Tobias Jakobi tjakobi@math.uni-bielefeld.de
Nice catch ! I will push the tomorrow, unless we hear any objections against it.
Patch 1/2 looks sane imho, although I'm not sure if some of the teams has some (automated?) testing which depends on the lack of transparency. Curious if pinging people (check git log for a list) at #dri-devel or via email might show such users ?
Cheers, Emil
Hey Emil,
Emil Velikov wrote:
Hi Tobias
On 12 May 2015 at 21:17, Tobias Jakobi tjakobi@math.uni-bielefeld.de wrote:
Don't assume that a plane supports any kind of pixelformat but do a check first.
v2: Simplify the format check. Signed-off-by: Tobias Jakobi tjakobi@math.uni-bielefeld.de
Nice catch ! I will push the tomorrow, unless we hear any objections against it.
Patch 1/2 looks sane imho, although I'm not sure if some of the teams has some (automated?) testing which depends on the lack of transparency.
I'm not sure what you mean by that ('lack of transparency'). If you create your primary plane with a XRGB-type format then this patch doesn't change anything. If you create it with an ARGB-type format then I can assume that the user wants an alpha-channel (he explicitly asks for it).
With best wishes, Tobias
Curious if pinging people (check git log for a list) at #dri-devel or via email might show such users ?
Cheers, Emil
On 21/05/15 18:02, Tobias Jakobi wrote:
Hey Emil,
Emil Velikov wrote:
Hi Tobias
On 12 May 2015 at 21:17, Tobias Jakobi tjakobi@math.uni-bielefeld.de wrote:
Don't assume that a plane supports any kind of pixelformat but do a check first.
v2: Simplify the format check. Signed-off-by: Tobias Jakobi tjakobi@math.uni-bielefeld.de
Nice catch ! I will push the tomorrow, unless we hear any objections against it.
Patch 1/2 looks sane imho, although I'm not sure if some of the teams has some (automated?) testing which depends on the lack of transparency.
I'm not sure what you mean by that ('lack of transparency').
The lack of transparency in my explanation :-)
If you create your primary plane with a XRGB-type format then this patch doesn't change anything. If you create it with an ARGB-type format then I can assume that the user wants an alpha-channel (he explicitly asks for it).
True. But the test might be assuming that alpha is always 255, thus it expects that the output for XRGB and ARGB type formats is the same.
Obviously the likely-hood of all that is negligible, esp. considering the benefit that the patch brings.
I'm picking libdrm patches off the list as we speak, which will include both of these.
Thanks Emil
Sorry for the late reply!
On 2015-05-28 14:25, Emil Velikov wrote:
If you create your primary plane with a XRGB-type format then this patch doesn't change anything. If you create it with an ARGB-type format then I can assume that the user wants an alpha-channel (he explicitly asks for it).
True. But the test might be assuming that alpha is always 255, thus it expects that the output for XRGB and ARGB type formats is the same.
I still don't understand this part at all. What "test" are we actually talking about? Do you mean some test application that somehow internally uses output from libdrm's modetest? I have trouble seeing how this should work at all? If this patch changes anything then it's visual output on the screen (assuming that the DRM driver somehow interprets the content of the 'X' channel). So only something that a human inspecting the screen could detect.
Or am I missing something here?
Obviously the likely-hood of all that is negligible, esp. considering the benefit that the patch brings.
I'm picking libdrm patches off the list as we speak, which will include both of these.
Thanks Emil
With best wishes, Tobias
On 11 June 2015 at 14:43, Tobias Jakobi tjakobi@math.uni-bielefeld.de wrote:
Sorry for the late reply!
On 2015-05-28 14:25, Emil Velikov wrote:
If you create your primary plane with a XRGB-type format then this patch doesn't change anything. If you create it with an ARGB-type format then I can assume that the user wants an alpha-channel (he explicitly asks for it).
True. But the test might be assuming that alpha is always 255, thus it expects that the output for XRGB and ARGB type formats is the same.
I still don't understand this part at all. What "test" are we actually talking about? Do you mean some test application that somehow internally uses output from libdrm's modetest? I have trouble seeing how this should work at all? If this patch changes anything then it's visual output on the screen (assuming that the DRM driver somehow interprets the content of the 'X' channel). So only something that a human inspecting the screen could detect.
Or am I missing something here?
I'm a master of finding some elaborate cases which few sane person would ever think of. The case I'm thinking is about a hypothetical broken test(ing scenario), and as such it's not our issue :-) So don't bother with it at all.
-Emil
dri-devel@lists.freedesktop.org
-
Emil Velikov -
Tobias Jakobi