Quote:
I just get back to Ubuntu on my smarttop.
I took XBMC sources and compiled them.
Now i've an awesome message :
"XBMC cannot run unless the screen colour depth is at least 24 bit. Please reconfigure your scren"
I add "ColorDepth 24" to /etc/X11/xord.conf.failsafe
I reboot and i've got the same message.
Any ideas ?
I'd suggest you fix XBMC: requiring 24 bit color depth is a rather odd restriction. Asking for ColorDepth 24 is also odd (32 would be better for the driver). You don't want the IPU driver to take you literally and give you a 24-bit display.
I'm also really quite sure that xorg.conf.failsafe has absolutely no effect for you anyway; you need to actually edit xorg.conf and if it's not there, create it. But setting a color depth here has no true effect either as it does not ask fbdev style drivers for that color depth.
But in the meantime you can recompile the kernel; drivers/video/mxc/mxc_ipuv3_fb.c line 1677 is a statement compiled out for the preprocessor. Just change #if 0 to #if 1 and the Smarttop (but not Smartbook) will run in 32-bit mode by default. It will scale the bit depth down the higher resolution you get to ensure that it can enable triple buffering for various reasons related to multimedia; so if you have a display
The reason we don't run this on by default is because we found 32-bit modes to confer a significant performance decrease in multimedia and in general the further away from 800x600 you get (1280x720 being the point where it gets more or less intolerable). You're also doubling the memory requirement for each screen. 1280x720 at 32-bit triple buffered would require 12MB where otherwise it would need 6MB (it's rounded up). 1440x900 means using 15MB instead of 8MB. That's pushing it. We only really have ~16MB available for the screen (otherwise we are taking memory away from the system and due to a quirk of running Xorg drivers on top of the Linux framebuffer subsystem, not reserving memory means a random placement of the framebuffer start which makes HDMI hotplug a crashable event). The only other solution to all the problems is reserve 32MB of memory for the framebuffer, but we'd end up having around 10MB of it basically unusable by anything in the system.. this is super dumb.
There should be a way to set the video mode on the kernel command line and afford yourself a better default bpp; try video=mxcdi0fb:bpp=32 *however* the mode searching functions we use to read the EDID absolutely do not have a way to be as introspective as we need and the HDMI driver shouldn't be peeking inside framebuffer drivers anyway. The only true solution is much tighter integration, which would only be possible via DRM/KMS.
It's much easier to recompile the kernel.
Login
Register
FAQ
Search