http://qs1969.pair.com?node_id=11129560


in reply to Tk screen and monitor size in mm, DPI and scaling

(508 mm == 20") is exactly 1920 px @ 96 dpi. Tk doesn't bother(*) to use "real" dpi of your display. The "1.3(3)" is result of default Windows (Linux) 96 dpi, i.e. 96/72 == 1.3(3).

Scaling is both getter and setter, for those who strive to work in mm. It's simple math that links display diagonal, aspect ratio (i.e. WxH in pixels) and real resolution. For Linux, unlike other commands mentioned in this thread, the xrandr output matches the calculation of mm, and also ruler being applied :). For Windows, you have found PS command yourself (it's posted misspelled), result matches previous mm values for my double-boot config. I think the source for both platforms is parsing the EDID data, as e.g. Parse::EDID does.

---

(*) Interesting, the fact that Tk's scaling is only approximately "1.3(3)" for some configurations (mine, too), makes me suspect that Tk doesn't set this parameter blindly, but some calculations involving e.g. display width, rounded to centimetres, are happening during start-up. I can think of good reasons for Tk to stick to "96 dpi", but they are speculations only.

Replies are listed 'Best First'.
Re^2: Tk screen and monitor size in mm, DPI and scaling -- Parse::EDID
by Discipulus (Canon) on Mar 14, 2021 at 20:24 UTC
    Thanks a lot vr for clarifications,

    > for those who strive to work in mm

    I think I will be no more in that number. it really seems too complicated to be sure of an exact measure in mm. It seems pixel are always accurate so I'll use pixels only.

    As always I must confess I make a lot of confusion with this matter and discovered about EDID today from your post. It seems EDID data in windows is concealed in the registry under HKLM\SYSTEM\CurrentControlSet\\Enum\DISPLAY\"name of your monitor"\Device Parameters\EDID key.

    I installed Parse::EDID and arranged the following:

    use strict; use warnings; use Parse::EDID; use Data::Dumper; # I have two similar keys: PHLC0E5 and PHL088B among many others. Bein +g the current monitor a Philips I guess it must be one of them. # I grabbed the relevant part of output of the command: # REG QUERY "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\ +PHL088B\4&2afe7bec&0&UID50529024\Device Parameters" my $registry =<<EOT; 00FFFFFFFFFFFF00410CE5C0FE050000051A010380301B782AE7E5A5564DA1250F5054 +BD4B00D1C09500950FB30081 C0818001010101023A801871382D40582C4500DD0C1100001E000000FF005A51303136 +3035303031353334000000FC0050484C2032323745360A2020 20000000FD00384C1E5311000A202020202020013D EOT my $raw_edid = join'',split /\n/, $registry; my $edid = parse_edid( $raw_edid ); print Dumper $edid;

    The output is very verbose and glancing it I dont find any physical measure resembling those of my monitor: I read in the wikipedia article you linked, measures in centimeters are stored in bytes 21-22, but under which names in the following output? Again: my monitor is 48cm x 27cm

    If I understand you correctly I must figure which is the real current dpi value, modify the scaling accordingly and re-calculate the size in mm. Right?

    While this matter is interesting and thanking you for hints and time you spent on it, I'm considering to remove entirely the mm calculation from my application, leaving pixel as only option.

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      I think parse_edid expects raw binary, and

      my $raw_edid = pack 'H*', $registry;

      will work. There's also check_parsed_edid to alert you, even when (very) suspicious results failed to do so :).

      Looking at output, fractional dimensions, in mm, indicate something more involved than simply reading size in whole cm (bytes 21-22), I didn't investigate more closely. Further, I didn't investigate neither (sorry), if, after MainWindow-> scaling(X), anywhere where number for size (meaning 'pixels') is to be used, string such as "N.nm" (N.n mm) would result in identical rendering on screen (let's assume no rounding). That's the whole point of it all, to forget about 'pixels', if I'm reading what you say "re-calculate the size in mm" correctly. I agree, I'd probably won't follow this route, neither (not until all displays are 250 dpi or more).

        Hello vr,

        > There's also check_parsed_edid to alert you, even when (very) suspicious results failed to do so :)

        ah ah ah.. so I was looking shadows on the wall of the cavern supposing them to be real things :)

        Adding print check_parsed_edid( $edid ); only prints for my bad edid_version but I already noticed in my previous output year => 2039 and I had to suspect something wrong.

        Anyway with you packed string (thanks again!) it seems I have meaningful results. I add it here for the posterity (hiding the serial number, just in case..), when we'll have 250 dpi monitors.

        Notably now I read:

        'max_size_horizontal' => '47.7', 'max_size_vertical' => '26.8',

        and these are the physical measures of my monitor!

        Even if I will remove mm calculation from my code, what is better than learn yet another unuseful thing? :)

        Thanks for the support

        L*

        There are no rules, there are no thumbs..
        Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.