[PATCH weston] desktop-shell: do not black out with startup "none"

[Bryce Harrington]

On Wed, May 27, 2015 at 09:48:50AM +0300, Pekka Paalanen wrote:
> On Tue, 26 May 2015 17:06:49 -0700
> Bryce Harrington <bryce at osg.samsung.com> wrote:
> 
> > On Tue, May 26, 2015 at 03:52:59PM +0300, Pekka Paalanen wrote:
> > > On Tue, 26 May 2015 07:24:04 -0500
> > > Derek Foreman <derekf at osg.samsung.com> wrote:
> > > > On 26/05/15 03:54 AM, Pekka Paalanen wrote:
> > > > > Now, when there is no black surface at all for "none", the compositor
> > > > > will show garbage until weston-desktop-shell gets everything up. This
> > > > > may be undesireable but works for tests. To have the old "none"
> > > > > behaviour back, I would propose to add a new startup-animation value
> > > > > "black" for it.
> > > 
> > > Btw. the "garbage" seems to be just black as well, as far as I've seen.
> > > So visually it's not any different from before, but of course is less
> > > reliably black.
> > 
> > Does debug vs. release type builds affect whether it's black or noise?
> 
> A good question. I don't really know, and I suspect it shouldn't. But
> the choice of Weston's renderer probably does affect, depending.
> 
> When ever a user space program is allocating memory, the kernel is
> expected to hand out zeroed memory because of security implications
> (data leak prevention). So, we'd get black (transparent if we use it as
> ARGB instead of XRGB).
 
> When Pixman renderer allocates memory, it does it with malloc() AFAIK,
> and since it's likely a big chunk, we are quite likely to get fresh
> memory from the kernel. If the memory is not fresh, it may contain
> garbage.
> 
> GL renderer is a different story though. Zeroing out gfx buffers on
> allocation is a non-trivial cost, so it's possible that some gfx stacks
> just skip it, leading to garbage if we don't render anything which most
> likely can be old screen contents. It's a trade-off between security
> (confidentiality) and performance.
> 
> I do not know what policy Mesa and our kernel DRM drivers have.
> Proprietary drivers are more likely to ignore security issues.
> 
> One thing worth to note: if Weston is using "none" background meaning
> that we get undefined (garbage) content, then removing a wl_surface may
> not really remove the surface's image from the screen, because there is
> nothing that would make Weston to scrub it (paint over it). Therefore
> no screenshooting test should ever rely on that scrubbing unless we
> know there is something that enforces the image to disappear.

Is there a way weston can forcibly ensure this is always zeroed when
doing testing so there's no question, without burdening test writers
from needing to be aware of it?

Bryce