From: Jon Smirl <hidden> Date: 2003-01-14 02:02:11
Does it make sense to try merging the DRM drivers into
the video directory? Maybe something like this:
video -- empty except for Kconfig file
video/console -- generic fbconsole code
video/DRM -- generic DRM code
video/ati -- ati drivers (drm & fb)
video/i810 -- i810 drivers (drm & fb)
etc.....
This would allow the merging of the DRM and FB
hardware device drivers over time. Switching VTs
should be coordinated with saving 3D state.
Even with out merging DRM should the console driver be
split out from the hardware drivers?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
From: Sven Luther <hidden> Date: 2003-01-14 09:13:19
On Mon, Jan 13, 2003 at 06:02:07PM -0800, Jon Smirl wrote:
Does it make sense to try merging the DRM drivers into
the video directory? Maybe something like this:
video -- empty except for Kconfig file
video/console -- generic fbconsole code
video/DRM -- generic DRM code
video/ati -- ati drivers (drm & fb)
video/i810 -- i810 drivers (drm & fb)
etc.....
This would allow the merging of the DRM and FB
hardware device drivers over time. Switching VTs
should be coordinated with saving 3D state.
Even with out merging DRM should the console driver be
split out from the hardware drivers?
I think Linus rejected this last time James submitted it.
That said, there is a trend with the DRI people that now want to use the
drm modules to do memory allocation or something such, which was, i
think, previously done in the X server.
Maybe this would be of interrest to a fbdev<->drm merging James did
speak about some time ago.
Friendly,
Sven Luther
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
From: Jon Smirl <hidden> Date: 2003-01-14 17:22:36
--- Sven Luther <luther@dpt-info.u-strasbg.fr> wrote:
I think Linus rejected this last time James
submitted it.
Didn't the last patch just move the DRM directory from
driver/char into the video directory.?
This could be done in two steps. First split out the
fb console driver files into their own directory and
then sort out the hardware drivers more. Then if the
DRM merge gets ok'd everything will be ready.
In the config system I don't like how you have to
enable driver support for the same piece of hardware
in two different places. I also don't like looking in
two different places for the source to drivers for the
same hardware.
What is Linus' take on merging a card's fb and drm
drivers into a single module in the long run?
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
From: Sven Luther <hidden> Date: 2003-01-14 21:26:56
On Tue, Jan 14, 2003 at 09:22:36AM -0800, Jon Smirl wrote:
quoted hunk
--- Sven Luther <luther@dpt-info.u-strasbg.fr> wrote:
quoted
I think Linus rejected this last time James
submitted it.
Didn't the last patch just move the DRM directory from
driver/char into the video directory.?
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.
This could be done in two steps. First split out the
fb console driver files into their own directory and
then sort out the hardware drivers more. Then if the
DRM merge gets ok'd everything will be ready.
In the config system I don't like how you have to
enable driver support for the same piece of hardware
in two different places. I also don't like looking in
two different places for the source to drivers for the
same hardware.
What is Linus' take on merging a card's fb and drm
drivers into a single module in the long run?
Well, the problem is that the fb drivers are maintained by us, and the
drm drivers are maintained by the DRI.
Also, i think the drm drivers should compile not only on linux, but on
other oses too (BSDs at least).
Also, i believe some of the XFree86 guys don't like fbdevs.
Friendly,
Sven Luther
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
From: James Simmons <hidden> Date: 2003-01-15 00:38:31
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.
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.
Also, i believe some of the XFree86 guys don't like fbdevs.
:-(
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
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.
I think Sven meant the userspace part of DRM. Of course the actual kernelspace
implementation differs.
quoted
Also, i believe some of the XFree86 guys don't like fbdevs.
:-(
Yes indeed :-(
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by: Take your first step towards giving
your online business a competitive advantage. Test-drive a Thawte SSL
certificate - our easy online guide will show you how. Click here to get
started: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0027en
From: Michel Dänzer <hidden> Date: 2003-01-15 21:38:36
On Mit, 2003-01-15 at 01:37, James Simmons wrote:
quoted
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.
quoted
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.
quoted
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