https://bugs.kde.org/show_bug.cgi?id=486585
Bug ID: 486585
Summary: Physical monitor size reported as 790x0 mm
Classification: Plasma
Product: kwin
Version: 6.0.4
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kwin-bugs-n...@kde.org
Reporter: j.piecuc...@gmail.com
Target Milestone: ---
Created attachment 169192
--> https://bugs.kde.org/attachment.cgi?id=169192&action=edit
Display EDID
SUMMARY
KWin reports the physical dimensions of my laptop's built-in display as 790x0
mm on Wayland and X11.
I queried the physical dimensions with the `wayland-info` utility.
STEPS TO REPRODUCE
(I don't know how to reproduce this without access to the hardware, but I have
attached the EDID of the display.)
1. Run `wayland-info`
OBSERVED RESULT
physical_width: 790 mm, physical_height: 0 mm
EXPECTED RESULT
physical_width: 344 mm, physical_height: 194 mm
SOFTWARE/OS VERSIONS
Linux: 6.8.8-2-MANJARO
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
ADDITIONAL INFORMATION
I used the `di-edid-decode` utility to parse the EDID and it turns out that the
correct physical dimensions (344x194 mm) are reported in the "Detailed Timing
Descriptors" section:
$ di-edid-decode /sys/class/drm/card1-eDP-1/edid
Block 0, Base EDID:
EDID Structure Version & Revision: 1.4
Vendor & Product Identification:
Manufacturer: LGD
Model: 1472
Made in: week 0 of 2017
Basic Display Parameters & Features:
Digital display
Bits per primary color channel: 8
DisplayPort interface
Aspect ratio: 1.78 (landscape)
Gamma: 2.20
DPMS levels: Standby Suspend Off
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing includes the native pixel format and preferred
refresh rate
Color Characteristics:
Red : 0.6396, 0.3300
Green: 0.3046, 0.6054
Blue : 0.1503, 0.0546
White: 0.3134, 0.3291
Established Timings I & II: none
Standard Timings: none
Detailed Timing Descriptors:
DTD 1: 1920x1080 143.998072 Hz 16:9 166.606 kHz 346.540000 MHz
(344 mm x 194 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 69 Vpol N
DTD 2: 1920x1080 60.002659 Hz 16:9 69.423 kHz 144.400000 MHz
(344 mm x 194 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 5 Vback 69 Vpol N
Checksum: 0xa8
An EDID can report the physical dimensions of the display in the "Basic Display
Parameters & Features" section, but the units there are centimeters, which
leads to imprecise dimensions. An EDID can instead use the same bytes to report
just the aspect ratio, which is exactly what is happening here (byte 0x15 = 79,
byte 0x16 = 0 correspond to aspect ratio of 16:9).
I believe the 790x0 mm dimensions come from the connector dimensions reported
by libdrm. These are then passed to the m_physicalSize of the DrmConnector
class in the updateProperties() method:
// check the physical size
if (m_edid.physicalSize().isEmpty()) {
m_physicalSize = QSize(m_conn->mmWidth, m_conn->mmHeight);
} else {
m_physicalSize = m_edid.physicalSize();
}
So in this case, m_edid.physicalSize().isEmpty() return true, because the Edid
class uses libdisplay-info to parse the EDID, which correctly parses the {79,
0} bytes as the aspect ratio, not the display's physical size, and reports the
physical size as 0x0. The logic falls back to reading the size from m_conn,
which is a pointer to libdrm's drmModeConnector. The libdrm library gets the
connector dimension from the kernel, which doesn't do as good of a job parsing
the EDID (or maybe it's intentional) and reports the connector dimensions as
790x0 mm.
As explained earlier, the {79, 0} bytes come from the "Basic Display Parameters
& Features" section of the EDID.
An EDID can also contain a number of detailed timing descriptors, which can
specify the physical dimensions of an image, this time in millimeters, giving
us more precision.
An important thing to note is that these dimensions are not the display's
physical size, but rather the physical size of the displayed image when this
particular mode is set. In many cases this will be equal to the display's
physical size, but it doesn't have to be.
However, I believe we can use this information as a fallback in case neither
libdisplay-info nor libdrm report sensible physical dimensions: we can check if
every detailed timing descriptor contains the same physical dimensions, and if
so, use these dimensions as the physical size of the display (provided these
dimension are sensible, i.e. both width and height are positive) .
I'm curious to know what you think of this workaround :)
--
You are receiving this mail because:
You are watching all bug changes.
