linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Otto Solares <solca@guug.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: James Simmons <jsimmons@infradead.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: fbdv/fbcon pending problems
Date: Tue, 24 Feb 2004 20:18:08 -0600	[thread overview]
Message-ID: <20040225021808.GB17390@guug.org> (raw)
In-Reply-To: <1077672591.978.49.camel@gaston>

On Wed, Feb 25, 2004 at 12:29:52PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2004-02-25 at 12:21, James Simmons wrote:
> > > Sure, hopefully fbdev drivers became more 'intelligent', with just a
> > > 
> > > echo "1024x768x16-75" > /sys/class/fbdev/0/geometry
> > > 
> > > they will compute internally the timings or get it from EDID and
> > > glad the user with something correct for the hardware.
> > > 
> > > cat /sys/class/fbdev/0/modes
> > > 
> > > will give you the modes supported by the card.
> > 
> > Yes.
> 
> Note that "the modes supported by the card" means nothing.
> 
> They depend on something fundamentally dynamic, which is what is
> connected to what output, mixed with some card-spcific limitations
> (like bandwidth limitations when using 2 very big monitors, vram
> limitations, etc...)
> 
> You can not really know a-priori what modes will be available for
> sure. You can provide a list of modes that are considered as valid
> for a given output, but the whole mode setting scheme cannot be
> anything else but non-deterministic. You setup a global configuration,
> send it down the driver, and obtain a new configuration which may or
> may not be what you asked for.

Hmm, how does winxp and macosx get their respectives video modes,
what is missing in fbdev for that? MacOSX always gives you valid modes
including refresh rates per adaptor/monitor, WinXP always give you valid
modes and valid refresh rates for the video card, you actually
'Apply' to test, most of the time it simply works.

> I'm trying to address the API issues as part of the userland library
> I'm talking about in the other email. The actual interface to the
> kernel driver should ultimately be hidden, and eventually private
> between card-specific kernel driver and card-specific module in
> the userland API.

Great! i think your idea is great, does that library will be xserver
dependant or will be an independent lib so others projects like mine
could benefit from it?  Any bits somewhere?  This alone could boom
and revolutionize the graphics solutions for linux.  A step in the
right direction for "World Domination" in the desktop field.

-otto



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

  reply	other threads:[~2004-02-25  2:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-23  0:53 fbdv/fbcon pending problems Benjamin Herrenschmidt
2004-02-23 15:52 ` Johannes Stezenbach
2004-02-23 18:59 ` James Simmons
2004-02-23 22:50   ` Benjamin Herrenschmidt
2004-02-24  1:19     ` James Simmons
2004-02-24  8:37     ` Geert Uytterhoeven
2004-02-24  8:33       ` Benjamin Herrenschmidt
2004-02-23 20:35 ` Thorsten Kranzkowski
2004-02-23 22:18   ` James Simmons
2004-02-24  2:37 ` Otto Solares
2004-02-24  8:35   ` Geert Uytterhoeven
2004-02-24 17:21     ` [Linux-fbdev-devel] " James Simmons
2004-02-24 21:41     ` Otto Solares
2004-02-25  1:21       ` James Simmons
2004-02-25  1:26         ` Benjamin Herrenschmidt
2004-02-25 21:24           ` James Simmons
2004-02-25 23:46             ` Benjamin Herrenschmidt
2004-02-26  0:20               ` James Simmons
2004-02-26  0:33                 ` Benjamin Herrenschmidt
2004-02-26  1:11                   ` [Linux-fbdev-devel] " James Simmons
2004-02-25  1:29         ` Benjamin Herrenschmidt
2004-02-25  2:18           ` Otto Solares [this message]
2004-02-25  2:33             ` Benjamin Herrenschmidt
2004-02-25  3:15         ` Otto Solares
2004-02-25 11:41           ` Geert Uytterhoeven
2004-02-25 14:01             ` Sven Luther
2004-02-25 14:08               ` Geert Uytterhoeven
2004-02-25 21:43             ` James Simmons
2004-02-26 19:40             ` Otto Solares
2004-02-26 19:45               ` James Simmons
2004-02-26 20:12                 ` Otto Solares
2004-02-25 21:42           ` James Simmons
2004-02-26 15:26           ` [Linux-fbdev-devel] " Michel Dänzer
2004-02-24  5:57 ` Stuart Young
2004-02-24  8:36   ` Geert Uytterhoeven
2004-02-25  7:14     ` Stuart Young
2004-02-26 15:11       ` [Linux-fbdev-devel] " Michel Dänzer

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=20040225021808.GB17390@guug.org \
    --to=solca@guug.org \
    --cc=benh@kernel.crashing.org \
    --cc=geert@linux-m68k.org \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /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).