<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Dell TB16 external displays blank in kernel 4.14.4+"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104425#c3">Comment # 3</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Dell TB16 external displays blank in kernel 4.14.4+"
href="https://bugs.freedesktop.org/show_bug.cgi?id=104425">bug 104425</a>
from <span class="vcard"><a class="email" href="mailto:arequipeno@gmail.com" title="Ian Pilcher <arequipeno@gmail.com>"> <span class="fn">Ian Pilcher</span></a>
</span></b>
<pre>After a bit more debugging around I have determined that this patch does not
*completely* disable the TB16-attached displays. Instead, I ran into a
combination of a couple of separate behaviors:
1. If I allow the i915 module to be loaded by dracut, the displays *are*
disabled when the system is asking for my LUKS password. Additionally, I
have been unsuccessful in a pretty large number of attempts to blind-type
the LUKS password, so it appears that something else is blocked as well
(even though the NumLock LED on my keyboard does respond).
2. systemd-logind was suspending my laptop, because the lid was closed and it
did not detect any external displays. Once I realized what was going on,
I was able to work around this by setting HandleLidSwitch=ignore in
logind.conf, but this is not a long-term solution.
If I boot with rd.driver.blacklist=i915 (so that I can enter my LUKS password
before the i915 module is loaded) and prevent systemd-logind from suspending
the system, then I am able to boot, and the TB16-attached displays are
eventually enabled.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>