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

[Pekka Paalanen]

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.


Thanks,
pq