[Intel-gfx] the questions about adding debug info for modeseting in KMS mode

yakui_zhao yakui.zhao at intel.com
Thu May 14 03:39:16 CEST 2009


On Thu, 2009-05-14 at 00:17 +0800, Jesse Barnes wrote:
> On Wed, 13 May 2009 17:51:06 +0800
> yakui_zhao <yakui.zhao at intel.com> wrote:
> 
> > Hi, Jesse
> > 
> >     When the X is started in UMS mode, we can see the info related
> > with the mode setting in the Xorg.log(For example: the detailed EDID
> > info, SDVO device command, modeline validation). This is very helpful
> > to analyze the issue related with modesetting.
> >     But when KMS is used, we have no such info. Maybe it is very
> > useful that we can get such info in KMS mode. It seems that the
> > following should be added if we hope to get such info. 
> >     a. register dump 
> >     b. the relationship between CRTC and output 
> >     c. the detailed info related with modeset (For example: the EDID
> > info, SDVO device command , modeline validatin)
> > 
> >     The item a/b is the static info and I will add them by using
> > debugfs. But for the item C, I have the following thoughts.
> >     1. Add the printk and the info can be obtained by using dmesg.
> > But as the kernel log buffer size is limited, we will add the
> > different debug level for DRM. For example: drm_core,
> > drm_driver_debug,drm_kms_debug Then the next is to add the debug info
> > for every output device.
> >2. Allocate a new buffer, which is used to
> > store the output info related with the modesetting and then a new
> > proc/sysfs I/F is used to get the info. the info related with
> > modesetting will be printed to the allocated buffer. But there exists
> > an issue. If too much debug info is printed, some info will be lost
> > as the buffer size is limited. The advantage is that other unrelated
> > info will be avoided.
> > 
> >     Which method is better? I will prefer to add the printk. 
> 
> Well, EDID info should be available from sysfs or as a property on the
> connector, so that info is already available.  Likewise with the mode
> lines, we should be able to read those back from the connector.
Yes. The EDID can also be obtained by using sysfs. 
For the modelines sometimes we want to know how the mode is validated
and which invalid modeline is removed as what we have done in UMS.

> 
> SDVO commands aren't available though that I know of; adding some
> buffers to debugfs might be useful there.
> 
> Adding separate DRM debug levels would be great though; to separate out
> ioctl vs mode vs various GEM execution debug output for example.
I will separate the different DRM debug levels and add the print to
obtain the debug info.
> 




More information about the Intel-gfx mailing list