Provide a mechanism to push an amended lens shading table
for when the user has changed the optics significantly.
It disables all ALCS and other manipulation of the table.
Provided table copies part of the OMAP3 style, taking a 64x64
grid of values. Each value is 3p5 fixed point representation,
same OMAP mode 6
0x6: Coded as 3-bit integer, 5-bit fraction Range from 0
to 7+31/32
Dry-run mode does the same processing as adding an overlay, but instead
of submitting the overlay to the kernel it saves the result in
"dry_run.dtbo" in the current directory. This feature is provided as a
diagnostic aid - when combined with the dtmerge command it allows one
to simulate the application of an overlay in the same manner as the
dynamic overlays are applied.
When the firmware applies an overlay it processes the fixups before
applying any parameters. Under Linux, parameters are handled by the
dtoverlay/dtparam application before submission to the kernel, which
is where the fixups are applied. As a consequence, fixups must be
modified if they refer to nodes which are renamed as the result of
using a parameter.
The process of updating the fixups (and symbols, in case the kernel
cares in the future) is too heavyweight to want the firmware to
do it unnecessarily, so internally use the fact that the fixups
have been applied as an indication that they no longer need to be
patched.
See: https://github.com/raspberrypi/linux/issues/2002
The DT parameter mechanism has long needed the ability to change node
names to allow the same overlay to be used repeatedly. Many such use
cases can be handled by simply patching the address part of the node
name when the node's "reg" property is written.
See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=178721
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Fixes#377.
Replace hard coded -j6 in make lines for -j `nproc`
to adopt the same number of jobs as processor cores.
Discussion abounds as to whether there is a better
multiple for CPU vs I/O speeds, but it's better than
always using 6.
If going through the "if (pState->netListen)" path,
sfd could potentially uninitialised before it is
used in fdopen.
Initialise to -1 and check it is >= 0 before use.
raspiyuv and raspividyuv are both shifting a fair amount
of data around and currently doing a copy through VCHI.
Enable zero copy to reduce this overhead. This does add
a dependency on VCSM, but that has been in the standard
builds for several years.
This fixes the problem where linker flags coming from top level
makefiles or environment are no longer respected anymore. This
is for example important to pass hardening flags to the build
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Opaque 32bit bitmask. Bottom 16 bits -> bayer_en.
Top 16 bits to ycbcr_en.
Critical blocks (eg Bayer/YUV input, resizes, and output
formatters) are masked out so the pipeline shouldn't totally
stall.
d35be767 relied on state->width/height being zero before setting
up the defaults, but the state structure is just on the stack
in main() and not initialised.
Initialise the whole structure to 0.
* very first draft for zoom, will make nice later, need to switch to other project
* zoom while video is capturing using i, o and r keys
* introduce constants and center zoom
* fixed reseting zoom in first zoom in
* some fixes from code review, not all for now
* removed wrong line
* added help for zoom change
* code review fixes
* renamed zoom command
On a CM with one OV5647 and one IMX219, the setup of whichever sensor
is camera 0 was taken for both sensors. That meant the default resolution
and EXIF headers were wrong for the second camera.
Add a new RaspiStill example scene (vcsm_square) that shows how to
render a camera buffer using a GLES2 shader to an frame-buffer texture
in shared memory. The texture is then modified by the CPU and drawn to
the window surface.
The example just draws an animated rectangle to demonstrate that the
pipeline is working. A more interesting example might use a GL
shader to do edge detect, pass the output to OpenVC and then render
or composite the result.
To run 'raspistill --gl --glscene vcsm_square'
Allocate a VCSM buffer using the dimensions supplied by the caller and
pass the vc mem-handle to 3D driver.
N.B. This API requires an update to the VideoCore firmware. If the update
is not present then eglCreateImageKHR will return an error if VCSM EGL
images are requested.
If HAVE_VCSM is defined then EGL is statically linked with libvcsm,
otherwise, libvcsm is loaded lazily as a plug-in when the first VCSM
EGL vcsm image target is requested.
Fixes building this file on 64bit arm
error: format '%lld' expects argument of type 'long long int', but argument 4 has type 'int64_t {aka long int}'
Signed-off-by: Khem Raj <raj.khem@gmail.com>
There is a potential race between the callback thread and the main test
thread when switching between asynchronous and synchronous modes.
The vchi_clnt_callback function tries to rapidly swallow zero-length
pong packets in asynchronous mode by looping in the callback until the
message queue is emptied. There is a danger that if the main test thread
switches to synchronous mode before the callback thread notices the
queue is empty that the callback thread will erroneously receive the
synchronous pong packet.
Remove the race by forcing the callback thread to leave dequeue loop
when a sync point (non-zero length reply) is received.
See: https://github.com/raspberrypi/linux/pull/1717
The raw video output is useful for image processing applications where
both motion vectors from encoder and image data are needed. This commit
adds a new --raw option which inserts a video splitter component between
camera's preview output and preview's input, which allows us to set
callback to capture raw video data into a file.
Another option --raw-format is introduced which allows us to choose
YUV420, RGB or grayscale format.
Parts of the code (video output format configuration and
splitter_buffer_callback()) come from RaspiYUV.c.
The splitter component is created only if the --raw option is specified.
Signed-off-by: Adam Heinrich <adam@adamh.cz>
Fixes
util/mmal_il.c:776:35: error:
implicit conversion from enumeration type 'enum OMX_BAYERORDERTYPE' to different enumeration type
'OMX_COLOR_FORMATTYPE' (aka 'enum OMX_COLOR_FORMATTYPE') [-Werror,-Wenum-conversion]
{MMAL_ENCODING_UNKNOWN, OMX_BayerOrderMax}
Signed-off-by: Khem Raj <raj.khem@gmail.com>
