I looked through the 2.4 radeon driver and I see all
of the code for parsing the EDID blocks. This is a lot
of code and it is seldom used (compared to something
like an interrupt handler).
Somewhat complete I2C driver code exists in the KATOS
project.
http://www.core.binghamton.edu/~insomnia/gatos/katos/src/katos-0.5.tar.gz
These next thoughts just apply to 2.6, not 2.4.
There are a lot of things on the I2C bus on the these
cards: EDID, video capture, teletext, tv out and mpeg
decoding control, etc..
1) How about making the fb driver register itself as
an I2C bus so that it appears in /proc/bus/I2C? I've
never touched I2C code so I don't know what this
involves.
2) Making the card appear in /proc/bus/I2C makes it
easy to get to from user space. A user level app can
read the EDID info, diff it off against card
capabilities and IOCTL the new mode in. Maybe modify
fbset.
3) Doesn't the video hardware always power on to a
visible state? So setting an alternate mode can wait
until we can run user space apps. I'm not sure it is
worth all of the kernel code just to get a 50 line
display with valid EDID during the first few seconds
of boot.
4) Once we have access to the other devices maybe
people will write apps that use them.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
On Sun, 2003-08-17 at 08:32, Jon Smirl wrote:
I looked through the 2.4 radeon driver and I see all
of the code for parsing the EDID blocks. This is a lot
of code and it is seldom used (compared to something
like an interrupt handler).
Yup. Which is a reason, btw, why a think the radeon driver
should be split into multiple files (and possibly share
some code with aty128), but I haven't had time to play with
that much.
Somewhat complete I2C driver code exists in the KATOS
project.
http://www.core.binghamton.edu/~insomnia/gatos/katos/src/katos-0.5.tar.gz
These next thoughts just apply to 2.6, not 2.4.
There are a lot of things on the I2C bus on the these
cards: EDID, video capture, teletext, tv out and mpeg
decoding control, etc..
1) How about making the fb driver register itself as
an I2C bus so that it appears in /proc/bus/I2C? I've
never touched I2C code so I don't know what this
involves.
I don't much like the Linux i2c layer because I think it's bloated
and not very convenient to use, but if you want to go that way, then
it's ok ;) Whatever i2c API we expose, be it custom or via the linux
i2c layer...
2) Making the card appear in /proc/bus/I2C makes it
easy to get to from user space. A user level app can
read the EDID info, diff it off against card
capabilities and IOCTL the new mode in. Maybe modify
fbset.
Well... I'd rather have an in-kernel monitor "driver" module that
would access the EDID to provide a default mode, validate modes
etc... It could expose the raw EDID data via sysfs. We want proper
mode detection & probing at boot time. Note that the linux i2c
layer also allows for in-kernel clients, not only userland interface.
3) Doesn't the video hardware always power on to a
visible state? So setting an alternate mode can wait
until we can run user space apps. I'm not sure it is
worth all of the kernel code just to get a 50 line
display with valid EDID during the first few seconds
of boot.
Unfortunately, not all cards power on with a visible state... Well,
in most cases they do, and we have offb on powermac to use as a basic
text console (since we don't have VGA text mode), so we could eventually
have this transition done later on.
4) Once we have access to the other devices maybe
people will write apps that use them.
Maybe... I see your point in wanting to expose those i2c busses
to userland. I think it makes sense for things like teletext or tv out
control. But I still prefer having monitor & edid management be an
in-kernel driver (same for capture btw).
Ben.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
Il Sat, Aug 16, 2003 at 11:32:34PM -0700, Jon Smirl ha scritto:
Somewhat complete I2C driver code exists in the KATOS
project.
http://www.core.binghamton.edu/~insomnia/gatos/katos/src/katos-0.5.tar.gz
Cool. I'm coding something like this but I'm unable to get an ACK back
from the card. I'll look at this code and see if I can speak to my
board.
These next thoughts just apply to 2.6, not 2.4.
There are a lot of things on the I2C bus on the these
cards: EDID, video capture, teletext, tv out and mpeg
decoding control, etc..
1) How about making the fb driver register itself as
an I2C bus so that it appears in /proc/bus/I2C? I've
never touched I2C code so I don't know what this
involves.
Well, on 2.6 the device model will handle this pretty well. The devices
and the driver will show up in /sys/bus/i2c (sysfs).
2) Making the card appear in /proc/bus/I2C makes it
easy to get to from user space. A user level app can
read the EDID info, diff it off against card
capabilities and IOCTL the new mode in. Maybe modify
fbset.
Sure, we can expose EDID and other infos to user space. Maybe we can use
sysfs to set a new mode. I think that Greg KH is working on it.
Luca
--
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Windows NT: Designed for the Internet. The Internet: Designed for Unix.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
--- Kronos <kronos@kronoz.cjb.net> wrote:
quoted
Somewhat complete I2C driver code exists in the
KATOS
Cool. I'm coding something like this but I'm unable
to get an ACK back
from the card. I'll look at this code and see if
I can speak to my
board.
Post as soon as you get something working. No sense
duplicating effort, I can spend the time working on
standalone OpenGL.
Exporting EDID info through sysfs is probably the best
universal solution. That way we can have a standard
utility for setting modes instead of having a custom
solution for each card. It also be fun to play with
all of the other devices on my All-in-Wonder.
How is I2C code in Katos vs the 2.6 kernel? Katos is
four years old, I'm sure I2C support has improved
since then.
sysfs to set a new mode. I think that Greg KH is
working on it.
Point Greg at the Katos code, it may same him some
effort.
Does anyone know how other vendors handle the EDID/DDC
info? Do other cards use I2C? Will sysfs work as a
universal solution?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01