[PATCH 8/9] handle cea-ext data block and insert mode into mode list.

Ma, Ling ling.ma at intel.com
Sat Feb 14 01:02:34 PST 2009


>-----Original Message-----
>From: Adam Jackson [mailto:ajax at nwnk.net] 
>Sent: 2009年2月14日 2:45
>To: Ma, Ling
>Cc: xorg at lists.freedesktop.org
>Subject: Re: [PATCH 8/9] handle cea-ext data block and insert 
>mode into mode list.
>On Thu, 2009-02-12 at 15:07 +0800, Ma Ling wrote:
>> On Thu, 2009-02-12 at 03:11 +0800, Adam Jackson wrote:
>> > This timing list actually brings up an unpleasant topic.  How are
>> > interlaced modes supposed to be represented inside the 
>server?  Detailed
>> > blocks seem to mostly be written such that 1080i is 
>described as 1920
>> > wide, 540 high, with the interlace bit set; ie, that 
>height is field
>> > height.  The mode list you've got here, and the standard mode list
>> > already in the server, give height as frame height.
>> > 
>> I notice xf86GetDefaultModes function will search
>> xf86DefaultModes table which also contain interlaced mode, 
>but whether
>> duplicate interlaced mode line or not depends on 
>interalceAllowed flag
>> set by driver, So can we implement the similar function like that to
>> handle CEA short video descriptor, and  Mode structure 
>always use 1080
>> as VDisplay?
>Hmm.  I think I'd rather GetDefaultModes just duplicate the whole list,
>and then validate each of {config,output,default}_modes against
>interlaceAllowed and doubleScanAllowed.  As it is, output_modes will
>have interlaced modes even if the driver says it can't do 
>them, which is
>just foolish.
>And yeah, I think frame height is the sensible representation for modes
>internally.  Now we just need to figure out how to fix up EDID timings
>that are in field height, but that's a fight for another day.
So your menas (If I was wrong, please correct me): we directly duplicate interlaced  mode from CEA table  which contains original height (like 1080i), 
then mode_valide function in driver will chose it or not ?
>BTW, you should probably send the next version of this series 
>to the new
>xorg-devel at lists.x.org list.
sure, I will do!
>- ajax

More information about the xorg mailing list