| 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>
|
|
While checking a fix for the warning
[2/390] Compiling C object lib/libigt-igt_edid_c.a.p/igt_edid.c.o
In file included from /usr/include/string.h:519,
from ../lib/igt_edid.c:29:
In function ‘strncpy’,
inlined from ‘detailed_timing_set_string’ at ../lib/igt_edid.c:186:2:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:95:10: warning: ‘__builtin_strncpy’ specified bound 13 equals destination size [-Wstringop-truncation]
95 | return __builtin___strncpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
96 | __glibc_objsize (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~
... I noticed we were not following the spec to the letter.
According to EDID 1.3 data format, EDID Other Monitor Descriptors has the this
information for bytes 5-17: "Defined by descriptor type. If text, code page 437
text, terminated (if less than 13 bytes) with LF and padded with SP."
So, while fixing the warning, also guarantee we correctly pad the field.
The only caller sets it to "IGT", so previously we would set the field
would always be 'IGT\n\0\0\0\0\0\0\0\0\0', since all the callers
zero-initialize the struct.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Petri Latvala <petri.latvala@intel.com>
|
|
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>
|
|
hdmi_vsdb is an element of cea_vsdb which makes the size of cea_vsdb to
be 8 ( 3bytes ieee_oui ) + ( 5bytes hdmi_vsdb struct), its true that we
only use 7 bytes technically we can only allocate 7byte array but since
we are writing to elements of hdmi_vsdb struct which is sitting at offet
4-8 in cea_vsdb, compiler thinks we have an element which is out of
array bounds since out allocated size is 7bytes
This errors out
../git/lib/igt_edid.c:365:13: error: array subscript 'struct hdmi_vsdb[0]' is partly outside array bounds of 'char[7]' [-Werror=array-bounds]
365 | hdmi->src_phy_addr[0] = 0x10;
| ^~
allocating one extra byte matches with size of cea_vsdb and compiler is
happy
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-by: Martin Peres <martin.peres@mupuf.org>
|
|
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 check could probably be more precise, but at least it checks we haven't
written past the EDID block end.
Signed-off-by: Simon Ser <simon.ser@intel.com>
Reviewed-by: Martin Peres <martin.peres@linux.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>
|
|
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>
|
|
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>
|
