From: Sven Luther <sven.luther@wanadoo.fr>
To: linux-fbdev-devel@lists.sourceforge.net
Subject: Re: monitor detection through ddc/edid stuff.
Date: Sun, 12 Sep 2004 10:42:40 +0200 [thread overview]
Message-ID: <20040912084240.GA21563@pegasos> (raw)
In-Reply-To: <20040911153625.GA3507@dreamland.darkstar.lan>
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
next prev parent reply other threads:[~2004-09-12 8:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-10 11:16 monitor detection through ddc/edid stuff Sven Luther
2004-09-10 11:44 ` Sven Luther
2004-09-11 15:36 ` Kronos
2004-09-11 16:52 ` Jon Smirl
2004-09-12 8:42 ` Sven Luther [this message]
2004-09-12 9:32 ` Antonino A. Daplas
2004-09-12 10:04 ` Sven Luther
2004-09-12 10:11 ` Antonino A. Daplas
2004-09-12 10:31 ` Sven Luther
2004-09-12 13:54 ` Sven Luther
2004-09-12 21:00 ` Antonino A. Daplas
2004-09-12 14:36 ` Sven Luther
2004-09-12 21:16 ` Antonino A. Daplas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040912084240.GA21563@pegasos \
--to=sven.luther@wanadoo.fr \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).