Commit graph

18 commits

Author SHA1 Message Date
William Wilgus
034b6d5bfb Remove some shadowed variables identified by -Wshadow
there are plenty more but these are the low hanging fruit

Change-Id: I86d9f4f56e8cd9b381d1bf6a6679cd58c6a4004d
2022-11-14 09:01:43 -05:00
Solomon Peachy
418169aff8 Revert "Remove YUV blitting functions and LCD modes"
This reverts commit fe6aa21e9e.

Change-Id: I8bb1e5d6c52ed1478002d2140ef494ec5d62b8e3
2022-10-13 11:08:06 -04:00
Aidan MacDonald
f8e968991d lcd: Move parameter handling calls to lcd-bitmap-common.c
No need to reimplement the same drawmode, getwidth, etc, calls
for each pixel format.

Change-Id: Ibbe32814f72e1492c190ba578cec303c1cf29b12
2022-10-09 22:07:49 +01:00
Aidan MacDonald
4f9e4ddb99 lcd: Consolidate drawpixel, drawline, and drawrect functions
All three functions are nearly identical regardless of the
LCD pixel format. Consolidate them into a generic version in
lcd-bitmap-common.c.

Change-Id: Iab13429ea27ea2b0150b9004535bd27d4a4121a0
2022-10-09 22:07:46 +01:00
Aidan MacDonald
4b8fe8acd1 lcd: Consolidate in-viewport clipping routines
In-viewport clipping code is duplicated across 8 files, making
it a chore to change anything related to clipping; refactor the
clipping logic into dedicated functions.

Change-Id: I4ab20bb3c59b0406098d0c7d23833025f17a320a
2022-10-09 22:07:44 +01:00
Aidan MacDonald
fe6aa21e9e Remove YUV blitting functions and LCD modes
None of this is needed now that mpegplayer is gone.

Change-Id: I360366db8513e4d988021e8d7b7d8eb09930efb8
2022-10-03 13:30:01 +01:00
Aidan MacDonald
f373c97c90 Define LCD_STRIDEFORMAT unconditionally
Instead of putting "#ifdef LCD_STRIDEFORMAT" at every usage of the
macro it's simpler to have config.h define LCD_STRIDEFORMAT to the
default of horizontal stride when the target leaves it unspecified.

Change-Id: Ib187012aad65ac678dbd837b1464a83bad722411
2022-09-30 10:42:49 +01:00
Aidan MacDonald
09cb3c7843 lcd: Remove HAVE_VIEWPORT_CLIP
This was only enabled for the mrobe500 and sansaconnect targets.
Most targets are therefore running without this "safety" measure,
and presumably we'd have noticed long ago if there was a problem.
So in all likelihood this is just a bunch of dead code that we
don't need to carry around.

Change-Id: I7d27701a38b1c2a985ee73fa6f277ad215d8d385
2022-09-27 14:13:15 +01:00
William Wilgus
c4156b1909 viewports, set flags to VP_DEFAULT_FLAGS
flags were getting un-initialized memory
it really didn't matter with the flags getting initialized
anyway
But once I added a new flag that didn't explicitly
set or clear the flag at init well here we are

set flags to VP_DEFAULT_FLAGS in viewport_set_defaults()

add the flags variable to the default vp's set to 0
(it was already initialized to 0 by bss, make it explicit)

Change-Id: I3a9a062455b4cf66d2b8c70fdf05402a5c0c091c
2022-04-17 10:59:56 -04:00
William Wilgus
cfeeb7889d Lcd save function pointer to frame buffer get_address_fn before loops
Calling multiple levels of indirection in a loop slows things down

Really these need to be rewritten to take a start and end address
like most of the rest of the codebase

But this is safer without having test hardware in hand

Change-Id: Idae7b92ee779d020ed7fcc9334e2d5a9c710e64d
2022-03-21 23:53:48 -04:00
William Wilgus
ed99b305a9 Revert "lcd framebuffer - Bugfix ensure proper alignment"
This reverts commit ffee661ab7.

Reason for revert: <INSERT REASONING HERE>
iAudio M5  `IRAM' overflowed by 48 bytes

Change-Id: Id808a72c6eacabc562d53eac8acd36b45f678a97
2021-03-24 18:44:35 +00:00
William Wilgus
ffee661ab7 lcd framebuffer - Bugfix ensure proper alignment
-- apparenty 0x4 aligned doesn't work properly

requires 0x8 alignment at least for the h10 20gb
but enabled for all arm processors

assign the default framebuffer to the default_vp as well

Change-Id: I0b76c30f2ddb5d6d2f7c6a132e4081aee58da17b
2021-03-24 18:22:01 +00:00
Franklin Wei
792f05f82a lcd: Wrap anonymous union initializer in braces
GCC 4.9.4 is apparently smart enough to compile this, but 4.4.4 is not.

Change-Id: I186f969cbad4c701936ab738f585efea07421d2e
2020-12-08 14:12:12 -05:00
William Wilgus
40e98a2e49 Whitespace cleanup on fb_viewport Rewrite
Change-Id: I24aac41c8abecf7b78a44d7f59e842b791be4563
2020-10-26 12:38:22 -04:00
William Wilgus
3237ae4a4f LCD core move buf ptr and address look up function viewport struct
I'm currently running up against the limitations of the lcd_draw functions
I want these functions to be able to be used on any size buffer not
just buffers with a stride matching the underlying device

[DONE] allow the framebuffer to be decoupled from the device framebuffer
[DONE need examples] allow for some simple blit like transformations
[DONE] remove the device framebuffer from the plugin api
[DONE}ditto remote framebuffer
[DONE] remove _viewport_get_framebuffer you can call struct *vp = lcd_set_viewport(NULL) and vp->buffer->fb_ptr

while remote lcds may compile (and work in the sim) its not been tested on targets

[FIXED] backdrops need work to be screen agnostic

[FIXED] screen statusbar is not being combined into the main viewport correctly yet

[FIXED] screen elements are displayed incorrectly  after switch to void*

[FIXED] core didn't restore proper viewport on splash etc.

[NEEDS TESTING] remote lcd garbled data

[FIXED] osd lib garbled screen on bmp_part

[FIXED] grey_set_vp needs to return old viewport like lcd_set_viewport

[FIXED] Viewport update now handles viewports with differing buffers/strides by copying to the main buffer

[FIXED] splash on top of WPS leaves old framebuffer data (doesn't redraw)
[UPDATE] refined this a bit more to have clear_viewport set the clean bit and have skin_render do its own screen clear
scrolling viewports no longer trigger wps refresh
also fixed a bug where guisyncyesno was displaying and then disappearing

[ADDED!] New LCD macros that allow you to create properly size frame buffers in you desired size without wasting bytes
(LCD_ and LCD_REMOTE_)
LCD_STRIDE(w, h) same as STRIDE_MAIN
LCD_FBSTRIDE(w, h) returns target specific stride for a buffer W x H
LCD_NBELEMS(w, h) returns the number of fb_data sized elemenst needed for a buffer W x H
LCD_NATIVE_STRIDE(s) conversion between rockbox native vertical and lcd native stride (2bitH)
test_viewports.c has an example of usage

[FIXED!!] 2bit targets don't respect non-native strides
[FIXED] Few define snags

Change-Id: I0d04c3834e464eca84a5a715743a297a0cefd0af
2020-10-26 12:28:48 -04:00
Amaury Pouly
d7871914ac Fix dangerous casts
On Windows 64-bit, the size of long is 32-bit, thus any pointer to long cast is
not valid. In any case, one should use intptr_t and ptrdiff_t when casting
to integers. This commit attempts to fix all instances reported by GCC.
When relevant, I replaced code by the macros PTR_ADD, ALIGN_UP from system.h

Change-Id: I2273b0e8465d3c4689824717ed5afa5ed238a2dc
2017-02-04 17:24:47 +01:00
Thomas Martitz
a1842c04f9 lcd-24bit: Introduce a 24-bit mid-level LCD driver
With LCD driver all calculation will be performed on RGB888 and the hardware/OS
can display from our 24bit framebuffer.

It is not yet as performance optimized as the existing drivers but should be
good enough.The vast number of small changes is due to the fact that
fb_data can be a struct type now, while most of the code expected a scalar type.

lcd-as-memframe ASM code does not work with 24bit currently so the with 24bit
it enforces the generic C code.

All plugins are ported over. Except for rockpaint. It uses so much memory that
it wouldnt fit into the 512k plugin buffer anymore (patches welcome).

Change-Id: Ibb1964545028ce0d8ff9833ccc3ab66be3ee0754
2014-06-21 00:15:53 +02:00
Thomas Martitz
0250be1d67 lcd-16bit: Split out some functions to lcd-color-common.c
An upcoming lcd-24bit.c driver will re-use a lot of code from the 16bit
drivers, so prepare for that.

Change-Id: I7bc7f6b992e5e3f4e0a0aa54dc08103ebb05315f
2014-06-21 00:13:58 +02:00