[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] edid: use physical dimensions if available
From: |
Gerd Hoffmann |
Subject: |
Re: [PATCH 1/4] edid: use physical dimensions if available |
Date: |
Tue, 18 Aug 2020 08:25:02 +0200 |
On Mon, Aug 17, 2020 at 04:57:55PM +0400, Marc-André Lureau wrote:
> Hi
>
> On Mon, Aug 17, 2020 at 4:21 PM Gerd Hoffmann <kraxel@redhat.com> wrote:
> >
> > On Mon, Aug 17, 2020 at 04:00:53PM +0400, marcandre.lureau@redhat.com wrote:
> > > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> > >
> > > Add width_mm/height_mm to qemu_edid_info, and use it if it is
> > > set (non-zero) to generate the EDID.
> >
> > Any specific reason why you switch from dpi to xmm/ymm?
>
> Not really, but there is no DPI information from Gtk. I also find it
> difficult to reason with DPI, dimensions are simpler to check about
> correctness imho (I take the ruler from my desk for example ;). And
> also DPI is a space density, without horizontal and vertical
> distinction.
Typically computer displays have square pixels, so that shouldn't be a
problem. For manually configuration it is easier if you have to deal
with one value only not two.
> So by giving width/height in mm we actually have something more
> correct and easier to debug imho. No?
I dislike having both with/height and dpi in struct qemu_edid_info.
Suggestion: Drop dpi struct member (should be easy, I think it isn't
wired anywhere yet). Add two little qemu_edid_* helpers to convert
from/to dpi. If only one of xmm/ymm is given go calculate the other
automatically (assuming square pixels). If none is given use 100 dpi
(like the current code does).
take care,
Gerd