Hi,
This issue is currently specific to the Ubuntu LEB for Origen and is also being discussed under the LP bug #906762 [1]. Writing to a wider audience to get views of others who might have come across similar situation before.
Currently the LCD FB is registered as /dev/fb0 and the HDMI FB is registered as /dev/fb1. While booting up, by default /dev/fb0 is used as the primary display device and the output is routed accordingly. To use the HDMI display, we need to update /etc/X11/xorg.conf (and this needs to be updated every time we update the file-system.)
If we don't enable support for LCD FB, the display comes on HDMI during boot-time, but again that is not desirable considering we want to use both the LCD and HDMI with the same kernel binary.
Is there any way where we can force the default frame-buffer (whether to choose /dev/fb0 or /dev/fb1) during boot-time, might be through some kernel command-line options?
[1] https://bugs.launchpad.net/linaro-landing-team-samsung/+bug/906762
Hi,
I wasn't sure what the "default framebuffer" you meant. so, would you clarify a bit?
At Wed, 15 Feb 2012 10:56:06 +0530, Tushar Behera wrote:
Currently the LCD FB is registered as /dev/fb0 and the HDMI FB is registered as /dev/fb1. While booting up, by default /dev/fb0 is used as the primary display device and the output is routed accordingly. To use the HDMI display, we need to update /etc/X11/xorg.conf (and this needs to be updated every time we update the file-system.)
can you clarify what you mean by the primary display device, and who's output is routed to there? is it the kernel log, some boot splash, android or X?
If we don't enable support for LCD FB, the display comes on HDMI during boot-time, but again that is not desirable considering we want to use both the LCD and HDMI with the same kernel binary.
Is there any way where we can force the default frame-buffer (whether to choose /dev/fb0 or /dev/fb1) during boot-time, might be through some kernel command-line options?
it seems like fbcon has a kernel param for tty mapping. does it help?
taken from: Documentation/fb/fbcon.txt
fbcon=map:<0123>
This is an interesting option. It tells which driver gets mapped to which console. The value '0123' is a sequence that gets repeated until the total length is 64 which is the number of consoles available. In the above example, it is expanded to 012301230123... and the mapping will be:tty | 1 2 3 4 5 6 7 8 9 ... fb | 0 1 2 3 0 1 2 3 0 ...
('cat /proc/fb' should tell you what the fb numbers are)
One side effect that may be useful is using a map value that exceeds the number of loaded fb drivers. For example, if only one driver is available, fb0, adding fbcon=map:1 tells fbcon not to take over the console.
Later on, when you want to map the console the to the framebuffer device, you can use the con2fbmap utility.
BTW, last I checked, android uses /dev/fb0 directly; meaning framework source code has the string "/dev/fb0" planted deep inside. so under the android framework, it always displays to the device (LCD or HDMI) the kernel detected first.
my two cents,
Hi Yasushi,
On 02/15/2012 11:44 AM, Yasushi SHOJI wrote:
Hi,
I wasn't sure what the "default framebuffer" you meant. so, would you clarify a bit?
For all display related activities, kernel uses the first framebuffer it registers (/dev/fb0). I was referring to this as the 'default framebuffer' and was thinking of a way to force the kernel to use /dev/fb1 instead.
At Wed, 15 Feb 2012 10:56:06 +0530, Tushar Behera wrote:
Currently the LCD FB is registered as /dev/fb0 and the HDMI FB is registered as /dev/fb1. While booting up, by default /dev/fb0 is used as the primary display device and the output is routed accordingly. To use the HDMI display, we need to update /etc/X11/xorg.conf (and this needs to be updated every time we update the file-system.)
can you clarify what you mean by the primary display device, and who's output is routed to there? is it the kernel log, some boot splash, android or X?
Sorry for making this a little confusing ...
'primary display device' should be read as 'default framebuffer' as explained above.
And looking at the problem a bit more, it seems more like a configuration option of Android or X to decide which framebuffer they use for display.
If we don't enable support for LCD FB, the display comes on HDMI during boot-time, but again that is not desirable considering we want to use both the LCD and HDMI with the same kernel binary.
Is there any way where we can force the default frame-buffer (whether to choose /dev/fb0 or /dev/fb1) during boot-time, might be through some kernel command-line options?
it seems like fbcon has a kernel param for tty mapping. does it help?
taken from: Documentation/fb/fbcon.txt
fbcon=map:<0123>
This is an interesting option. It tells which driver gets mapped to which console. The value '0123' is a sequence that gets repeated until the total length is 64 which is the number of consoles available. In the above example, it is expanded to 012301230123... and the mapping will be:tty | 1 2 3 4 5 6 7 8 9 ... fb | 0 1 2 3 0 1 2 3 0 ...
('cat /proc/fb' should tell you what the fb numbers are)
One side effect that may be useful is using a map value that exceeds the number of loaded fb drivers. For example, if only one driver is available, fb0, adding fbcon=map:1 tells fbcon not to take over the console.
Later on, when you want to map the console the to the framebuffer device, you can use the con2fbmap utility.
BTW, last I checked, android uses /dev/fb0 directly; meaning framework source code has the string "/dev/fb0" planted deep inside. so under the android framework, it always displays to the device (LCD or HDMI) the kernel detected first.
Thanks for this info. That answers some of my questions.
my two cents,
-
Tushar Behera -
Yasushi SHOJI