From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux Frame Buffer Device Development
<linux-fbdev-devel@lists.sourceforge.net>,
Andrew Morton <akpm@osdl.org>,
Linux Kernel Development <linux-kernel@vger.kernel.org>,
Thomas Winischhofer <thomas@winischhofer.net>
Subject: Re: [Linux-fbdev-devel] [PATCH 4/5][RFC] fbdev: Clean up framebuffer initialization
Date: Sun, 5 Sep 2004 18:40:10 +0800 [thread overview]
Message-ID: <200409051840.10202.adaplas@hotpop.com> (raw)
In-Reply-To: <Pine.GSO.4.58.0409051206180.28961@waterleaf.sonytel.be>
On Sunday 05 September 2004 18:13, Geert Uytterhoeven wrote:
> On Sun, 5 Sep 2004, Antonino A. Daplas wrote:
> > On Sunday 05 September 2004 17:16, Geert Uytterhoeven wrote:
> > > On Sat, 4 Sep 2004, Antonino A. Daplas wrote:
> > > > Currently, the framebuffer system is initialized in a roundabout
> > > > manner. First, drivers/char/mem.c calls fbmem_init(). fbmem_init()
> > > > will then iterate over an array of individual drivers' xxxfb_init(),
> > > > then each driver registers its presence back to fbmem. During
> > > > console_init(), drivers/char/vt.c will call fb_console_init(). fbcon
> > > > will check for registered drivers, and if any are present, will call
> > > > take_over_console() in drivers/char/vt.c.
> > > >
> > > > This patch changes the initialization sequence so it proceeds in this
> > > > manner: Each driver has its own module_init(). Each driver calls
> > > > register_framebuffer() in fbmem.c. fbmem.c will then notify fbcon of
> > > > the driver registration. Upon notification, fbcon calls
> > > > take_over_console() in vt.c.
> > >
> > > My main concern with this change is that it will be no longer possible
> > > to change initialization order (and hence choose the primary display
> > > for systems with multiple graphics adapters) by specifying
> > > `video=xxxfb' on the kernel command line.
> >
> > I see your point. But, can we use "fbcon=" setup options to choose which
> > fb gets mapped to what console? We already have fbcon=map:<option> so we
> > can choose which becomes the primary display. Granted the "fbcon=" setup
> > is currently broken, but if fixed, will that be a fair compromise?
>
> Yes, sounds fine.
Thanks.
>
> Just thinking of something else: right now it's possible to disable a fbdev
> by saying `video=xxxfb:off'. This can be useful if the fbdev driver doesn't
> work with your hardware. After you change, individual fbdev drivers will
> have to reimplement this theirselves in their __setup() functions.
Yes. I hope this doesn't bite too deep. If it does, I think we can let
fb_get_options() return an error when the "off" option is present. But I'm
not going to implement it unless we get a lot of complaints.
Tony
prev parent reply other threads:[~2004-09-05 10:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-04 3:08 [PATCH 4/5][RFC] fbdev: Clean up framebuffer initialization Antonino A. Daplas
2004-09-04 3:08 ` Antonino A. Daplas
2004-09-04 3:36 ` Thomas Winischhofer
2004-09-04 6:53 ` Antonino A. Daplas
2004-09-04 6:53 ` Antonino A. Daplas
2004-09-04 7:46 ` Otto Wyss
2004-09-04 12:37 ` Antonino A. Daplas
2004-09-05 9:16 ` Geert Uytterhoeven
2004-09-05 9:16 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2004-09-05 9:50 ` Antonino A. Daplas
2004-09-05 10:13 ` Geert Uytterhoeven
2004-09-05 10:40 ` Antonino A. Daplas [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=200409051840.10202.adaplas@hotpop.com \
--to=adaplas@hotpop.com \
--cc=adaplas@pol.net \
--cc=akpm@osdl.org \
--cc=geert@linux-m68k.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas@winischhofer.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 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.