[PATCH] compositor-headless: Report a more realistic physical size

[Pekka Paalanen]

On Mon, 02 Jul 2018 10:29:48 -0400
Simon Ser <contact at emersion.fr> wrote:

> > On Thu, 12 Apr 2018 09:31:48 +0200
> > Johan Klokkhammer Helsing <johan.helsing at qt.io> wrote:
> >  
> > > Some clients rely on the physical size to determine the physical DPI. With the
> > > previous implementation, we would report 1px==1mm, which is a DPI of 25.4,
> > > which is incredibly low.
> > >
> > > The problem is solved by setting a physical size so the DPI is close to 72
> > > instead. If the output is scaled, the DPI is set to the corresponding multiple
> > > of 72.
> > >
> > > This makes the headless backend more usable for automated testing of DPI
> > > sensitive functionality such as point sized fonts.
> > >
> > > Signed-off-by: Johan Klokkhammer Helsing <johan.helsing at qt.io>
> > > ---
> > >  libweston/compositor-headless.c | 16 ++++++++++++----
> > >  1 file changed, 12 insertions(+), 4 deletions(-)  
> >
> > Hi,
> >
> > this is a good idea, but could you rebase this patch to master?
> >
> >
> > Thanks,
> > pq  
> 
> Hi,
> 
> Would it make sense to change the protocol to allow compositors to send a zero
> physical size in case it isn't relevant?

I think it's often full of lies anyway, because usually the reported
numbers come directly from EDID. I've heard rumours of something like
width=16 height=9 (mm? cm?) etc. when the physical size is unknowable
(e.g. a projector) but they still want to send the aspect ratio.

If existing toolkits can cope with it, zero would be fine. Whether they
do, I really don't know.

Something about aspect ratio might need to be taken into account
though. We've never really had non-square pixels, so the assumption of
square pixels is probably used throughout the stack. If output
information implied non-square pixels, does it mean client pixels will
be shown equally non-square or are they scaled assuming they are
originally square?

OTOH, headless reporting a sensible fake size for a fake output is
still a good idea in my opinion.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180703/71ed75ab/attachment-0001.sig>