Created attachment 73042 [details]
xorg.conf

Please boot with drm.debug=0xe and attach the complete dmesg. And since we've fixed a few gazillion DP bugs since 3.0, retesting on latest mainline kernels would be good ...

Also, can you please describe more precisely what happens when you're setting the 800x600 resolution with xrandr?

And please also try the different refresh rates @800x600, in case we have a funny timing bug somewhere.

(In reply to comment #2)
> Please boot with drm.debug=0xe and attach the complete dmesg. And since
> we've fixed a few gazillion DP bugs since 3.0, retesting on latest mainline
> kernels would be good ...
> 
> Also, can you please describe more precisely what happens when you're
> setting the 800x600 resolution with xrandr?

Attached the dmesg output for both the 3.0.13-0.27-pae and 3.0.57-10-pae kernel respectively.

When setting the 800x600 resolution with xrandr, a white line appears on the display and it just freezes there. I will also attach a photo of that.

Created attachment 73063 [details]
dmesg for kernel 3.0.13-0.27-pae

Created attachment 73064 [details]
dmesg for kernel 3.0.57-10-pae

Created attachment 73067 [details]
output of 'xrandr --output DP1 --mode 800x600'

New request: Please boot again with drm.debug=0xe, then first reproduce the issue and then attach dmesg.

(In reply to comment #3)
> And please also try the different refresh rates @800x600, in case we have a
> funny timing bug somewhere.

For both refresh rates of 75 and 72.2, the white line is shown on the display. For the rate of 60.3, the display shows only on 3/4 of the screen and is fuzzy. Attaching photo.

Created attachment 73068 [details]
output of 'xrandr --output DP1 --mode 800x600'

(In reply to comment #8)
> New request: Please boot again with drm.debug=0xe, then first reproduce the
> issue and then attach dmesg.

If I understand correctly, I booted again with drm.debug=0xe, run 'xrandr --output DP1 --mode 800x600' and collect the dmesg.

For the stock kernel, 3.0.13-0.27-pae, the mode was not found. Therefore it remained at 1024x768. For the kotd, 3.0.57-10-pae, the white line appeared on the display. Attaching both dmesg.

Created attachment 73069 [details]
dmesg for 3.0.13-0.27-pae after xrandr

Created attachment 73070 [details]
dmesg for 3.0.57-10-pae after xrandr

When you set the 800x600 mode:

[   42.705782] [drm:drm_crtc_helper_set_config], attempting to set mode from userspace
[   42.705783] [drm:drm_mode_debug_printmodeline], Modeline 27:"" 0 50000 800 856 976 1040 600 637 643 666 0x0 0x5

It doesn't match up with the one computed from the EDID:

[   42.424119] [drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 72 50000 800 856 976 1040 600 637 643 666 0x40 0x5
[   42.424122] [drm:drm_mode_debug_printmodeline], Modeline 19:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5
[   42.424125] [drm:drm_mode_debug_printmodeline], Modeline 17:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5

Do you perchance have a custom mode somewhere, e.g. in xorg.confg?

(In reply to comment #14)
> When you set the 800x600 mode:
> 
> [   42.705782] [drm:drm_crtc_helper_set_config], attempting to set mode from
> userspace
> [   42.705783] [drm:drm_mode_debug_printmodeline], Modeline 27:"" 0 50000
> 800 856 976 1040 600 637 643 666 0x0 0x5
> 
> It doesn't match up with the one computed from the EDID:
> 
> [   42.424119] [drm:drm_mode_debug_printmodeline], Modeline 18:"800x600" 72
> 50000 800 856 976 1040 600 637 643 666 0x40 0x5
> [   42.424122] [drm:drm_mode_debug_printmodeline], Modeline 19:"800x600" 75
> 49500 800 816 896 1056 600 601 604 625 0x40 0x5
> [   42.424125] [drm:drm_mode_debug_printmodeline], Modeline 17:"800x600" 60
> 40000 800 840 968 1056 600 601 605 628 0x40 0x5
> 
> Do you perchance have a custom mode somewhere, e.g. in xorg.confg?

The xorg.conf provided is the default xorg.conf generated since installation. The only change was that "PreferredMode" was changed. I will attach another copy of the dmesg log collected after the command 'xrandr --output DP1 --mode 800x600 --rate 72.2'. Are there any ways that I can use to specify the modes?

Created attachment 73133 [details]
new dmesg for 3.0.57-10-pae after xrandr

Ok, I fail to see any differences. Can you please boot with modesetting disable (i915.modeset=0) and use the vesa X driver to set up the 800x600 resolution. Then grab the output of the intel_reg_dumper tool (please grab the latest version from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/). Then also grab the same output when trying to set up the 800x600 resolution with kms. Hopefully comparing the reg dumps will shed some light on this issue.

(In reply to comment #17)
> Ok, I fail to see any differences. Can you please boot with modesetting
> disable (i915.modeset=0) and use the vesa X driver to set up the 800x600
> resolution. Then grab the output of the intel_reg_dumper tool (please grab
> the latest version from
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/). Then also grab the
> same output when trying to set up the 800x600 resolution with kms. Hopefully
> comparing the reg dumps will shed some light on this issue.

When I included the boot parameter to disable modesetting (i915.modeset=0), X fails to load and GDM errors were seen. This occurs for both kernel versions. Xorg.0.log shows 'No devices detected'. Therefore, should I continue running the tool since there is no way to enter X and change the resolution?

I will attach the Xorg.0.log for your reference. Do let me know if you need more information.

Created attachment 73177 [details]
Xorg.0.log with i915.nomodeset=0 boot parameter

Comment on attachment 73177 [details]
Xorg.0.log with i915.nomodeset=0 boot parameter

Scrap your xorg.conf and ensure that you have the vesa ddx driver installed. With that it should just work.

(In reply to comment #20)
> Comment on attachment 73177 [details]
> Xorg.0.log with i915.nomodeset=0 boot parameter
> 
> Scrap your xorg.conf and ensure that you have the vesa ddx driver installed.
> With that it should just work.

Yes it did boot up to X.

On a side note, I built the intel gpu tools on a build machine and ran it on the target machine. Hopefully this does not cause any issues.

When you mention to change the resolution via KMS, do you mean specifying 'video=800x600' in the boot parameter?

In any case, I have attached 2 files. output.txt is collected on a default boot with 'i915.modeset=0' on the boot parameter and output2.txt is collected with the boot parameters 'i915.modeset=0 video=800x600'

Created attachment 73182 [details]
intel_reg_dumper_1024x768

Created attachment 73183 [details]
intel_reg_dumper_800x600

Just to add, with the boot parameter 'i915.modeset=0 video=800x600', X still boots up in 1024x768.

(In reply to comment #24)
> Just to add, with the boot parameter 'i915.modeset=0 video=800x600', X still
> boots up in 1024x768.

You should be able to change the resolution with xrandr once X has booted ...

(In reply to comment #25)
> (In reply to comment #24)
> > Just to add, with the boot parameter 'i915.modeset=0 video=800x600', X still
> > boots up in 1024x768.
> 
> You should be able to change the resolution with xrandr once X has booted ...

Was able to change the resolution via xrandr with the boot parameter. Will attach both the output. Anyway, here is the diff between the 2 files.

22c22
<                       PIPEASRC: 0x03ff02ff (1024, 768)
---
>                       PIPEASRC: 0x031f0257 (800, 600)

Created attachment 73228 [details]
intel_reg_dumper_1024x768

Created attachment 73229 [details]
intel_reg_dumper_800x600

(In reply to comment #26)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > Just to add, with the boot parameter 'i915.modeset=0 video=800x600', X still
> > > boots up in 1024x768.
> > 
> > You should be able to change the resolution with xrandr once X has booted ...
> 
> Was able to change the resolution via xrandr with the boot parameter. Will
> attach both the output. Anyway, here is the diff between the 2 files.
> 
> 22c22
> <                       PIPEASRC: 0x03ff02ff (1024, 768)
> ---
> >                       PIPEASRC: 0x031f0257 (800, 600)

I want to compare the reg dumps when setting up the 800x600 resolution with the vesa driver and with the kms driver. Not compare different resolutions using the vesa driver ... Do we have all the dumps for that already - I'm unsure which is which since the dumps aren't labelled with vesa/kms. Can you pls update that?

Here are my steps to reproduce the reg dumps.

- intel_reg_dumper_kms
1. Boot into X without any boot parameters.
2. Ran 'xrandr --output DP1 --mode 800x600'
3. Saw black screen with white line as previously attached.
4. Switched to other console and ran 'intel_reg_dumper > intel_reg_dumper_kms'

- intel_reg_dumper_vesa
1. Boot into X with 'i915.modeset=0'
2. Ran 'xrandr --output display --mode 800x600'
3. X correctly displays in 800x600.
4. Run 'intel_reg_dumper > intel_reg_dumper_vesa'

Do let me know if any of my steps are not correct.

Created attachment 73354 [details]
intel_reg_dumper-kms

Created attachment 73355 [details]
intel_reg_dumper-vesa

Hi, any updates on this bug? Do you require more information on this?

Hi, any updates to this bug?

From the regdumps it can be seen that vesa mode is not pure 800x600 mode but
upscaled to 1024x768 using panel fitter. So BIOS supports that mode through the panel fitter only. Changing this to feature request.

The reason for feature request is that for _external_ outputs we currently don't support the panel fitter in any way. We only support it for eDP/LVDS panels right now. So maybe the issue here is just that the vbt don't spec that this is an eDP panel?

Otoh we can't even manage to talk to your panel and get an EDID, so something's really strange here.

That feature is already implemented. What is wrong here is that the DP provides no EDID, so we assume that is a GTF capable monitor and generate some default GTF modelines. The panel is not GTF capable. But since it doesn't provide the EDID we have no way of telling, so instead the alternative mechanisms of passing modelines to the kernel should be used (the EDID blob, video=).

Actually, the source of that 800x600 mode is fixed by:

commit 196e077dc165a307efbd9e7569f81bbdbcf18f65
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Feb 15 13:36:27 2013 -0200

    drm: don't add inferred modes for monitors that don't support them

The 800x600 mode is false. To generate the same effect as on windows you want to apply a RandR transform.

We received a firmware update kit for the machine to add support for 800x600 resolution to the EDID of the display panel. The firmware has been updated and the steps to collect the reg dumps are as follows:

- intel_reg_dumper_kms2
1. Boot into X without any boot parameters.
2. Ran 'xrandr --output DP1 --mode 800x600'
3. Saw black screen with white line as previously attached.
4. Switched to other console and ran 'intel_reg_dumper > intel_reg_dumper_kms2'

Are these dumps sufficient for the investigation if the EDID shows support for 800x600? If not, could you kindly let me know how to get them? Thanks!

Created attachment 76674 [details]
intel_reg_dumper-kms2

Hello, any updates for this bug?

Can you please test the below linked patch?

http://cgit.freedesktop.org/~danvet/drm/commit/?h=pll-limits-mess&id=64ac8695df0df5e9937da1b55ddb0e3fa37e6258

(In reply to comment #42)
> Can you please test the below linked patch?
> 
> http://cgit.freedesktop.org/~danvet/drm/commit/?h=pll-limits-
> mess&id=64ac8695df0df5e9937da1b55ddb0e3fa37e6258

Tested patch and recompiled kernel. The machine was still unable to boot in 800x600 mode. Do let me know which logs are required for investigation.

We have updated the EDID of the machine and xrandr now shows 800x600 support.  This is tested on SLE11 SP3 kotd version 3.0.68-31-pae and 3.0.70-33-pae. Here is the output of xrandr:

Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm
   1024x768       60.0*+   75.1     75.0     70.1     60.0* 
   832x624        74.6  
   800x600        72.2     75.0     60.3     60.0     56.2  
   640x480        72.8     75.0     72.8     75.0     66.7     60.0     59.9  
   720x400        70.1  

hwinfo --monitor now also shows the monitor's support for 800x600

21: None 00.0: 10002 LCD Monitor
  [Created at monitor.95]
  Unique ID: rdCR.YqWNTiPsv_3
  Hardware Class: monitor
  Model: "IBM 1024x768 LCD"
  Vendor: IBM "IBM"
  Device: eisa 0x0002 "1024x768 LCD"
  Resolution: 720x400@70Hz
  Resolution: 640x480@60Hz
  Resolution: 640x480@67Hz
  Resolution: 640x480@72Hz
  Resolution: 640x480@75Hz
  Resolution: 800x600@56Hz
  Resolution: 800x600@60Hz
  Resolution: 800x600@72Hz
  Resolution: 800x600@75Hz
  Resolution: 1024x768@60Hz
  Resolution: 1024x768@70Hz
  Resolution: 1024x768@75Hz
  Size: 304x228 mm
  Detailed Timings #0:
     Resolution: 1024x768
     Horizontal: 1024 1048 1184 1344 (+24 +160 +320) -hsync
       Vertical:  768  771  777  806 (+3 +9 +38) -vsync
    Frequencies: 65.00 MHz, 48.36 kHz, 60.00 Hz
  Driver Info #0:
    Max. Resolution: 1024x768
    Vert. Sync Range: 51-75 Hz
    Hor. Sync Range: 41-57 kHz
    Bandwidth: 65 MHz
  Config Status: cfg=new, avail=yes, need=no, active=unknown

However, the machine is still not able to boot into X. The whole screen is white as shown in the next attachment.

Created attachment 77270 [details]
x display

reopening this bug and there is new EDID file used that already shows the support of 800x600 from the xrandr but the monitor is still having problem  able to display  800x600.

could you help to check out and advise. let us know if you need other logs to help in this investigation. thank you.

What EDID? I do not see it attached?

The EDID file was used to update the EDID information for the machine. I have provided a dmesg output for your reference. Do let us know if you still require other logs.

Created attachment 77302 [details]
dmesg output

Either the Xorg.0.log or a simple dump of the EDID - preferably the Xorg.0.log in this case.

Created attachment 77307 [details]
Xorg.0.log file

The EDID is invalid.

(In reply to comment #52)
> The EDID is invalid.

could you share what are you expecting to consider EDID to be valid?
Please let us know so that we could forward the expectation
to the BIOS team.

The EDID is either absent or being rejected by the kernel, as it is not being passed to X and the resolutions provided are only the fallback modes.

All the evidence so far points towards an invalid EDID. Please reopen if you can demonstrate that it is otherwise.

Closing (>3 years) old Resolved+Invalid.