On Thu, 2004-04-29 at 11:07, Otto Solares wrote:
> On Thu, Apr 29, 2004 at 12:26:41AM +0200, Michel Dänzer wrote:
> > Why? The purpose of the DRM lock is arbitration and state management
> > between DRM clients. It's not necessarily connected to direct hardware
> > access.
> 
> Agree, fbdev is too low-level to use the lock.

Yes and No. We _DO_ need an arbitration mecanism between fbdev (or
whoever changes the mode) and other "clients" like DRI and the DRI
lock would be well suited for that too. Right now, you can very easily
lockup the whole box solid by just sending a mode switch down to the
fbdev while DRI is active.

And since the model we are aiming too is just that: sending mode
switches at any time and have all clients adapt properly, we need a
solution for that. One of the reasons is hotplug displays. The hotplug
is equivalent to a mode switch in this regard and will happen whatever
the card is doing.
 
> > A small low-level driver could handle this, which both the framebuffer
> > device and the DRM use. Linus has proposed this approach, and I must say
> > I like it.
> 
> That should be fbdev without fbcon.

Yes, except that I'd like to see most of the mode list processing moved
to userland. But I agree that the low level driver could/should be fbdev
without the accel hooks. Those are really fbcon specific accel hooks,
I would even like to separate it from the fbdev completely. In that sense,
fbcon would just be another "client" of the framebuffer. But in this regard
too, we need some arbitration.

Ben.




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id�66&op=click