The functions of xf86-video-vesa were incorporated into the modesetting driver. Yes it works but there are noted issues, and yes I will find them, but ATM, I'm on my phone and finding a link isn't priority.

Edit:

Was able to take a minute and find a noted issue:

https://www.mail-archive.com/ubuntu-...sg4864426.html

1. The bug report your link to is about a failing DDC/VBE probe. This has nothing to do "recent xorg-server" as the server is of course not involved in gathering information from the monitor. That's only the driver's job. Furthermore the initial bug report is dated 2010-02-06.
2. In this case the monitor (probably a CRT here) does not fully comply to a VESA standard hence does not provide the expected info according to DDC and/or VBE. This can be due to the monitor itself, to the connector, to the video card, whatever, but in any case this is not the driver's fault. Maybe another detection mode of the monitor's capabilities could have succeeded, but it is expected that a vesa driver uses the detection modes mentioned in VESA standards, isn't it?
3. This is a fairly common case of failing automatic detection of the highest monitor graphics mode (aka display resolution). It' s easily solved writing a few mode lines and refresh rates in xorg.conf in Linux (and there are some in xorg.conf-vesa) and similarly in Windows as stated in this article (see under "workaround").

As a side note, I am well aware that some old display devices / video cards can hardly be handled by e.g. a framebuffer driver, e.g. because the information they send can't be used to determine the coordinates of the upper left corner of the display from where drawing of the screen should begin. That's was our finding with Diantre in 2014, e.g. with these devices managed by a Chrome video card:
- AOC CT500n (CRT, old monitor)
- Acer v173 (flat screen, 5:4, built around 2007)
- AOC e2243Fwsk (recent monitor, 22inch, 16:9)

At that time I used fbterm in Slint installers to be able to adapt the font size to the display size, but for that reason renounced to do that later, despite a helper program provided by Sébastien Ballet (phenixia203) that allowed us to fall back to a plain Linux console in case fbterm would have failed.

Sorry for the digression, in any case I am still eager to look at (hopefully more convincing) bug reports.

In any case, if it's working fine then no harm no foul. I'll dig through my old mailing lists for the vesa driver write up. It was over a year ago, so it might have been a conflict with xorg-server at the time, possibly in the 1.16.x branch.

If I remember it right, xorg-server only should probe for three drivers in the system, the vendor driver, modesetting, and fbdev if available.

I haven't actually tested this, but the nouveau homepage says that acceleration support was added for GM107 (which includes the GTX 960M) in April 2015, so it might have come along a bit. Probably worth a shot trying nouveau on Slackware 14.2 to see how it goes.

Also, if this is an Optimus laptop, then this page should be read--it definitely made a big difference on the Sandy Bridge laptop I just bought off Craigslist:

https://nouveau.freedesktop.org/wiki/Optimus