I use xrandr to get resolution list, it only has 1366x768 there is no 1024x768. Then, I use result of `gtf 1024 768 60` for xrandr to addmode as below steps: xrandr --newmode "1024x768_60.00" 64.11 1024 1080 1184 1344 768 769 772 795 -HSync +Vsync xrandr --addmode DP1 1024x768_60.00 xrandr --output DP1 --mode 1024x768_60.00 I got black screen. but system is still alive. Machine: Dell E6510 CPU: Intel Core i5 M 540 @ 2.53GHz OS: Ubuntu 10.04 PS, On Windows, there is 1024x768x60 and can be used normally.
Created attachment 36190 [details] /var/log/Xorg.0.log
Created attachment 36191 [details] xrandr -q --verbose
Created attachment 36192 [details] VBIOS dump
Created attachment 36193 [details] intel_reg_dumper
Modesetting, including EDID probing, is handled in the kernel. I don't know how many of the Arrandale/Ironlake timing fixes from post-2.6.32 Ubuntu have applied to their kernel - it would be worth checking against the current mainline as well. In the meantime, can you please upload the dmesg in case something is reported whilst probing - and adding drm.debug=6 to your kernel commandline would increase the amount of debugging information whilst modesetting. Was the xrandr output after adding the new mode?
Created attachment 36699 [details] [review] Be more permissive with pll frequencies. This is the most likely candidate to fix missing modes, although there are a few other timing fixes for Ironlake/eDP.
Created attachment 36787 [details] dmesg with kernel 2.6.35-rc4 + patch This is dmesg using 2.6.35-rc4 + below patch https://bugs.freedesktop.org/attachment.cgi?id=36699
(In reply to comment #6) > Created an attachment (id=36699) [details] > Be more permissive with pll frequencies. > > This is the most likely candidate to fix missing modes, although there are a > few other timing fixes for Ironlake/eDP. Hi, I use (In reply to comment #5) > Modesetting, including EDID probing, is handled in the kernel. I don't know how > many of the Arrandale/Ironlake timing fixes from post-2.6.32 Ubuntu have > applied to their kernel - it would be worth checking against the current > mainline as well. In the meantime, can you please upload the dmesg in case > something is reported whilst probing - and adding drm.debug=6 to your kernel > commandline would increase the amount of debugging information whilst > modesetting. > > Was the xrandr output after adding the new mode? After adding the new mode, I can see it listed in `xrandr` output. But screen black when I switch resolution to 1024x768. but I still can type command `xrandr -s 0` to go back from black screen. and resolution come back to 1366x768
Created attachment 37105 [details] [review] [Patch 1/4]: Add fixed panel mode for eDP without fixed mode in VBT
Created attachment 37106 [details] [review] [Patch 2/4]: Always enable panel fitting for eDP
Created attachment 37107 [details] [review] [Patch 3/4]: Use fixed panel timing to drive eDP
Created attachment 37108 [details] [review] [Patch 4/4]: validate modes for eDP by using fixe panel size
Hi, CSJ Will you please try the attached four patches in comment #9-12 on the latest Eric's drm-intel-next tree and see whether the issue can fixed? Please add the boot option of "drm.debug=0x04" and attach the output of dmesg, intel_reg_dumper after trying the other display mode created by yourself. thanks.
Created attachment 37230 [details] dmesg dmesg after `xrandr --output DP1 --mode 1024x768` with insmod drm.ko debug=4
Created attachment 37231 [details] intel_reg_dumper the result of intel_reg_dumper after `xrandr --output DP1 --mode 1024x768`
(In reply to comment #13) > Hi, CSJ > Will you please try the attached four patches in comment #9-12 on the > latest Eric's drm-intel-next tree and see whether the issue can fixed? > > Please add the boot option of "drm.debug=0x04" and attach the output of > dmesg, intel_reg_dumper after trying the other display mode created by > yourself. > > thanks. Hi ykzhao, I applied 4 patches(#9 ~ #12) on kernel 2.6.35-rc4 (but I removed some PCH_eDP for compile succesffuly) and add 1024x768 resolution got from gtf, the screen not black now, but become fuzzy(like many small screen overlaps likes a garbage screen) dmesg and intel_reg_dumper are attached.
(In reply to comment #16) > (In reply to comment #13) > > Hi, CSJ > > Will you please try the attached four patches in comment #9-12 on the > > latest Eric's drm-intel-next tree and see whether the issue can fixed? > > > > Please add the boot option of "drm.debug=0x04" and attach the output of > > dmesg, intel_reg_dumper after trying the other display mode created by > > yourself. > > > > thanks. > > Hi ykzhao, > I applied 4 patches(#9 ~ #12) on kernel 2.6.35-rc4 > (but I removed some PCH_eDP for compile succesffuly) > > and add 1024x768 resolution got from gtf, > the screen not black now, > but become fuzzy(like many small screen overlaps likes a garbage screen) > > dmesg and intel_reg_dumper are attached. P.S: I got fuzzy screen after `xrandr --output DP1 --mode 1024x768`
Created attachment 37232 [details] [review] Fix panel fitting regression. Sounds like you then hit the panel fitting regression in 2.6.35-rc1.
Created attachment 37236 [details] dmesg with 2.6.35-rc4 + 4 patches + Fix panel fitting regression since 734b4157 dmesg with debug=4, remove drm_mode_set_crtcinfo(adjusted_mode, 0); https://bugs.freedesktop.org/attachment.cgi?id=37232
(In reply to comment #18) > Created an attachment (id=37232) [details] > Fix panel fitting regression. > > Sounds like you then hit the panel fitting regression in 2.6.35-rc1. Hi Chris, I applied [PATCH] drm/i915: Fix panel fitting regression since 734b4157 But looks like the same, got a garbage screen. dmesg attached. thanks
Created attachment 37256 [details] [review] [Patch]: add the support of setting other modes for eDP Hi, CSJ thanks for the testing. Very sorry that the patches in comment #9-12 is not based on 2.6.35-rc4. From the output of intel_reg_dumper in comment #15 it seems that the panel fitting is not set. Not sure whether the patch in comment #10 is correctly applied. > PFA_CTL_1: 0x00800000 (disable, PFB_CTL_1: 0x00000000 (disable, PFA_WIN_POS: 0x00000000 (0, 0) PFB_WIN_POS: 0x00000000 (0, 0) PFA_WIN_SIZE: 0x00000000 (0, 0) PFB_WIN_SIZE: 0x00000000 (0, 0) Will you please double check whether the patch in comment #10 is correctly applied? Of course I merge the patches in comment #9-12 into one patch for your convenience. And it is refreshed based on 2.6.35-rc4 kernel(The IS_PCH_eDP is also removed). Will you please try it and see whether the screen is still garbled? thanks. thanks.
(In reply to comment #21) > Created an attachment (id=37256) [details] > [Patch]: add the support of setting other modes for eDP > > Hi, CSJ > thanks for the testing. Very sorry that the patches in comment #9-12 is > not based on 2.6.35-rc4. > From the output of intel_reg_dumper in comment #15 it seems that the panel > fitting is not set. Not sure whether the patch in comment #10 is correctly > applied. > > PFA_CTL_1: 0x00800000 (disable, > PFB_CTL_1: 0x00000000 (disable, > PFA_WIN_POS: 0x00000000 (0, 0) > PFB_WIN_POS: 0x00000000 (0, 0) > PFA_WIN_SIZE: 0x00000000 (0, 0) > PFB_WIN_SIZE: 0x00000000 (0, 0) > > Will you please double check whether the patch in comment #10 is correctly > applied? > Of course I merge the patches in comment #9-12 into one patch for your > convenience. And it is refreshed based on 2.6.35-rc4 kernel(The IS_PCH_eDP is > also removed). > Will you please try it and see whether the screen is still garbled? > > thanks. > > thanks. Hi ykzhao, After appling #
(In reply to comment #21) > Created an attachment (id=37256) [details] > [Patch]: add the support of setting other modes for eDP > > Hi, CSJ > thanks for the testing. Very sorry that the patches in comment #9-12 is > not based on 2.6.35-rc4. > From the output of intel_reg_dumper in comment #15 it seems that the panel > fitting is not set. Not sure whether the patch in comment #10 is correctly > applied. > > PFA_CTL_1: 0x00800000 (disable, > PFB_CTL_1: 0x00000000 (disable, > PFA_WIN_POS: 0x00000000 (0, 0) > PFB_WIN_POS: 0x00000000 (0, 0) > PFA_WIN_SIZE: 0x00000000 (0, 0) > PFB_WIN_SIZE: 0x00000000 (0, 0) > > Will you please double check whether the patch in comment #10 is correctly > applied? > Of course I merge the patches in comment #9-12 into one patch for your > convenience. And it is refreshed based on 2.6.35-rc4 kernel(The IS_PCH_eDP is > also removed). > Will you please try it and see whether the screen is still garbled? > > thanks. > > thanks. Hi ykzhao, After appling #12, it works fine on the new added mode 1024x768 Thanks a lot :)
Hi, CSJ Thanks for so quick response. It is good news that it can work as expected after applying the patch in comment #21. thanks.
(In reply to comment #24) > Hi, CSJ > Thanks for so quick response. It is good news that it can work as expected > after applying the patch in comment #21. > > thanks. sorry for typo, I applied comment #21. but not #12. thanks
The patches are now in Eric's drm-intel-next branch and will be included in 2.6.36-rc1.
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.