The HDMI block on 2711 has a dedicate I2C module in order to support
SCDC and HDCP. Create a new I2C driver which implements DDC read and
SCDC that can be used by both the hdmi_2711 driver and the edid
middlware.
Remove the CHIPIT specific configuration which forced dummy edid and
hotplug on 2711. The preferred HDMI mode selection from EDID should now
work in the same manner as on Pi3.
Calling mmal_vc_shm from the constructor means that vcsm_init
is initialised very early. Should another user come along and
want to use export then it can't.
Move mmal_vc_shm init and exit calls to mmal_vc_component_create /
destroy so that other things can be created first, and reference
count calls so that it can be called for every component.
Wasn't handling the new bitmap based flag for ID correctly
in the send command function. Not picked up before as this
function is not used by many commands, and it was simply missed
Moved the command check to before the point where the ID bit is set.
Commands now use a bit set to specify that they include
a display_id parameter, rather than having two sets of
commands, one with and one without the display_id.
Makes things a lot easier.
Tested on Pi4 and Pi3 with older firmware to check backwards
compatibility. Seemed OK.
Previously, not able to run new tvservice app on firmware that
did not support the new commands. You could use old apps on new
firmware though!
This fixes this and forces use of old non-ID display commands
on older firmware.
Add basic support for deep color RGBA. Images can be uploaded/copied and
displayed via dispmanx but there is no support for converting to other
formats.
Argon 10bit YUV had been temporarily hacked in as a modified
YUV_UV format. Actually add it as a new image format at Scalerlib,
vc_image, IL, and MMAL levels.
NOTE: Dual HDMI mode is only enabled if hdmi_test | 0x2 != 0
The reason for conditionally enabling dual HDMI mode because this might
cause problems if force_hotplug is enabled. Instead of enabling one
display this would enable two displays. A proper configuration for
dual HDMI has yet to be designed.
Change the static state to arrays of state structures indexed by HDMI
core.
It compiles and both HDMI cores seem to work individually.
Concurrent display usage works with one display just displaying the HVS
background colour.
HDCP functions have NOT been updated. The code won't compile if
WANT_HDCP is enabled. HDCP isn't supported on Raspberry Pi and the 2711
HDCP functionality has changed so this would need re-writing anyway.
TODO:
* Create hdmi_primary instead of using C(hdmi_core) everywhere
* Fix issue where hotplug of HDMI0 causes missaligned exception in EOF
frame handler for core 0 - seems to only happen with logging enabled
and might be a long standing issue.
Minor string replacement so that
- raspberrypi_full gotes to start_x
- raspberrypi_debug goes to start_db
- raspberrypi goes to start
to match the ELF names. All others are left untouched.
Includes reporting it via gencmd version and mailbox service.
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.
