Commit graph

4 commits

Author SHA1 Message Date
Amaury Pouly
7fddc2327b fuze+: add lcd debug screen (display kind)
Change-Id: I08ffcfb8e4cf516aae1c23740eedf80d2cfcea41
2012-12-26 02:38:56 +01:00
Amaury Pouly
d32891fa59 fuze+: change rendering scheme, do not rely on generic framebuffer and implement rect updating and yuv blitting correctly.
Now lcd_framebuffer is the only framebuffer in the system. We still use a ARM-buffered buffer
which serve as an intermediate buffer for copying, to accomodate the requirement of the controller.
We implement lcd_update_rect() properly using this new scheme (this requires two little quirks),
this allows to implement lcd_blit_yuv with the right semantic (bypasses the framebuffer). YUV to RGB
conversion is still done in software but the DCP CSC should be able to do that but the hardware rotation
scheme is not the same as our software so it will require some tricks.

Change-Id: I0752e9c2f1a705d2e6a6010084e1f150965d8370
2012-01-27 20:08:33 +01:00
Amaury Pouly
8cadb587e8 fuzeplus: fix lcd-target.h (LCD_FRAMEBUF_ADDR must point to lcd_framebuffer and not FRAME)
Change-Id: Ia1f16f9b8e3041517b60336c06aedd40dfd2be12
2012-01-15 02:29:30 +01:00
Michael Sevakis
95e6043d5e Convert remaining memframe LCDs that can be convert to common code.
Massage the way it interfaces a bit to make things more flexible.
The chroma_buf scheme on Sansa Connect and Creative ZVx calling the
lcd_write_yuv420_lines implementation in lcd-as-memframe.S with five params
with a chroma buffer that the function can't use wouldn't work anyway so just
have them use the stock implementation (really, how was that working?).


git-svn-id: svn://svn.rockbox.org/rockbox/trunk@31335 a1c6a512-1295-4272-9138-f99709370657
2011-12-16 23:40:39 +00:00