linux-kernel - Re: [PATCH V3 4/5] drm/vkms: Compute CRC without change input data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Jul 2019 11:00:56 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Simon Ser <contact@...rsion.fr>
Cc:     Rodrigo Siqueira <rodrigosiqueiramelo@...il.com>,
        Brian Starkey <brian.starkey@....com>,
        Liviu Dudau <liviu.dudau@....com>,
        Haneen Mohammed <hamohammed.sa@...il.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V3 4/5] drm/vkms: Compute CRC without change input data

On Thu, Jul 11, 2019 at 10:28 AM Simon Ser <contact@...rsion.fr> wrote:
>
> On Thursday, July 11, 2019 11:21 AM, Daniel Vetter <daniel@...ll.ch> wrote:
>
> > On Tue, Jun 25, 2019 at 10:38:31PM -0300, Rodrigo Siqueira wrote:
> >
> > > The compute_crc() function is responsible for calculating the
> > > framebuffer CRC value; due to the XRGB format, this function has to
> > > ignore the alpha channel during the CRC computation. Therefore,
> > > compute_crc() set zero to the alpha channel directly in the input
> > > framebuffer, which is not a problem since this function receives a copy
> > > of the original buffer. However, if we want to use this function in a
> > > context without a buffer copy, it will change the initial value. This
> > > patch makes compute_crc() calculate the CRC value without modifying the
> > > input framebuffer.
> >
> > Uh why? For writeback we're writing the output too, so we can write
> > whatever we want to into the alpha channel. For writeback we should never
> > accept a pixel format where alpha actually matters, that doesn't make
> > sense. You can't see through a real screen either, they are all opaque :-)
>
> I'm not sure about that. See e.g.
> https://en.wikipedia.org/wiki/See-through_display

They have variable opaqueness, independent of the color value?

> Many drivers already accept FBs with alpha channels for the primary
> plane.
> https://drmdb.emersion.fr/formats?plane=1

If you have a background color (we assume it to be black) that makes
sense. Still doesn't mean we render transparent output, we don't.

> Just making sure we aren't painting ourselves into a corner. :P

You can add ARGB to your writeback format support list, there is no
corner here at all to get into (at least in the abstract sense).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch