On Tue, Jul 24, 2018 at 11:44:35AM +0200, Olivier Fourdan wrote:
> Hi,
>
> On Tue, 24 Jul 2018 at 11:34, Simon Ser wrote:
> >
> > On July 13, 2018 12:00 PM, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote:
> > > > Physical size doesn't always make sense fo
Hi,
On Tue, 24 Jul 2018 at 11:34, Simon Ser wrote:
>
> On July 13, 2018 12:00 PM, Daniel Stone wrote:
> > Hi,
> >
> > On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote:
> > > Physical size doesn't always make sense for all outputs. In case
> > > it's not available or not relevant, allow compositors
On July 13, 2018 12:00 PM, Daniel Stone wrote:
> Hi,
>
> On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote:
> > Physical size doesn't always make sense for all outputs. In case
> > it's not available or not relevant, allow compositors to send zero.
> > ---
> > In practice this doesn't seem to break an
Hi,
On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote:
> Physical size doesn't always make sense for all outputs. In case
> it's not available or not relevant, allow compositors to send zero.
> ---
> In practice this doesn't seem to break any client toolkit. We've been
> doing that for a long time in
Hi all,
I'd like to bump this, because it seems that's how they do it on the
X11 side [1]. So adding this would allow to have better Wayland
behaviour _and_ correct X11 screen data via Xwayland.
Thanks,
[1]: https://lists.x.org/archives/xorg-devel/2018-July/057301.html
On July 3, 2018 12:27 PM,
Physical size doesn't always make sense for all outputs. In case
it's not available or not relevant, allow compositors to send zero.
---
In practice this doesn't seem to break any client toolkit. We've been
doing that for a long time in wlroots.
protocol/wayland.xml | 3 +++
1 file changed, 3 ins
