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: Thu, 26 Feb 2004 11:33:01 +1100 [thread overview]
Message-ID: <1077755580.22232.89.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.44.0402260014130.24952-100000@phoenix.infradead.org>
> Well now that we have one input api that can happen. Of course with
> graphics its much more diverse with what you can do. That is one of the
> reasons for so many graphics libraries. It would be really hard to write
> a one size fits all library when it comes to graphics.
Note that I am NOT talking about a graphics library. This has NO
BUSINESS doing any kind of rendering. It's only the userland interface
to the underlying kernel drivers as far as mode switching & geometry
is concerned. That's _ALL_. In the same was as libGL is the userland
interface to DRI, or iptables the userlnad interface to netfilter,
etc...
> By state machine I mean the physical hardware state. If it's hardware
> access then it should be in the kernel. Note I'm refering to mode setting
> not acceleration. Now EDID overrides per monitor model and saving the
> state to disk is different. That should be userland.
I agree. The HW access is done in kernel space. That's even true for
acceleration actually. You are mixing things. What I'm taking about
is exactly that: The userland library gets the various EDID & other
probing informations coming from the kernel drivers. It does the various
policy decisions on mode setting, it provides the API for userland to
deal with mode setting & monitor placement (what I call geometry)
and saving/restoring of configurations. The actual banging of the mode
to the HW is done by the kernel driver though. (The card specific back
end of the library probably builds either a mode description or a
register list and pass that to the kernel driver).
> I think we are fine for whats in the kernel. As for multiple head and
> geometry stuff its not that hard if done right. I have been using
> multi-head systems for years. I have multip desktop systems for years!!!
I have been using multi head systems for years and I've seen how good
it can be, but also a bunch of the pitfalls when trying to design a
driver for it. If it was that easy, we would have had the right support
in fbdev for ages. We don't.
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
WARNING: multiple messages have this Message-ID (diff)
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: [Linux-fbdev-devel] fbdv/fbcon pending problems
Date: Thu, 26 Feb 2004 11:33:01 +1100 [thread overview]
Message-ID: <1077755580.22232.89.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.44.0402260014130.24952-100000@phoenix.infradead.org>
> Well now that we have one input api that can happen. Of course with
> graphics its much more diverse with what you can do. That is one of the
> reasons for so many graphics libraries. It would be really hard to write
> a one size fits all library when it comes to graphics.
Note that I am NOT talking about a graphics library. This has NO
BUSINESS doing any kind of rendering. It's only the userland interface
to the underlying kernel drivers as far as mode switching & geometry
is concerned. That's _ALL_. In the same was as libGL is the userland
interface to DRI, or iptables the userlnad interface to netfilter,
etc...
> By state machine I mean the physical hardware state. If it's hardware
> access then it should be in the kernel. Note I'm refering to mode setting
> not acceleration. Now EDID overrides per monitor model and saving the
> state to disk is different. That should be userland.
I agree. The HW access is done in kernel space. That's even true for
acceleration actually. You are mixing things. What I'm taking about
is exactly that: The userland library gets the various EDID & other
probing informations coming from the kernel drivers. It does the various
policy decisions on mode setting, it provides the API for userland to
deal with mode setting & monitor placement (what I call geometry)
and saving/restoring of configurations. The actual banging of the mode
to the HW is done by the kernel driver though. (The card specific back
end of the library probably builds either a mode description or a
register list and pass that to the kernel driver).
> I think we are fine for whats in the kernel. As for multiple head and
> geometry stuff its not that hard if done right. I have been using
> multi-head systems for years. I have multip desktop systems for years!!!
I have been using multi head systems for years and I've seen how good
it can be, but also a bunch of the pitfalls when trying to design a
driver for it. If it was that easy, we would have had the right support
in fbdev for ages. We don't.
Ben.
next prev parent reply other threads:[~2004-02-26 0:49 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-23 0:53 fbdv/fbcon pending problems Benjamin Herrenschmidt
2004-02-23 0:53 ` 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-23 22:50 ` Benjamin Herrenschmidt
2004-02-24 1:19 ` James Simmons
2004-02-24 1:19 ` James Simmons
2004-02-24 8:37 ` Geert Uytterhoeven
2004-02-24 8:37 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2004-02-24 8:33 ` Benjamin Herrenschmidt
2004-02-24 8:33 ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2004-02-23 20:35 ` Thorsten Kranzkowski
2004-02-23 22:18 ` James Simmons
2004-02-23 22:18 ` James Simmons
2004-02-24 2:37 ` Otto Solares
2004-02-24 2:37 ` [Linux-fbdev-devel] " Otto Solares
2004-02-24 8:35 ` Geert Uytterhoeven
2004-02-24 8:35 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2004-02-24 17:21 ` James Simmons
2004-02-24 21:41 ` Otto Solares
2004-02-25 1:21 ` James Simmons
2004-02-25 1:21 ` [Linux-fbdev-devel] " James Simmons
2004-02-25 1:26 ` Benjamin Herrenschmidt
2004-02-25 1:26 ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2004-02-25 21:24 ` James Simmons
2004-02-25 21:24 ` [Linux-fbdev-devel] " James Simmons
2004-02-25 23:46 ` Benjamin Herrenschmidt
2004-02-25 23:46 ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2004-02-26 0:20 ` James Simmons
2004-02-26 0:20 ` [Linux-fbdev-devel] " James Simmons
2004-02-26 0:33 ` Benjamin Herrenschmidt [this message]
2004-02-26 0:33 ` Benjamin Herrenschmidt
2004-02-26 1:11 ` James Simmons
2004-02-25 1:29 ` Benjamin Herrenschmidt
2004-02-25 1:29 ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2004-02-25 2:18 ` Otto Solares
2004-02-25 2:18 ` [Linux-fbdev-devel] " Otto Solares
2004-02-25 2:33 ` Benjamin Herrenschmidt
2004-02-25 2:33 ` [Linux-fbdev-devel] " Benjamin Herrenschmidt
2004-02-25 3:15 ` Otto Solares
2004-02-25 3:15 ` [Linux-fbdev-devel] " Otto Solares
2004-02-25 11:41 ` Geert Uytterhoeven
2004-02-25 11:41 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2004-02-25 14:01 ` Sven Luther
2004-02-25 14:01 ` [Linux-fbdev-devel] " Sven Luther
2004-02-25 14:08 ` Geert Uytterhoeven
2004-02-25 14:08 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2004-02-25 21:43 ` James Simmons
2004-02-25 21:43 ` [Linux-fbdev-devel] " James Simmons
2004-02-26 19:40 ` Otto Solares
2004-02-26 19:40 ` [Linux-fbdev-devel] " Otto Solares
2004-02-26 19:45 ` James Simmons
2004-02-26 19:45 ` [Linux-fbdev-devel] " James Simmons
2004-02-26 20:12 ` Otto Solares
2004-02-26 20:12 ` [Linux-fbdev-devel] " Otto Solares
2004-02-25 21:42 ` James Simmons
2004-02-25 21:42 ` [Linux-fbdev-devel] " James Simmons
2004-02-26 15:26 ` Michel Dänzer
2004-02-26 15:26 ` Michel Dänzer
2004-02-24 5:57 ` Stuart Young
2004-02-24 5:57 ` Stuart Young
2004-02-24 8:36 ` Geert Uytterhoeven
2004-02-24 8:36 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2004-02-25 7:14 ` Stuart Young
2004-02-25 7:14 ` [Linux-fbdev-devel] " Stuart Young
2004-02-26 15:11 ` Michel Dänzer
2004-02-26 15:11 ` 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=1077755580.22232.89.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 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.