From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: linux-fbdev-devel@lists.sourceforge.net,
Geert Uytterhoeven <geert@linux-m68k.org>
Cc: 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 17:50:47 +0800 [thread overview]
Message-ID: <200409051750.47987.adaplas@hotpop.com> (raw)
In-Reply-To: <Pine.GSO.4.58.0409051113060.28961@waterleaf.sonytel.be>
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?
Tony
next prev parent reply other threads:[~2004-09-05 9:50 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 [this message]
2004-09-05 10:13 ` Geert Uytterhoeven
2004-09-05 10:40 ` Antonino A. Daplas
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=200409051750.47987.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.