[PATCH] adding parameter for set_fullscreen

[Pekka Paalanen]

On Wed, 04 Jan 2012 14:29:10 +0800
Juan Zhao <juan.j.zhao at linux.intel.com> wrote:

> 
> On Tue, 2012-01-03 at 11:54 -0800, Bill Spitzak wrote:
> > 
> > juan.j.zhao at linux.intel.com wrote:
> > > From: Juan Zhao <juan.j.zhao at linux.intel.com>
> > > 
> > > support two methods:
> > > "FORCE" means changing the screen resolution to the mode of the
> > > surface. If there is no matched mode, just fallback to FILL mode.
> > > "FILL" means changing fill the around of the surface to match the
> > > screen's mode. currently, we will put the surface in the center
> > > of the screen.
> > 
> > I thought Wayland was going to be capable of scaling surfaces as
> > part of the compositing operation?

> This scaling capability on the client side should be ready now. Just
> have a look at terminal in clients, it uses scale mode in the client
> itself. F11 to set fullscreen.

That's not scaling, that's just plain old window (client side) size
change and decorations on/off.

> We are also considering the scaling capability of compositor side. It
> is not a hard work to scale the surface, but the handling of input
> according to that scale should be considered, which is not a easy task
> in my current opinion. Need some suggestion for handling the input
> issues for scaling the surface in the server side.

As far as I understand, that is already implemented. Struct
wlsc_surface has 'transform' member, containing 4x4 matrices, that are
used to represent (so far, only) 2D linear transformations. It is used
for drawing the surface, but I don't see it used for fixing up input
event coordinates. That shouldn't be hard to implement, though, just
augment the function that maps absolute coordinates to surface
coordinates.

The zoom effect already uses scaling.

The scaling could also be used for quick & dirty compositor-driven
resize, where instead of sending a stream of configure events you just
scale the surface, and send only the very last configure event for the
application to redraw itself in the final size.

> > What I would prefer to see, rather than a special "fullscreen"
> > mode, is the ability to set the rectangle the client's surface is
> > mapped to. 

Bill, that would require knowledge of absolute coordinates, right?

So it's a no-go, since the compositor can do whatever nonlinear
coordinate transforms it wishes, and we can't know how the window maps
to screen, so we can't use coordinates.

What we can do, is say, I want this to be fullscreen, do the best you
can to achieve an effect doing that as close as possible.

> We add such special "fullscreen" interface here, is to facilitate the
> client's work for fullscreen setting. The client can set fullscreen
> only by one command to express their preferred way.
> For your concern, we can add (x, y) to specify the top-left
> coordination for the fill mode. Now we map it on the center directly.

We can't do coordinates, because that would imply knowledge of absolute
position. FWIW, we cannot even know on which output an application is
going fullscreen on, only the compositor knows that.

> > Normally this will produce scaling, but if it is the only client
> > visible (because it fills a screen and there are none above it) the
> > compositor can then automatically switch the display mode to one
> > that requires less or no scaling.

> Whether changing the display mode should be requested by the client
> but not decided by the compositor. There are some applications which
> would like to change the display mode to make itself fullscreen no
> matter whether there is any other application. Like XBMC and Quake 3.

Personally, I have the opposite opinion. The decision to switch video
mode is compositors business and not the clients. I don't want to be
switching video modes while I alt+tab through my windows, one of them
being a fullscreen game, for example.

Changing the video mode in games is an artifact from the time, when it
was the only feasible way to scale an arbitrary sized image to full
screen. You can pick the window size based on how many pixels your
computer can handle, and then you want it fullscreen - therefore you
changed the video mode, since a CRT monitor can do the scaling for
free. This is no longer true, especially with most laptop integrated
panels, which can only do one video mode, ever, so the driver needs to
scale one way or another anyway.

I'm not saying that changing video modes is useless. On proper
circumstances, a compositor can choose to do that (scan out directly
from the client buffer), but I definitely want it to be the compositor's
choice. All that apps need to do is to request to be fullscreen and not
draw their decorations.

There is an orthogonal feature, and I think may have been after that
one more. It is about assigning clients' surfaces to specific outputs,
for example, the wallpaper surface of desktop-shell. Intuitively it may
make sense to assign wallpapers per output. The interesting question
is, what happens when two outputs overlap (partially)? Currently we do
not have the notion of surfaces exclusive to only some outputs.

Background is just a background, and you have other windows on top of
it. A twist is to make a surface exclusive on an output, and show
nothing else on that output, for example, assign a slideshow to a video
projector output. It gets complicated and I don't have a clear opinion
on whether that should be solved somehow completely different, or not
at all.

> > Being able to scale a surface will allow video playback windows to
> > be scaled without bypassing the non-scaling video decompression
> > hardware. I would expect the windows to be scaled to the correct
> > location and put below the normal window where there is a hole of
> > zero alpha so the video shows through.

> The multi-plane/overlay supporting should also be supported but not in
> fullscreen protocol, we will add some other protocol for video HW
> acceleration.

Right.

> > I would also really like Wayland to dump the idea that "fullscreen"
> > is somehow special. It just means there are no borders and the
> > window edges touch the edge of the monitor. There should be ZERO
> > effect on window stacking, and other windows should be able to be
> > put atop the fullscreen one. Please don't make overlapping windows
> > useless.

Fullscreen *is* special, since requires special window positioning,
which you cannot do client-side. Your other points I agree with, and it
should not prevent putting other windows on top of a fullscreen window.
The current demo compositor code, IIRC, checks only the topmost surface
in the stack for fullscreen case, and scans it out directly, if
possible.

Also, the since the client cannot know its window's absolute position,
or even shape because of arbitrary transformations by the compositor,
it cannot choose the output before-hand, either, if it want's to
maximize on the output it already occupied.

After all this, there is a point in choosing the scaling mode for a
fullscreen application: centered, aspect scaled, scaled, maybe others.
"*scaled" would include both scaling by compositing and scaling by
video mode switching, per compositor's decision. I'm just not sure it
is the client's business to decide the scaling mode, after all, it is
user preference. And, it applies only to clients that choose to render
in a different size than suggested by the compositor.


Just my opinions, hopefully raising useful ideas.

- pq