black surface in desktop shell fullscreen mode

[zou lan]

Hi pekka

>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?

Actually I ask for instructions on this. Because I use "hide" to switch the
apps. But I met some problems of the black screen if I just hide the
surface.

I want to implement the function like "background" or "home", just hide the
UI.

Thank you.

Best Regards
Nancy

2015-11-20 16:03 GMT+08:00 Pekka Paalanen <ppaalanen at gmail.com>:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151120/6bd0a61f/attachment.html>