video dir reorg

video dir reorg

[Jon Smirl]

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

Re: video dir reorg

[Sven Luther]

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

Re: video dir reorg

[Jon Smirl]

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

Re: video dir reorg

[Sven Luther]

On Tue, Jan 14, 2003 at 09:22:36AM -0800, Jon Smirl wrote:
> --- 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.?

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

Re: video dir reorg

[James Simmons]

> 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

Re: video dir reorg

[Geert Uytterhoeven]

On Wed, 15 Jan 2003, James Simmons wrote:
> > 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.

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

Re: video dir reorg

[Michel Dänzer]

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

Re: video dir reorg

[Sven Luther]

On Wed, Jan 15, 2003 at 07:52:31PM -0800, Jon Smirl wrote:
> --- Michel D?nzer <michel@daenzer.net> wrote:
> > 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.
> 
> Some areas of cooperation.....
> 
> 1) We have two drivers for the same hardware. They
> should be sharing the same include files describing
> the hardware.
> 2) Bug fixing, in some cases the same hardware bug
> would need to be fixed in two places.
> 3) State saving.  When the virtual terminal is changed
> is the complete state of the DRM driver saved? What if
> one of the other virtual terminals plays with 3D mode?

Currently, mostly the state saving code is in the X server anyway, so it
would not help here.

> 4) DDC and secondary reset support. I was looking at
> adding this to some of the framebuffer drivers. The X
> driver can't share this code.
> 5) General kernel config. The same peice of hardware
> appears in two different places.

Also, i believe that some discution about the sharing of fb memory and
other such may be in common.

Also, there could be the possibility (remote possiblity though) that the
fbdev driver author and the DRI author is the same person.

> There is no immediate reason for merging. I am just
> thinking about where this will be in three to five
> years. 
> 
> A more general question, what should be the
> capabilities of an in kernel video driver?
> 
> Required:
> 1) Complete state save on VT switch

This is done in the X server right now, altough i believe the fbdev also
does save its state on VT exit.

> 2) Security and control of DMA hardware

done in the drm module.

> Maybe required:
> 1) Reset and initialize hardware
> 2) Video mode change
> 3) Power saving

Currently duplicated in the X server and the fbdev driver. Mmm, maybe X
does not know about power saving, since i think the dri/ati people leave the
X VT  for fbdev before going in power saving mode.

> Not clear if better in user or kernel space:
> 1) copy, fill, blit, etc in current fb interface

This is common between X and fbdev. The architecture and the needs are
different, though, so i don't believe there will be anything shareable
here.

Also i thought Linus would not accept anything beyond console
acceleration stuff in the kernel anyway.

> Where is the right place to draw the link between
> kernel and user space for video drivers?

All accel except basic console driving code we have right now go to
userspace.

DMA, security control and irq handling need to be in the kernel though.

Friendly,

Sven Luther
> 
> 
> 
> 
> 
> =====
> 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: 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en

Re: video dir reorg

[Michel Dänzer]

On Don, 2003-01-16 at 04:52, Jon Smirl wrote: 
> 
> 1) We have two drivers for the same hardware. They
> should be sharing the same include files describing
> the hardware.

Might be a good idea.

> 2) Bug fixing, in some cases the same hardware bug
> would need to be fixed in two places.

Not sure about this, as I don't see much overlap, but it's plausible I
guess.

> 3) State saving.  When the virtual terminal is changed
> is the complete state of the DRM driver saved? What if
> one of the other virtual terminals plays with 3D mode?

A 3D driver (at least an OpenGL driver) needs to always keep track of
hardware state anyway, so after a VT switch it can just upload
everything it needs again.

> 4) DDC and secondary reset support. I was looking at
> adding this to some of the framebuffer drivers. The X
> driver can't share this code.

The framebuffer device could offer interfaces for these though?

> 5) General kernel config. The same peice of hardware
> appears in two different places.

For very different purposes. Anyway, couldn't the config hierarchy be
changed without moving code around, at least with Kconfig?


-- 
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: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en