External display adapters (HDMI, mini-DP, Thunderbolt) on Lenovo P70?

Has anyone gotten any of the external display adapters to work under any flavor of Linux on the above laptop? My specific configuration is a Xeon E3-1505Mv5 and nVidia M4000M. I happen to be using openSUSE 42.3, and I've never been able to get the M4000M to work by any means other than optirun and primusrun (which is enough to get me openCL, which is my primary use case for the fast graphics adapter for image processing, so I'm getting meaningful use out of it).

The issue is that this laptop, like most such, is an Optimus setup. But Optimus seems to mean a lot of different underlying hardware setups. If I'm understanding matters correctly, the internal display is wired to the integrated HD530 while at least the HDMI, and quite possibly the miniDP (I have no idea about the Thunderbolt), are wired through the discrete adapter. I tried the mini-DP via a mini-DP->HDMI adapter. When I connect either mini-DP or HDMI to an external HDMI TV, the TV can clearly see that there's something on the other end but doesn't receive a signal; the laptop briefly flashes "No external display" or something similar on the screen (I'm presuming something in the X stack is detecting something being added, tries to connect to it, and fails), and xrandr -q doesn't show any other display.

I've tried using optirun and primusrun, also with no luck.

 

This seems to be causing grief under Windows too: https://forums.lenovo.com/t5/ThinkP...enovo-P50-HDMI-not-working/m-p/2264525#M55880

When I next boot Windows I will have to look at this and update the Thunderbolt firmware if applicable.

 

I booted Knoppix, which I believe uses the Nouveau driver. It won't talk over HDMI either -- unless I set the BIOS to discrete graphics only, in which case it will not talk to the internal display but will connect just fine over HDMI.

Windows connects unreliably over HDMI in addition to the internal display when it's set to hybrid. Set to discrete only, the internal display won't work (I didn't try the external display).

So it would appear that they don't have things fully debugged yet.

 

OK, looks like I have all my problems solved:

1) The unreliable connection via Windows appears to be due to a bad (or at least flaky) HDMI cable.

2) The issues with connecting to an external monitor appear to be due to problems with bumblebee/primusrun. Both of these use an auxiliary, headless X server to do GL rendering. If I try to put a head on that auxiliary X server it won't start up. But I did find that someone implemented Prime for Linux (the package is named suse-prime); this is simply a few scripts and an X server configuration that enable use of the nVidia driver as intended. GL performance is a lot better, and it also drives external monitors with no problems at all.

I haven't yet tried in discrete-only mode (in the BIOS), but that's not a high priority.

With suse-prime I can turn off the discrete GPU for power saving if I want (at the cost of a logout), but otherwise it's almost completely perfect. The only glitch is that after suspend/resume sometimes icon labels show up as a blank box without the text; that's presumably some kind of small driver bug.

 

One other significant issue I need to work through: when I boot, X does not come up. This appears to be because the nvidia module doesn't load. I haven't had a lot of luck (yet) finding a point to modprobe it and get the X server to start on boot.

This is a nuisance, nothing more, since I can simply login, modprobe nvidia, systemctl restart display-manager;logout. It's a significant nuisance, though, because it should work. But I do want to debug it.

 

This is looking like a timing issue; sometimes X does come up and sometimes it doesn't on boot. I'm suspecting that what's happening is that modprobe nvidia is returning before the module is fully initialized; if the X server tries to start too quickly, the nvidia kernel module isn't initialized so the nvidia driver doesn't see it and fails to start.

The obvious workaround attempt would be to introduce a delay after modprobing nvidia. But the question is really whether the userland nvidia driver should be autoloading the kernel driver, and if it should, why it isn't.

 

Okay, I ran into this issue on my Lenovo T430, not P70, but T430 with a discrete graphics. XServer does have the timing issue, and it does fail still to this day. For my case, I dedicated a keyboard shortcut (the thinkpad button) to reload the xserver.

The only way I could get the nvidia kernel module to talk to nvidia card properly was to use bumblebee and using respective kernel with it. I also needed to blacklist many many graphics drivers in order to load my NVS 5400m. Even then, it was finicky. It always worked at the end, but I often got the double mouse pointer thanks to the laptop screen being loaded twice. One mouse pointer remained at center, while the actual working one moves.

I cannot speak for the M4000M, but if nouveau works fine with this card, I STRONGLY recommend just changing the renderer from OpenGL to the third option. I don't remember, and dedicating a keyboard shortcut for rebooting xserver with a simple command "xrandr"

 

It turns out not to be that hard to use the nVidia driver directly, but it's not obvious a priori (it makes a lot more sense when reading it) and I cloned it from the suse-prime package. You need to add this to /etc/X11/xorg.conf.d/90-nvidia.conf (which should be distribution-independent), and aside from the initial boot, things should just work:

Section "ServerLayout"
Identifier "layout"
Screen 0 "nvidia"
Inactive "intel"
EndSection
Section "Device"
Identifier "intel"
# Driver "intel"
Driver "modesetting"
EndSection
Section "Screen"
Identifier "intel"
Device "intel"
EndSection
Section "Device"
Identifier "nvidia"
Driver "nvidia"
BusID "PCI:1:0:0"
EndSection
Section "Screen"
Identifier "nvidia"
Device "nvidia"
Option "AllowEmptyInitialConfiguration" "on"
EndSection​

You may need to use either the intel or the modesetting driver in the second stanza, depending upon the age of your CPU (I think somewhere around Broadwell/Haswell is the cutoff). But once I got this working, external monitors now Just Work with no glitches.

Nouveau does work with the M4000M, but then I lose OpenCL, which is something I want for image/video work. My work laptop is a very similar system, a P50 with an M1000M, and it's using the Nouveau driver. But it's markedly slower -- dragging windows around is a lot slower than on my old Dell Precision M6500, with an i7-920XM (Nehalem, first generation i7) and AMD Radeon HD5870M. And it has its own issues with external monitors; if the monitor is turned on and attached during boot, it's never seen; suspend/hibernate also loses connections with external monitors.

What's the context here about renderer (and what's "the third option")? Different people are using different desktops, and I presume you're referring to some desktop setup.

 

@rlk, sorry, I was half asleep in bed when I wrote that. I will have to get back to you on that when I'm booted from linux. I was referring to a renderer for OpenSUSE KDE. There are two OpenGL options and a third one I don't remember.

 

Yep, OpenGL 2.0, OpenGL 3.1, and Xrender. Xrender is definitely smoother than the other two when using Nouveau (on work laptop).

I'm not having any of the problems you're referring to with the nvidia driver.

 

Yes, Xrender that one seems to work the best with Nouveau.

With the Nvidia driver, At least NVS5400m driver is really really shoddy.