Sascha Hauer wrote: > On Fri, Oct 22, 2010 at 06:53:17PM +0200, Juergen Beisert wrote: > > This patch mostly rewrites all parts of /drivers/video/fb.c. As it > > changes the API to the drivers, it must be done in one step to keep the > > repository bisectable. But to do it in one step makes the patches itself > > unreadable. > > > > So, I decided to do it in a few steps, only for the review. All patches > > marked with a "step n of m" should be merged, prior the final commit into > > the repository. > > > > This step brings in the required functions for dynamic videomode > > selection at runtime, but keep the old functions untouched (the new ones > > are commented out). > > > > This is patch 1 of 7 to keep the repository bisectable. > > > > Signed-off-by: Juergen Beisert <jbe@xxxxxxxxxxxxxx> > > --- > > drivers/video/Kconfig | 23 +++++ > > drivers/video/fb.c | 251 > > +++++++++++++++++++++++++++++++++++++++++++++++++ include/fb.h | > > 40 ++++++++ > > 3 files changed, 314 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > > index 7a89a3f..e6ecfc8 100644 > > --- a/drivers/video/Kconfig > > +++ b/drivers/video/Kconfig > > @@ -5,6 +5,29 @@ menuconfig VIDEO > > > > if VIDEO > > > > +comment "runtime options" > > + > > +config VIDEO_DELAY_ENABLING > > + bool "Delayed enabling" > > + help > > + Say 'y' here to delay enabling video output. This is useful to first > > + fill the framebuffer (splash screen for example) prior enabling the > > + video device. > > + This entry adds the "enable" parameter to the video device, to > > enable + or disable video output at runtime. > > + > > +config VIDEO_DELAY_INIT > > + bool "Delayed initialization" > > + select VIDEO_DELAY_ENABLING > > + help > > + If the platform supports more than one video mode say 'y' her to > > delay + the initialization of the video device until any kind of > > barebox's + shell code sets up the correct mode at runtime. > > + This entry adds the "mode" parameter to the video device, to > > setup + the desired videomode prior enabling it at runtime. > > I think the framebuffers should *never* be activated by the setup code > and should be explicitely initialized by doing a 'fb0.enable=1' on the > command line. Okay. It "should not" is a new policy to barebox. Currently the framebuffer is activated immediately (except the platforms you changed already). I just wanted to keep this behaviour. > This way we have the most flexibility. We can enable > the framebuffer when we actually need it, we can draw a splash screen > before enabling it so that we do not have a black screen before we draw > an image. Also, the environment can decide to leave the framebuffer > disabled because the kernel will draw another screen a second later. If > necessary, the environemt can do a fb0.display="sharp-whatever" before > activating it. And we do not need any kconfig options for this. Okay. We can change the default behaviour for all platforms using graphic in this way. I will try to include it in the next series. jbe -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | Phone: +49-8766-939 228 | Vertretung Sued/Muenchen, Germany | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
