linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Sven Luther <luther@dpt-info.u-strasbg.fr>
Cc: "Michel Dänzer" <michel@daenzer.net>,
	"Fredrik Noring" <noring@nocrew.org>,
	"Linux Fbdev development list"
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Vertical retrace interrupts?
Date: 01 Feb 2003 07:34:07 +0800	[thread overview]
Message-ID: <1044055934.997.20.camel@localhost.localdomain> (raw)
In-Reply-To: <20030131213245.GA2905@iliana>

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.

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

> 
> 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?

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

Tony




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

  reply	other threads:[~2003-01-31 23:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-26  1:51 Vertical retrace interrupts? Fredrik Noring
2003-01-28 19:21 ` James Simmons
2003-01-30  2:34   ` Antonino Daplas
2003-01-30 11:45     ` Michel Dänzer
2003-01-30 23:22       ` Antonino Daplas
2003-01-31  0:16         ` Fredrik Noring
2003-01-31  1:35           ` Antonino Daplas
2003-01-31 11:24         ` Michel Dänzer
2003-01-31 11:55           ` Ville Syrjälä
2003-01-31 18:35           ` Antonino Daplas
2003-01-31 19:12             ` Michel Dänzer
2003-01-31 21:32               ` Sven Luther
2003-01-31 23:34                 ` Antonino Daplas [this message]
2003-02-01 15:45                   ` Michel Dänzer
2003-02-01 16:50                     ` Antonino Daplas
2003-02-12 20:21                       ` James Simmons
2003-02-12 20:08       ` James Simmons

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1044055934.997.20.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=luther@dpt-info.u-strasbg.fr \
    --cc=michel@daenzer.net \
    --cc=noring@nocrew.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).