From: Jon Smirl <jonsmirl@yahoo.com>
To: Eric Anholt <eta@lclark.edu>
Cc: DRI <dri-devel@lists.sourceforge.net>,
fb-devel <linux-fbdev-devel@lists.sourceforge.net>
Subject: DRM and Framebuffer conflicts
Date: Thu, 23 Oct 2003 09:24:54 -0700 (PDT) [thread overview]
Message-ID: <20031023162454.31377.qmail@web14903.mail.yahoo.com> (raw)
In-Reply-To: <1066889583.643.2.camel@leguin>
--- Eric Anholt <eta@lclark.edu> wrote:
> I've converted the DRM to old-style attachment. I haven't tested with
> radeonfb to see if it actually fixed it (netboot linux kernels are
> annoying to prepare), but my radeon and sis cards continued to work. If
> someone could test with radeonfb and the latest DRM, that would be
> great.
I think we need to implement both the old and new schemes and fallback to the
old one if radeonfb is present. DRM also needs to add code marking resources in
use which will also conflict with framebuffer. DRM needs to mark the resources
when framebuffer isn't around to be compatible with hotplug.
It would flow something like this:
new style probe
if (new probe has device)
mark resources in use
else
do old style probe
The framebuffer drivers that have DRM parallels need to implement the same
code. That way it won't matter what order things get loaded.
A second possibility would be to implement a tiny stub for just attaching to
the PCI ID and resources. Then framebuffer and DRM could both share the stub.
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
parent reply other threads:[~2003-10-23 16:24 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <1066889583.643.2.camel@leguin>]
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=20031023162454.31377.qmail@web14903.mail.yahoo.com \
--to=jonsmirl@yahoo.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=eta@lclark.edu \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/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).