This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#11615 - Dynamic screen size
Attached to Project:
Rockbox
Opened by Maurus Cuelenaere (mcuelenaere) - Tuesday, 07 September 2010, 20:10 GMT+2
Opened by Maurus Cuelenaere (mcuelenaere) - Tuesday, 07 September 2010, 20:10 GMT+2
|
DetailsThis patch converts LCD_{WIDTH,HEIGHT} into variables, allowing Rockbox to change screen size at runtime.
I've tried to make the changes as less intrusive as possible, but still, there will be some binsize increases. Most of the #if's were converted to C if()'s which should be functionally equivalent (and if the compiler is smart enough, no increase in binsize should occur). In order to use this, just define DYNAMIC_LCD_SIZE in your target config and compile without plugins (if the preprocessor spits errors, try clearing ENABLEDPLUGINS in your Makefile). What still needs to be done: * figure a way out how to compile several rockbox logos into the binary and choose the correct one at runtime * do something about the hacks in apps/bitmaps/SOURCES and apps/settings_list.c * get the Android port working 
dynamic-screen-size.diff
(31 KiB)
b/apps/bitmaps/native/SOURCES | 18 ++++ b/apps/debug_menu.c | 20 +++- b/apps/gui/skin_engine/skin_fonts.h | 6 - b/apps/main.c | 1 b/apps/plugin.c | 6 - b/apps/recorder/bmp.c | 9 +- b/apps/recorder/keyboard.c | 7 - b/apps/screen_access.c | 8 + b/apps/screen_access.h | 2 b/apps/settings_list.c | 8 - b/firmware/bidi.c | 4 b/firmware/drivers/lcd-16bit.c | 18 +++- b/firmware/export/config.h | 8 + b/firmware/export/lcd.h | 2 b/firmware/export/scroll_engine.h | 4 b/firmware/font.c | 17 +--- b/firmware/screendump.c | 65 ++++++++++----- b/firmware/scroll_engine.c | 22 ++++- b/firmware/target/hosted/android/lcd-android.c | 103 +++++++++++++----------- b/firmware/target/hosted/sdl/lcd-bitmap.c | 106 +++++++++++++------------ 20 files changed, 268 insertions(+), 166 deletions(-) |
This task depends upon
1) why the changes to apps/recorder/bmp.c? Seems the end result is the same?
2) ditto firmware/bidi.c ?
3) scroll engine... we aren't memory constrained on these targets so lets just set LCD_SCROLLABLE_LINES to something massive like 64 or so?
4) built in bitmaps: we could load them at runtime instead of compile time with a nice function to grab the right size (i.e <image name>.widthxheightxdepth.bmp )
I think I've freed up the skin engine which could have caused big problems so I'm going to apply this now and see how it goes (come on irc if you can :) )
- scroll engine is totally stuffed
- loads backdrops and skins with the widthxheightxdepth extension so builds will need to have all the cabbie theme files for the dimensions we want to support.
I've only fixed the sdl app for now... "--display <width>x<height>" on the command line will set the size. sims still seem to work but I'm not sure if it is correct.
to test it with the themes "cp -R backdrops wps /usr/local/share/rockbox" from your rockbox tree
2) same reason (allocation is on-stack this time though)
3) why not just allocate this dynamically? That way, there are no limits to run into in the future and it shouldn't result in a large binsize increase (talking about firmware/scroll_engine.c changes)
4) I was thinking of modifying bmp2rb to output an array of possible images, but dynamically loading them at runtime seems OK too
P.S.: your apps/gui/skin_engine/skin_parser.c change looks unrelated + you have some whitespace changes in apps/plugin.c
3) do you mean LCD_SCROLLABLE_LINES should be dynamically alloced based on the screen size? or properly dynamically allocated as needed? the first seems a bit pointless because you still have a artificial limit (so using a hardcoded large value is just as good and simpler).
4) we don't want to load too many images into the binary if we can avoid it, what could be fun is loading them all into the end of the *audiobuffer* region and then copying the one which is actually used to some buffer_alloced() block so the ram is reclaimed.
the skin_parser change is relevant, (It needs a comment). skin images are loaded from a directory with the same name as the skin file (i.e cabbiev2.wps -> wps/cabbiev2/) now with the above changes we could be loading cabbiev2.60x480x16.wps but we want the images to still be in the wps/cabbiev2 folder.. so that change does this.
I think we should package cabbiev2 separate, somehow. How about we put cabbiev2 into libcabbiev2.so (either libcabbiev2 which has it for all dimensions, or one libcabbiev2.XXXxYYYxZZ.so for each) and extract that separatenly, possibly to the sdcard directly? Or we make it so that the right cabbiev2 is downloaded on the first run?
I thought we really didnt want to be downloading anything on first run? Althoughnot having to package the fonts into the zip would be very helpful
4) INIT_ATTR & friends could be used for that, but if loading the bitmaps at runtime is an easier way out I won't disagree (there would be a need for default bitmaps compiled into the binary though, so Rockbox still is "usable" without any additional files).
I'm for the "download the correct default theme at first start"-idea, if we don't want to waste binsize by putting all possible resolutions in the APK (not sure how big that would be?).
with all the cabbie files (all screen sizes and depths so more than required) and all fonts, rockbox.apk ends up at about 9MB which is too big. however having to download 5MB of fonts/themes on first run sucks just as much.
very busy week at work so unlikely to be able to touch this till Wednesday night :(
http://jdgordon.info/rockbox/rockbox.apk is prebuilt with a manually hacked rockbox.zip so it works. it contains most of the big fonts and all cabbie files. comes to about 7MB which is probbaly too big, we can work out how to fix that later.
scrolling is broken but otherwise looks good (scrolling is broken on sim also)
I'd really like to commit this in the next few days, so comments welcome. This does disable some plugins again but I really dont think it is a big deal (people that actually care about the missing plugins can disable the config option.) I'm going to look into fixing the plugins later.
Otherwise this looks fine (also see my comments on the mailing list).
Will look at it later.
+#if !defined(HAVE_DYNAMIC_LCD_SIZE) && \
+ (CONFIG_PLATFORM != (PLATFORM_HOSTED|PLATFORM_ANDROID))
+ lcd_framebuffer = &_lcd_framebuffer[0][0];
+#endif
hunk to firmware/target/hosted/android/lcd-android.c
You've also left some DEBUGF statements in lcd-bitmap-common and lcd-android.c
And the "lcd_framebuffer = malloc(sizeof(fb_data) * lcd_width * lcd_height);" line in lcd-android.c can be moved into the HAVE_DYNAMIC_LCD_SIZE #ifdef (you overwrite it later on anyways).
Anyway, if the alloc'ing of the framebuffer in lcd-android.c is properly excluded on #ifdef HAVE_DYNAMIC_LCD_SIZE, there should be no need to have that special case for Android.
it looks like a bunch of other lcd drivers need fiddling because of the lcd_framebuffer arrray->pointer change which is mildly annoying... i'll get it done over the weekend hopefully
Changed to only enable dynamic code for targets with HAVE_DYNAMIC_LCD_SIZE. Other targets are (should be) unaffected.
sdlapp (with dynamic size) builds and runs. sansac200, ipodvideo and archosplayer (without dynamic) all build, haven't run them yet.
A few malloc calls still remain.