|
Description
Bryce Harrington
2009-07-10 18:01:49 UTC
Created attachment 27581 [details]
Xorg log with KMS and Option "ModeDebug" "true"
While booting with usplash resolution is 1280x1024@74,6Hz and not 640x480@59,9Hz (X still has 1024x768@75,1 Hz). please upload your xorg.conf file in KMS mode. Thanks Ma Ling (In reply to comment #3) > please upload your xorg.conf file in KMS mode. I am the original reporter of the Ubuntu bug. I have an empty xorg.conf. (In reply to comment #4) > (In reply to comment #3) > > please upload your xorg.conf file in KMS mode. > I am the original reporter of the Ubuntu bug. I have an empty xorg.conf. please run the below command and move xorg.conf into /etc/X11/ directory. $Xorg -configure could it because the native preferred modeline is filtered out by: "(II) intel(0): Not using mode "1280x1024" (bad mode clock/interlace/doublescan) " then xserver falls into fuzzy aspect match algorithm to pick the initial mode? Before X start, KMS has choose 1280x1024.. (In reply to comment #6) > could it because the native preferred modeline is filtered out by: > "(II) intel(0): Not using mode "1280x1024" (bad mode > clock/interlace/doublescan) > " > then xserver falls into fuzzy aspect match algorithm to pick the initial mode? > Before X start, KMS has choose 1280x1024.. when boot start, kms control all operation, and not check mode line seriously as X does. When X start, it take over system, and discard 1280x1024. So I think we can not get 1280x1024 in UMS either. (In reply to comment #7) > (In reply to comment #6) > > could it because the native preferred modeline is filtered out by: > > "(II) intel(0): Not using mode "1280x1024" (bad mode > > clock/interlace/doublescan) > > " > > then xserver falls into fuzzy aspect match algorithm to pick the initial mode? > > Before X start, KMS has choose 1280x1024.. > > when boot start, kms control all operation, and not check mode line seriously > as X does. When X start, it take over system, and discard 1280x1024. So I think > we can not get 1280x1024 in UMS either. > but the user says "Booting without KMS gives a 1280x1024 resolution"... see the first comment. (In reply to comment #4) > (In reply to comment #3) > > please upload your xorg.conf file in KMS mode. > > I am the original reporter of the Ubuntu bug. I have an empty xorg.conf. > Fabio, could you please give us a xorg.log with KMS disabled, and modedebug turns on? this will help us to see how UMS works...thanks. > Fabio, could you please give us a xorg.log with KMS disabled, and modedebug > turns on? this will help us to see how UMS works...thanks. I already attached this to the Ubuntu bug report: Xorg.log with KMS disabled + "ModeDebug" "true": http://launchpadlibrarian.net/28767779/Xorg.1.log Also, output of xrandr --verbose with KMS disabled: http://launchpadlibrarian.net/28767801/xrandr-verbose-UMS.txt Created attachment 27701 [details] [review] pleaset try the patch on your machine in KMS mode, thanks. please try the debug patch in KMS mode, then upload dmesg. Then patch intends to print all modes from edid in KMS mode, which are transmitted to X. Thanks Ma Ling (In reply to comment #11) > Created an attachment (id=27701) [details] > pleaset try the patch on your machine in KMS mode, thanks. > > please try the debug patch in KMS mode, then upload dmesg. > Then patch intends to print all modes from edid in KMS mode, which are > transmitted to X. The patch is for the linux kernel rigth? Currently I am doing tests with the LiveCD, I can compile the -intel driver and restart X from the LiveCD, but can't do that with the kernel. Unless Bryce make available a LiveCD with this kernel patch... :) (In reply to comment #12) > (In reply to comment #11) > > Created an attachment (id=27701) [details] [details] > > pleaset try the patch on your machine in KMS mode, thanks. > > > > please try the debug patch in KMS mode, then upload dmesg. > > Then patch intends to print all modes from edid in KMS mode, which are > > transmitted to X. > The patch is for the linux kernel rigth? > Currently I am doing tests with the LiveCD, I can compile the -intel driver and > restart X from the LiveCD, but can't do that with the kernel. > Unless Bryce make available a LiveCD with this kernel patch... :) Hi Fabio Because our issue is from KMS mode, the patch is for KMS. It will help us to narrow down the issue, could you please try it or under Bryce's help :) Thanks a lot Ma Ling Created attachment 27724 [details]
dmesg output with debug patch in KMS mode
OK, I installed karmic it to a new partition, applied the patch and recompiled the kernel.
dmesg output is attached. Note the last two lines were printed after a switch to VT and again to X.
Created attachment 27839 [details]
pleaset try the debug patch on your machine in KMS mode, thanks.
The patch intends to print all modes from edid and results from mode valid function in kms mode, through it we can find those mode line we transmitted to X server. please try it on your machine, then upload dmesg.
Thanks for your help.
Ma Ling
Created attachment 27873 [details]
dmesg output with second debug patch in KMS mode
Updated dmesg output is attached.
the root cause is stardard timing is not implemented in KMS, please try the patchset against latest drm-intel-next tree. http://lists.freedesktop.org/archives/intel-gfx/2009-July/003560.html thanks Ma Ling *** Bug 22780 has been marked as a duplicate of this bug. *** *** Bug 22779 has been marked as a duplicate of this bug. *** (In reply to comment #17) > the root cause is stardard timing is not implemented in KMS, please try the > patchset against latest drm-intel-next tree. > http://lists.freedesktop.org/archives/intel-gfx/2009-July/003560.html Where is drm-intel-next tree? If it's this: git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel then it fails to build here: CC [M] drivers/gpu/drm/drm_modes.o drivers/gpu/drm/drm_modes.c: In function ‘drm_cvt_mode’: drivers/gpu/drm/drm_modes.c:136: error: ‘gt’ undeclared (first use in this function) drivers/gpu/drm/drm_modes.c:136: error: (Each undeclared identifier is reported only once drivers/gpu/drm/drm_modes.c:136: error: for each function it appears in.) drivers/gpu/drm/drm_modes.c:158: error: ‘amp’ undeclared (first use in this function) ... please switch to drm-next tree(Dave Airlie <airlied@gmail.com>), the patch has been merged into it. Thanks Ma LIng (In reply to comment #21) > please switch to drm-next tree(Dave Airlie <airlied@gmail.com>), the patch has > been merged into it. OK, I switched to: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next this compiles fine, however I still get the 1024x768 resolution in X (maybe with slight different vertical refresh). (In reply to comment #22) > (In reply to comment #21) > > please switch to drm-next tree(Dave Airlie <airlied@gmail.com>), the patch has > > been merged into it. > OK, I switched to: > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next > this compiles fine, however I still get the 1024x768 resolution in X (maybe > with slight different vertical refresh). please upload your latest xorg log file with modedebug option. thanks Created attachment 28031 [details] Xorg log with KMS using linux drm-next 2009-07-24 and Option "ModeDebug" "true" > please upload your latest xorg log file with modedebug option. Xorg log is attached. This is my xorg.conf: Section "Device" Identifier "Configured Video Device" Option "ModeDebug" "true" EndSection Section "Monitor" Identifier "Configured Monitor" EndSection Section "Screen" Identifier "Default Screen" Monitor "Configured Monitor" Device "Configured Video Device" EndSection would you please try to apply patch in comment# 15 to dave's tree and post your dmesg? thanks. Will you please add the boot option of "drm.debug=0x6" on the lastest Dave's drm-next tree and see whether the issue still exits? If it still exists, please attach the output of dmesg. thanks. (In reply to comment #26) > Will you please add the boot option of "drm.debug=0x6" on the lastest Dave's > drm-next tree and see whether the issue still exits? > If it still exists, please attach the output of dmesg. > thanks. Please use the following command to switch to the Dave's drm-next tree. 1. git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 2. git branch -r 3. git checkout -b origin/drm-next Thanks. Created attachment 28746 [details] dmesg output with second debug patch in KMS mode using drm-next tree up to cfcf4738cd6b5 (2009-08-13) and drm.debug=0x6 option > Please use the following command to switch to the Dave's drm-next tree. > 1. git clone > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git > 2. git branch -r > 3. git checkout -b origin/drm-next These command don't work. That's what I did: git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git ** git tree up to: cfcf4738cd6b5 drm: fixup include file in drm_encoder_slave 2009-08-13 git checkout --track -b drm-next origin/drm-next patch -p1 < ../print_mode_line_in_kms.patch ** compiled kernel... booted with kernel option drm.debug=0x6 (during boot it says that that option is unknown...) Then I still get 1024x768. dmesg output is attached. > dmesg output is attached.
Note that the first lines are missing, maybe because dmesg has a size limit.
(In reply to comment #29) > > dmesg output is attached. > > Note that the first lines are missing, maybe because dmesg has a size limit. > Thanks for the testing. From the Xorg.log it seems that the version of EDID is 1.1. In such case the standard timing level is DMT, which causes that it won't call the CVT/GTF to generate the required timing mode. But in UMS mode it will also check whether the given parameter can be found in the default mode list and then return the correct mode. Maybe we should also add the default mode list in KMS. thanks. > Maybe we should also add the default mode list in KMS. Is this patch supposed to fix this issue? http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=882f0219518196a94cd2772004e87b178467139a If not, is a patch planned? (In reply to comment #31) > > Maybe we should also add the default mode list in KMS. > > Is this patch supposed to fix this issue? > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=882f0219518196a94cd2772004e87b178467139a > > If not, is a patch planned? It is not this patch. I will attach it as soon as I finish it. Thanks. > Created attachment 29099 [details] [review] [Patch 1/2]: add the default mode table Created attachment 29100 [details] [review] [Patch 2/2]: it will first check whether the given standard mode can be found in default mode table Will you please try the attach two patches on Dave's drm-next tree and see whether the issue still exists? How to get Dave's drm-next tree can be found in comment #27. Thanks. (In reply to comment #35) > Will you please try the attach two patches on Dave's drm-next tree and see > whether the issue still exists? > How to get Dave's drm-next tree can be found in comment #27. > Thanks. It works fine now! X gets the right 1280x1024 resolution. The only problem, however, is that switching to VT is still slow, maybe because when booting or on VT Vf is 74,6~75Hz, while when on X Vf changes to 59,9Hz. I also tried running openarena with the kernel with the two patches: the screen is completely out of sync (it moves horizontally very quickly), using a resolution of (according to my monitor OSD): 640x480, Hf 37KHz, Vf 72,6Hz. When using standard Ubuntu kernel (KMS but 1024x768 X resolution) I get the right image, with a resolution of: 640x480, Hf 37KHz, Vf 72,8Hz. I tried current drm-next where the patches were merged: the openarena problem is now fixed, however X still has a different refresh compared to boot and shutdown (both using Ubuntu usplash) and VT; also switching between VT and X require a mode change and is slow as without KMS. Thanks for the test. From the test it seems that this bug can be resolved by the patches in comment #33/34. As the following commit is already shipped in Dave's drm-next tree, this bug will be marked as resolved. 1. commit aa9eaa1f0962152d0bde821149d82fe7b70a6f92 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Thu Sep 3 09:33:46 2009 +0800 drm/kms: Add the default mode table 2. commit 559ee21d261a54c42594ef9405d27e9008eedf44 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Thu Sep 3 09:33:47 2009 +0800 drm/kms: try to find the std mode in DMT table (In reply to comment #39) > Thanks for the test. > From the test it seems that this bug can be resolved by the patches in comment Well, according to my test reported in comment #38 this bug should not be resolved ;) ... however since this bug is getting very long I opened a new bug report for the yet unfixed part: https://bugs.freedesktop.org/show_bug.cgi?id=23833 |
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.