dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Siqueira via dri-devel <dri-devel@lists.freedesktop.org>
To: Mamta Shukla <mamtashukla555@gmail.com>
Cc: hamohammed.sa@gmail.com, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 2/2] drm/vkms: Modify memset() in compute_crc function
Date: Thu, 14 Feb 2019 20:31:58 -0200	[thread overview]
Message-ID: <20190214223158.ris2sgueygkwxzoh@smtp.gmail.com> (raw)
In-Reply-To: <b7f37c793c9f37cddff6dc548a592412335114c6.1548798107.git.mamtashukla555@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4052 bytes --]

Hi,

On 01/30, Mamta Shukla wrote:
> Replace memset(vaddr_out + src_offset + 24, 0,  8) with
> memset(vaddr_out + src_offset + 3, 0, 1) because memset fills
> memory in bytes and not in bits.
> 
> Signed-off-by: Mamta Shukla <mamtashukla555@gmail.com>
> ---
> No changes in v2.
> 
>  drivers/gpu/drm/vkms/vkms_crc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
> index dc6cb4c2cced..5135642fb204 100644
> --- a/drivers/gpu/drm/vkms/vkms_crc.c
> +++ b/drivers/gpu/drm/vkms/vkms_crc.c
> @@ -31,7 +31,7 @@ static uint32_t compute_crc(void *vaddr_out, struct vkms_crc_data *crc_out)
>  				     + (i * crc_out->pitch)
>  				     + (j * crc_out->cpp);
>  			/* XRGB format ignores Alpha channel */
> -			memset(vaddr_out + src_offset + 24, 0,  8);
> +			memset(vaddr_out + src_offset + 3, 0, 1);

Nice catch :)

This look like a bug.
The strange part for me is the fact that IGT does not complain about
this operation. Additionally, I expect a buffer overflow here... Why the
current code works without any problem?

Anyway...
As you already knows, this patch makes IGT shows some warnings like
this:

(kms_cursor_crc:423) igt_debugfs-WARNING: Warning on condition all_zero in function crc_sanity_checks, file ../lib/igt_debugfs.c:901
(kms_cursor_crc:423) igt_debugfs-WARNING: Suspicious CRC: All values are 0.

For me, your code makes sense, but I can't understand why we still get
these warnings. After long hours of testing and thinking about this
issue I started to suspect that we have a byte-order problem here.

I suspect that "memset(addr + 3, 0, 1)" does not set 0 in the Alpha
channel because we're using a Little-endian architecture and your code
works like a big-endian. In other words, the correct offset should be 0.

I did a bunch of experiments, and in the end, I wrote this "draft" of
fix:

diff --git a/drivers/gpu/drm/vkms/vkms_crc.c b/drivers/gpu/drm/vkms/vkms_crc.c
index 9d9e8146db90..a9876ade619b 100644
--- a/drivers/gpu/drm/vkms/vkms_crc.c
+++ b/drivers/gpu/drm/vkms/vkms_crc.c
@@ -14,9 +14,23 @@
  * returns CRC value computed using crc32 on the visible portion of
  * the final framebuffer at vaddr_out
  */
-static uint32_t compute_crc(void *vaddr_out, struct vkms_crc_data *crc_out)
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#define RGBA_ALPHA 0
+#define RGBA_BLUE  1
+#define RGBA_GREEN 2
+#define RGBA_RED   3
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#define RGBA_ALPHA 3
+#define RGBA_BLUE  2
+#define RGBA_GREEN 1
+#define RGBA_RED   0
+#endif
+
+static uint32_t compute_crc(char *vaddr_out, struct vkms_crc_data *crc_out)
 {
  int i, j, src_offset;
+ unsigned char *pixel;
  int x_src = crc_out->src.x1 >> 16;
  int y_src = crc_out->src.y1 >> 16;
  int h_src = drm_rect_height(&crc_out->src) >> 16;
@@ -29,9 +43,9 @@ static uint32_t compute_crc(void *vaddr_out, struct vkms_crc_data *crc_out)
          + (i * crc_out->pitch)
          + (j * crc_out->cpp);
    /* XRGB format ignores Alpha channel */
-   memset(vaddr_out + src_offset + 24, 0,  8);
-   crc = crc32_le(crc, vaddr_out + src_offset,
-           sizeof(u32));
+   pixel = vaddr_out + src_offset;
+   pixel[RGBA_ALPHA] = 0;
+   crc = crc32_le(crc, pixel, sizeof(u32));
   }
  }
 
Noticed that I made some extra changes, but the important part
"pixel[RGBA_ALPHA] = 0". Accordingly with the endianness architecture
the macro RGBA will change its value. Anyway, the above code fixed the
warning issue; Could you take a look on this? Or do you have another
idea?

In addition, Daniel suggested taking a look at "drm fourcc" code since
it has fixed endianness and take a look at DRM_FORMAT_HOST_ARGB8888.

Best Regards

>  			crc = crc32_le(crc, vaddr_out + src_offset,
>  				       sizeof(u32));
>  		}
> -- 
> 2.17.1
> 

-- 
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

  parent reply	other threads:[~2019-02-14 22:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-29 21:54 [PATCH v2,1/2] drm/vkms: Use alpha for blending in blend() function Mamta Shukla
2019-01-29 22:00 ` [PATCH v2 2/2] drm/vkms: Modify memset() in compute_crc function Mamta Shukla
2019-01-31 16:39   ` Wentland, Harry
2019-02-14 22:31   ` Rodrigo Siqueira via dri-devel [this message]
2019-01-31 12:44 ` [PATCH v2,1/2] drm/vkms: Use alpha for blending in blend() function Rodrigo Siqueira
2019-02-01 17:15   ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190214223158.ris2sgueygkwxzoh@smtp.gmail.com \
    --to=dri-devel@lists.freedesktop.org \
    --cc=hamohammed.sa@gmail.com \
    --cc=mamtashukla555@gmail.com \
    --cc=rodrigosiqueiramelo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox