xf86-video-intel (update to a newer snapshot before BLFS release)

[bdubbs@…]

The current version in the book is a development version.

Check occasionally for newer version than 2.99.917. The next stable version will probably be 3.0.0.

[Armin K]

Now 2.99.917. I suggest you update to this version as it disables DRI3, which is enabled by default in previous versions and causes many breakages.

[bdubbs@…]

OK, I'll do it, but will continue to leave the ticket open until the next stable is released.

[bdubbs@…]

Updated to xf86-video-intel-2.99.917 at revision 15336.

Leaving ticket as hold until 3.0 is released.

[Armin K]

Glamor is gone. Needs a bit more work than you did.

[bdubbs@…]

Removed glamor from this package at revisions 15338 and 15339.

[Douglas R. Reno]

If you do not have a box with an Intel card, my laptop that is replacing that is replacing my current physical dev laptop has an 965GM in it. I would be happy to test the new version if/when it comes out.

[bdubbs@…]

I can test it, but having additional testers is good. But don't hold your breath. We've been waiting several months.

[Armin K]

A snapshot update is in order I think.

[bdubbs@…]

I take it that you mean form git. What? the URL again? I can't find it right now.

[Armin K]

git clone ​git://anongit.freedesktop.org/xorg/driver/xf86-video-intel

[Armin K]

A new snapshot once again wouldn't hurt. Yay for 18 months without a release.

[bdubbs@…]

I'll do a new snapshot next month right before the package freeze.

[Douglas R. Reno]

Going to update it this time. Stand by.

[bdubbs@…]

Milestone renamed

[Armin K]

At this rate, there won't be any kind of new releases, yet alone 3.0.

[Bruce Dubbs]

Milestone renamed

[ken@…]

Updated to 20190723 for BLFS-9.0 in r21973

[Douglas R. Reno]

I'll need this for when I build X

[Douglas R. Reno]

Here's a general procedure for the next time this needs to be done:

cd /tmp
mkdir xf86-video-intel-<date>
cd xf86-video-intel-<date>
git clone https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel.git
cd xf86-video-intel
rm -rf .git
cd ..
mv -v xf86-video-intel xf86-video-intel-<date>
tar -cJvf xf86-video-intel-<date>.tar.xz xf86-video-intel-<date>

[Douglas R. Reno]

Added for 9.1 at r22725

[Bruce Dubbs]

Make the script in comment 23 more robust:

date=$(date +'%Y%m%d')  #yyyymmdd
version=xf86-video-intel-$date

cd    /tmp

git clone https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel.git
rm xf86-video-intel/.git

mv -v xf86-video-intel $version
tar -cJvf $version.tar.xz $version

rm -r $version

scp $version.tar.xz anduin:/srv/www/BLFS/xf86-video-intel/

[Pierre Labastie]

There is an issue exposed by gcc 10: a macro is not properly defined because of a typo in certain cases. Since it is not defined, it is taken as a variable when used. And this lead to a "multiple definition" error at link time. See ​https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/commit/db2356f5861d4a81d67c00843a15f5624cd21fb5

So creating a new tarball. [Edit] The new tarball contains the above commit

[Pierre Labastie]

Updated at r23163, version 20200518. Giving back to the book.

[Douglas R. Reno]

I'll take this ticket for 10.0

[Douglas R. Reno]

Updated to xf86-video-intel-20200817 at r23557.

Giving back to the book.

[Douglas R. Reno]

I'll do this ticket for 10.1.

[Douglas R. Reno]

Updated at r24270 , version 20210222. Tarball uploaded to anduin, handing back to the book.

[ken@…]

Should we still be using xf86-video-intel ?

On phoronix there was mention of a new mesa 'crocus' driver in 21.2 for gen4 through to haswell. I asked if it would work with modesetting (I switched to that last year on my haswell to get parole to display videos) and someone who is a apparently a mesa dev replied "No, modesetting is the preferred way to go. I haven't used xf86-video-intel in years." ​https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1262210-mesa-s-new-crocus-opengl-driver-is-performing-well-for-old-intel-hardware/page2

Looking around, I think fedora gave up on this ages ago (and anyway they prefer Wayland). Arch aur seem to still have this, as do gentoo.

Debian at ​https://packages.debian.org/stretch/xserver-xorg-video-intel say "The use of this driver is discouraged if your hw is new enough (ca. 2007 and newer). You can try uninstalling this driver and let the server use it's builtin modesetting driver instead."

2007 is now 13+ years ago, I wonder if it is becoming time to just let this die ? I will note that I've using our current version on my i3 skylake, ISTR that the video output from parole on that machine was NOT fixed by changing to modesetting (but was still broken with xf86-video-intel when I last tried it).

[Douglas R. Reno]

I'll note that my Haswell machine will refuse to start X unless I have this installed, just tested that :)

Running 'lsof' on my Skylake shows it being used as well, but I'm building something so I don't want to kill GNOME to try moving it out of the way

[Douglas R. Reno]

It looks like it can be used with:

What is xf86-video-intel
------------------------
The xf86-video-intel module is an open-source 2D graphics driver for
the X Window System as implemented by X.org. It supports a variety of
Intel graphics chipsets including:

	i810/i810e/i810-dc100,i815,
	i830M,845G,852GM,855GM,865G,
	915G/GM,945G/GM/GME,946GZ
	G/GM/GME/Q965,
	G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
	PineView-M (Atom N400 series)
	PineView-D (Atom D400/D500 series)
	Intel(R) HD Graphics,
	Intel(R) Iris(TM) Graphics,
	Intel(R) Iris(TM) Pro Graphics.

[ken@…]

Replying to Douglas R. Reno:

I'll note that my Haswell machine will refuse to start X unless I have this installed, just tested that :)

Running 'lsof' on my Skylake shows it being used as well, but I'm building something so I don't want to kill GNOME to try moving it out of the way

For your haswell, have you perhaps told it to use intel by setting that in a file in /usr/share/X11/xorg.conf.d ?

On my haswell with versions as at 20210609 my ~/.local/share/xorg/Xorg has

[    16.616] (==) Matched intel as autoconfigured driver 0
[    16.616] (==) Matched modesetting as autoconfigured driver 1
[    16.616] (==) Matched fbdev as autoconfigured driver 2
[    16.616] (==) Matched vesa as autoconfigured driver 3
[    16.616] (==) Assigned the driver to the xf86ConfigLayout
[    16.616] (II) LoadModule: "intel"
[    16.617] (WW) Warning, couldn't open module intel
[    16.617] (EE) Failed to load module "intel" (module does not exist, 0)
[    16.617] (II) LoadModule: "modesetting"
[    16.617] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    16.618] (II) Module modesetting: vendor="X.Org Foundation"

followed by failures to load the also not-present fbdev and vesa, and then it uses modesetting without any problems.

I will stress that I haven't used modesetting on my skylake at the moment, and since that is severely underpowered (i3) I'm in no rush to try that on a fresh build.

On the skylake, the intel driver installed several things as well as man pages, perhaps not removing them all causes breakage:

/usr/bin/intel-virtual-output
/usr/libexec/xf86-video-intel-backlight-helper
/usr/lib/libIntelXvMC.la.hidden
/usr/lib/libIntelXvMC.so
/usr/lib/libIntelXvMC.so.1
/usr/lib/libIntelXvMC.so.1.0.0
/usr/lib/xorg/modules/drivers/intel_drv.so
/usr/share/polkit-1/actions/org.x.xf86-video-intel.backlight-helper.policy

[Douglas R. Reno]

Replying to ken@…:

Replying to Douglas R. Reno:

I'll note that my Haswell machine will refuse to start X unless I have this installed, just tested that :)

Running 'lsof' on my Skylake shows it being used as well, but I'm building something so I don't want to kill GNOME to try moving it out of the way

For your haswell, have you perhaps told it to use intel by setting that in a file in /usr/share/X11/xorg.conf.d ?

On my haswell with versions as at 20210609 my ~/.local/share/xorg/Xorg has

[    16.616] (==) Matched intel as autoconfigured driver 0
[    16.616] (==) Matched modesetting as autoconfigured driver 1
[    16.616] (==) Matched fbdev as autoconfigured driver 2
[    16.616] (==) Matched vesa as autoconfigured driver 3
[    16.616] (==) Assigned the driver to the xf86ConfigLayout
[    16.616] (II) LoadModule: "intel"
[    16.617] (WW) Warning, couldn't open module intel
[    16.617] (EE) Failed to load module "intel" (module does not exist, 0)
[    16.617] (II) LoadModule: "modesetting"
[    16.617] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[    16.618] (II) Module modesetting: vendor="X.Org Foundation"

followed by failures to load the also not-present fbdev and vesa, and then it uses modesetting without any problems.

I will stress that I haven't used modesetting on my skylake at the moment, and since that is severely underpowered (i3) I'm in no rush to try that on a fresh build.

On the skylake, the intel driver installed several things as well as man pages, perhaps not removing them all causes breakage:

/usr/bin/intel-virtual-output
/usr/libexec/xf86-video-intel-backlight-helper
/usr/lib/libIntelXvMC.la.hidden
/usr/lib/libIntelXvMC.so
/usr/lib/libIntelXvMC.so.1
/usr/lib/libIntelXvMC.so.1.0.0
/usr/lib/xorg/modules/drivers/intel_drv.so
/usr/share/polkit-1/actions/org.x.xf86-video-intel.backlight-helper.policy

I just looked over in /usr/share/X11/xorg.conf.d and I just have the standard quirks, evdev, synaptics, and wacom files - looking at my log, it fails to load Modesetting, saying that it's incompatible with this particular chipset. I'm running HD Graphics 4400 with an Intel Core i7-4800MQ.

I wonder if this is related to the Intel QM87 chipset...

Next time I have it booted, I'll try fully uninstalling the intel driver just to make sure

[Douglas R. Reno]

No changes have been made to the intel driver upstream, so we'll stay with our existing snapshot here.

I will be tagging this on my 32-bit system, which normally uses the i915 driver in the kernel because of it's 945GM chipset

[Douglas R. Reno]

No changes have been made to the intel driver upstream since our last release.

[Xi Ruoyao]

Bye xf86-video-intel.