All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michel Dänzer" <michel@daenzer.net>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: James Simmons <jsimmons@infradead.org>,
	Sven Luther <luther@dpt-info.u-strasbg.fr>,
	fbdev <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: video dir reorg
Date: 16 Jan 2003 21:14:10 +0100	[thread overview]
Message-ID: <1042748050.11409.35.camel@thor> (raw)
In-Reply-To: <20030116035231.36507.qmail@web14910.mail.yahoo.com>

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

      parent reply	other threads:[~2003-01-16 20:14 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
     [not found]           ` <20030116035231.36507.qmail@web14910.mail.yahoo.com>
2003-01-16 10:38             ` Sven Luther
2003-01-16 20:14             ` Michel Dänzer [this message]

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=1042748050.11409.35.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.