summaryrefslogtreecommitdiff
path: root/lib/decompress_unlz4.c
diff options
context:
space:
mode:
authorMaxime Ripard <maxime@cerno.tech>2022-02-03 12:54:16 +0100
committerMaxime Ripard <maxime@cerno.tech>2022-02-23 14:12:01 +0100
commitecbd4912a693b862e25cba0a6990a8c95b00721e (patch)
treee76c431b8d8bec303ffb0b7751b2890e99b9df33 /lib/decompress_unlz4.c
parentf762ce78897d734a08f52e39a353359b7d417578 (diff)
drm/edid: Always set RGB444drm-misc-fixes-2022-02-23
In order to fill the drm_display_info structure each time an EDID is read, the code currently will call drm_add_display_info with the parsed EDID. drm_add_display_info will then call drm_reset_display_info to reset all the fields to 0, and then set them to the proper value depending on the EDID. In the color_formats case, we will thus report that we don't support any color format, and then fill it back with RGB444 plus the additional formats described in the EDID Feature Support byte. However, since that byte only contains format-related bits since the 1.4 specification, this doesn't happen if the EDID is following an earlier specification. In turn, it means that for one of these EDID, we end up with color_formats set to 0. The EDID 1.3 specification never really specifies what it means by RGB exactly, but since both HDMI and DVI will use RGB444, it's fairly safe to assume it's supposed to be RGB444. Let's move the addition of RGB444 to color_formats earlier in drm_add_display_info() so that it's always set for a digital display. Fixes: da05a5a71ad8 ("drm: parse color format support for digital displays") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: Matthias Reichl <hias@horus.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203115416.1137308-1-maxime@cerno.tech
Diffstat (limited to 'lib/decompress_unlz4.c')
0 files changed, 0 insertions, 0 deletions