[RESEND PATCH 1/2] modetest: make middle SMPTE colors transparent

[RESEND PATCH 1/2] modetest: make middle SMPTE colors transparent

[Tobias Jakobi]

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 */
-- 
2.0.5

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[RESEND PATCH 2/2] modetest: only select plane with matching format

[Tobias Jakobi]

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)
-- 
2.0.5

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH 2/2] modetest: only select plane with matching format

[Emil Velikov]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH 2/2] modetest: only select plane with matching format

[Tobias Jakobi]

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
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH 2/2] modetest: only select plane with matching format

[Emil Velikov]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH 2/2] modetest: only select plane with matching format

[Tobias Jakobi]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH 2/2] modetest: only select plane with matching format

[Emil Velikov]

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 mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel