incorrect video driver?

You have a problem with Salix? Post here and we'll do what we can to help.
Post Reply
User avatar
mimosa
Salix Warrior
Posts: 3037
Joined: 25. May 2010, 17:02
Contact:

incorrect video driver?

Post by mimosa » 11. Jul 2018, 13:53

For the longest time, I've experienced rather unsatisfactory, choppy video, with a flickering line across the screen in lively sequences. I just built the latest mesa to see if that might help, having seen the suggestion that the mesa that ships with 14.2 might not support my hardware - but this doesn't seem to have helped.

I'm using the Intel Haswell chipset:

Code: Select all

mimosa[~]$ inxi -G
Graphics:  Card: Intel Haswell-ULT Integrated Graphics Controller
           Display Server: X.Org 1.18.3 drivers: intel (unloaded: vesa) Resolution: 1920x1080@60.00hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 18.1.3
This is a niggle I normally suppress, but it was rekindled by that "unloaded".

A friend I installed Salix for reports similar issues ("but it's fine with Ubuntu") which also made me wonder about the mesa version.

Should I have been installing some "driver", all along?

I see the same flickering line when scrolling in the browser, as if there has been a small jump in horizontal alignment of the image.

User avatar
mimosa
Salix Warrior
Posts: 3037
Joined: 25. May 2010, 17:02
Contact:

Re: incorrect video driver?

Post by mimosa » 12. Jul 2018, 14:44

This from Arch wiki seems to have helped:

Code: Select all

mimosa[~]$ cat /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
 Identifier  "Intel Graphics"
 Driver      "intel"
 Option      "TearFree" "true"
EndSection
mimosa[~]$ inxi -G
Graphics:  Card: Intel Haswell-ULT Integrated Graphics Controller
           Display Server: X.Org 1.18.3 [b]driver: intel[/b] Resolution: 1920x1080@60.00hz
           GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 18.1.3
The tearing does seem to have improved, though I suspect other imperfections less apparent to the untutored eye remain. I haven't tried reverting mesa and libdrm,llvm to stock Salix packages while retaining 20-intel.conf, but removing the latter brings back the mention of vesa in inxi's output - and also the tearing.

galmei
Posts: 31
Joined: 1. Jun 2018, 21:54

Re: incorrect video driver?

Post by galmei » 12. Jul 2018, 22:53

From your description, I can not see why Mesa should be responsible.

The inxi message drivers: intel (unloaded: vesa) has no adverse meaning and has only misled you. The X-Server loads all suitable graphics hardware drivers (modules) and probes them. Those whom the server rejects are removed then. That's why the unloaded comes. In your system the Vesa driver was loaded and then discarded. By using Driver "intel" in Section "Device" the server is stated the driver to use, eliminating probing over all drivers. Therefore no more unloaded message. Which drivers are involved can be found in the X-Server-Logging (/var/log/Xorg.0.log), as long as no driver is specified. For me, four drivers are probed and three are discarded. The same inxi call indicates only two of them as unloaded.

The logging also contains the exact name of the chipset. Also, the command lspci shows the exact chipset name. Both gives you the certainty that a suitable Haswell graphics driver has been loaded. To your question, whether always a driver must be loaded: Yes, always when X11 is running.

For the troubleshooting, I would first turn off the option TearFree (comment out) or remove the 20-intel.conf file. Then check in the logging whether the functionality TripleBuffer is still switched on. This is active by default, but is turned off by the server if the shared video memory is insufficient for a third buffer. If this third buffer is missing, this can lead to a constant change in the representation, which can cause such a line-flicker. The definition of the video memory size for the integrated video adapter is made in the BIOS settings. I can choose between four sizes for my non-Intel hardware. You could choose the largest possible for testing. There are cases when the X server can not determine the size of the video memory. Then this size must be communicated via the keyword VideoRam. The VideoRam keyword usage in Section Device:

Code: Select all

VideoRam integer  # integer in KiByte
Next you can check all acceleration settings. Almost all are already switched on or pre-assigned with a method. The actual uses are also dependent on conditions.

Also, I would check if frames are displayed in non-interlace method. If the interlace method is used instead, that's unlikely, one will also see jumps on horizontal edges. That would be visible in a standing image, too.

It would not be wrong if you show the X server logging (without the 20-intel.conf setup). You should also make sure that there are no unwanted or outdated X11 rules in /etc/udev/rules.d. Same for unwanted or outdated X11 configuration files in /etc/X11 (except xorg.conf-vesa) and /etc/X11/xorg.conf.d (except 10-keymap.conf).

User avatar
mimosa
Salix Warrior
Posts: 3037
Joined: 25. May 2010, 17:02
Contact:

Re: incorrect video driver?

Post by mimosa » 14. Jul 2018, 17:19

Thank you for your helpful post which gives some avenues to explore. I am about to go on the road for a while so it may be a while before I get round to it.

However, my hunch is this is a problem that is not limited to particular hardware or misconfiguration. My evidence is anecdotal: I've seen this myself on every machine I've used in recent years (that was one reason I splashed out on slightly better hardware, though in fact, the video element is still relatively weak). There is also the friend for whom I installed Salix. Could the common denominator just be lacklustre hardware?

The fix I found by searching, on the Arch wiki, is widely repeated, especially among Ubuntu users. That suggests the problem is not distro-specific, though sometimes, using a different distro does seem to improve matters.

Have any other Salix users seen this?

User avatar
mimosa
Salix Warrior
Posts: 3037
Joined: 25. May 2010, 17:02
Contact:

Re: incorrect video driver?

Post by mimosa » 18. Jul 2018, 14:15

I can't find any mention of Triple Buffer in the log, with or without the notear option. My BIOS also doesn't have a readily apparent way of specifying reserved graphics memory. It looks as though it should be adequate though:

Code: Select all

mimosa[~]$ sudo lspci -v -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Intel Corporation Haswell-ULT Integrated Graphics Controller
        Flags: bus master, fast devsel, latency 0, IRQ 50
        Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
        Memory at e0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at f000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
        Kernel modules: i915
As I said above, searching does suggest this "tearing" is a widespread problem across hardware and distros; and (anectdotal evidence) it's something I've seen myself on different hardware.

galmei
Posts: 31
Joined: 1. Jun 2018, 21:54

Re: incorrect video driver?

Post by galmei » 18. Jul 2018, 17:38

After your second, more comprehensive, description, I had already thought that you are right with your assumptions that the tearing problem is not distribution-dependent and not limited to specific hardware. It can occur with any hardware that uses multi-buffering, if certain conditions meet. It is therefore a general hardware-related problem, which can be particularly strong in appearance, with changing image content. So it is not a matter of lacklustre hardware, as you have noted in the case of doubt.

A few more notes that you should not misunderstand. The anecdotal evidence (nice), as well as the installation with the friend, has one thing in common: the installations were done by you. Maybe you have a preferred approach or idea of what something has to be in the installation and configuration, and that is why this problem occurs. A systematic error, so to speak. Or, maybe the automatic configuration of the driver for this chipset is not good enough. The number of Ubuntu users is much larger than the number of Salix users, so there are more affected Ubuntu users. Maybe Salix users will still report; the lack of feedback may have their cause because of the holiday season in the northern hemisphere. Does the friend have similar Intel-based hardware as you?

I only had one Nodebook, which does not exist anymore. An additional screen could be connected to this and for this the shared graphics memory was resizable. Now assuming that this is not possible with your device, then the manufacturer will probably have specified the shared graphics memory with a fixed size. An adjustment in the BIOS is then superfluous. Unfortunately, I had not thought of this possibility.

The settings for avoiding screen tearing should all already be set according to the manual. The manual is one and the implementation then often something else. Therefore, an explicit configuration may be considered for testing. How do the following settings affect the image?

/etc/X11/xorg.conf.d/20-intel.conf

Code: Select all

Section "Device"
   Identifier "Intel Graphics"
   Driver     "intel"

   Option     "VSync"           "true"
   Option     "TripleBuffer"    "true"
   Option     "PageFlip"        "true"  # Has reference to GL.
   Option     "SwapbuffersWait" "true"  # Has reference to MESA and GL.
#  Option     "TearFree"        "true"
EndSection
When using the third buffer at TripleBuffer, the shared graphics memory should be twice the size of the otherwise required graphics memory. In the case of an unconfigurable shared graphics memory, the manufacturer must have already considered this somehow. TripleBuffer can only be usefully used together with VSync. You wrote, TripleBuffer is not in the log. It may be necessary to explicitly enable TripleBuffer, along with VSync, if the automatic driver configuration contains negligence. The above example could already fulfill all requirements. Whether the option "TearFree" is then additionally required must be proved, but would be sad, because this activated option costs performance. I understood that it brought easing but no cure.

There are clear recommendations on how to avoid screen tearing. The fact that tearing occurs suggests that the rules for the X11 auto configuration are not going far enough. At this point, there would be another approach. For example, how do Salix 14.2 and Slackware Current differ herein?

My previous references to /etc/udev/rules.d and VideoRam are meaningless, please do not track.

User avatar
mimosa
Salix Warrior
Posts: 3037
Joined: 25. May 2010, 17:02
Contact:

Re: incorrect video driver?

Post by mimosa » 28. Oct 2018, 08:34

I've finally got round to trying that, and it doesn't really seem to have helped. But my main interest in this thread is not so much to solve the problem for myself, as to establish whether (as anecdotal evidence suggests, in combination with my own experience on a variety of hardware and media players) it is a broader problem for Slackware/Salix in general, or perhaps for a certain subset of users. If so this looks like an exception to the general principle that Salix (like Slack) performs better than average with mediocre hardware, if indeed that is where the problem is clustered.

So I repeat the question with which I opened this thread: is anyone else seeing this? Is there something obvious I am missing, perhaps some initial configuration step that would just go without saying for any truly seasoned Slacker?

I also haven't yet tried looking at it in current, which is of course the future.

In answer to your question galmei about my installation practices, I don't think there's anything unusual, though it's certainly a good point.

Post Reply