Hi
Am 17.03.26 um 03:44 schrieb Jammy Huang:
Hi Thomas,
Thanks for the comments. I found the code at [1] is now not working.
Because i+=4 in the loop iteration.
For the block map, we should handle it depending on the number of blocks:
1. 0 or 1, no edid modification required.
2. >= 2, check block1 offset 0x00 to see if it is 0xF0 which means block map.
Set number of extensions to 0 if block1 is block map; Otherwise, set number
of extensions to 1.
Yeah, I think that should work well.
Best regards
Thomas
BR
Jammy
Hi
Am 16.03.26 um 12:38 schrieb Jani Nikula:
On Mon, 16 Mar 2026, Thomas Zimmermann <[email protected]>
wrote:
Hi Jammy
Am 13.03.26 um 11:04 schrieb Jammy Huang:
DisplayPort supports edid at most 256 bytes. Thus, allow it to fetch
edid block 0 and 1.
Signed-off-by: Jammy Huang <[email protected]>
---
ASPEED DisplayPort's EDID size can be 256 bytes at most. Thus, EDID
blocks fetched can be 0 and 1.
---
drivers/gpu/drm/ast/ast_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_dp.c
b/drivers/gpu/drm/ast/ast_dp.c index 9d07dad358c..c938e1d6b1d 100644
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -88,7 +88,7 @@ static int ast_astdp_read_edid_block(void *data, u8
*buf, unsigned int block, si
int ret = 0;
unsigned int i;
- if (block > 0)
+ if (block > 1)
return -EIO; /* extension headers not supported */
But see the code at [1]. It clears the number of extensions to zero
and updates the checksum accordingly. This is required to make the
shortened EDID work with DRM. If you leave this as-is, it will still
clear support for any extension in block 1.
See the table 2.4 in the VESA EDID 1.4 standard for the semantics.
For 1.3, if the number of blocks is >2, the first extensions is a
'block map of the extensions'. This is useless, as it's not a data
extension in itself. In 1.4, the block map is optional. That code
should clear the EDID's number of extensions to 0 or 1, depending on
whether there is a block map to be expected.
I think long-term the goal should be for the kernel to not modify the
EDID, at all.
We only fix up the checksum to address the fact that we cannot read the
extensions.
I guess the kernel could be fixed to work correctly with the extensions missing,
but what about user space? Exporting an EDID without the extensions blocks
could cause problems with user-space programs.
Best regards
Thomas
BR,
Jani.
Best regards
Thomas
[1]
https://elixir.bootlin.com/linux/v6.19.8/source/drivers/gpu/drm/ast/a
st_dp.c#L157
/*
---
base-commit: 5ee8dbf54602dc340d6235b1d6aa17c0f283f48c
change-id: 20260313-upstream_ast_dp_edid-5fe6adf7ad36
Best regards,
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG
Nürnberg)
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
