dtoverlay_find_pins_for_device looks up a device node by its label,
verifies that it is enabled, and opens the list of pinctrl nodes.
dtoverlay_next_pin retrieves the details of the next pin (beginning
with the first) from the relevant pinctrl nodes, return 1 if found
or 0 if there are no more pins.
The dtoverlay library will leak an allocation of 4 bytes for every
application of an overlay that attempt to set a "reg" property that
doesn't already exist, e.g. the old i2c-gpio overlay. This is an
error case since it won't do what the user expects, but that's no
excuse to leak.
vcilcs requries libbrcmEGL, libbrcmGLESv2 and libkhrn_client which have
only 32 bit versions currently, so disable it when building aarch64
Signed-off-by: Dagg Stompler <daggs@gmx.com>
Drops
host_applications/android/apps/vidtex
interface/mmal/openmaxil
interface/mmal/client(/brcmjpeg)
as they aren't directly supported and need further fixup for 64bit.
Where 32bit values are passed down to the VPU, these need to
be mapped into a lookup table within the client. Any pointers
that happen to be within structures such as MMAL_ES_FORMAT_T
are already recreated at each end, but the IPC structures must
always be of the same structure.
Where there are pointers to host side client contexts or component
handles, these are stored in lookup tables and a 32bit handle passed
to the VPU. On return these are looked back up again to convert
back to the handle.
vcsm_clean_invalid2 created and filled a struct for the older
kernel driver, and this caused problems when used against the
new driver.
Use the correct struct.
When building software targeting Pi, it's common practice to use
the pkgconfig to assist building by specifying PKG_CONFIG_PATH.
Unfortunately, the presence of the legacy pkgconfig that conflict with
Mesa's libraries will cause issues for users that build against the
firmware pkgconfig, but wish to target Mesa. (Pi 4B or earlier revisions
using the f/kms overlay).
Although a possible workaround may be to omit the custom PKG_CONFIG_PATH
of the firmware pkgconfig during build, there are plausible use cases in
which to target a software build against Mesa whilst also leveraging
the non GL-specific firmware libraries (e.g. MMAL for hardware codec support
that works on the FKMS overlay, or BCM_HOST for basic board detection).
Note: this conflict is already resolved via the Raspbian packages by deliberately
omitting the conflicting .pc files during the packaging stage; see https://github.com/raspberrypi/firmware/issues/857
If export is not requested, then /dev/vcsm was the only device tried.
On aarch64 we are not including /dev/vcsm as it has too many
32 bit assumptions, therefore the sensible thing is to try
/dev/vcsm-cma, even if export hasn't been explicitly requested.
Not portable with 64 bit, and rather nasty to be exposing caching
operations to userspace, but effectively reimplement the same
as the older vcsm driver did.
Allows options like -dn 7 to push the preview onto HDMI1.
Values are Dispmanx display enums, therefore predominantly
0 = DSI/DPI LCD
2 = HDMI0
3 = SDTV
7 = HDMI1
Behaviour should the chosen display not be present should be to
revert to the primary display that is present.
Next step into making vcsm-cma the default.
Only one instance can be opened per process, and that is then used for
all clients. If the first client didn't ask for export so opened
vc-sm, but a subsequent request wants export (and therefore vcsm-cma)
then fail the vcsm_init.
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.
