mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Juergen Beisert <jbe@pengutronix.de>
To: barebox@lists.infradead.org
Subject: [PATCHv2] Add dynamic video initialization to barebox
Date: Tue, 26 Oct 2010 13:31:36 +0200	[thread overview]
Message-ID: <1288092708-5187-1-git-send-email-jbe@pengutronix.de> (raw)

Currently barebox uses a fixed videomode setup. Everything is compiled in.
This change adds the possibility to select a videomode according to a
connected display at runtime. The current behaviour is still present if not
otherwise configured. If configured for runtime setup, initialization of the
video hardware will be delayed until the required videomode will be selected
from the shell code. If more than one videomode is supported by the platform,
running the 'devinfo' command on the framebuffer device shows the supported
videomode list. After selecting the videomode, the output can be enabled.

On my hardware I can connect a regular monitor, which supports more than one
videomode. The runtime setup sequence looks like that:

tx28:/ devinfo framebuffer0
base  : 0x00000000
size  : 0x00000000
driver: framebuffer

 Video/Mode info:
   Video output not enabled
 Current video mode:
   No video mode selected yet
 Supported video mode(s):
   'VGA'
   'SVGA'
   'XGA'
   'SXGA'
 Parameters:
           cdepth = 16
             mode = <NULL>
           enable = <NULL>

tx28:/ framebuffer0.mode=SVGA
tx28:/ bmp splash.bmp
tx28:/ framebuffer0.enable=1

After the last command the monitor shows the splash screen.

This is revision 2 of this patch stack.
 - enabling the video output is now always required to get a picture
 - driver specific data can now be added on a per videomode base
 - documentation is adapted to the new behaviour

jbe


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

             reply	other threads:[~2010-10-26 11:31 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-26 11:31 Juergen Beisert [this message]
2010-10-26 11:31 ` [PATCH 01/12] Separate framebuffer platformdata and the videomode Juergen Beisert
2010-10-26 11:31 ` [PATCH 02/12] Add more flags for sync control Juergen Beisert
2010-10-26 11:31 ` [PATCH 03/12] Bring in dynamic videomode selection at runtime Juergen Beisert
2010-11-01 13:47   ` Sascha Hauer
2010-11-15 10:04     ` Juergen Beisert
2010-11-17  8:27       ` Sascha Hauer
2010-11-01 14:16   ` Sascha Hauer
2010-11-15 10:08     ` Juergen Beisert
2010-10-26 11:31 ` [PATCH 04/12] Remove the old videomode functions Juergen Beisert
2010-10-26 11:31 ` [PATCH 05/12] Add verbose framebuffer device info Juergen Beisert
2010-10-26 11:31 ` [PATCH 06/12] Adapt the existing imx fb driver to support runtime videomode selection Juergen Beisert
2010-10-26 11:31 ` [PATCH 07/12] Adapt the existing imx-ipu " Juergen Beisert
2010-10-26 11:31 ` [PATCH 08/12] Add a video driver for S3C2440 bases platforms Juergen Beisert
2010-11-01 14:41   ` Sascha Hauer
2010-11-15 11:35     ` Juergen Beisert
2010-11-17  8:36       ` Sascha Hauer
2010-10-26 11:31 ` [PATCH 09/12] STM378x: Add video driver for this platform Juergen Beisert
2010-10-26 11:31 ` [PATCH 10/12] Remove variable size restrictions Juergen Beisert
2010-10-26 11:31 ` [PATCH 11/12] Add doxygen documentation to the framebfuffer code Juergen Beisert
2010-10-26 11:31 ` [PATCH 12/12] Provide more driver specific data in a videomode Juergen Beisert
2010-11-01 13:19 ` [PATCHv2] Add dynamic video initialization to barebox Sascha Hauer
2010-11-01 13:29   ` Eric Bénard
2010-11-01 14:18     ` Sascha Hauer
2010-11-15  9:57   ` Juergen Beisert
2010-11-15 10:25     ` Belisko Marek
2010-11-17  8:44       ` Sascha Hauer
2010-11-18  8:18         ` Belisko Marek
2010-11-18 10:09           ` Sascha Hauer
2010-11-17  8:43     ` Sascha Hauer

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=1288092708-5187-1-git-send-email-jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=barebox@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox