black surface in desktop shell fullscreen mode

Pekka Paalanen ppaalanen at gmail.com
Fri Nov 20 00:03:05 PST 2015


On Fri, 20 Nov 2015 10:52:54 +0800
zou lan <nancy.lan.zou at gmail.com> wrote:

> Hi Pekka
> 
> How to not use the black surface behind the fullscreen surface? I want to

Hi Nancy,

are you looking for disabling the black surface in a way that would
work on upstream Weston or be upstreamable, or something you hack just
for yourself?

Or are you asking for instructions on how to fix the alleged Weston
desktop-shell bug where the black surface is not removed when attaching
a NULL wl_buffer to the wl_surface?

> have a try for the special needs to switch the apps. I can't use the
> minimize because it can't restore to its original shape.

Oh that's the real problem here. Obviously restoring to original size
and position after minimization should work, so I think that is the
primary issue to be solved. However, I'm not sure if it is possible
with wl_shell, but it should be possible with xdg_shell.

You have to note, that both desktop shell protocols are still far from
being finished. Switching the active window from clients is still on
the drawing board, AFAIK.

Hmm, or is the fundamental problem really that you want to reassign
which window is active and on top from the client?

There is a continuum of possible solutions, ranging from
non-upstreamable quick hacks on one end to joining the work on
designing the family of desktop related protocol extensions on the
other end which can take at least months.

I think we should go back to the original use case you are trying to
make work:

App1 launches App2. App2 appears on top and active (by the current
policy implemented in Weston's desktop shell, which is subject to
change). Then App2 wants to put App1 on top and active again. Is this
right?

Should App2 stay up but behind App1? Or should App2 be hidden or
minimized?

Note that hiding and minimizing are two different things: minimizing
leaves a window handle in something like a task bar, while hiding does
not. (Hiding with wl_shell probably triggers a (mis?)feature in Weston
where it forgets the window position, IIRC.)

And you want App2 to be able to come back later in the original
position and size, active and on top of App1?

I'm afraid on short term, all workable solutions will be more or less
hacks, because the desktop shell protocol extensions just do not exist
yet for this sort of things.


Thanks,
pq

> > > 2015-10-09 9:29 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> > > > On Fri, 9 Oct 2015 10:04:49 +0300
> > > > Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> > > >
> > > >> You get a black surface because weston puts a black surface behind the
> > > >> fullscreen one even if it has the right size, and it seems like it
> > > >> doesn't remove the black surface when the client surface attachs a
> > > >> NULL buffer. That's a weston bug, i'd say.
> > > >
> > > > Giulio's analysis sounds good to me. I think no-one has tried - or
> > > > reported - to hide a window using wl_shell that was also fullscreen, so
> > > > probably we have never considered that case in the code.
> > > >
> > > > Very likely a Weston bug indeed, specifically in the case of committing
> > > > a NULL wl_buffer when using wl_shell. Transparency was a red herring
> > > > all along.
> >

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151120/eb1d2a74/attachment.sig>


More information about the wayland-devel mailing list