On 6/28/05, Dave Airlie <[EMAIL PROTECTED]> wrote: > > > > > I can also predict the probable outcome on kernel submission if we use > > the stub to start building suspend/resume in two different places - > > DRM and fbdev. > > My stub isn't your totally fb in the stub, we are only going to put > initially interrupt handling, suspend/resume, PCI driver handling and some > arbitration into the stub... this is similiar to what was going into the > vga class stuff before, myself and benh have been talking this over > and believe there is no point having mode setting or monitor detection in > a lowlevel stub,
I'm starting to think that a stub is a really bad idea. It is going to make it easier to build multiple implementations of the same features in the different drivers. The net result will probably be an increase in the architectural chaos of video drivers. > > You cannot do intelfb modesetting in the kernel, it needs VBE calls no-one > is going to put those near the kernel hopefully... The callgate for getting to mode setting has to be in the kernel. That provides a standard API and a secure user-root transition. After the call is in the kernel each driver can choose to satisfy the call in-kernel or use something like call_userhelper() to do the work in user space. > > I'm trying to decide if the stub framework is worth the hassle of making > generic or whether doing it for each driver is probably less trouble... -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
