Re: [ANNOUNCE] xf86-video-intel 2.6.2

2009-02-27 Thread Eric Anholt 
On Wed, 2009-02-25 at 19:13 +0100, Brice Goglin wrote:
> Eric Anholt wrote:
> > On Wed, 2009-02-25 at 14:10 +0100, Jacek Luczak wrote:
> >>
> >> this release is totally unusable while running in UXA. System eats lot of
> >> memory, including swapping. Is this that, reported earlier, ,,memory 
> >> leak''? As
> >> a result X are really slow and lot of lockups occur (everything freeze for 
> >> a few
> >> seconds). At the end I can't even switch to text console, but system 
> >> reacts on
> >> power button and it goes down successfully. With EXA there's no such issue:
> >> total system memory usage around 40%, no lockups.
> >>
> >> If it's not know issue I will try to bisect it down.
> >>
> >> -Jacek
> >>
> >> --
> >> Details:
> >>1. X.Org X Server 1.5.99.903 (1.6.0 RC 3)
> >>2. Linux Kernel 2.6.29-rc6
> > 
> > Can you give me exact steps to reproduce this leak?
> 
> Same problem here with libdrm 2.4.5, intel 2.6.2, Xserver 1.6-rc2,
> Mesa 7.3 on
> Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
> Graphics Controller [8086:27a2] (rev 03)
> 
> Nothing specific needed to reproduce the problem, just use X :)
> As soon as I start a big application such as firefox ou thunderbird,
> my 1GB RAM is entirely used after a couple seconds and the system
> becomes vey slow.
> 
> Only downgrade intel to 2.6.1 => 200MB used, no problem.

I think the problem here was the DRI2 tiling fix, which was great for
the 915-class 3D performance regression but bad for 915-class 2D.  I've
pushed a fix to master that should help.  If it does, I'll try to get a
2.6.3 out soon.

commit 5bfd73cd31ba197a62f549cdbad1a1270b571027
Author: Eric Anholt 
Date:   Fri Feb 27 19:09:49 2009 -0800

Only allocate pixmaps aligned for tiling when requested by DRI2 GetBuffers.

This saves massive quantities of memory on pre-965 since the DRI2 tiling
enable caused the minimum size of any pixmap to be 1MB.

-- 
Eric Anholt
e...@anholt.net eric.anh...@intel.com




signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: New Video Decode and Presentation API

2009-02-27 Thread Xavier Bestel 
Le vendredi 27 février 2009 à 15:21 -0800, Andy Ritger a écrit :
> > Neither, I'm trying to not use deinterlacing in the graphics card.
> >
> > Is it technically (theoretically) possible to rearrange the order of 
> > merging the fields and scaling?
> 
> I think if you want to scale, then you really need to deinterlace, first.

Not if you want to scale to an interlaced display.

Xav


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Preferred way to create & insert input events?

2009-02-27 Thread Chris Riddoch 
Hi, folks.

I'm working on some accessibility software that will enter events into
X, and have had some difficulty finding the appropriate APIs to use to
do so. I've looked at some existing software (cellwriter, easystroke,
xvkbd, etc.) and it seems like this is a relatively tricky thing to
do.

I've learned quite a bit about the uinput kernel module, but I haven't
figured out how to determine how it's been mapped to another key
before it gets to the application, or how to get at the mapping from
scancodes to keycodes, or even whether that's where I should be trying
to hook in, in the first place.  I have an old copy of O'Reilly's Xlib
programming manual, volume 1, from 1995, but I'm sure things have
moved on since then and there's a preferred way to generate input
events in software in modern X.

I also saw, via LWN, that there are people that have been working on
major changes to the input system - http://lwn.net/Articles/316274/

Can someone point me in the right direction?  A lot of this seems
exceedingly difficult to find.

Thanks,

-- 
Chris Riddoch
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: New Video Decode and Presentation API

2009-02-27 Thread Andy Ritger 

Sorry for the slow response, Torgeir.

> Neither, I'm trying to not use deinterlacing in the graphics card.
>
> Is it technically (theoretically) possible to rearrange the order of merging 
> the fields and scaling?

I think if you want to scale, then you really need to deinterlace, first.

The deinterlacer in NVIDIA's VDPAU implementation was improved in the
latest 180.35 beta:

 http://www.nvnews.net/vbulletin/showthread.php?t=128939

If you're having problems with the deinterlacer, and that is your
motivation for trying to avoid deinterlacing, then it might be worth
evaluating the deinterlacer updates.

I hope that helps,
- Andy


On Wed, 18 Feb 2009, Torgeir Veimo wrote:

>
> On 17 Feb 2009, at 18:05, Andy Ritger wrote:
>
> Are the even and odd frames scaled individually before applied to the
> resulting surface, or are they applied to the screen, then scaled?
>
> I believe the latter: the content is deinterlaced at the resolution
> of the content, and then the progressive frame is scaled to the size
> specified by the video player.
>
> The documentation here may be helpful (particularly the data flow diagram):
>
>   ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/index.html
>
> Deinterlacing is done in the VdpVideoMixer, and I expect scaling is done
> as part of constructing the VdpOutputSurface.
>
> It may be worth looking at what deinterlacing configuration your video
> player is using.  E.g., is it requesting temporal or temporal-spatial
> deinterlacing?
>
> Neither, I'm trying to not use deinterlacing in the graphics card.
>
> Is it technically (theoretically) possible to rearrange the order of merging 
> the fields and scaling?
>
> --
> Torgeir Veimo
> torg...@pobox.com
>
>
>
>
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xclock's problem

2009-02-27 Thread Glynn Clements 

Masaru Nomiya wrote:

>   Subject: Re: xclock's problem
>   Message-ID : <18855.23177.348554.585...@cerise.gclements.plus.com>
>   Date & Time: Fri, 27 Feb 2009 03:14:17 +
> 
> [Glynn] == Glynn Clements  has written:
> 
> Me>> I'm using xlock with the settings in .xinitrc;
> Me>> 
> Me>> xclock -digital -update 1 -fg gray100 -bg gray25 -fn 
> "-*-*-bold-r-normal--16-*" -geometry 270x33+1642+0 -strftime "%Y年%m月%d日(%a)   
> %H時%M分%S秒" &
> 
> Glynn> I don't know if it's related to your problem, but you should probably
> Glynn> be using e.g.:
> 
> Glynn>-xrm "*fontSet: -*-*-bold-r-normal--16-*"
> 
> Glynn> instead of -fn.
> 
> Glynn> Also, try using the -norender option.
> 
> Thanks.
> 
> With -xrm and -norender, I can use my favotite font.
> 
> But, how do you know -xrm option?
> It is not in man, nor massage by executing "xclock -h".

It's a standard option implemented by the X toolkit (Xt). Similarly,
the fontSet resource is standardised by the Athena (Xaw) widget set
which xclock uses.

When xclock was written, it was probably assumed that users would be
familiar with this. As other toolkits have become more popular
(primarily GTK and Qt), users are less likely to be familiar with the
X toolkit and X resources

> Anyway, a problem of time display is a bug, isn't it?

Probably. AFAICT, the problem relates to the code which only redraws
the portion which has changed (which seems like needless optimisation
to me). It's complicated by the fact that there are three different
versions of the text handling code: Xft, multi-byte (using fontSets)
and unibyte (using fonts).

-- 
Glynn Clements 
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: how to display a XImage with 16bits depth in a drawable with a depth of 24bits ?

2009-02-27 Thread Glynn Clements 

hd wrote:

> I my app, I receive a raw image in 16 bits depth.
> My defaut visual have a depth of 24 bits (and all other Visual have 24 
> or 32bits depth on my X server).
> 
> To display the bitmap I try to create an XImage with XCreateImage() and 
> display it with XPutImage().
> But X displays a "bad match" error
> 
> If I try to display a "raw image" with the same depth (24bits) as the 
> visual (24bits), my app works.
> 
> Question : XImage APIs (XCreateImage() / XPutImage() / ...) can convert 
> 'on the fly' the depth of the bitmap to match the visual depth
> or must I convert myself the raw bitmap to match the visual depth ? 
> (convert each pixel from 16bits to 24 bits)

You must convert yourself, or use a higher-level interface. The core X
protocol doesn't do format conversions.

If you want the conversion to be done in hardware, look at OpenGL or
XRender. It's implementation-dependent whether either of these
supports a specific format (other than 24-bit RGB), so you still need
to provide a software conversion.

-- 
Glynn Clements 
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Missing file for dri

2009-02-27 Thread Alex Deucher 
On Fri, Feb 27, 2009 at 1:30 PM, Gene Heskett  wrote:
> Greetings;
>
> Just installed by upgrade route, fedora 10.  Running kernel-2.6.28.7 now.
> When booted to the latest fedora i386 kernel-PAE, I have no dpms control over
> the monitor, and now booted to 2.6.28.7 I do.
>
> I ran that script I posted in my other radeonhd thread, after booting back to
> 2.6.28.7 expecting to see some improvement in glxgears, however on starting X,
> I find this in the Xorg.0.log, which seems to indicate several problems:
>

you won't see any change in gears since there is no 3D driver for
r6xx/r7xx hardware yet.

> (II) RADEONHD: version 1.2.4, built from git branch r6xx-r7xx-support, commit
> 62f401aa
> [...]  But:
> (**) RADEONHD(0): Option "AccelMethod" "exa"
> (**) RADEONHD(0): Option "DRI" "on"
> (**) RADEONHD(0): Selected EXA 2D acceleration.
> (II) RADEONHD(0): Unknown card detected: 0x94C3:0x1092:0x0710.
>        If - and only if - your card does not work or does not work optimally
>        please contact radeo...@opensuse.org to help rectify this.
>        Use the subject: 0x94C3:0x1092:0x0710: 
>        and *please* describe the problems you are seeing
>        in your message.
> (--) RADEONHD(0): Detected an RV610 on an unidentified card
> (II) RADEONHD(0): Mapped IO @ 0xfdde to 0xb7ee7000 (size 0x0001)
> (II) RADEONHD(0): PCIE Card Detected
> (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
> (II) RADEONHD(0): ATOM BIOS Rom:
>        SubsystemVendorID: 0x1092 SubsystemID: 0x0710
>        IOBaseAddress: 0x6c00
>        Filename: SD303VTD.I1J
>        BIOS Bootup Message:
> DM-HD610LG2-512
> [...]  and a few lines later:
> (II) RADEONHD(0): Using only 262144kB of the total 524288kB.
> (--) RADEONHD(0): VideoRAM: 262144 kByte
> (II) RADEONHD(0): Framebuffer space used by Firmware (kb): 16
> (II) RADEONHD(0): Start of VRAM area used by Firmware: 0x1fffc000
> (II) RADEONHD(0): AtomBIOS requests 16kB of VRAM scratch space
> (II) RADEONHD(0): AtomBIOS VRAM scratch base: 0x1fffc000
> (WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area 536854528
> (size: 16384) extends beyond available framebuff
> er size 268435456
> (II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory
> instead
> 
> So how do I fix this as I build my own kernels here?  Or is this not a kernel
> problem?
>

you can ignore this.

> Later still:
> 
> drmOpenByBusid: Searching for BusID pci::03:00.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 10, (OK)
> drmOpenByBusid: drmOpenMinor returns 10
> drmOpenByBusid: drmGetBusid reports pci::03:00.0
> (EE) AIGLX error: dlopen of /usr/lib/dri/r600_dri.so failed
> -
> and indeed, there is not such a file on the system.  How do I fix this?

There is no 3D driver yet, so you can safely ignore this.

> -
> (/usr/lib/dri/r600_dri.so: cannot open shared object file: No such
> file or directory)
> (EE) AIGLX: reverting to software rendering
> (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so
> 
> and of course glxgears is very hard put to make 300fps.

Once we have a 3D driver, you should see 3D performance improve.

Alex
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Missing file for dri

2009-02-27 Thread Gene Heskett 
Greetings;

Just installed by upgrade route, fedora 10.  Running kernel-2.6.28.7 now.
When booted to the latest fedora i386 kernel-PAE, I have no dpms control over 
the monitor, and now booted to 2.6.28.7 I do.

I ran that script I posted in my other radeonhd thread, after booting back to 
2.6.28.7 expecting to see some improvement in glxgears, however on starting X, 
I find this in the Xorg.0.log, which seems to indicate several problems:

(II) RADEONHD: version 1.2.4, built from git branch r6xx-r7xx-support, commit 
62f401aa
[...]  But:
(**) RADEONHD(0): Option "AccelMethod" "exa"
(**) RADEONHD(0): Option "DRI" "on"
(**) RADEONHD(0): Selected EXA 2D acceleration.
(II) RADEONHD(0): Unknown card detected: 0x94C3:0x1092:0x0710.
If - and only if - your card does not work or does not work optimally
please contact radeo...@opensuse.org to help rectify this.
Use the subject: 0x94C3:0x1092:0x0710: 
and *please* describe the problems you are seeing
in your message.
(--) RADEONHD(0): Detected an RV610 on an unidentified card
(II) RADEONHD(0): Mapped IO @ 0xfdde to 0xb7ee7000 (size 0x0001)
(II) RADEONHD(0): PCIE Card Detected
(II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location
(II) RADEONHD(0): ATOM BIOS Rom:
SubsystemVendorID: 0x1092 SubsystemID: 0x0710
IOBaseAddress: 0x6c00
Filename: SD303VTD.I1J
BIOS Bootup Message:
DM-HD610LG2-512
[...]  and a few lines later:
(II) RADEONHD(0): Using only 262144kB of the total 524288kB.
(--) RADEONHD(0): VideoRAM: 262144 kByte
(II) RADEONHD(0): Framebuffer space used by Firmware (kb): 16
(II) RADEONHD(0): Start of VRAM area used by Firmware: 0x1fffc000
(II) RADEONHD(0): AtomBIOS requests 16kB of VRAM scratch space
(II) RADEONHD(0): AtomBIOS VRAM scratch base: 0x1fffc000
(WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area 536854528 
(size: 16384) extends beyond available framebuff
er size 268435456
(II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory 
instead

So how do I fix this as I build my own kernels here?  Or is this not a kernel 
problem?

Later still:

drmOpenByBusid: Searching for BusID pci::03:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 10, (OK)
drmOpenByBusid: drmOpenMinor returns 10
drmOpenByBusid: drmGetBusid reports pci::03:00.0
(EE) AIGLX error: dlopen of /usr/lib/dri/r600_dri.so failed
-
and indeed, there is not such a file on the system.  How do I fix this?
-
(/usr/lib/dri/r600_dri.so: cannot open shared object file: No such
file or directory)
(EE) AIGLX: reverting to software rendering
(II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so

and of course glxgears is very hard put to make 300fps.

Many thanks for any help/instructs/urls.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Your wig steers the gig.
-- Lord Buckley

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xclock's problem

2009-02-27 Thread Masaru Nomiya 
Hello,

In the Message; 

  Subject: Re: xclock's problem
  Message-ID : <87bpsogfxm.wl%nom...@galaxy.dti.ne.jp>
  Date & Time: Fri, 27 Feb 2009 22:36:21 +0900

[Me] == Masaru Nomiya  has written:

Me> Anyway, a problem of time display is a bug, isn't it?

Sorry, it's not a bug.
Glynn's advice solves my problem.

Thanks. > Glynn

Regards,
 

---
  Masaru Nomiya   mail-to: nomiya @ galaxy.dti.ne.jp

  "Bill! You married with Computers.
   Not with Me!"
  "No..., with money."
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [ANNOUNCE] xf86-video-intel 2.6.2

2009-02-27 Thread Jacek Luczak 
Eric Anholt pisze:
> On Wed, 2009-02-25 at 14:10 +0100, Jacek Luczak wrote:
>> Eric Anholt pisze:
>>> Here comes a pretty significant bugfix release for the 2.6 2D series.
>>> The goal of this release is to get out the major fixes for GEM and KMS
>>> that we think we've pounded on enough to be stable -- certainly more
>>> stable than previously.  Notable fixes include a significant BO memory
>>> usage reduction (which many have suffered from with compositing),
>>> textured XV suppor twith KMS, and rotation support with KMS.  Some
>>> infrequent failure to render/xv with GEM on 965 (dmesg warnings about
>>> being unable to bind objects) should also be fixed. 
>>>
>>> But perhaps the exciting thing for most people will be the dynamic front
>>> buffer allocation.  We nearly slipped this into 2.6.0, but decided that
>>> it was just a little too new.  Well, turns out it was actually in good
>>> shape, and it's time to get it out there.  You'll need UXA to do this.
>> Hi Eric,
>>
>> this release is totally unusable while running in UXA. System eats lot of
>> memory, including swapping. Is this that, reported earlier, ,,memory leak''? 
>> As
>> a result X are really slow and lot of lockups occur (everything freeze for a 
>> few
>> seconds). At the end I can't even switch to text console, but system reacts 
>> on
>> power button and it goes down successfully. With EXA there's no such issue:
>> total system memory usage around 40%, no lockups.
>>
>> If it's not know issue I will try to bisect it down.
>>
>> -Jacek
>>
>> --
>> Details:
>>  1. X.Org X Server 1.5.99.903 (1.6.0 RC 3)
>>  2. Linux Kernel 2.6.29-rc6
> 
> Can you give me exact steps to reproduce this leak?

Launch X and any application. Thunderbird is really fast in killing it.

I will do some debug and provide more info on the weekend.

-Jacek
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xclock's problem

2009-02-27 Thread Masaru Nomiya 
Hello,

In the Message; 

  Subject: Re: xclock's problem
  Message-ID : <18855.23177.348554.585...@cerise.gclements.plus.com>
  Date & Time: Fri, 27 Feb 2009 03:14:17 +

[Glynn] == Glynn Clements  has written:

Me>> I'm using xlock with the settings in .xinitrc;
Me>> 
Me>> xclock -digital -update 1 -fg gray100 -bg gray25 -fn 
"-*-*-bold-r-normal--16-*" -geometry 270x33+1642+0 -strftime "%Y年%m月%d日(%a)   
%H時%M分%S秒" &

Glynn> I don't know if it's related to your problem, but you should probably
Glynn> be using e.g.:

Glynn>  -xrm "*fontSet: -*-*-bold-r-normal--16-*"

Glynn> instead of -fn.

Glynn> Also, try using the -norender option.

Thanks.

With -xrm and -norender, I can use my favotite font.

But, how do you know -xrm option?
It is not in man, nor massage by executing "xclock -h".

Anyway, a problem of time display is a bug, isn't it?

Regards,

---
  Masaru Nomiya   mail-to: nomiya @ galaxy.dti.ne.jp

  "Bill! You married with Computers.
   Not with Me!"
  "No..., with money."
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

how to display a XImage with 16bits depth in a drawable with a depth of 24bits ?

2009-02-27 Thread hd 

Hi,

I my app, I receive a raw image in 16 bits depth.
My defaut visual have a depth of 24 bits (and all other Visual have 24 
or 32bits depth on my X server).

To display the bitmap I try to create an XImage with XCreateImage() and 
display it with XPutImage().
But X displays a "bad match" error

If I try to display a "raw image" with the same depth (24bits) as the 
visual (24bits), my app works.

Question : XImage APIs (XCreateImage() / XPutImage() / ...) can convert 
'on the fly' the depth of the bitmap to match the visual depth
or must I convert myself the raw bitmap to match the visual depth ? 
(convert each pixel from 16bits to 24 bits)

thanks



___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 8/9] construct video block unified interface, insert SVD into mode list

2009-02-27 Thread Ma Ling 
construct unified video block interface, and insert mode into mode list 
according to video short descriptor from CEA extension

---
 hw/xfree86/ddc/interpret_edid.c  |   71 +++
 hw/xfree86/ddc/xf86DDC.h |6 ++
 hw/xfree86/modes/xf86EdidModes.c |   98 ++
 3 files changed, 175 insertions(+), 0 deletions(-)

diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index d2a9fb4..91ed930 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -253,6 +253,77 @@ void xf86ForEachDetailedBlock(xf86MonPtr mon,
 }
 }
 
+static struct cea_data_block *
+extract_cea_data_block(Uchar *ext, int data_type)
+{
+struct cea_ext_body *cea;
+struct cea_data_block *data_collection;
+struct cea_data_block *data_end;
+
+cea = (struct cea_ext_body *)ext;
+
+if (cea->dt_offset <= CEA_EXT_MIN_DATA_OFFSET)
+return NULL;
+
+data_collection = &cea->data_collection;
+data_end = (struct cea_data_block *)(cea->dt_offset + ext);
+
+for ( ;data_collection < data_end;) {
+
+   if (data_type == data_collection->tag) {
+   return data_collection;
+   }
+   data_collection = (unsigned char *)data_collection +
+   data_collection->len + 1 ;
+}
+
+return NULL;
+}
+
+static void handle_cea_video_block(Uchar *ext, handle_video_fn fn, void *data)
+{
+struct cea_video_block *video;
+struct cea_video_block *video_end;
+struct cea_data_block *data_collection;
+
+data_collection = extract_cea_data_block(ext, CEA_VIDEO_BLK);
+if (data_collection == NULL)
+return;
+
+video = &data_collection->u.video;
+video_end = (struct cea_video_block *)
+   ((Uchar *)video + data_collection->len);
+
+for (; video < video_end; video = video + 1) {
+   fn(video, data);
+}
+}
+
+void xf86ForEachVideoBlock(xf86MonPtr mon,
+  handle_video_fn fn,
+   void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+   return;
+
+for (i = 0; i < mon->no_sections; i++) {
+   ext = mon->rawData + EDID1_LEN * (i + 1);
+   switch (ext[EXT_TAG]) {
+   case CEA_EXT:
+   handle_cea_video_block(ext, fn, data);
+   break;
+   case VTB_EXT:
+   case DI_EXT:
+   case LS_EXT:
+   case MI_EXT:
+   break;
+   }
+}
+}
+
 xf86MonPtr
 xf86InterpretEEDID(int scrnIndex, Uchar *block)
 {
diff --git a/hw/xfree86/ddc/xf86DDC.h b/hw/xfree86/ddc/xf86DDC.h
index 0f4f65f..d168626 100644
--- a/hw/xfree86/ddc/xf86DDC.h
+++ b/hw/xfree86/ddc/xf86DDC.h
@@ -106,4 +106,10 @@ xf86DDCDetectQuirks(int scrnIndex, xf86MonPtr DDC, Bool 
verbose);
 void xf86DetTimingApplyQuirks(struct detailed_monitor_section *det_mon,
   ddc_quirk_t quirks, int hsize, int vsize);
 
+typedef void (* handle_video_fn)(struct cea_video_block *, void *);
+
+void xf86ForEachVideoBlock(xf86MonPtr,
+   handle_video_fn,
+   void *);
+
 #endif
diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c
index f7a9916..c522255 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -741,6 +741,100 @@ xf86DDCSetPreferredRefresh(int scrnIndex, DisplayModePtr 
modes,
best->type |= M_T_PREFERRED;
 }
 
+#define CEA_VIDEO_MODES_NUM  64
+static const DisplayModeRec CEAVideoModes[CEA_VIDEO_MODES_NUM] = {
+{ MODEPREFIX,25175,  640,  656,  752,  800, 0,  480,  490,  492,  525, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 1:640x...@60hz */
+{ MODEPREFIX,27000,  720,  736,  798,  858, 0,  480,  489,  495,  525, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 2:720x...@60hz */
+{ MODEPREFIX,27000,  720,  736,  798,  858, 0,  480,  489,  495,  525, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 3:720x...@60hz */
+{ MODEPREFIX,74250, 1280, 1390, 1430, 1650, 0,  720,  725,  730,  750, 
0, V_PHSYNC | V_PVSYNC, MODESUFFIX }, /* VIC 4: 1280x...@60hz */
+{ MODEPREFIX,74250, 1920, 2008, 2052, 2200, 0, 1080, 1084, 1094, 1125, 
0, V_PHSYNC | V_PVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 5:1920x10...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0,  480,  488,  494,  525, 
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 6:1440x4...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0,  480,  488,  494,  525, 
0, V_NHSYNC | V_NVSYNC | V_INTERLACE, MODESUFFIX }, /* VIC 7:1440x4...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0,  240,  244,  247,  262, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 8:1440x...@60hz */
+{ MODEPREFIX,27000, 1440, 1478, 1602, 1716, 0,  240,  244,  247,  262, 
0, V_NHSYNC | V_NVSYNC, MODESUFFIX }, /* VIC 9:1440x...@60hz */
+{ MODEPREFIX,54000, 2880, 2956, 3204, 3432, 0,  480,  488,  494,  525, 
0, V_NHSYNC | V_NVSYNC | V_INTERLACE,

[PATCH 6/9] configure name and range according to detailed timing block

2009-02-27 Thread Ma Ling 
through unified interface configure name and range

---
 hw/xfree86/common/xf86Configure.c |   57 
 1 files changed, 32 insertions(+), 25 deletions(-)

diff --git a/hw/xfree86/common/xf86Configure.c 
b/hw/xfree86/common/xf86Configure.c
index b803b49..c5d8f34 100644
--- a/hw/xfree86/common/xf86Configure.c
+++ b/hw/xfree86/common/xf86Configure.c
@@ -531,6 +531,36 @@ configureMonitorSection (int screennum)
 return ptr;
 }
 
+/* Initialize Configure Monitor from Detailed Timing Block */
+static void handle_detailed_input(struct detailed_monitor_section *det_mon,
+  void *data)
+{
+XF86ConfMonitorPtr ptr = (XF86ConfMonitorPtr) data;
+
+switch (det_mon->type) {
+case DS_NAME:
+ptr->mon_modelname = xf86confrealloc(ptr->mon_modelname,
+ 
strlen((char*)(det_mon->section.name)) +
+ 1);
+strcpy(ptr->mon_modelname,
+ (char*)(det_mon->section.name));
+break;
+case DS_RANGES:
+ptr->mon_hsync[ptr->mon_n_hsync].lo =
+det_mon->section.ranges.min_h;
+ptr->mon_hsync[ptr->mon_n_hsync].hi =
+det_mon->section.ranges.max_h;
+ptr->mon_n_vrefresh = 1;
+ptr->mon_vrefresh[ptr->mon_n_hsync].lo =
+det_mon->section.ranges.min_v;
+ptr->mon_vrefresh[ptr->mon_n_hsync].hi =
+det_mon->section.ranges.max_v;
+ptr->mon_n_hsync++;
+default:
+break;
+}
+}
+
 static XF86ConfMonitorPtr
 configureDDCMonitorSection (int screennum)
 {
@@ -578,31 +608,8 @@ configureDDCMonitorSection (int screennum)
 }
 #endif /* def CONFIGURE_DISPLAYSIZE */
 
-for (i=0;i<4;i++) {
-   switch (ConfiguredMonitor->det_mon[i].type) {
-   case DS_NAME:
-   ptr->mon_modelname  = xf86confrealloc(ptr->mon_modelname, 
- strlen((char*)(ConfiguredMonitor->det_mon[i].section.name))
-   + 1);
-   strcpy(ptr->mon_modelname,
-  (char*)(ConfiguredMonitor->det_mon[i].section.name));
-   break;
-   case DS_RANGES:
-   ptr->mon_hsync[ptr->mon_n_hsync].lo =
-   ConfiguredMonitor->det_mon[i].section.ranges.min_h;
-   ptr->mon_hsync[ptr->mon_n_hsync].hi =
-   ConfiguredMonitor->det_mon[i].section.ranges.max_h;
-   ptr->mon_n_vrefresh = 1;
-   ptr->mon_vrefresh[ptr->mon_n_hsync].lo =
-   ConfiguredMonitor->det_mon[i].section.ranges.min_v;
-   ptr->mon_vrefresh[ptr->mon_n_hsync].hi =
-   ConfiguredMonitor->det_mon[i].section.ranges.max_v;
-   ptr->mon_n_hsync++;
-   default:
-   break;
-   }
-}
-
+xf86ForEachDetailedBlock(ConfiguredMonitor, handle_detailed_input,
+ ptr);
 if (ConfiguredMonitor->features.dpms) {
   ptr->mon_option_lst = xf86addNewOption(ptr->mon_option_lst, 
xstrdup("DPMS"), NULL);
 }
-- 
1.5.4.4



___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 7/9] print all detailed timing blocks

2009-02-27 Thread Ma Ling 
through unified interface print all detailed timing blocks.

---
 hw/xfree86/ddc/print_edid.c |  256 +++---
 1 files changed, 140 insertions(+), 116 deletions(-)

diff --git a/hw/xfree86/ddc/print_edid.c b/hw/xfree86/ddc/print_edid.c
index 7b6e298..2ad199f 100644
--- a/hw/xfree86/ddc/print_edid.c
+++ b/hw/xfree86/ddc/print_edid.c
@@ -333,125 +333,143 @@ print_detailed_timings(int scrnIndex, struct 
detailed_timings *t)
 }
 }
 
+/* This function handle all detailed patchs,
+ * including EDID and EDID-extension
+ */
+struct det_print_parameter{
+  xf86MonPtr m;
+  int index;
+  ddc_quirk_t quirks;
+};
+
 static void
-print_detailed_monitor_section(int scrnIndex,
-  struct detailed_monitor_section *m)
+handle_detailed_print(struct detailed_monitor_section *det_mon,
+  void *data)
 {
-int i,j;
-  
-for (i=0;im->scrnIndex;
+xf86DetTimingApplyQuirks(det_mon,p->quirks,
+ p->m->features.hsize,
+ p->m->features.vsize);
+
+switch (det_mon->type) {
+case DT:
+print_detailed_timings(scrnIndex,&det_mon->section.d_timings);
+break;
+case DS_SERIAL:
+xf86DrvMsg(scrnIndex,X_INFO,"Serial No: %s\n",det_mon->section.serial);
+break;
+case DS_ASCII_STR:
+xf86DrvMsg(scrnIndex,X_INFO," %s\n",det_mon->section.ascii_data);
+break;
+case DS_NAME:
+xf86DrvMsg(scrnIndex,X_INFO,"Monitor name: 
%s\n",det_mon->section.name);
+break;
+case DS_RANGES:
+{
+struct monitor_ranges *r = &det_mon->section.ranges;
+xf86DrvMsg(scrnIndex,X_INFO,
+   "Ranges: V min: %i V max: %i Hz, H min: %i H max: %i kHz,",
+   r->min_v, r->max_v, r->min_h, r->max_h);
+if (r->max_clock_khz != 0) {
+xf86ErrorF(" PixClock max %i kHz\n", r->max_clock_khz);
+if (r->maxwidth)
+xf86DrvMsg(scrnIndex, X_INFO, "Maximum pixel width: %d\n",
+   r->maxwidth);
+   xf86DrvMsg(scrnIndex, X_INFO, "Supported aspect ratios:");
+   if (r->supported_aspect & SUPPORTED_ASPECT_4_3)
+   xf86ErrorF(" 4:3%s",
+   r->preferred_aspect == PREFERRED_ASPECT_4_3?"*":"");
+   if (r->supported_aspect & SUPPORTED_ASPECT_16_9)
+   xf86ErrorF(" 16:9%s",
+   r->preferred_aspect == PREFERRED_ASPECT_16_9?"*":"");
+if (r->supported_aspect & SUPPORTED_ASPECT_16_10)
+xf86ErrorF(" 16:10%s",
+   r->preferred_aspect == PREFERRED_ASPECT_16_10?"*":"");
+   if (r->supported_aspect & SUPPORTED_ASPECT_5_4)
+   xf86ErrorF(" 5:4%s",
+   r->preferred_aspect == PREFERRED_ASPECT_5_4?"*":"");
+   if (r->supported_aspect & SUPPORTED_ASPECT_15_9)
+   xf86ErrorF(" 15:9%s",
+   r->preferred_aspect == PREFERRED_ASPECT_15_9?"*":"");
+xf86ErrorF("\n");
+   xf86DrvMsg(scrnIndex, X_INFO, "Supported blankings:");
+   if (r->supported_blanking & CVT_STANDARD)
+   xf86ErrorF(" standard");
+   if (r->supported_blanking & CVT_REDUCED)
+   xf86ErrorF(" reduced");
+   xf86ErrorF("\n");
+   xf86DrvMsg(scrnIndex, X_INFO, "Supported scalings:");
+   if (r->supported_scaling & SCALING_HSHRINK)
+   xf86ErrorF(" hshrink");
+   if (r->supported_scaling & SCALING_HSTRETCH)
+   xf86ErrorF(" hstretch");
+   if (r->supported_scaling & SCALING_VSHRINK)
+   xf86ErrorF(" vshrink");
+   if (r->supported_scaling & SCALING_VSTRETCH)
+   xf86ErrorF(" vstretch");
+xf86ErrorF("\n");
+xf86DrvMsg(scrnIndex, X_INFO, "Preferred refresh rate: %d\n",
+   r->preferred_refresh);
+} else if (r->max_clock != 0) {
+   xf86ErrorF(" PixClock max %i MHz\n", r->max_clock);
+} else {
+   xf86ErrorF("\n");
+}
+if (r->gtf_2nd_f > 0)
+xf86DrvMsg(scrnIndex,X_INFO," 2nd GTF parameters: f: %i kHz "
+   "c: %i m: %i k %i j %i\n", r->gtf_2nd_f,
+   r->gtf_2nd_c, r->gtf_2nd_m, r->gtf_2nd_k,
+   r->gtf_2nd_j);
+break;
+}
+case DS_STD_TIMINGS:
+for (j = 0; j<5; j++)
xf86DrvMsg(scrnIndex,X_INFO,
-  "Ranges: V min: %i V max: %i Hz, H min: %i H max: %i 
kHz,",
-  r->min_v, r->max_v, r->min_h, r->max_h);
-   if (r->max_clock_khz != 0) {
-   xf86ErrorF(" PixClock max %i kHz\n", r->max_clock_khz);
-   if (r->maxwidth)
-   xf86DrvMsg(scrnIndex, X_INFO, "Maximum pixel width: %d\n",
-  r->maxwidth);
-   xf86DrvMsg(scrnIndex, X_INFO, "Supported aspect ratios:");
-   if (r->supported_aspect & SUPPORTED_ASPECT_4_3)
-   xf86ErrorF(" 4:3%s",
-

[PATCH 5/9] handle monitor record and physical size

2009-02-27 Thread Ma Ling 
through unified interface handle monitor record and physical size of detailed 
timing block.

---
 hw/xfree86/modes/xf86Crtc.c |  133 ---
 1 files changed, 87 insertions(+), 46 deletions(-)

diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index cb13deb..87237b9 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -1530,6 +1530,42 @@ GuessRangeFromModes(MonPtr mon, DisplayModePtr mode)
mon->vrefresh[0].lo = 58.0;
 }
 
+struct det_monrec_parameter {
+MonRec *mon_rec;
+int *max_clock;
+Bool set_hsync;
+Bool set_vrefresh;
+enum { sync_config, sync_edid, sync_default } *sync_source;
+};
+
+static void handle_detailed_monrec(struct detailed_monitor_section *det_mon,
+   void *data)
+{
+enum { sync_config, sync_edid, sync_default };
+struct det_monrec_parameter *p;
+p = (struct det_monrec_parameter *)data;
+
+if (det_mon->type == DS_RANGES) {
+struct monitor_ranges *ranges = &det_mon->section.ranges;
+if (p->set_hsync && ranges->max_h) {
+p->mon_rec->hsync[p->mon_rec->nHsync].lo = ranges->min_h;
+p->mon_rec->hsync[p->mon_rec->nHsync].hi = ranges->max_h;
+p->mon_rec->nHsync++;
+if (*p->sync_source == sync_default)
+*p->sync_source = sync_edid;
+}
+if (p->set_vrefresh && ranges->max_v) {
+p->mon_rec->vrefresh[p->mon_rec->nVrefresh].lo = ranges->min_v;
+p->mon_rec->vrefresh[p->mon_rec->nVrefresh].hi = ranges->max_v;
+p->mon_rec->nVrefresh++;
+if (*p->sync_source == sync_default)
+*p->sync_source = sync_edid;
+}
+if (ranges->max_clock * 1000 > *p->max_clock)
+*p->max_clock = ranges->max_clock * 1000;
+}
+}
+
 void
 xf86ProbeOutputModes (ScrnInfoPtr scrn, int maxX, int maxY)
 {
@@ -1608,42 +1644,24 @@ xf86ProbeOutputModes (ScrnInfoPtr scrn, int maxX, int 
maxY)

edid_monitor = output->MonInfo;

-   if (edid_monitor)
-   {
-   int i;
-   Boolset_hsync = mon_rec.nHsync == 0;
-   Boolset_vrefresh = mon_rec.nVrefresh == 0;
-   struct disp_features*features = &edid_monitor->features;
+if (edid_monitor)
+{
+struct det_monrec_parameter p;
+struct disp_features*features = &edid_monitor->features;
 
/* if display is not continuous-frequency, don't add default modes 
*/
if (!GTF_SUPPORTED(features->msc))
add_default_modes = FALSE;
 
-   for (i = 0; i < sizeof (edid_monitor->det_mon) / sizeof 
(edid_monitor->det_mon[0]); i++)
-   {
-   if (edid_monitor->det_mon[i].type == DS_RANGES)
-   {
-   struct monitor_ranges   *ranges = 
&edid_monitor->det_mon[i].section.ranges;
-   if (set_hsync && ranges->max_h)
-   {
-   mon_rec.hsync[mon_rec.nHsync].lo = ranges->min_h;
-   mon_rec.hsync[mon_rec.nHsync].hi = ranges->max_h;
-   mon_rec.nHsync++;
-   if (sync_source == sync_default)
-   sync_source = sync_edid;
-   }
-   if (set_vrefresh && ranges->max_v)
-   {
-   mon_rec.vrefresh[mon_rec.nVrefresh].lo = ranges->min_v;
-   mon_rec.vrefresh[mon_rec.nVrefresh].hi = ranges->max_v;
-   mon_rec.nVrefresh++;
-   if (sync_source == sync_default)
-   sync_source = sync_edid;
-   }
-   if (ranges->max_clock * 1000 > max_clock)
-   max_clock = ranges->max_clock * 1000;
-   }
-   }
+   p.mon_rec = &mon_rec;
+   p.max_clock = &max_clock;
+   p.set_hsync = mon_rec.nHsync == 0;
+   p.set_vrefresh = mon_rec.nVrefresh == 0;
+   p.sync_source = &sync_source;
+
+   xf86ForEachDetailedBlock(edid_monitor,
+handle_detailed_monrec,
+&p);
}
 
if (xf86GetOptValFreq (output->options, OPTION_MIN_CLOCK,
@@ -2887,6 +2905,35 @@ xf86OutputSetEDIDProperty (xf86OutputPtr output, void 
*data, int data_len)
 
 #endif
 
+/* Pull out a phyiscal size from a detailed timing if available. */
+struct det_phySize_parameter {
+xf86OutputPtr output;
+ddc_quirk_t quirks;
+Bool ret;
+};
+
+static void  handle_detailed_physical_size(struct detailed_monitor_section
+ *det_mon, void *data)
+{
+struct det_phySize_parameter *p;
+p = (struct det_phySize_parameter *)data;
+
+if (p->ret == TRUE )
+return ;
+
+xf86Det

[PATCH 4/9] insert detailed timing block into mode list

2009-02-27 Thread Ma Ling 
handle detailed timing block quirks and insert detailed timing block
into mode list

---
 hw/xfree86/ddc/xf86DDC.h |   39 +
 hw/xfree86/modes/xf86EdidModes.c |  285 --
 2 files changed, 191 insertions(+), 133 deletions(-)

diff --git a/hw/xfree86/ddc/xf86DDC.h b/hw/xfree86/ddc/xf86DDC.h
index b865e1a..0f4f65f 100644
--- a/hw/xfree86/ddc/xf86DDC.h
+++ b/hw/xfree86/ddc/xf86DDC.h
@@ -62,9 +62,48 @@ extern _X_EXPORT DisplayModePtr xf86DDCGetModes(int 
scrnIndex, xf86MonPtr DDC);
 extern _X_EXPORT Bool
 xf86MonitorIsHDMI(xf86MonPtr mon);
 
+/*
+ * Quirks to work around broken EDID data from various monitors.
+ */
+typedef enum {
+DDC_QUIRK_NONE = 0,
+/* First detailed mode is bogus, prefer largest mode at 60hz */
+DDC_QUIRK_PREFER_LARGE_60 = 1 << 0,
+/* 135MHz clock is too high, drop a bit */
+DDC_QUIRK_135_CLOCK_TOO_HIGH = 1 << 1,
+/* Prefer the largest mode at 75 Hz */
+DDC_QUIRK_PREFER_LARGE_75 = 1 << 2,
+/* Convert detailed timing's horizontal from units of cm to mm */
+DDC_QUIRK_DETAILED_H_IN_CM = 1 << 3,
+/* Convert detailed timing's vertical from units of cm to mm */
+DDC_QUIRK_DETAILED_V_IN_CM = 1 << 4,
+/* Detailed timing descriptors have bogus size values, so just take the
+ * maximum size and use that.
+ */
+DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE = 1 << 5,
+/* Monitor forgot to set the first detailed is preferred bit. */
+DDC_QUIRK_FIRST_DETAILED_PREFERRED = 1 << 6,
+/* use +hsync +vsync for detailed mode */
+DDC_QUIRK_DETAILED_SYNC_PP = 1 << 7,
+/* Force single-link DVI bandwidth limit */
+DDC_QUIRK_DVI_SINGLE_LINK = 1 << 8,
+} ddc_quirk_t;
+
+DisplayModePtr xf86DDCGetModes(int scrnIndex, xf86MonPtr DDC);
+
+extern Bool
+xf86MonitorIsHDMI(xf86MonPtr mon);
+
 typedef void (* handle_detailed_fn)(struct detailed_monitor_section *,void *);
 
 void xf86ForEachDetailedBlock(xf86MonPtr mon,
   handle_detailed_fn,
   void *data);
+
+ddc_quirk_t
+xf86DDCDetectQuirks(int scrnIndex, xf86MonPtr DDC, Bool verbose);
+
+void xf86DetTimingApplyQuirks(struct detailed_monitor_section *det_mon,
+  ddc_quirk_t quirks, int hsize, int vsize);
+
 #endif
diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c
index 1413e87..f7a9916 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -45,20 +45,23 @@
 #include 
 #include 
 
+static void handle_detailed_rblank(struct detailed_monitor_section *det_mon,
+   void *data)
+{
+if (det_mon->type == DS_RANGES)
+if (det_mon->section.ranges.supported_blanking & CVT_REDUCED)
+*(Bool*)data = TRUE;
+}
+
 static Bool
 xf86MonitorSupportsReducedBlanking(xf86MonPtr DDC)
 {
 /* EDID 1.4 explicitly defines RB support */
 if (DDC->ver.revision >= 4) {
-   int i;
-   for (i = 0; i < DET_TIMINGS; i++) {
-   struct detailed_monitor_section *det_mon = &DDC->det_mon[i];
-   if (det_mon->type == DS_RANGES)
-   if (det_mon->section.ranges.supported_blanking & CVT_REDUCED)
-   return TRUE;
-   }
-   
-   return FALSE;
+Bool ret = FALSE;
+
+xf86ForEachDetailedBlock(DDC, handle_detailed_rblank, &ret);
+return ret;
 }
 
 /* For anything older, assume digital means RB support. Boo. */
@@ -68,34 +71,6 @@ xf86MonitorSupportsReducedBlanking(xf86MonPtr DDC)
 return FALSE;
 }
 
-/*
- * Quirks to work around broken EDID data from various monitors.
- */
-
-typedef enum {
-DDC_QUIRK_NONE = 0,
-/* First detailed mode is bogus, prefer largest mode at 60hz */
-DDC_QUIRK_PREFER_LARGE_60 = 1 << 0,
-/* 135MHz clock is too high, drop a bit */
-DDC_QUIRK_135_CLOCK_TOO_HIGH = 1 << 1,
-/* Prefer the largest mode at 75 Hz */
-DDC_QUIRK_PREFER_LARGE_75 = 1 << 2,
-/* Convert detailed timing's horizontal from units of cm to mm */
-DDC_QUIRK_DETAILED_H_IN_CM = 1 << 3,
-/* Convert detailed timing's vertical from units of cm to mm */
-DDC_QUIRK_DETAILED_V_IN_CM = 1 << 4,
-/* Detailed timing descriptors have bogus size values, so just take the
- * maximum size and use that.
- */
-DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE = 1 << 5,
-/* Monitor forgot to set the first detailed is preferred bit. */
-DDC_QUIRK_FIRST_DETAILED_PREFERRED = 1 << 6,
-/* use +hsync +vsync for detailed mode */
-DDC_QUIRK_DETAILED_SYNC_PP = 1 << 7,
-/* Force single-link DVI bandwidth limit */
-DDC_QUIRK_DVI_SINGLE_LINK = 1 << 8,
-} ddc_quirk_t;
-
 static Bool quirk_prefer_large_60 (int scrnIndex, xf86MonPtr DDC)
 {
 /* Belinea 10 15 55 */
@@ -667,7 +642,7 @@ DDCGuessRangesFromModes(int scrnIndex, MonPtr Monitor, 
DisplayModePtr Modes)
 }
 }
 
-static ddc_quirk_t
+ddc_quirk_t
 xf86DDCDetectQuirks(int scrnIndex, xf86MonPtr DDC, Bool verbose)
 {

[PATCH 3/9] find max time clock and horizone & vertical size

2009-02-27 Thread Ma Ling 
through the unified interface find ranges section, max time clock and 
horizon & vertical size respectively.

---
 hw/xfree86/ddc/interpret_edid.c |  120 +++
 1 files changed, 72 insertions(+), 48 deletions(-)

diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index f04c6bc..d2a9fb4 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -54,11 +54,25 @@ static void get_detailed_timing_section(Uchar*, struct  
detailed_timings *);
 static Bool validate_version(int scrnIndex, struct edid_version *);
 
 static void
+find_ranges_section(struct detailed_monitor_section *det, void *ranges)
+{
+   if (det->type == DS_RANGES && det->section.ranges.max_clock)
+   *(struct monitor_ranges **)ranges = &det->section.ranges;
+}
+
+static void
+find_max_detailed_clock(struct detailed_monitor_section *det, void *ret)
+{
+if (det->type == DT) {
+*(int *)ret = max(*((int *)ret),
+  det->section.d_timings.clock);
+}
+}
+
+static void
 handle_edid_quirks(xf86MonPtr m)
 {
-int i, j;
-struct detailed_timings *preferred_timing;
-struct monitor_ranges *ranges;
+struct monitor_ranges *ranges = NULL;
 
 /*
  * max_clock is only encoded in EDID in tens of MHz, so occasionally we
@@ -66,28 +80,49 @@ handle_edid_quirks(xf86MonPtr m)
  * similar.  Strictly we should refuse to round up too far, but let's
  * see how well this works.
  */
-for (i = 0; i < 4; i++) {
-   if (m->det_mon[i].type == DS_RANGES) {
-   ranges = &m->det_mon[i].section.ranges;
-   for (j = 0; j < 4; j++) {
-   if (m->det_mon[j].type == DT) {
-   preferred_timing = &m->det_mon[j].section.d_timings;
-   if (!ranges->max_clock) continue; /* zero is legal */
-   if (ranges->max_clock * 100 < preferred_timing->clock) {
-   xf86Msg(X_WARNING,
-   "EDID preferred timing clock %.2fMHz exceeds "
-   "claimed max %dMHz, fixing\n",
-   preferred_timing->clock / 1.0e6,
-   ranges->max_clock);
-   ranges->max_clock =
-   (preferred_timing->clock+99)/100;
-   return;
-   }
-   }
-   }
-   }
+
+/* Try to find Monitor Range and max clock, then re-set range value*/
+xf86ForEachDetailedBlock(m, find_ranges_section, &ranges);
+if (ranges && ranges->max_clock) {
+int clock = 0;
+xf86ForEachDetailedBlock(m, find_max_detailed_clock, &clock);
+if (clock && (ranges->max_clock * 1e6 < clock)) {
+xf86Msg(X_WARNING, "EDID timing clock %.2f exceeds claimed max "
+"%dMHz, fixing\n", clock / 1.0e6, ranges->max_clock);
+ranges->max_clock = (clock+99)/1e6;
+}
+}
+}
+
+struct det_hv_parameter {
+int real_hsize;
+int real_vsize;
+float target_aspect;
+};
+
+static void handle_detailed_hvsize(struct detailed_monitor_section *det_mon,
+   void *data)
+{
+struct det_hv_parameter *p = (struct det_hv_parameter *)data;
+float timing_aspect;
+
+if (det_mon->type == DT) {
+struct detailed_timings *timing;
+timing = &det_mon->section.d_timings;
+
+if (!timing->v_size)
+return;
+
+timing_aspect = (float)timing->h_size / timing->v_size;
+if (fabs(1 - (timing_aspect / p->target_aspect)) < 0.05) {
+p->real_hsize = max(p->real_hsize, timing->h_size);
+p->real_vsize = max(p->real_vsize, timing->v_size);
+}
 }
+}
 
+static void encode_aspect_ratio(xf86MonPtr m)
+{
 /*
  * some monitors encode the aspect ratio instead of the physical size.
  * try to find the largest detailed timing that matches that aspect
@@ -97,38 +132,26 @@ handle_edid_quirks(xf86MonPtr m)
(m->features.hsize == 16 && m->features.vsize == 10) ||
(m->features.hsize == 4 && m->features.vsize == 3) ||
(m->features.hsize == 5 && m->features.vsize == 4)) {
-   int real_hsize = 0, real_vsize = 0;
-   float target_aspect, timing_aspect;
-   
-   target_aspect = (float)m->features.hsize / (float)m->features.vsize;
-   for (i = 0; i < 4; i++) {
-   if (m->det_mon[i].type == DT) {
-   struct detailed_timings *timing;
-   timing = &m->det_mon[i].section.d_timings;
-
-   if (!timing->v_size)
-   continue;
-
-   timing_aspect = (float)timing->h_size / (float)timing->v_size;
-   if (fabs(1 - (timing_aspect / target_aspect)) < 0.05) {
-   real_hsize = max(real_hsize, timing->h_size);
-   real_vsize = max(real_vsize, timing->v_size);
-   }
-   }
-

[PATCH 2/9] detailed timing unified interface

2009-02-27 Thread Ma Ling 
construct unified interface, anytime when program need to handle detailed 
timing block,
it always dynamically parse and deal with it through the interface.

---
 hw/xfree86/ddc/interpret_edid.c |  182 +++
 hw/xfree86/ddc/xf86DDC.h|5 +
 2 files changed, 132 insertions(+), 55 deletions(-)

diff --git a/hw/xfree86/ddc/interpret_edid.c b/hw/xfree86/ddc/interpret_edid.c
index c0e3df9..f04c6bc 100644
--- a/hw/xfree86/ddc/interpret_edid.c
+++ b/hw/xfree86/ddc/interpret_edid.c
@@ -41,6 +41,8 @@ static void get_display_section(Uchar*, struct disp_features 
*,
 static void get_established_timing_section(Uchar*, struct established_timings 
*);
 static void get_std_timing_section(Uchar*, struct std_timings *,
   struct edid_version *);
+static void fetch_detailed_block(Uchar *c, struct edid_version *ver,
+ struct detailed_monitor_section *det_mon);
 static void get_dt_md_section(Uchar *, struct edid_version *,
  struct detailed_monitor_section *det_mon);
 static void copy_string(Uchar *, Uchar *);
@@ -163,6 +165,70 @@ xf86InterpretEDID(int scrnIndex, Uchar *block)
 return NULL;
 }
 
+static int get_cea_detail_timing(Uchar *blk, xf86MonPtr mon,
+ struct detailed_monitor_section *det_mon)
+{
+int dt_num;
+int dt_offset = ((struct cea_ext_body *)blk)->dt_offset;
+
+dt_num = 0;
+
+if (dt_offset < CEA_EXT_MIN_DATA_OFFSET)
+return dt_num;
+
+for (; dt_offset < (CEA_EXT_MAX_DATA_OFFSET - DET_TIMING_INFO_LEN) &&
+   dt_num < CEA_EXT_DET_TIMING_NUM;
+  _NEXT_DT_MD_SECTION(dt_offset)) {
+
+fetch_detailed_block(blk + dt_offset, &mon->ver, det_mon + dt_num);
+dt_num = dt_num + 1 ;
+}
+
+return dt_num;
+}
+
+static void handle_cea_detail_block(Uchar *ext, xf86MonPtr mon,
+handle_detailed_fn fn,
+void *data)
+{
+int i;
+struct detailed_monitor_section det_mon[CEA_EXT_DET_TIMING_NUM];
+int det_mon_num;
+
+det_mon_num = get_cea_detail_timing(ext, mon, det_mon);
+
+for (i = 0; i < det_mon_num; i++)
+fn(det_mon + i, data);
+}
+
+void xf86ForEachDetailedBlock(xf86MonPtr mon,
+  handle_detailed_fn fn,
+  void *data)
+{
+int i;
+Uchar *ext;
+
+if (mon == NULL)
+return;
+
+for (i = 0; i < DET_TIMINGS; i++)
+fn(mon->det_mon + i, data);
+
+for (i = 0; i < mon->no_sections; i++) {
+ext = mon->rawData + EDID1_LEN * (i + 1);
+switch (ext[EXT_TAG]){
+case CEA_EXT:
+handle_cea_detail_block(ext, mon, fn, data);
+break;
+case VTB_EXT:
+case DI_EXT:
+case LS_EXT:
+case MI_EXT:
+   break;
+}
+}
+}
+
 xf86MonPtr
 xf86InterpretEEDID(int scrnIndex, Uchar *block)
 {
@@ -285,65 +351,71 @@ get_std_timing_section(Uchar *c, struct std_timings *r,
 }
 
 static void
-get_dt_md_section(Uchar *c, struct edid_version *ver, 
- struct detailed_monitor_section *det_mon)
+fetch_detailed_block(Uchar *c, struct edid_version *ver,
+ struct detailed_monitor_section *det_mon)
 {
-  int i;
- 
-  for (i=0;iversion == 1 && ver->revision >= 1 && IS_MONITOR_DESC) {
+switch (MONITOR_DESC_TYPE) {
+case SERIAL_NUMBER:
+det_mon->type = DS_SERIAL;
+copy_string(c,det_mon->section.serial);
+break;
+case ASCII_STR:
+det_mon->type = DS_ASCII_STR;
+copy_string(c,det_mon->section.ascii_data);
+break;
+case MONITOR_RANGES:
+det_mon->type = DS_RANGES;
+get_monitor_ranges(c,&det_mon->section.ranges);
+break;
+case MONITOR_NAME:
+det_mon->type = DS_NAME;
+copy_string(c,det_mon->section.name);
+break;
+case ADD_COLOR_POINT:
+det_mon->type = DS_WHITE_P;
+get_whitepoint_section(c,det_mon->section.wp);
+break;
+case ADD_STD_TIMINGS:
+det_mon->type = DS_STD_TIMINGS;
+get_dst_timing_section(c,det_mon->section.std_t, ver);
+break;
+case COLOR_MANAGEMENT_DATA:
+det_mon->type = DS_CMD;
+break;
+case CVT_3BYTE_DATA:
+det_mon->type = DS_CVT;
+get_cvt_timing_section(c, det_mon->section.cvt);
+break;
+case ADD_EST_TIMINGS:
+det_mon->type = DS_EST_III;
+break;
+case ADD_DUMMY:
+det_mon->type = DS_DUMMY;
+break;
+default:
+det_mon->type = DS_UNKOWN;
+break;
+}
+if (c[3] <= 0x0F) {
+det_mon->type = DS_VENDOR + c[3];
+}
+} else {
+det_mon->type = DT;
+get_

[PATCH 1/9] new structures and defined MACRO for CEA extension

2009-02-27 Thread Ma Ling 
declare new structure and MACRO related with CEA extension.

---
 hw/xfree86/ddc/edid.h |   97 +
 1 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/hw/xfree86/ddc/edid.h b/hw/xfree86/ddc/edid.h
index b556003..69c8399 100644
--- a/hw/xfree86/ddc/edid.h
+++ b/hw/xfree86/ddc/edid.h
@@ -555,4 +555,101 @@ typedef struct {
 
 extern _X_EXPORT xf86MonPtr ConfiguredMonitor;
 
+#define EXT_TAG 0
+#define EXT_REV 1
+#define CEA_EXT   0x02
+#define VTB_EXT   0x10
+#define DI_EXT0x40
+#define LS_EXT0x50
+#define MI_EXT0x60
+
+#define CEA_EXT_MIN_DATA_OFFSET 4
+#define CEA_EXT_MAX_DATA_OFFSET 127
+#define CEA_EXT_DET_TIMING_NUM 6
+
+#define IEEE_ID_HDMI0x000C03
+#define CEA_AUDIO_BLK   1
+#define CEA_VIDEO_BLK   2
+#define CEA_VENDOR_BLK  3
+#define CEA_SPEAKER_ALLOC_BLK 4
+#define CEA_VESA_DTC_BLK 5
+#define VENDOR_SUPPORT_AI(x) ((x) >> 7)
+#define VENDOR_SUPPORT_DC_48bit(x)  ( ( (x) >> 6) & 0x01)
+#define VENDOR_SUPPORT_DC_36bit(x)  ( ( (x) >> 5) & 0x01)
+#define VENDOR_SUPPORT_DC_30bit(x)  ( ( (x) >> 4) & 0x01)
+#define VENDOR_SUPPORT_DC_Y444(x)   ( ( (x) >> 3) & 0x01)
+#define VENDOR_LATENCY_PRESENT(x) ( (x) >> 7)
+#define VENDOR_LATENCY_PRESENT_I(x) ( ( (x) >> 6) & 0x01)
+#define HDMI_MAX_TMDS_UNIT   (5000)
+
+struct cea_video_block {
+  Uchar video_code;
+};
+
+struct cea_audio_block_descriptor {
+  Uchar audio_code[3];
+};
+
+struct cea_audio_block {
+  struct cea_audio_block_descriptor descriptor[10];
+};
+
+struct cea_vendor_block_hdmi {
+  Uchar  portB:4;
+  Uchar  portA:4;
+  Uchar  portD:4;
+  Uchar  portC:4;
+  Uchar  support_flags;
+  Uchar  max_tmds_clock;
+  Uchar  latency_present;
+  Uchar  video_latency;
+  Uchar  audio_latency;
+  Uchar  interlaced_video_latency;
+  Uchar  interlaced_audio_latency;
+};
+
+struct cea_vendor_block {
+  unsigned char ieee_id[3];
+  union {
+  struct cea_vendor_block_hdmi hdmi;
+  /* any other vendor blocks we know about */
+  };
+};
+
+struct cea_speaker_block
+{
+  Uchar FLR:1;
+  Uchar LFE:1;
+  Uchar FC:1;
+  Uchar RLR:1;
+  Uchar RC:1;
+  Uchar FLRC:1;
+  Uchar RLRC:1;
+  Uchar FLRW:1;
+  Uchar FLRH:1;
+  Uchar TC:1;
+  Uchar FCH:1;
+  Uchar Resv:5;
+  Uchar ResvByte;
+};
+
+struct cea_data_block {
+  Uchar len:5;
+  Uchar tag:3;
+  union{
+struct cea_video_block video;
+struct cea_audio_block audio;
+struct cea_vendor_block vendor;
+struct cea_speaker_block speaker;
+  }u;
+};
+
+struct cea_ext_body {
+  Uchar tag;
+  Uchar rev;
+  Uchar dt_offset;
+  Uchar flags;
+  struct cea_data_block data_collection;
+};
+
 #endif /* _EDID_H_ */
-- 
1.5.4.4



___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 0/9] handle detailed timing and short video descriptor of CEA extension

2009-02-27 Thread Ma Ling 
Hi All,

I re-updated the patches according to Ajax's great suggestion &
clarification, which intends to handle detailed timing blocks in EDID
and E-EDID. In patch 8, we select appropriate modes from video blocks
of CEA extension, then insert them into mode list.

Any comments are welcome!
   
[PATCH 1/9] new structures and defined MACRO for CEA extension 
[PATCH 2/9] detailed timing unified interface
[PATCH 3/9] find max time clock and horizone & vertical size
[PATCH 4/9] insert detailed timing block into mode list
[PATCH 5/9] handle monitor record and physical size
[PATCH 6/9] configure name and range according to detailed timing block
[PATCH 7/9] print all detailed timing blocks
[PATCH 8/9] construct video block unified interface, insert SVD into
mode list


Thanks
Ma Ling

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg