Opened 3 years ago
Closed 3 years ago
#17462 closed bug (fixed)
edid support digital input types
Reported by: | kallisti5 | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta4 |
Component: | Drivers/Graphics | Version: | R1/beta3 |
Keywords: | edid | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
Our EDID headers are designed as follows:
https://git.haiku-os.org/haiku/tree/headers/private/graphics/common/edid_raw.h
// display info typedef struct _PACKED { BBITFIELD8_7 ( input_type : 1, // 1 : digital input_voltage : 2, // 0=0.7V/0.3V, 1=0.714V/0.286, // 2=1V/0.4V, 3=0.7V/0V setup : 1, // true if voltage configurable sep_sync : 1, comp_sync : 1, sync_on_green : 1, sync_serr : 1 );
However, per the EDID (1.4) specifications, when input_type changes from 0 (analog) to 1 (digital), the meaning of the bits of the first bitfield change. (see attached screenshot)
We should likely rename these "input_settings : 7", and parse them manually in our code when we translate from edid1_display_raw to edid1_display.
Attachments (2)
Change History (6)
comment:1 by , 3 years ago
comment:2 by , 3 years ago
Description: | modified (diff) |
---|
comment:3 by , 3 years ago
x512 suggested a union. I agree and made https://review.haiku-os.org/c/haiku/+/4775.
The reason for this one is the radeon_hd driver wants to know the bits_per_color edid field for AtomBIOS + deep color.
comment:4 by , 3 years ago
Milestone: | Unscheduled → R1/beta4 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Merged in hrev55740.
source: https://en.wikipedia.org/wiki/Extended_Display_Identification_Data