From: Jon S. <jon...@ya...> - 2003-08-17 06:34:05
|
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 jon...@ya... __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: Benjamin H. <be...@ke...> - 2003-08-17 08:07:43
|
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. |
From: Kronos <kr...@kr...> - 2003-08-17 15:47:00
|
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: kr...@kr... Home: http://kronoz.cjb.net Windows NT: Designed for the Internet. The Internet: Designed for Unix. |
From: Jon S. <jon...@ya...> - 2003-08-17 17:34:26
|
--- Kronos <kr...@kr...> wrote: > > 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 jon...@ya... __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: <sy...@sc...> - 2003-08-17 23:42:58
|
On Sun, Aug 17, 2003 at 10:34:07AM -0700, Jon Smirl wrote: > Does anyone know how other vendors handle the EDID/DDC > info? Do other cards use I2C? DDC2 uses I2C. There's aready a module that reads EDID via DDC2 in lm_sensors. It does require a working i2c adapter driver for the graphics card. matroxfb has the i2c driver included and lm_sensors has a driver fo= r voodoo3. Not sure about other cards but maybe that katos driver has something for ATI cards... In DDC1 mode the monitor transmits the EDID continuously with vsync actin= g as the clock. I don't think that any driver supports DDC1. --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |