[PATCH weston] xdg-shell: Make stable

Pekka Paalanen ppaalanen at gmail.com
Wed Aug 27 23:44:08 PDT 2014


On Wed, 27 Aug 2014 11:37:13 -0700
Jason Ekstrand <jason at jlekstrand.net> wrote:

> On Wed, Aug 27, 2014 at 1:52 AM, Giulio Camuffo <giuliocamuffo at gmail.com>
> wrote:
> 
> > 2014-08-27 11:38 GMT+03:00 Pekka Paalanen <ppaalanen at gmail.com>:
> > > On Wed, 27 Aug 2014 11:03:04 +0300
> > > Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> > >
> > >> 2014-08-27 10:32 GMT+03:00 Pekka Paalanen <ppaalanen at gmail.com>:

> > >> > Let's do a summary:
> > >> > - a request to go fullscreen
> > >> > - preferred framerate hint, including dont-care option
> > >> > - allow the fullscreen window to be smaller than configured,
> > defaulting
> > >> >   to scaling up as big as possible without losing any image content or
> > >> >   changing aspect ratio
> > >>
> > >> What about bigger than configured? The compositor could scale them
> > >> down, i don't see any difference here.
> > >
> > > I would say that the app is being stupid, no-one wants to have
> > > downscaling when the window is upposed be shown in its normal way.
> > >
> > > IIRC we already forbid larger than configured anyway.
> >
> > Forbid as in protocol error or undefined behavior? I agree that's a
> > stupid thing to do, but the compositor should be able to deal with
> > stupideness, and scaling down seems the most sensible thing to do. I'm
> > fine with leaving it as undefined behavior in the spec, anyway.
> >
> 
> There are use-cases where you want the surface scaled down.  For instance,
> 1920x1080 video on a 1600x1200 display.  If we want to have the client
> create a viewport that scales it down to 1600x900, that's probably fine but
> I don't see how that's needed.

Oh, indeed. I was only thinking about games and GUIs there,
forgot the video could be larger than output.

> My big point (that may not have gotten through) is that, as long as we have
> a sensible default ("shoot the client if it's not the right size" doesn't
> count), we can add support for additional fine-grained control later and
> this isn't a blocker for xdg_shell going stable.  My recommendation for
> said default would be "fill the screen without changing aspect ratio", i.e.
> scale and letter-box.  If we want to call bigger-than-configure undefined
> behavior, I don't care but I don't think it's needed either.  For the rest
> of it (modifiers, etc.), let's start another thread on the list and let the
> details bike shed there and get xdg_shell stabalized.

I totally agree here.


Thanks,
pq


More information about the wayland-devel mailing list