Re: video dir reorg

[Sven Luther <luther@dpt-info.u-strasbg.fr>]

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