black surface in desktop shell fullscreen mode

[Hyungwon Hwang]

Hello all,

Reading the mail thread, I tried to figure out the problem by myself.
Until now, I couldn't find any reason to make fullscreen application
totally opaque. As I found in git history, in my opinion, the author
of fullscreen implementation just thought that fullscreen has black
surface behind it.

IMHO, the fix could be fairly simple. Just remove "struct weston_view
*black_view" from struct fullscree and the usages in the source. As I
tested, it works fine. But I am new to weston and not familiar with
weston testing, it needs more test and code analysis. Could you give
your opinion about it?

Best regards,
Hyungwon Hwang

On Fri, 27 Nov 2015 10:15:00 +0200
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Thu, 26 Nov 2015 15:33:24 +0800
> zou lan <nancy.lan.zou at gmail.com> wrote:
> 
> > Hi Pekka
> > 
> > I have another question about the fullscreen NULL buffer display
> > black surface. Why the fullscreen App call hide(commit Null
> > buffer), then start another App, only the fullscreen App can show
> > normally? Is  the normal screen App's layer below on the black
> > surface?
> 
> Like Giulio mentioned before, sounds like a Weston bug.
> 
> The relevant window manager code is in desktop-shell/shell.c. I don't
> think I can explain how to fix it in any more detail without going in
> and fixing it myself. I rarely look into shell.c and that probably
> applies to most developers.
> 
> The black surface should be torn down when the window gets unmapped.
> 
> The entrypoint into shell.c for all window state changes is the
> weston_surface::configure vfunc.
> 
> 
> Thanks,
> pq
> 
> > 2015-11-20 17:31 GMT+08:00 zou lan <nancy.lan.zou at gmail.com>:
> > 
> > > 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.  
> > >> > >  
> > >>
> > >>  
> > >  
>