Any kernel not using bcm2708_fb as the FB driver is likely to
fail the FBIODMACOPY ioctl that vcdbg tries to use to access
the hidden 16MB of RAM behind the peripheral space.
Remove the error message as it drops back to using /dev/mem
instead anyway.
Adds new video formats XRGB8888 and XBGR8888 as no-alpha
versions of ARGB8888 and ABGR8888.
The MMAL types of MMAL_ENCODING_RGB32 and MMAL_ENCODING_BGR32
were already defined but didn't map onto anything. The functionality
could be replicated by setting the per-plane alpha on the HVS,
but it makes some more sense to support it explicitly.
FKMS wants to add the relevant modes for DPI and DSI displays,
and the VEC.
Plumbing required to expose the PV timings info for these displays,
and then added the mailbox call.
The current maximum response size for a non-bulk VCHI transfer is
4092 bytes. Increase the GENCMD buffer size to match this.
Additionally, ensure that the buffer is null terminated and use
the size defined in in the vcgencmd_defs header instead of
hard-coding this.
Under certain circumstances, the Linux file system write behind caching
gets so much data to write in one go that is causes frames to be dropped.
The current fflush is not sufficient as that only flushes the C library
caches, not the Linux filesystem caches.
This fix forces data to be written to media as soon as it arrives, using
fdatasync().
Note, currently it's conditional on the --flush command line parameter.
The addition of a NAL flag appears to have broken timestamps with
large buffers. This simplifies the 'if' around timestamps and takes
the NAL change in to account.
Also fixed up some bad code formatting after the if statement. Yes, I know.
Fix a couple of FIXME's where no error was reported should a
bulk receive fail to start. The buffer header got forwarded
to the app with length 0, so the client was left with little
idea what had gone wrong.
If no output file is defined, then only the preview port is active
and it doesn't get the frame rate programmed based on the command
line (0 is used for variable FPS).
Set the fps based on the command line for the preview port.
Supports native builds on aarch64 machines.
Supports making a 64-bit build via either cross compiling, or on
aarch64 machines.
Both options require the addition of --aarch64 to the command line,
otherwise 32-bit libraries will be built.
Cross compiling requires the aarch64-linux-gnu- compile tools to
be installed (packages gcc-5-aarch64-linux-gnu and g++-aarch64-linux-gnu
on Ubuntu).
Observed on
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=189830&start=25#p1432589
The raspivid command line
raspivid --raw-format rgb --raw foo.rgb -o foo.h264
actually saved YUV data to foo.rgb as the --raw option reset
raw-format to YUV mode.
Renumber the enums so that YUV is 0, and use the fact the state
structure is memset to 0 (and therefore YUV) to avoid the
-raw parser needing to change the format at all.
The camera apps were using vcos_getmicrosecs64 which
was in turn using gettimeofday. This means timelapse code
goes very wrong when the date/time is changed while the
timelapse is being done.
Moved to a scheme based on clock_gettime(CLOCK_MONOTONIC_RAW)
which is not affected by underlying clock changes.
This is a modified version of that provided by shizukachan
We are having to limit this to widths < 1280 due to an as yet
unfixed firmware issue. I've taken a quick look - its not
obvious what is going on.
This involved:
Moving GPS code to own file so can be used in all apps
Adding option in apps to apply GPS data to annotation
Enabled with the -gps flag on command line plus -a 2 to turn on
application annotation.
Also involved adding a file for helper functions.
As a indirect result, some features are now available
in the xxxxyuv apps that were originally only in the
non-yuv versions.
Also involved adding a file for helper functions.
As a indirect result, some features are now available
in the xxxxyuv apps that were originally only in the
non-yuv versions.
All the cam apps were duplicating the same code for outputing camera
settings (e.g. exposure), so have moved it to the CamControl file
so we now only have one set.
Also fixed up a couple of missing bad error returns that were not being
translated correctly from the MMAL error to ints.