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  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 15 Feb 2016 16:42:15 +0100
From:	Daniel Vetter <daniel@...ll.ch>
To:	Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc:	Oleksandr Natalenko <oleksandr@...alenko.name>,
	Daniel Vetter <daniel.vetter@...el.com>,
	intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Sonika Jindal <sonika.jindal@...el.com>,
	Shashank Sharma <shashank.sharma@...el.com>,
	Gary Wang <gary.c.wang@...el.com>
Subject: Re: [REGRESSION] i915: No HDMI output with 4.4

On Mon, Feb 15, 2016 at 04:42:35PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
> > 13.02.2016 01:23, Ville Syrjälä wrote:
> > > - Do you have another monitor to try?
> > > - Do you have another cable to try?
> > 
> > More on this.
> > 
> > Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working
> > Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not 
> > working
> > Computer DVI —— DVI-DVI cable —— another monitor DVI == works
> > 
> > So
> > 
> > > Shouldn't really matter. HDMI and DVI are identical at this level.
> > 
> > Not quite, as far as I can see.
> 
> Well, it seems this particular monitor is just somehow funky. It's a bit
> strange that the hpd interrupt still works. It would seem to indicate
> that there's two separate voltage thresholds for detection, one for the
> hpd generation, and another for the live status. I did see something
> similar on another platforms (CHV) where it had two different hpd
> detection registers, and those produced different results when the
> pullup on the hpd pin was misconfigured.
> 
> Anyway, I'm out of ideas now :( Anyone else got something up their
> sleeve?
> 
> I'm starting to think this is going to be our only option:
> -       if (intel_hdmi_set_edid(connector, live_status)) {
> +       if (intel_hdmi_set_edid(connector, true)) {
> 
> It would more or less turn the live status check into a fixed
> msleep(80) for the disconnect case. For the connect case it would
> still break out sooner when live status works.
> 
> The downside is that if the cable is yanked slowly, we'll still succeed
> in the ddc communication during unplug and thus fail to notice that the
> monitor was actually disconnected. But the delay should make that less
> likely.

The other downside is that it'll make us non-compliant, which was the
point of this entire ordeal: HDMI spec forbids us from starting any i2c
transactions when the hpd isn't signalling a present screen.

So maybe we need to buy one of these broken screens.

Oleksandr, what exact model are you using? And any chance that you could
test this on some other machine with intel gfx and latest kernel, just to
make sure this really is some issue with the sink and not with the machine
itself? And I guess you've tested with some other hdmi sink, and that
works?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ