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

[Jesse Barnes]

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.

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.

-- 
Jesse Barnes, Intel Open Source Technology Center