monitor detection through ddc/edid stuff.

monitor detection through ddc/edid stuff.

[Sven Luther]

Hello,

I am currently working on a 3dlabs wildcat vp fbdev driver (my 560 died, but i
got a 880 Pro :). And i have some questions with the monitor detection and
ddc/edid stuff.

I have looked over fbmon.c, and foung that it contains code for parsing the
EDID data, but not for actually reading it, apart the get_EDID_from_firmware
which is rather primitive, and doesn't actually do anything (i suppose that
the edid_info.dummy is read from the x86 bios in some other function).

I also have quickly overviewed the radeon driver, which has a function to read
the EDID either from the BIOS or the pmac OF. There seem to be no code
whatsoever that adds proper EDID reading through the graphic card directly,
like it is done in XFree86, where one can do in the individual drivers (using
i2c stuff also) :

	...
	pBus->BusName = "DDC";
	pBus->I2CUDelay = WildcatVPI2CUDelay;
	pBus->I2CPutBits = WildcatVPI2CPutBits;
	pBus->I2CGetBits = WildcatVPI2CGetBits;

These three being smallish functions to delay a bit, and to put/get bits in
the DCC Clock/Data Out/In registers.

And then :

	pMon = xf86DoEDID_DDC2(pScrn->scrnIndex, pBus);

There is also a DCC1 function i think, or something such.

Would it make sense to implement such a feature in fbmon.c ? Is fbmon.c the
right place for this ? Is this already implemented somewhere else, or maybe in
some private tree somewhere ? 

As i understand this, we would need some place to set the those three
function, and then a common function to actually do a real EDID reading
through the graphic card (get_EDID_from_harware ?).

Does this make sense ? Any hint on how to best implement this ? 

Friendly,

Sven Luther




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Sven Luther]

On Fri, Sep 10, 2004 at 01:16:27PM +0200, Sven Luther wrote:
> Hello,
> 
> I am currently working on a 3dlabs wildcat vp fbdev driver (my 560 died, but i
> got a 880 Pro :). And i have some questions with the monitor detection and
> ddc/edid stuff.
> 
> I have looked over fbmon.c, and foung that it contains code for parsing the
> EDID data, but not for actually reading it, apart the get_EDID_from_firmware
> which is rather primitive, and doesn't actually do anything (i suppose that
> the edid_info.dummy is read from the x86 bios in some other function).
> 
> I also have quickly overviewed the radeon driver, which has a function to read
> the EDID either from the BIOS or the pmac OF. There seem to be no code
> whatsoever that adds proper EDID reading through the graphic card directly,
> like it is done in XFree86, where one can do in the individual drivers (using
> i2c stuff also) :
> 
> 	...
> 	pBus->BusName = "DDC";
> 	pBus->I2CUDelay = WildcatVPI2CUDelay;
> 	pBus->I2CPutBits = WildcatVPI2CPutBits;
> 	pBus->I2CGetBits = WildcatVPI2CGetBits;
> 
> These three being smallish functions to delay a bit, and to put/get bits in
> the DCC Clock/Data Out/In registers.
> 
> And then :
> 
> 	pMon = xf86DoEDID_DDC2(pScrn->scrnIndex, pBus);
> 
> There is also a DCC1 function i think, or something such.
> 
> Would it make sense to implement such a feature in fbmon.c ? Is fbmon.c the
> right place for this ? Is this already implemented somewhere else, or maybe in
> some private tree somewhere ? 
> 
> As i understand this, we would need some place to set the those three
> function, and then a common function to actually do a real EDID reading
> through the graphic card (get_EDID_from_harware ?).
> 
> Does this make sense ? Any hint on how to best implement this ? 

Ah, i suppose i need to setup a i2c bus like the voodoo3 does, right ? but i
don't see that the voodoo3 tdfx driver uses this bus to probe for monitor
stuff, but maybe i missed it.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Kronos]

Il Fri, Sep 10, 2004 at 01:16:27PM +0200, Sven Luther ha scritto: 
> I also have quickly overviewed the radeon driver, which has a function to read
> the EDID either from the BIOS or the pmac OF. There seem to be no code
> whatsoever that adds proper EDID reading through the graphic card directly,
> like it is done in XFree86, where one can do in the individual drivers (using
> i2c stuff also) :
> 
> 	...
> 	pBus->BusName = "DDC";
> 	pBus->I2CUDelay = WildcatVPI2CUDelay;
> 	pBus->I2CPutBits = WildcatVPI2CPutBits;
> 	pBus->I2CGetBits = WildcatVPI2CGetBits;
>
> These three being smallish functions to delay a bit, and to put/get bits in
> the DCC Clock/Data Out/In registers.

Ok, you a have a bit-style adapter. i2c kernel core needs function to
control SDA and SCL but they can be easily created from X functions.

*GetBits must be splited in getscl (read clock) and getsda (get data),
and *PutBits must be splited in setscl and setsda.

I've done that with the radeon driver, look at drivers/video/aty/radeon_i2c.c.

> Would it make sense to implement such a feature in fbmon.c ? Is fbmon.c the
> right place for this ? Is this already implemented somewhere else, or maybe in
> some private tree somewhere ?

We already have a I2C subsystem, all you have to do is create a new
adapter and read from it (ie. you put the starting address on bus and
start reading).

> As i understand this, we would need some place to set the those three
> function, and then a common function to actually do a real EDID reading
> through the graphic card (get_EDID_from_harware ?).

Well, instead of PutBits/GetBits we have 4 functions, the algorithm is 
provided by the i2c subsystem. Look at radeon_do_probe_i2c_edid in the
radeon driver, it's not hard to do.

Oh, radeon_probe_i2c_connector contains some "black magic" to wakeup
some older boards/monitor. An ATI developer confirmed that it's needed
to cover some corner case, probably you don't need that on your board.

Luca
-- 
Home: http://kronoz.cjb.net
"L'abilita` politica e` l'abilita` di prevedere quello che
 accadra` domani, la prossima settimana, il prossimo mese e
 l'anno prossimo. E di essere cosi` abili, piu` tardi,
 da spiegare  perche' non e` accaduto."


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Jon Smirl]

On Sat, 11 Sep 2004 17:36:25 +0200, Kronos <kronos@people.it> wrote:
> Oh, radeon_probe_i2c_connector contains some "black magic" to wakeup
> some older boards/monitor. An ATI developer confirmed that it's needed
> to cover some corner case, probably you don't need that on your board.

That radeon "black magic" is not in the correct place for an I2C
driver. It's suposed to be on a different driver hook. If it was moved
it wouldn't be so messy. I've forgotten which hook it belongs on, the
conversation is in the I2C email archive.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Sven Luther]

On Sat, Sep 11, 2004 at 05:36:25PM +0200, Kronos wrote:
> Il Fri, Sep 10, 2004 at 01:16:27PM +0200, Sven Luther ha scritto: 
> > I also have quickly overviewed the radeon driver, which has a function to read
> > the EDID either from the BIOS or the pmac OF. There seem to be no code
> > whatsoever that adds proper EDID reading through the graphic card directly,
> > like it is done in XFree86, where one can do in the individual drivers (using
> > i2c stuff also) :
> > 
> > 	...
> > 	pBus->BusName = "DDC";
> > 	pBus->I2CUDelay = WildcatVPI2CUDelay;
> > 	pBus->I2CPutBits = WildcatVPI2CPutBits;
> > 	pBus->I2CGetBits = WildcatVPI2CGetBits;
> >
> > These three being smallish functions to delay a bit, and to put/get bits in
> > the DCC Clock/Data Out/In registers.
> 
> Ok, you a have a bit-style adapter. i2c kernel core needs function to
> control SDA and SCL but they can be easily created from X functions.

Well, i have full specs of the board, so it will be enough to base the code
on.

> *GetBits must be splited in getscl (read clock) and getsda (get data),
> and *PutBits must be splited in setscl and setsda.

Yeah, i have seen that.

> I've done that with the radeon driver, look at drivers/video/aty/radeon_i2c.c.

Ah, i see, i had searched for it in the place with the rest of the i2c stuff,
where the prosavage and voodoo i2c code is. Why did you not add it there, but
in the radeon driver ? Should i do the same, or put it together with the other
code ? 

I had seen the voodoo i2c driver, and searched in vain for code using it in
the tdfx driver.

> > Would it make sense to implement such a feature in fbmon.c ? Is fbmon.c the
> > right place for this ? Is this already implemented somewhere else, or maybe in
> > some private tree somewhere ?
> 
> We already have a I2C subsystem, all you have to do is create a new
> adapter and read from it (ie. you put the starting address on bus and
> start reading).

Ok.

> > As i understand this, we would need some place to set the those three
> > function, and then a common function to actually do a real EDID reading
> > through the graphic card (get_EDID_from_harware ?).
> 
> Well, instead of PutBits/GetBits we have 4 functions, the algorithm is 
> provided by the i2c subsystem. Look at radeon_do_probe_i2c_edid in the
> radeon driver, it's not hard to do.

Ok, will look.

> Oh, radeon_probe_i2c_connector contains some "black magic" to wakeup
> some older boards/monitor. An ATI developer confirmed that it's needed
> to cover some corner case, probably you don't need that on your board.

No, i don't think so.

Now, another question which has me baffled. In set_par, i set the video mode
for the card, but i only seem to have access to the bpp, and not the actual
depth. Since i can distinguish between depth 15 (5551) and 16 (5650), as well
as between depth 24 (8888) and 30 (AAA2), where do i get the information
concerning the actual depth used from ? 

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Antonino A. Daplas]

On Sunday 12 September 2004 16:42, Sven Luther wrote:
>
> Now, another question which has me baffled. In set_par, i set the video
> mode for the card, but i only seem to have access to the bpp, and not the
> actual depth. Since i can distinguish between depth 15 (5551) and 16
> (5650), as well as between depth 24 (8888) and 30 (AAA2), where do i get
> the information concerning the actual depth used from ?
>

var->green.length

Tony




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Sven Luther]

On Sun, Sep 12, 2004 at 05:32:44PM +0800, Antonino A. Daplas wrote:
> On Sunday 12 September 2004 16:42, Sven Luther wrote:
> >
> > Now, another question which has me baffled. In set_par, i set the video
> > mode for the card, but i only seem to have access to the bpp, and not the
> > actual depth. Since i can distinguish between depth 15 (5551) and 16
> > (5650), as well as between depth 24 (8888) and 30 (AAA2), where do i get
> > the information concerning the actual depth used from ?
> >
> 
> var->green.length

So, on a 5551 more, i should get :

  var->green.length + var->red.length + var->blue.length == 15 

right ?

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Antonino A. Daplas]

On Sunday 12 September 2004 18:04, Sven Luther wrote:
> On Sun, Sep 12, 2004 at 05:32:44PM +0800, Antonino A. Daplas wrote:
> > On Sunday 12 September 2004 16:42, Sven Luther wrote:
> > > Now, another question which has me baffled. In set_par, i set the video
> > > mode for the card, but i only seem to have access to the bpp, and not
> > > the actual depth. Since i can distinguish between depth 15 (5551) and
> > > 16 (5650), as well as between depth 24 (8888) and 30 (AAA2), where do i
> > > get the information concerning the actual depth used from ?
> >
> > var->green.length
>
> So, on a 5551 more, i should get :
>
>   var->green.length + var->red.length + var->blue.length == 15
>
> right ?

Yes, sorry for being cryptic.  Only if (visual == truecolor ||
visual == directcolor), otherwise color depth = var->green.length.  If you
are using at least a 2.6.8 kernel, there is a new helper in
drivers/video/fbmem.c that you can check out:

int fb_get_color_depth(struct fb_info *)

Tony




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Sven Luther]

On Sun, Sep 12, 2004 at 06:11:01PM +0800, Antonino A. Daplas wrote:
> On Sunday 12 September 2004 18:04, Sven Luther wrote:
> > On Sun, Sep 12, 2004 at 05:32:44PM +0800, Antonino A. Daplas wrote:
> > > On Sunday 12 September 2004 16:42, Sven Luther wrote:
> > > > Now, another question which has me baffled. In set_par, i set the video
> > > > mode for the card, but i only seem to have access to the bpp, and not
> > > > the actual depth. Since i can distinguish between depth 15 (5551) and
> > > > 16 (5650), as well as between depth 24 (8888) and 30 (AAA2), where do i
> > > > get the information concerning the actual depth used from ?
> > >
> > > var->green.length
> >
> > So, on a 5551 more, i should get :
> >
> >   var->green.length + var->red.length + var->blue.length == 15
> >
> > right ?
> 
> Yes, sorry for being cryptic.  Only if (visual == truecolor ||
> visual == directcolor), otherwise color depth = var->green.length.  If you
> are using at least a 2.6.8 kernel, there is a new helper in
> drivers/video/fbmem.c that you can check out:
> 
> int fb_get_color_depth(struct fb_info *)

Yes, thanks, this will do nicely.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Sven Luther]

On Sun, Sep 12, 2004 at 06:11:01PM +0800, Antonino A. Daplas wrote:
> On Sunday 12 September 2004 18:04, Sven Luther wrote:
> > On Sun, Sep 12, 2004 at 05:32:44PM +0800, Antonino A. Daplas wrote:
> > > On Sunday 12 September 2004 16:42, Sven Luther wrote:
> > > > Now, another question which has me baffled. In set_par, i set the video
> > > > mode for the card, but i only seem to have access to the bpp, and not
> > > > the actual depth. Since i can distinguish between depth 15 (5551) and
> > > > 16 (5650), as well as between depth 24 (8888) and 30 (AAA2), where do i
> > > > get the information concerning the actual depth used from ?
> > >
> > > var->green.length
> >
> > So, on a 5551 more, i should get :
> >
> >   var->green.length + var->red.length + var->blue.length == 15
> >
> > right ?
> 
> Yes, sorry for being cryptic.  Only if (visual == truecolor ||
> visual == directcolor), otherwise color depth = var->green.length.  If you
> are using at least a 2.6.8 kernel, there is a new helper in
> drivers/video/fbmem.c that you can check out:
> 
> int fb_get_color_depth(struct fb_info *)

Another question now, left_margin and co, they are no more in picos value, but
in actual pixels, right ? and the pixclock field contains how much each pixel
is in picos.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Antonino A. Daplas]

On Sunday 12 September 2004 21:54, Sven Luther wrote:
> Another question now, left_margin and co, they are no more in picos value,
> but in actual pixels, right ? and the pixclock field contains how much each
> pixel is in picos.
>

Yes.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Sven Luther]

On Sun, Sep 12, 2004 at 06:11:01PM +0800, Antonino A. Daplas wrote:
> On Sunday 12 September 2004 18:04, Sven Luther wrote:
> > On Sun, Sep 12, 2004 at 05:32:44PM +0800, Antonino A. Daplas wrote:
> > > On Sunday 12 September 2004 16:42, Sven Luther wrote:
> > > > Now, another question which has me baffled. In set_par, i set the video
> > > > mode for the card, but i only seem to have access to the bpp, and not
> > > > the actual depth. Since i can distinguish between depth 15 (5551) and
> > > > 16 (5650), as well as between depth 24 (8888) and 30 (AAA2), where do i
> > > > get the information concerning the actual depth used from ?
> > >
> > > var->green.length
> >
> > So, on a 5551 more, i should get :
> >
> >   var->green.length + var->red.length + var->blue.length == 15
> >
> > right ?
> 
> Yes, sorry for being cryptic.  Only if (visual == truecolor ||
> visual == directcolor), otherwise color depth = var->green.length.  If you
> are using at least a 2.6.8 kernel, there is a new helper in
> drivers/video/fbmem.c that you can check out:
> 
> int fb_get_color_depth(struct fb_info *)

Ah, it seems this one didn't make it to 2.6.8, since i don't have such a
function. Will do : 

if (fix->visual == FB_VISUAL_TRUECOLOR || fix->visual == FB_VISUAL_DIRECTCOLOR)
	depth = var->green.length + var->red.length + var->blue.length;
else
	depth = var->green.length

instead. Hope this is ok.

Friendly,

Sven Luther


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: monitor detection through ddc/edid stuff.

[Antonino A. Daplas]

On Sunday 12 September 2004 22:36, Sven Luther wrote:
> if (fix->visual == FB_VISUAL_TRUECOLOR || fix->visual ==
> FB_VISUAL_DIRECTCOLOR) depth = var->green.length + var->red.length +
> var->blue.length;
> else
> 	depth = var->green.length
>
> instead. Hope this is ok.
>

Yes, that should cover most of the visuals.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php