I have a partial Slackware-current installation which is going to become Slackware 15 when they go beyond alpha. Earlier I found that I was getting weird effects in some software when using the intel driver in X, something I haven't seen elsewhere. Basically I couldn't scroll up. I could scroll down OK and I could page up and down using the keyboard, but scrolling up with the mouse produced a broken display with two lines repeating endlessly.

Not everything was affected: for example gvim was fine. But vim on an xterm misbehaved and so did the graphical version of links.

Now I'm using the modesetting driver and everything seems to be working normally. I was always told before to use the specific driver for your card if you can because it's better and faster, but a quick google suggests that this advice is out of date.

What do people think?

I think just recently I read somewhere Intel still has quite an advantage over modesetting in 2D performance. How noticeable this is in everyday use is another question.

It is noticeable on sucky intel video cards like mine, and I daresay Hazel's. What is irritating is that some drivers are in /usr/lib64/xorg/modules/drivers (intel, modesetting) but the i965 driver (which my ivy bridge/HD4000 which is also used) is in /usr/lib64/dri and it's not funny trying to sort out what is actually using for what.

The intel driver has not been developed for 5+ years. To say intel has 'quite an advantage in performance' implies quite a performance from a generation of sucky cards, and I would dispute that.

While it is true they haven't reached version three there is something going on, at least the driver is maintained to keep in running with latest Xorg. Intel driver in Gentoo is x11-drivers/xf86-video-intel-2.99.917_p20201215, as you can see, released in December.

GPU-specific X drivers are old technology. Intel pays its graphics developers to work on both the (unofficially deprecated) Intel and the Modesetting, with primary focus on the newer technology Modesetting. Modesetting is the DDX I've been using on most GPUs that it supports for around 6 years, around the time the modesetting DDX ceased to be a separate package, having been moved into the 1.17.0 server package in 2015 to make it the default DDX. It doesn't require the reverse engineering that the Nouveau DDX does. Modesetting DDX support includes Intel since around 2008, and AMD & NVidia since mostly a bit later. Newer AMDs seem to get more recommendations to use the amdgpu DDX. My newest AMDs aren't really new enough to tell any behavioral difference between the two. Each have their own bugs, strengths and weaknesses, depending on which APU/GPU/IGP is employed. Use whichever works best for yours, if you can tell any difference.

Bugfixes and compatibility issues, I imagine. My next video card will not be intel, and I'll inform myself of the state of play whenever that is.

Interesting discussion. Someone once told me that the _drv.so drivers in /usr/lib64/xorg/modules/drivers are little more than envelopes these days, and that the main rendering work is now done by mesa. Presumably that's where the secondary driver files in /usr/lib64/dri that business kid mentioned come into the picture.

In Slackware 14, I use the Intel driver and it works perfectly, which is why I set up Slackware-current to use it too. But it doesn't work there.

I don't actually have a video card. I have an Intel Baytrail system-on-a-chip cpu that apparently does the video in its spare time.

Intel driver uses SNA, modesetting knows nothing about it.

I am intrigued as to how such a thing occurs. Consider: this is not a random screen phenomenon like tearing. It occurs inside specific windows that display text and it causes the wrong text to be displayed. Now how can that be related to the video driver such that it occurs with one driver but not another? These are well-formed images; they just show the wrong thing.

When I scroll upwards with my mouse, that is an X-event. It gets reported by evdev to the X-window. In the case of gvim, it gets reported as a gdk-event and the gtk text window widget rewrites the window with the correct text (earlier text from the buffer). Everything works.

In the case of xterm or links, the X-event gets handled directly. Something (some kind of display widget?) rewrites the window but uses a scrap of random text that just repeats itself over and over. But what has that to do with what video driver I am using?

I try to keep agetty-type console stuff out of X, for the very reason you stated. There's a chasm between them, and it's not where the development is at. That's at OpenGL & OpenCL, dri, all that stuff, not emulating 80×25 consoles. Personally, I think it may get worse, and nobody will care. Use links in a agetty console.

But I like graphical links. Why shouldn't I use it? Anyway I only use consoles in partial systems where I haven't got X up and running yet.

I want an explanation, not a solution. The solution is obviously to use the modesetting driver. But how the heck can a driver problem cause such weird symptoms?

To me it seems obvious. A lot of puzzle pieces go into making everything work. FOSS developers don't keep using 8, 10 or 15 year old PCs or laptops as primary platforms, or have every combination of DE, WM, CPU, theme or GPU at their disposal to test on. Old machines get to be unbearably slow as bloat progresses, or they die. So, as development progresses, "testing" older hardware falls more on users who complain or find and report regressions.