On Sunday 05 September 2004 18:13, Geert Uytterhoeven wrote:

On Sun, 5 Sep 2004, Antonino A. Daplas wrote:

quoted

On Sunday 05 September 2004 17:16, Geert Uytterhoeven wrote:

quoted

On Sat, 4 Sep 2004, Antonino A. Daplas wrote:

quoted

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