lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 4 Mar 2019 14:31:39 +0100
From:   Luc Verhaegen <libv@...net.be>
To:     Priit Laes <plaes@...es.org>
Cc:     Maxime Ripard <maxime.ripard@...tlin.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>, Chen-Yu Tsai <wens@...e.org>,
        dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...glegroups.com, Priit Laes <priit.laes@....com>,
        Russell King <linux@...linux.org.uk>
Subject: Re: [linux-sunxi] [RESEND PATCH] drm/sun4i: hdmi: Improve
 compatibility with hpd-less HDMI displays

On Mon, Mar 04, 2019 at 03:06:16PM +0200, Priit Laes wrote:
> From: Priit Laes <priit.laes@....com>
> 
> Even though HDMI connector features hotplug detect pin (HPD), there
> are older devices which do not support it. For these devices fall
> back to additional check on I2C bus to probe for EDID data.
> 
> One known example is HDMI/DVI display with following edid:
> 
> $ xxd -p display.edid
> 00ffffffffffff0005a1e00301000000150f0103800f05780a0f6ea05748
> 9a2610474f200000010101010101010101010101010101012a08804520e0
> 0b1020004000953600000018000000fd0034441a2403000a202020202020
> 0000001000310a20202020202020202020200000001000002a4030701300
> 782d1100001e006b
> 
> $ edid-decode display.edid
> EDID version: 1.3
> Manufacturer: AMA Model 3e0 Serial Number 1
> Digital display
> Maximum image size: 15 cm x 5 cm
> Gamma: 2.20
> RGB color display
> First detailed timing is preferred timing
> Display x,y Chromaticity:
>   Red:   0.6250, 0.3398
>   Green: 0.2841, 0.6044
>   Blue:  0.1494, 0.0644
>   White: 0.2802, 0.3105
> 
> Established timings supported:
>   640x480@...z 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
> Standard timings supported:
> Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm
>                640  672  672  709 hborder 0
>                480  484  484  491 vborder 0
>                -hsync -vsync
>                VertFreq: 60 Hz, HorFreq: 29478 Hz
> Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz
> Dummy block
> Dummy block
> Checksum: 0x6b (valid)
> 
> Now, current implementation is still flawed, as HDMI uses the
> HPD signal to indicate that the source should re-read the EDID
> due to change in device capabilities. With current HPD polling
> implementation we would most certainly miss those notifications
> as one can try just swapping two HDMI monitors really fast.
> 
> Proper fix would be skipping the HPD pin detection and relying
> on just EDID fetching and acting on its changes.

HPD has been a hard requirement since DDWG came up with DVI somewhere in 
the late 90s. This monitor is plainly broken, and should not get an 
expensive i2c address polling based workaround at the driver level.

Luc Verhaegen.

Powered by blists - more mailing lists