Created attachment 124412 [details] kernel messages debug DRM Screen shows only upper left detail Bug description: The PC has a single display called 'AUO 5.7" VGA (640x480) Colour TFT' (G057VN01 V2). I installed several Ubuntu flavours on its harddisk resulting always in the effect described in the summary field while & after booting. chipset: Core/Core2 system architecture: i686 xf86-video-intel: 2.99.917 xserver: 1.17.2 mesa: not installed? libdrm: 2.4.64 kernel version: 4.2.0-27-generic Linux distribution: - Xubuntu 14.04.4 LTS - Ubuntu 14.04.4 LTS - Ubuntu MATE 14.04.2 LTS - Ubuntu GNOME 14.04.4 - Lubuntu 14.04 LTS Machine or mother board model: Advantech AIMB-212 (with one Intel Atom N450) Display connector: LVDS Reproducing steps: Screen shows only upper left detail while & after booting Ubuntu, even in the boot loader GRUB2. Additional info: After installing 'intel-gpu-tools'-package I ran intel_reg_dumper, but I am seeing: 'Gen2/3 Ranges are not supported. Please use unsafe access.'. Because I am new to Linux I don't know how to download & build 'intel-gpu-tools'. So provide me 'intel_reg_dumper' and I will run it. Following the description from https://01.org/linuxgraphics/documentation/development/how-dump-video-bios I am seeing: 'cat: /sys/devices/pci0000:00/0000:00:02.0/rom: Invalid argument'.
Created attachment 124413 [details] output of 'xrandr --verbose'
Created attachment 124414 [details] Picture of screen
(In reply to Sebastian Gutzwiller from comment #2) > Created attachment 124414 [details] > Picture of screen I don't quite understand what's wrong with the picture. Please clarify. What should I look for? It's not promising that it's broken already before i915 loads.
The screen is only 640x480 but we define a 1024x768 framebuffer since there is no EDID for the panel. Not sure if there is anything we can do without user invention since the hardware is not providing a description, so the best approach would appear to be video=VGA-1:640x480
Created attachment 124433 [details] XOrg log file
(In reply to Jani Nikula from comment #3) > (In reply to Sebastian Gutzwiller from comment #2) > > Created attachment 124414 [details] > > Picture of screen > > I don't quite understand what's wrong with the picture. Please clarify. What > should I look for? > > It's not promising that it's broken already before i915 loads. In the 'XOrg log file'-attachment one sees that the physical screen size is set to 270 x 203. I calculated the proportion to the real screen size (115 x 86) and compared it with the whole screen content that I see if I connect a standalone PC-monitor to the VGA-connector: And it matches. So if I would have a real screen size of 270 x 203 I would see the whole screen content.
(In reply to Chris Wilson from comment #4) > The screen is only 640x480 but we define a 1024x768 framebuffer since there > is no EDID for the panel. I tried to give an appropriate EDID of the 'AUO 5.7" VGA (640x480) Colour TFT' to the DRM as suggested by https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID I am verifying that EDID with the manufacturer. During trials with that EDID I saw in the XOrg log that the default DPI of 96 x 96 also led to the wrong physical screen size. Is giving the EDID to the DRM an option? > Not sure if there is anything we can do without > user invention since the hardware is not providing a description, so the > best approach would appear to be video=VGA-1:640x480 I made two trials without success, see attached pictures. Shall I attach a log?
Created attachment 124436 [details] picture of screen without video parameter (1024x768)
Created attachment 124437 [details] picture of screen with video parameter (640x480)
Timeout. Closing bug for the lack of activity. Thank you.
(In reply to Elizabeth from comment #10) > Timeout. Closing bug for the lack of activity. Thank you. If problem persist on newest kernels open new bug to follow up. Thank you.
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.