black surface in desktop shell fullscreen mode

[Pekka Paalanen]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151127/99172dc0/attachment-0001.sig>