Commen=
t # 10
on bug 75985<=
/a>
from zigarrre@gmail=
.com
Any updates?
I can confirm this bug on my Lenovo Thinkpad T520 (4242-PT2). For testing I
used a FHD TV connected via a DP to HDMI connector. The hardware setup was
tested and confirmed to work as expected with Windows 7 so a hardware cause=
can
be ruled out.
uname -a
Linux t520 4.8.13-1-ARCH #1 SMP PREEMPT Fri Dec 9 07:24:34 CET 2016 x86_64
GNU/Linux
I am using the optimus implementation provided by nouveau together with the
intel graphics driver.
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x8c cap: 0xb, Source Output, Sink Output, Sink Offload crt=
cs:
3 outputs: 3 associated providers: 0 name:Intel
Provider 1: id: 0x66 cap: 0x7, Source Output, Sink Output, Source Offload
crtcs: 2 outputs: 5 associated providers: 0 name:nouveau
'lspci' doesn't show the audio device but 'lspci -H1' does:
01:00.0 VGA compatible controller: NVIDIA Corporation GF119M [Quadro NVS 42=
00M]
(rev a1)
01:00.1 Audio device: NVIDIA Corporation GF119 HDMI Audio Controller (rev a=
1)
Even 'lspci -H1' shows the audio device only when the discrete GPU is power=
ed
up (e.g. by doing 'lspci; lspci -H1').
I am not using a DM or a DE but bspwm launched via startx from the tty.
The procedure I used:
1) boot and login (x not yet started)
2) modprobe nouveau
3) echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
4) echo 1 > /sys/bus/pci/rescan
5) lspci now shows the audio device
6) startx
7) open pavucontrol (to trigger launch of pulseaudio via rtkit)
It made no difference when, or even if a device is connected to the DP Port.
The output wasn't usable even with this workaround as pulseaudio showed it
always as unplugged. On one single attempt it did show as connected and wor=
ked
ok but even though following procedure exactly and trying many times I was =
not
able to reproduce this.
After starting pulseaudio multiple errors of the form 'kernel:
snd_hda_codec_hdmi hdaudioC2D0: out of range cmd 0:5:707:ffffffff' showed u=
p.
The usage of this workaround also lead to a very unstable system till the n=
ext
boot. I experienced cpu soft locks multiple times (though found no way to
reliably reproduce them) from which no recovery except hard resetting the
computer was possible.
Attached is a dmesg log where I follow the above procedure (connecting the
display between steps 3 and 4) and activating/deactivating the display with
xrandr once in the end.
I could also provide a syslog from boot till shutdown recorded with journal=
d if
required.
If I can help fixing this by providing more information or testing things l=
et
me know.