From: "Michel Dänzer" <michel@daenzer.net>
To: James Simmons <jsimmons@infradead.org>
Cc: Sven Luther <luther@dpt-info.u-strasbg.fr>,
Jon Smirl <jonsmirl@yahoo.com>,
fbdev <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: video dir reorg
Date: 15 Jan 2003 22:38:31 +0100 [thread overview]
Message-ID: <1042666710.3186.40.camel@thor> (raw)
In-Reply-To: <Pine.LNX.4.44.0301150035470.23774-100000@phoenix.infradead.org>
On Mit, 2003-01-15 at 01:37, James Simmons wrote:
> > There is a response of linus in the mailing list archive about this, i
> > don't remember nor checked if it was only the first time, or not. I
> > think the objection was about complicate to supervise diffs.
>
> Yes. The DRI people want to keep there work seperate from us.
While I hope there will be some form of cooperation between framebuffer
devices and the DRM in the future, I do think they basically serve very
different purposes so I don't think merging them makes sense.
> > Also, i think the drm drivers should compile not only on linux, but on
> > other oses too (BSDs at least).
>
> That will be difficult. The VM layer to BSD is very very different from
> linux. There is no way they coudl use the same code set for both without
> making a mess.
Probably, but keeping all code separate for all supported OSs would be
at least as big a mess, so we share as much code as possible via a
template mechanism. The BSD specific parts aren't in the Linux kernel of
course.
> > Also, i believe some of the XFree86 guys don't like fbdevs.
>
> :-(
Luckily, those aren't part of the DRI project AFAICT. On the contrary,
several DRI developers have declared interest in supporting framebuffer
devices, and at least one of them is working on 'an embedded radeon 3d
driver that lives on top of fbdev' in Mesa CVS.
--
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: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
next prev parent reply other threads:[~2003-01-15 21:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-14 2:02 video dir reorg Jon Smirl
2003-01-14 9:13 ` Sven Luther
2003-01-14 17:22 ` Jon Smirl
2003-01-14 21:26 ` Sven Luther
2003-01-15 0:37 ` James Simmons
2003-01-15 9:39 ` Geert Uytterhoeven
2003-01-15 21:38 ` Michel Dänzer [this message]
[not found] ` <20030116035231.36507.qmail@web14910.mail.yahoo.com>
2003-01-16 10:38 ` Sven Luther
2003-01-16 20:14 ` Michel Dänzer
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=1042666710.3186.40.camel@thor \
--to=michel@daenzer.net \
--cc=jonsmirl@yahoo.com \
--cc=jsimmons@infradead.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=luther@dpt-info.u-strasbg.fr \
/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).