Re: Vertical retrace interrupts?

["Michel Dänzer" <michel@daenzer.net>]

On Sam, 2003-02-01 at 00:34, Antonino Daplas wrote: 
> On Sat, 2003-02-01 at 05:32, Sven Luther wrote:
> > On Fri, Jan 31, 2003 at 08:12:16PM +0100, Michel Dänzer wrote:
> > > On Fre, 2003-01-31 at 19:35, Antonino Daplas wrote:
> > > > On Fri, 2003-01-31 at 19:24, Michel Dänzer wrote:
> > > > > 
> > > > > You don't need X to use the DRM, just some privileged client to
> > > > > initialize it.
> > > > 
> > > > You're right.  I just realized that since DRM already has an interrupt
> > > > handler, it is unwise for fbdev to install its own interrupt handler
> > > > too, as this will fatally lock up the machine when DRM and fbdev are
> > > > loaded simultaneously.
> > > > 
> > > > So, how about this?  Let fbdev have its own vblank ioctl, but for fbdev
> > > > drivers with a DRM counterpart, fbdev will just call the DRM
> > > > wait_vblank() and send_vbl_signals() functions.   Do you think this is
> > > > doable, I haven't examined the code thoroughly?  
> > > > 
> > > > The main goal is too avoid having 2 independent interrupt handlers for
> > > > one device.
> > > 
> > > A noble goal, but the framebuffer device would still need its own code
> > > when the DRM isn't active, so I'm afraid there's no way around code
> > > duplication, unless we could somehow factor out the common code for the
> > > two to share?
> 
> The fbdev driver will automatically load the DRM module when it refers
> to any exportable symbol of DRM.  We can also make the fbdev drivers
> specifically depend on DRM in Kconfig so users don't accidentally
> compile fbdev without its DRM counterpart.

I wonder if people will like having to build the DRM for a framebuffer
device... a solution where one component uses the other if it's there,
but works without it otherwise, might be better.

> The aim is not to avoid code duplication, although that is a plus, it's
> two independent handlers clashing and locking up the machine.

I'm not sure it would be that bad, but certainly suboptimal. :)


> > Could it not be that the fbdev sort of minimally intialize the DRM when
> > it is not already active ? After all, the fbdev knows as much, if not
> > more, than the X driver about the graphic chips state, especially if the
> > X driver is using the fbdev.
> 
> I was wondering about this to.  How much initialization is required?  Is
> it not enough to just load the DRM module?

No. The DRM_INST_HANDLER ioctl needs to be called to make the IRQs work,
and I suspect more needs to be done before that.

> Also, we have fbdev drivers that are incompatible with DRM, so having
> fbdev load DRM is like telling it to commit suicide :-)

Out of curiosity, is that about i8xx?


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com