mirror of
https://github.com/Rockbox/rockbox.git
synced 2025-11-09 13:12:37 -05:00
1f63604e2c
Lcd_update rect was hanging during horizontal screen update x = 238 and width = 2 which was within the bounds of the screen, this seems to be a weird corner case but more testing needs done. Update_rect now properly bounded between 0 - screen w/h --Cleaned up code Pixels in x are now multiples of 4. Datasheet states: ------------------------------------------------------------------------------------------- WORD_LENGTH=0 implies the input frame buffer is RGB 16 bits per pixel. DATA_FORMAT_16_BIT field indicates if the pixels are in RGB 555 or RGB 565 format. Limitations: — BYTE_PACKING_FORMAT [3:0] should be 0x3 or 0xC if there is only one pixel per word. — If there are two pixels per word, BYTE_PACKING_FORMAT [3:0] should be 0xF and H_COUNT will be restricted to be a multiple of 2 pixels. and WORD_LENGTH=3 indicates that the input frame-buffer is RGB 24 bits per pixel (RGB 888). If BYTE_PACKING_FORMAT [3:0] is 0x7, it indicates that there is only one pixel per 32-bit word and there is no restriction on H_COUNT. Limitations: — If BYTE_PACKING_FORMAT [3:0] is 0xF, it indicates that the pixels are packed, i.e. there are 4 pixels in 3 words or 12 bytes. In that case, H_COUNT must be a multiple of 4 pixels. ------------------------------------------------------------------------------------------- We are using 16 bits per pixel and byte_packing = 0xF but device crashes with multiple of 2 pixels Behaviour can be verified with plugin - oscilloscope, Horizontal mode device hangs as indicator reaches right of screen Change-Id: I1445f5334f4e7fe59304c65c76b47d0daa0614b2 |
||
|---|---|---|
| .. | ||
| arm | ||
| coldfire | ||
| hosted | ||
| mips | ||
| sh | ||