[Intel-gfx] the question about adding the default modes for LVDS output device in KMS mode

[Jesse Barnes]

On Mon, 15 Jun 2009 18:28:56 +0800
yakui_zhao <yakui.zhao at intel.com> wrote:

> Hi, All
>     
>     When the system is booted with KMS enabled, the xrandr tool will
> get less modes than in UMS mode. And it seems that this is a top KMS
> gap. Many laptops will be affected by this issue. 
> 
>     I worked on this issue and gave two proposals for this issue. One
> is realized in user space(src/drmmode_display.c). Another is realized
> in kernel space.
> 
>     a. user space: This is similar to what we have done in UMS mode.
> 	In UMS mode the gtf flag is always set in EDID for integrated
> LVDS device. Even when there is no EDID, we will construct a bogus
> EDID. Then the xorg will add the default mode for the LVDS output
> device. So when this is done in user space, the gtf flag will be set
> in EDID for the LVDS output device. When there is no EDID, we will
> construct a bogus EDID. Then the default mode will be added for the
> LVDS output device. At the same time in order to remove the invalid
> the modeline, the LVDS panel limit will be obtained and used to check
> whether the given modeline is valid.
>       
>     This solution is very simple. And it won't touch the kernel code. 
> 
>     b. kernel space: 
>        Add the CVT/GTF algorithm in kernel space and then it can be
> called to generate the required modelines for the given parameters(The
> CVT/GTF patches are ready. They are converted from CVT/GTF algorithm
> in xserver). In fact this two patches are should be used for
> interpreting the standard timing mode in EDID. I will send this patch
> set ASAP(CVT/GTF, get the standard timing mode by CVT/GTF).
>        But I have three issues about this method. 
>       1. the inconsistence of modeline parameter between the modeline
> generated by CVT/GTF and that defined in
> xserver/hw/xfree86/commons/xf86DefModeset.c. 
>          For the given modeline parameter(hdisplay, vdisplay,
> vfreshrate), we will get the different modelines by using CVT/GTF. At
> the same time the modeline is also different with that defined
> xf86DefModset.c 
>          Can we ignore the difference?
>       2. which of CVT/GTF algorithm should be used to generate the
> default mode?
>          If the CVT/GTF is used to generate the default mode lines for
> the given output device, which should be preferred? 
>          In the UMS mode we will get the timing_level,which is used to
> select CVT/GTF for the standard timing mode. So we can also get the
> timing level in KMS mode and then select CVT/GTF to generate  the
> default modes.
>         But what should we do if there is no EDID? At the same time it
> seems that sometimes we will get the different modelines for the
> different output devices with the different standard timing level in
> EDID. 
>       3. Is default mode table static or generated dynamically by
> using CVT/GTF?
>          We can add the default mode table once for the drm_device by
> calling the CVT/GTF algorithm. And when the default mode is required
> for the output device, we will add the default mode by copying it.
>          Of course we can generate the default modes dynamically by
> calling CVT/GTF algorithm for every output device. It will take more
> time to call the CVT/GTF algorithm in the boot phase.
>          
>       
> In fact I prefer the first proposal that adds the default modes for
> LVDS device in user space. It is very simple. 

Maybe we should just do both.  The userland solution will work for
people with 2.6.30 and earlier kernels, while adding the CVT/GTF code
to the kernel is the right long term solution.

If there's no EDID we can fall back to what we do today: just add a few
standard modes (probably 800x600 at a minimum); no need for big changes
there.

I don't really care about static or dynamic modes for the standard
stuff.  We already have the static tables in place; there's not much
reason to remove them.  CVT/GTF is mainly needed to properly generate
mode lists when we parse the EDID I think.

-- 
Jesse Barnes, Intel Open Source Technology Center