[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