[Intel-gfx] the questions about adding the default mode for LVDS device in KMS mode

[yakui_zhao]

On Thu, 2009-05-14 at 00:22 +0800, Jesse Barnes wrote:
> On Wed, 13 May 2009 17:01:41 +0800
> yakui_zhao <yakui.zhao at intel.com> wrote:
> 
> > Hi, Eric/Jesse
> >     Many users are affected by the issue that the number of modelines
> > in KMS is less than that in UMS. And we have gotten the root cause
> > that the default mode is not added for the LVDS output device.  But
> > how can we fix this issue? 
> >     a. Add the default modes by using CVT/GTF . I have send two
> > patches(CVT/GTF) to mailing list. If they are merged, we can generate
> > the required modeline based on the modeline parameter(hdisplay,
> > vdisplay, vfresh) by using the CVT/GTF algorithm. In such case we
> > will have to add a modeline table, which contains the basic modeline
> > parameter(hdisplay, vdisplay, vfreshrate). How can we get the
> > modeline table? Do they come from the default mode table in
> > xserver/hw/xfree86/common/xf86defmodeset.c? Are both CVT/GTF
> > algorithm used to generate the modeline for the given modeline
> > parameter?(hdisplay, vdisplay, vfreshrate). If only one algorithm is
> > enough, which should be used? 
> >        At the same time there exists another issue. If the modeline
> > is generated by using CVT/GTF, the parameter is different with that
> > defined in default mode table. For example: 1024*768 at 60HZ
> >        CVT: hdisplay=1024, hsync_start=1072 hsync_end=1176,
> > htotal=1328 vdsipaly=768, vsync_start=771, vsync_end=775, vtotal=798
> > 	    dotclk = 63.50MHz
> >        GTF: hdisplay=1024, hsync_start=1080 hsync_end=1184,
> > htotal=1344 vdsipaly=768, vsync_start=769, vsync_end=772, vtotal=795
> > 	    dotclk = 64.11MHz
> >        default table:
> >             hdisplay=1024, hsync_start=1048 hsync_end=1184,
> > htotal=1344 vdsipaly=768, vsync_start=771, vsync_end=777, vtotal=806
> > 	    dotclk = 65MHz
> >             65000, 1024,1048,1184,1344,0, 768,771,777,806
> >        
> >        Can the above difference be ignored?
> 
> I think so; we have a panel fitter on LVDS so we can actually support
> more modes.  I prefer adding a flag to the LVDS output indicating
> whether it supports GTF/CVT timings, then letting userspace just send
> in hdisplay, vdisplay and refresh params at LVDS mode set time.
> If that flag is set, userspace would also be free to add a set of
> default modes for apps to use.
If the difference can be ignored, it will be better to add them in
kernel space. 
It is difficult to add the modelines for most users by using xrandr.
What they cared is how to switch the different mode. At the same time we
can't do the validation in the mode_valid function of
src/drmmode_display.c (Now it always returns MODE_OK).
  
For the given modeline(hdisplay, vdisplay, vfreshrate), which should be
selected? CVT, GTF Or both are used to generate the modeline?
> 
> Alternately, we could generate a fake EDID for the LVDS output using
> GTF/CVT timings in addition to the native mode we get from the VBT.
> 
> I think the main issue here is that userspace apps expect to get a mode
> list back, so one has to be generated somewhere.  I'd prefer that be
> done in userspace though if we can get away with it...
I do a test in userspace. The function of adddefault mode is added in
the drmmode_output_get_modes for the LVDS output device. 
Then I can get the modelines as UMS. But too many modelines are
returned. Even the modeline that is beyond the panel limit is also
returned and it can't be marked as the invalid.

Of course if we can call the kernel mode_valid function in the
drmmode_mode_valid, it will be easy to add them in userspace.