linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: James Simmons <jsimmons@infradead.org>
Cc: Otto Solares <solca@guug.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: Wed, 25 Feb 2004 12:26:43 +1100	[thread overview]
Message-ID: <1077672403.1084.45.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.44.0402250118210.24952-100000@phoenix.infradead.org>


> > We have now with 2.6 a good input and sound layers.  Just by fixing
> > the graphics layer many interesting userland projects could be born.
> 
> I agree. The graphics layer is the last frontier.

It is. What we really need right now is a proper way to get the mode
lists. but more than that. We need to expose per-output detection data,
mapping of CRTCs to outputs, and a way to change that mapping & trigger
a re-probe. All of that can probably not be done in a completely card
neutral way.  

I've started working on a userland library taking care of managing
the "environment", that is the various screens & heads, their modes,
the geometry (relative screen positions), and such. I haven't gone
very far yet, but the idea is ultimately to have the entire mode
setting go through this library. That include proper interface to
the kernel drivers (whatever they become, fbdev is what we have to
day but that may change) and that also probably means moving some
of the monitor management down to userland.

This library will also be responsible to broadcast, possibly via
D-BUS, events like screen hotplug and mode changes. We are thinking
about interfacing the fd.o xserver on this among others. It will
not do anything about rendering though.

That leads to another issue which is arbitration at the low level
driver between rendering & mode switching. That should be done by
the kernel driver at some point, we need to merge the mode setting
driver (fbdev) and the command queue diver (DRI). Probably moving 
some of the higher level mode management out of the kernel driver
down to this userland library.

Anyway, it's all mostly ideas at this point. I'm trying to get an
API out with a test implementation on top of fbdev. At which point
we'll be able to move further.

Ben.




-------------------------------------------------------
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  1:42 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 [this message]
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
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=1077672403.1084.45.camel@gaston \
    --to=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 \
    --cc=solca@guug.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).