linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@yahoo.com>
To: Ian Romanick <idr@us.ibm.com>, Egbert Eich <eich@pdx.freedesktop.org>
Cc: dri-devel <dri-devel@lists.sourceforge.net>,
	mesa3d-dev <mesa3d-dev@lists.sourceforge.net>,
	fb-devel <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: RE: [Dri-devel] Memory management of AGP and VRAM
Date: Sun, 9 May 2004 09:45:14 -0700 (PDT)	[thread overview]
Message-ID: <20040509164514.17651.qmail@web14922.mail.yahoo.com> (raw)
In-Reply-To: <409BFE5B.5020308@us.ibm.com>

Can you run grub or lilo on these machines?

Also, these is no rule saying a device driver can't have several tables of _init
register values that can be used to set the mode on a primary monitor at boot. I
would just like to see all of the code that does DDC decoding and modeline
computations moved to user space. When you add up that code there is about 40K
of it in the fbdriver and about 50K in the radeon driver. When the fbdev drivers
start probing for multiple heads, TV support, etc that code is going to get even
larger. Since the code is used only rarely (in kernel terms) this code should be
in user space instead of the driver.

I've also proposed that if you really, really want to you could do the DDC
probing the in driver at boot and mark all of the code _init. Then the user
space code would take over after that. Note that I'm talking about early
userspace (initrd) timeframe, not normal user space.

--- Ian Romanick <idr@us.ibm.com> wrote:
> Egbert Eich wrote:
> 
> > However chipset probing/display device probing and mode setting isn't
> > required to live in kernel space. Portability and system stability 
> > arguments speak against it. In fact only Apple MAC users seem to
> > advocate this idea to be able to an initial video mode on their
> > systems.
> 
> Allow me to speak up for users of IBM pSeries hardware or Sun SPARC 
> hardware.  Users of those systems face exactly the same issues as Mac 
> users.  I imagine most embedded systems will be in the same boat.  Being 
> forced to use a serial console for early boot messages is so 1980's. ;)
> 
> The kernel doesn't need to have support for everything, but I think it's 
> important to have at least minimal support.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Mesa3d-dev mailing list
> Mesa3d-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 


-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

  reply	other threads:[~2004-05-09 16:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <A98078D7EF5BEA4D8D8FD797FFBBC75F0742A3A0@fmsmsx402.fm.intel.com>
     [not found] ` <16539.63659.810291.931565@xf11.fra.suse.de>
2004-05-07 21:23   ` RE: [Dri-devel] Memory management of AGP and VRAM Ian Romanick
2004-05-09 16:45     ` Jon Smirl [this message]
2004-05-09 21:27       ` Holger Waechtler
2004-05-09 21:53         ` Holger Waechtler
2004-05-10  7:59       ` [Mesa3d-dev] " Alan Cox
2004-05-10 16:16       ` [Linux-fbdev-devel] " James Simmons
2004-05-11 16:50       ` Egbert Eich
2004-05-11 18:48         ` [Linux-fbdev-devel] " James Simmons

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=20040509164514.17651.qmail@web14922.mail.yahoo.com \
    --to=jonsmirl@yahoo.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=eich@pdx.freedesktop.org \
    --cc=idr@us.ibm.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=mesa3d-dev@lists.sourceforge.net \
    /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).