All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: fb-devel <linux-fbdev-devel@lists.sourceforge.net>,
	Paul Mackerras <paulus@samba.org>
Subject: Re: Some thoughts on Rage128/Radeon EDID
Date: 17 Aug 2003 10:05:59 +0200	[thread overview]
Message-ID: <1061107558.641.14.camel@gaston> (raw)
In-Reply-To: <20030817063234.75420.qmail@web14910.mail.yahoo.com>

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

  reply	other threads:[~2003-08-17  8:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-17  6:32 Some thoughts on Rage128/Radeon EDID Jon Smirl
2003-08-17  8:05 ` Benjamin Herrenschmidt [this message]
2003-08-17 14:45 ` Kronos
2003-08-17 17:34   ` EDID through sysfs Jon Smirl
2003-08-17 23:36     ` Ville Syrjälä

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=1061107558.641.14.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=jonsmirl@yahoo.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=paulus@samba.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.