On the Surface 3 (Atom x7 X8700), the kernel is unable to get the correct EDID data for the display. As a result, the correct display dimensions are not set, meaning that user-space programs that depend on this info do not have it. As an example, Gnome would kick in to Hi-DPI mode if the correct dimensions were available. Windows seems to be able to fetch an EDID record for the display with the proper dimensions set, and as far as I can tell it doesn't use any mechanisms to override the EDID using a specific driver implying that the GPU could be accessing it somehow. I will attach an export of the Windows Registry showing what it can see. In this file, DISPLAY\MEI9001\4 is the Surface's screen with the correct dimensions specified. Work around: 1. Build a kernel with CONFIG_DRM_LOAD_EDID_FIRMWARE=Y 2. Download attached EDID record (extracted on Windows), surface3.bin, to /lib/firmware/edid/surface3.bin 3. Add drm_kms_helper.edid_firmware=DSI-1:edid/surface3.bin to your kernel line
Created attachment 124140 [details] Surface 3 EDID Record
Created attachment 124141 [details] Display device records in Windows registry
Created attachment 124142 [details] dmesg
Created attachment 124143 [details] Output of "intel_reg dump --all"
Created attachment 124150 [details] i915_opregion i915_opregion contains the string "Surface Panel" so I suspect the EDID is derived from something here
Created attachment 124176 [details] [review] [PATCH] drm/i915: Extract physical display dimensions from VBT Looks like the VBT should have the physical display dimensions after all. Let's try to use it for DSI panels. Please test.
Created attachment 124188 [details] i915_display_info After applying attachment 124176 [details] [review] i915_display_info shows the correct display dimensions.
Created attachment 124189 [details] xdpyinfo After applying attachment 124167 [details] xdpyinfo does *not* output the correct display dimensions. This might be a different bug though, perhaps in the xorg driver.
Sorry, mistyped attachment ID. You know what I meant.
Created attachment 124190 [details] xrandr output xdpyinfo gave display dimensions that corresponded with a fixed 96dpi screen. xrandr is actually showing 0mm x 0mm which makes more sense. In any case, the dimensions are not being propagated somewhere.
Created attachment 124201 [details] [review] [PATCH xf86-video-intel] sna: Avoid clobbering output physical size with xf86OutputSetEDID() xf86OutputSetEDID() in the xserver clobbers the physical size, even if we go from no edid to no edid. This ddx patch is for sure not the best way to fix it, but works as a test hack at least. So with this xrandr should show the correct information. The per screen dpi (as shown by xdpyinfo) is a lost cause. There's just no way to make that correct when you have multiple displays with different dpi.
Sucked up Ville's patch: commit 7337f558d8bae26e626305fc478d070368bd86cd Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue May 31 09:32:31 2016 +0100 sna: Use physical output size from the kernel We have a conflict between Xorg and the kernel, once again, over the meaning of the EDID. Since the kernel supplies us with the physical size of the connector, let's place the burden of trust on the kernel and ignore the quirky behaviour of Xorg. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=96255 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Thank you, these two patches were sufficient to get X reporting the correct display dimensions for my device. I appreciate your help!
Fixed with commit df457245b5b7515cf97763ebd8975229e34d4cf3 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue May 31 12:08:34 2016 +0300 drm/i915: Extract physical display dimensions from VBT
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.