Hi, Am Dienstag, den 16.05.2017, 11:30 +0300 schrieb Pekka Paalanen: > On Mon, 15 May 2017 17:51:16 +0200 > Philipp Kerling <pkerl...@casix.org> wrote: > > > 2017-05-15 (月) の 12:19 +0200 に Philipp Zabel さんは書きました: > > > On Mon, 2017-05-15 at 11:18 +0300, Pekka Paalanen wrote: > > > > On Sun, 14 May 2017 14:43:44 +0200 > > > > Philipp Kerling <pkerl...@casix.org> wrote: > > > > > * Am I correct in that if I use zxdg_toplevel (i.e. give > > > > > this > > > > > role to > > > > > a surface), I cannot also use wl_shell_surface? If so, > > > > > this > > > > > would be > > > > > > > > Yes. wl_shell and xdg_shell suites of protocol extensions are > > > > mutually > > > > exclusive, you cannot use both for the same wl_surface. > > > > wl_shell is > > > > the > > > > deprecated one, and xdg_shell suite is the replacement waiting > > > > to > > > > be > > > > decleared stable. > > > > > > > > > quite a problem. I can see that zxdg_toplevel > > > > > functionality is > > > > > mostly superior to that of wl_shell_surface, but it has > > > > > one > > > > > omission > > > > > that is crucial for Kodi: the ability to request a > > > > > specific > > > > > refresh > > > > > rate for fullscreen display. This is needed for closely > > > > > matching the > > > > > display and video FPS so duplicated and skipped frames are > > > > > kept to a > > > > > minimum. Is this an intentional omission and/or is there > > > > > anything > > > > > that provides this functionality? > > > > > > > > Hopefully the xdg_shell designers would answer that, but I > > > > believe > > > > it > > > > has been omitted for now to make it easier to declare the first > > > > fundamental parts of xdg_shell stable. It is missing a lot, but > > > > the > > > > foundation must agreed upon first before building more on > > > > top. > > > > > > Rather than combining the FPS request with fullscreening, > > > wouldn't it > > > be > > > better to let applications set FPS as a property of the surface? > > > > > > That way the client would make a promise that is is going to > > > update > > > surface contents with periodic commits of the specified rate, > > > completely > > > independent of the actual output hardware or fullscreen state. > > > > > > The server could use that information to choose the best display > > > refresh > > > rate even if not in fullscreen mode. > > > > I would not want my compositor to do that, since changing the > > refresh > > rate means that the monitor will go blank for a while while > > resyncing > > on most hardware. > > Hi, > > I get the feeling that you are assuming the server would always obey > the > client refresh rate. The protocol should not be designed like that. I actually don't and I think I explicitly stated that in an earlier email. I know that Wayland has nothing like RANDR (i.e. where every application can mess around with the output modes as it pleases) on purpose. Sorry if I gave the impression that this or something similar is what I'd want.
> Wayland protocol design principle for the desktops is that clients > describe what they would want to do (and why), and the server > implements the policy on when and how that actually happens - if at > all. This is very much the opposite from X11. A typical example is > input grabs: a client has to provide both the reason (the input event > they are acting on) and the context (the surface a grab will be tied > to). The server decides if it grants a grab or not, and if yes, it > can > also revoke the grab at any time. > > The reason the framerate was in the fullscreen request in wl_shell is > that fullscreen offers fairly clear conditions on when the server > should or could switch the video mode: > - when the fullscreen window becomes top-most and active, switch > video > mode to the client requested one > - when the fullscreen window becomes inactive, is hidden, or some > other > top-level window comes on top of it; a condition that is not just > transient; switch video mode back to the default one > - do not switch back to default one for insignificant actions, e.g. a > notification window appearing, window switcher starter but not yet > chosen the next active window > > If a custom video mode request can be made on any kind of window, it > becomes more hard to figure out the right situations when to switch - > if switching at all. The server always has to have the choice to not > switch at all, ever, e.g. if the hardware is incapable, would make > the > screen blank for too long that it's annoying, or simply a policy set > by > the user. That's perfectly OK. I don't think it necessarily becomes more difficult by attaching the information to all surfaces as opposed to only full-screen surfaces though. As you said, the compositor should not be obligated to do anything at all and the arguably most common use case which is the old set_fullscreen behaviour that only considers fullscreen surfaces is still possible and reasonably easy to implement. It would be a great improvement to have *any* chance of influencing the output refresh rate decision since at the moment it's just not really possible at all - if you use wl_shell_surface you lose a lot of other functionality since you cannot also use xdg_shell. - Philipp _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel