On Sat, 2004-09-11 at 06:19 +0100, Dave Airlie wrote:> >> > You're probably right, but it still doesn't follow that this driver must> > include all the fbdev and DRM code as well. Both fbdev and the DRM could> > use that driver, e.g., just like ide_cd and ide_disk use the IDE driver.> > I think your wrong, look at drivers/video/aty/radeon* and tell me what in> there is capable of being abstracted from the hardware, every file access> lowlevel registers for something or other, be it mode setting or I2C,

I'm not talking about abstracting much of anything, just moving(arbitration of) actual hardware access to a common lowlevel driver. Thethings you mentioned but snipped above, basically.

> now accessing lowlevels while the CP is running on a radeon is a one way> express to the land of the lockups...

No need to tell me that...

> (think mode setting a second head, while a 3d app is running on the first > head...), the lowlevel driver can provide a DRM and FB interface to fbcon > and 3d stuff, but the lowlevel driver needs all the code to do both...

I still haven't seen a complete logical chain leading to thatconclusion.

The lowlevel driver could provide all the necessary arbitration andsafety measures to prevent the two from stepping on each other's toes.

> The other thing I think some people are confusing is 2.4 fbdev and 2.6...

Again, not me.

> there is no console support in 2.6 fbdev drivers, it is all in the fbcon> stuff, so the fbdev drivers are only doing 2d mode setting and monitor> detection, [...]

Exactly. Why not leave it like that, and the DRM taking care of memorymanagement and rendering?

> 1. It doesn't matter where the code lives, fbdev/DRM need to start talking> about things

Agreed.

> 2. A generic interface between the two is probably going to be impossible,

Probably true, I'm not talking about a generic interface (although someparts might be generic, just like the DRM userspace interface).