Some devices(1-bit / 2-bit displays) have packed bit formats that
need to be unpacked in order to work on them at a pixel level.
This caused a few issues on 1 & 2-bit devices:
Greatly Oversized data arrays for bitmaps
Improper handling of native image data
Framebuffer data was near unusable without jumping through hoops
Conversion between native addressing and per pixel addressing
incurs extra overhead but it is much faster to do it
on the 'C' side rather than in lua.
Not to mention the advantage of a unified interface for the end programer
-------------------------------------------------------------------
Adds a sane way to access each pixel of image data
Adds:
--------------------------------------------------------------------
img:clear([color],[x1],[y1],[x2],[y2])
(set whole image or a portion to a particular value)
--------------------------------------------------------------------
img:invert([x1],[y1],[x2],[y2])
(inverts whole image or a portion)
--------------------------------------------------------------------
img:marshal([x1],[y1],[x2],[y2],[funct])
(calls funct for each point defined by rect of x1,y1 x2,y2
returns value and allows setting value of each point return
nil to terminate early)
--------------------------------------------------------------------
img:points([x1],[y1],[x2],[y2],[dx],[dy])
(returns iterator function that steps delta-x and delta-y pixels each call
returns value of pixel each call but doesn't allow setting to a new value
compare to lua pairs method)
--------------------------------------------------------------------
img:copy(src,[x1],[y1],[x2],[y2],[w],[h],[clip][operation][clr/funct])
(copies all or part of an image -- straight copy or special ops
optionally calls funct for each point defined by rect of
x1, y1, w, h and x2, y2, w, h for dest and src images
returns value of dst and src and allows setting value of
each point return nil to terminate early)
--------------------------------------------------------------------
img:line(x1, y1, x2, y2, color)
--------------------------------------------------------------------
img:ellipse(x1, y1, x2, y2, color, [fillcolor]
--------------------------------------------------------------------
Fixed handling of 2-bit vertical integrated screens
Added direct element access for saving / restoring native image etc.
Added more data to tostring() handler and a way to access individual items
Added equals method to see if two variables reference the same image address
(doesn't check if two separate images contain the same 'picture')
Optimized get and set routines
Fixed out of bound x coord access shifting to next line
Added lua include files to expose new functionality
Finished image saving routine
Static allocation of set_viewport struct faster + saves ram over dynamic
Cleaned up code
Fixed pixel get/set for 1/2 bit devices
-------------------------------------------------------------------------
Example lua script to follow on forums
-------------------------------------------------------------------------
Change-Id: I7b9c1fd699442fb683760f781021091786c18509
Also removes the sd_enable() function call. It was only used in
the debug screen on AMSv1 and not used at all on AMS v2.
For v1,obtain debug info in a struture passed to a dedicated
debug info function so that enabling and disabling the controller
isn't racy.
Change-Id: I7c44693bc2df5a1f16168b05b3abfe622f9584ce
This brings the source to upstream commit 506b073 (though I have made some
extra commits on top of that). Notably this includes a fix for a double-free
bug that I myself introduced upstream.
Change-Id: I02671586bbc34d63e05398ee971271fed42538cf
AUDIOHW_SETTING() defines number of decimals and step size.
This is taken into account in sound menu but ignored in WPS.
This was not a problem so far since all drivers used 0 decimal
places and step size equal 1.
Change-Id: I3466d6651c46a24cb5114eae1e1747293a76a1a6
When zoomed in, the original commit made a mono bitmap (a.k.a. text) always
have the red component set to 255. This would cause drawn text to always be
red. Fixed.
Change-Id: Iec06256a3a783948c60c70557de042b375224448
Rocker is configured with CST (China Standard Time) timezone
which is UTC+8. Time in RTC is stored in UTC.
Change-Id: Ib9c03e0f0a1d3ea3a69f238cb083809ea9386e2a
Add define in config file to enable RTC support in rockbox,
Fix time_menu.c to include radio.h only when tuner is present
Implement time setting function on linux (was empty stub)
Not tested.
Change-Id: I40e6c4a6c1b66ada9cf4e698e502e221d0fc44df
Actual / of underlying linux OS should not be available to user.
I am still not sure if implementation is correct. It doesn't
perform any relative path sandboxing for example.
Change-Id: Ic577a10f3947f6e950e2c4d03173f9f207395eb7
Original firmware update is provided as .upt file. This file
is actually ISO9660 image containing uBoot, kernel image and
UBIFS rootfs and additional control files. Installing
bootloader means patching UBIFS rootfs image.
Change-Id: Ica86d1189dc1d5f3131d2035d8b87c8d08ec36b5
If we use mips-rockbox-linux target resulting toolchain is
big endian. If we use mipsel-rockbox-linux build fail since
linux doesn't have separate archs for BE and LE mips. So we
tweak arch passed to linux-headers stage to fix this.
Change-Id: Iccae529998d1cd8f3429fa3b2ca4f030122f23bb
I can only assume in the course of the original conversion to fixed point
math in RbLua the fact that division by zero and NaN handling was to be
caught as a graceful exception by the floating point handler was overlooked.
As a result lua doesn't handle these exceptions and instead results in a
panic on the device.
This patch fixes this handling in the lexer for compile time Inf and Nan
results and in the luavm for runtime division by zero (Inf)
I missed the runtime exception of n%0 added checks for that as well..
Change-Id: I7746c087ea93678e5875f15ec6fe3f29f26bdb31
Fixes action fall through of select|release on fuze during FMS screen
allowing detection of unmapped button
Change-Id: I53945766263d8710f31621a4c9ad50cec7be2b0d
When long pressing PLAY/PAUSE and FM_MODE on devices that use the clip keymap
the volume changes in addition to toggling PLAY/PAUSE and SCAN/SEEK,this patch
removes the volume functionality as these devices provide dedicated volume
buttons
Change-Id: I3ab5af6da07900417c31c7a1036343b32b950e4e
Allows changing file sort options directly through context menu in the file browser
rather than having to exit the browser and go through General Settings>File_View
Change-Id: Iec124d512dcb934bd261b2144a699c23f536c165
lua would not return or set arbitrary file positions
file:seek("set", 0) worked file:seek("cur") worked
but setting an offset or file:seek("end") failed
I tracked this down to a bug checking the return of rb->lseek
on error lseek returns a negative number and returns the file
position otherwise, the function was checking for if(N) instead of
if(N < 0)
Fixed - limited size of lseek to size of signed LuaNumber
Fixed - io:lines() stopped after first line containing only a newline
instead of returning a blank line and continuing till EOF
this fixes file:read("*l") as well
Fixed - ssize_t for read() with error checking
Change-Id: Ie859b288fb8f6814f1b3ae30992ecf78f2669de7
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
