| Age | Commit message (Collapse) | Author |
|---|
|
Add a helper function to read the panel's deep-color capability
from EDID.
For EDID 1.3, we need to read deep color capability from Vendor
Specific Data Block, and for EDID 1.4 read bit depth from Video
Input Definition.
Vendor Specific Data Block for "HDMI Licensing LLC":
---------------------------------------------------------
| Byte| Bit | Description |
---------------------------------------------------------
| | Bit 6 | 16-bit-per-channel deep color (48-bit)|
| 6 | Bit 5 | 12-bit-per-channel deep color (36-bit)|
| | Bit 4 | 10-bit-per-channel deep color (30-bit)|
---------------------------------------------------------
Video Input Definition (1-byte):
* Video Signal Interface: Bit 7 (1:Digital, 0:Analog)
* Color Bit Depth: Bits 6 → 4
-----------------------------------------------------
| 7 | 6 5 4 | 3 2 1 0 | Color Bit Depth: Bits 6 → 4 |
|---|-------|---------|-----------------------------|
| 1 | 0 0 0 | x x x x | Color Bit Depth is undefined|
| 1 | 0 0 1 | x x x x | 6 Bits per Primary Color |
| 1 | 0 1 0 | x x x x | 8 Bits per Primary Color |
| 1 | 0 1 1 | x x x x | 10 Bits per Primary Color |
| 1 | 1 0 0 | x x x x | 12 Bits per Primary Color |
| 1 | 1 0 1 | x x x x | 14 Bits per Primary Color |
| 1 | 1 1 0 | x x x x | 16 Bits per Primary Color |
| 1 | 1 1 1 | x x x x | Reserved (Do Not Use) |
-----------------------------------------------------
For deep-color we need atleast 10-bits.
V2:
* Add EDID 1.3 support
V3:
* Fix reading VSDB flags1 for deep-color
V4:
* Separate functions for EDID 1.3 & EDID 1.4
* Other minor cleanups
V5:
* Fine tune the logic to identify DC support for RGB format
V6:
* Cleanup
V7:
* Cleanup: Fix typos, comments and rename function names
* Update max_bpc() to capture the prop value
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
|
Byte 26 in a edid struct is supposed to be "Blue and white
least-significant 2 bits", not "black and white". Rename the field
accordingly.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
|
|
Generating the tiled edid which can be flashed on chamelium and added
some functions to support the same.
v2: No change.
v3: No change.
v4: No change.
v5: No change.
Signed-off-by: Kunal Joshi <kunal1.joshi@intel.com>
Signed-off-by: Karthik B S <karthik.b.s@intel.com>
Reviewed-by: Navare Manasi D <manasi.d.navare@intel.com>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
Callers no longer need to call edid_ext_update_cea_checksum on each extension
block. This makes it less error-prone to miss one block by mistake.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This array is filled manually, some bytes might have the MSB set.
This fixes the following warning:
../lib/igt_kms.c:357:18: warning: implicit conversion from 'int' to 'char' changes value from 128 to -128 [-Wconstant-conversion]
hdmi->data[0] = HDMI_VSDB_VIDEO_3D_PRESENT; /* HDMI video flags */
~ ^~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
EDID_LENGTH is misleading because EDIDs are a variable size (they contain one
or more 128-byte EDID blocks). This commit renames it to EDID_BLOCK_SIZE which
makes it clear users need to call edid_get_size to get the total size.
The declaration has also been moved to igt_edid.
("Size" has been chosen over "length" because it's clearer that it's a number
of bytes, not a number of elements)
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Add a description of the library, and add misisng function docs.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Short Video Descriptors (SVDs, not to be confused with Vendor-Specific Data
blocks) describe CEA video formats supported by the monitor.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
Native Detailed Timing Descriptors follow the Data Block Collection in the CEA
extension.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
The HDMI Vendor-Specific Data Block, defined as an opaque blob in the EDID
spec, is described in the HDMI 1.4 spec.
Most of the extension fields are optional, so it doesn't translate well to a C
struct. For now callers need to manually fill the hdmi_vsdb.data field.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
"VSDB" (Vendor-Specific Data Block) is the wording used by CEA 861D.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
This returns the 3-letter manufacturer identifier of an EDID.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
This is a simple helper to get the size in bytes of an arbitrary EDID.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
|
detailed_timing_set_mode uses detailed_timing_set_mode from xf86drmMode.h, but
doesn't include it. This has gone unnoticed because all the igt_edid users
were already including this file.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Fixes: a2fd0489c87a ("lib/igt_edid: new library for generating EDIDs")
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
Speaker Allocation Data blocks describe which speakers are present in the
display device.
This block is required to make DisplayPort audio work.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
|
|
For some reason HDMI audio won't work unless you cast a magic IEEE Registration
Identifier alongside with its appropriate Components of Source Physical
Address. The easiest way to do this is to capture a wild HDMI EDID, study it,
and blindly copy bytes because you don't understand anything about their
possible meaning (if any).
This commit also changes the SAD API exposed by igt_edid, to allow for both a
SAD block and a VSD block to be included in the same CEA block.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
Short Audio Descriptors (SADs) can be wrapped in an EDID extension to advertise
audio support.
The EDID structure is as follows:
- The 128-byte EDID block contains a field with the number of 128-byte
extension blocks that follow.
- Each extension block has a tag which specifies its type. The tag we're
interested in is CEA-861.
- The CEA block has a few flags, including one that indicates whether basic
audio is supported. The CEA block contains several sub-blocks of variable
size. There are two types of CEA sub-blocks:
- Detailed Timing Descriptors (DTDs): additional video timings
- Data Block Collection: these can detail video, audio, speaker placement and
other pieces of information about the display.
We're interested in audio blocks.
- Audio blocks contain one or more Short Audio Descriptors (SADs). A SAD is a
3-byte record describing a supported format.
- SADs can describe support for the PCM format, including sampling rate,
sample size and channels.
The igt_edid library intentionally exposes all of this complexity because it
would be nice to generate all kind of valid EDIDs and test the kernel handles
them correctly (e.g. multiple SADs in different CEA blocks, or any EDID we find
in the wild really).
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
The generated EDIDs were wrongly indicating that they support analog sync.
Fixup the detailed timings flags to advertise digital sync instead.
Currently the Linux kernel seems to ignore this completely. However I'd prefer
to fix this anyway to make sure we don't run into issues if an EDID consumer
actually cares about it.
The header definitions for EDID_PT_* values has been re-organized to make it
clearer in which situations the flags are relevant.
Changes from v1 to v2:
- Fix misleading commit message
- Revert the "misc" → "features" rename
- Re-organize EDID_PT_* definitions to make them clearer
Changes from v2 to v3:
- Include review changelog in commit message
- Fix "Fixes:" tag to conform to the kernel style
- Re-order EDID_PT_* definitions to sort by descending bitshift
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: a2fd0489c87a ("lib/igt_edid: new library for generating EDIDs")
|
|
For the purposes of testing different EDID features, we need to generate more
and more complex EDID blobs (e.g. with audio support). However currently IGT
uses a macro-based system to generate EDIDs. This doesn't scale well and is
pretty inflexible.
This commit introduces a new little library to generate EDIDs. For now it can't
do more than the old macro. Future commits will extend the API.
The structures are mostly based on the Linux kernel code (drm_edid.h). Setters
have been added for convenience.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
|
|
This has been replaced by igt_kms_get_base_edid().
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
|
|
Add a function to set an EDID data block on a connector and include a
set of generic EDID blocks for testing.
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
|
