Re: Design for setting video modes, ownership of sysfs attributes

[Jon Smirl]

On Sun, 19 Sep 2004 14:48:38 +1000, Benjamin Herrenschmidt
<benh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 2004-09-19 at 08:12, Jon Smirl wrote:
> 
> > I'm still undecided if there needs to be a root priv daemon caching
> > the EDID and polling for a monitor change. EDID can be regenerated on
> > each request to change mode but it takes a few seconds. The root priv
> > daemon will dynamically link to card specific libraries. Initially I'm
> > going to add the functions to the mesa libraries but they may get
> > broken out later.
> 
> I'd rather have the kernel driver do the actual probing and provide
> the EDID or other infos for non-EDID capable monitors to userland (via
> hotplug maybe ?), though userland can then of course decide to
> "override" it and it's still userland that decodes it etc....
> 
> There are various cases of HW hackery involved in proper monitor
> detection that I'd rather not see in userland anymore. Also, some cards
> may provide an interrupt for detecting connector state change.

The design doesn't force DDC to be in the kernel or user space. You
can do it in either place.

In the driver I'm working on I use a standard in kernel i2c driver and
the i2c eeprom driver. This makes the EDID appear as a block in sysfs.
I've also take the monitor detection code from radeonfb and made it
into an IOCTL that the user space app calls.

The radeon driver has that extra code for intializing older DDC. That
can be handled generically in the I2C layer by writing a ddc driver
that is a superset of the eeprom driver.  I'd rather get that code
into a generic driver than repeat it in every video card driver.

-- 
Jon Smirl
jonsmirl@xxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/