Opened 8 years ago

Last modified 4 months ago

#5918 new enhancement

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

Reported by: bdubbs@… Owned by: blfs-book
Priority: normal Milestone: hold
Component: BOOK Version: git
Severity: normal Keywords:
Cc:

Description (last modified by 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.

Attachments (1)

intel.patch (1.9 KB ) - added by Armin K 7 years ago.

Download all attachments as: .zip

Change History (39)

comment:1 by Armin K, 7 years ago

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.

comment:2 by bdubbs@…, 7 years ago

Owner: changed from blfs-book@… to bdubbs@…
Status: newassigned

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

comment:3 by bdubbs@…, 7 years ago

Description: modified (diff)
Summary: xf86-video-intel (placeholder)xf86-video-intel (waiting for 3.0 -- now 2.99.917)

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

Leaving ticket as hold until 3.0 is released.

comment:4 by Armin K, 7 years ago

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

by Armin K, 7 years ago

Attachment: intel.patch added

comment:5 by bdubbs@…, 7 years ago

Removed glamor from this package at revisions 15338 and 15339.

comment:6 by Douglas R. Reno, 7 years ago

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.

comment:7 by bdubbs@…, 7 years ago

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

comment:8 by Armin K, 6 years ago

A snapshot update is in order I think.

comment:9 by bdubbs@…, 6 years ago

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

comment:11 by Armin K, 6 years ago

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

comment:12 by bdubbs@…, 6 years ago

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

comment:13 by Douglas R. Reno, 5 years ago

Going to update it this time. Stand by.

comment:14 by bdubbs@…, 5 years ago

Milestone: holdy-hold

Milestone renamed

comment:15 by Armin K, 5 years ago

Summary: xf86-video-intel (waiting for 3.0 -- now 2.99.917)xf86-video-intel (update to a newer snapshot before BLFS release)

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

comment:16 by bdubbs@…, 4 years ago

Owner: changed from bdubbs@… to blfs-book@…
Status: assignednew

comment:17 by bdubbs@…, 4 years ago

Owner: changed from blfs-book@… to bdubbs@…

comment:18 by bdubbs@…, 4 years ago

Owner: changed from bdubbs@… to blfs-book

comment:19 by Bruce Dubbs, 4 years ago

Milestone: y-holdhold

Milestone renamed

comment:20 by ken@…, 3 years ago

Owner: changed from blfs-book to ken@…

comment:21 by ken@…, 3 years ago

Owner: changed from ken@… to blfs-book

Updated to 20190723 for BLFS-9.0 in r21973

comment:22 by Douglas R. Reno, 2 years ago

Owner: changed from blfs-book to Douglas R. Reno
Status: newassigned

I'll need this for when I build X

comment:23 by Douglas R. Reno, 2 years ago

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>

comment:24 by Douglas R. Reno, 2 years ago

Owner: changed from Douglas R. Reno to blfs-book
Status: assignednew

Added for 9.1 at r22725

comment:25 by Bruce Dubbs, 2 years ago

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/

comment:26 by Pierre Labastie, 2 years ago

Owner: changed from blfs-book to Pierre Labastie
Status: newassigned

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

Last edited 2 years ago by Pierre Labastie (previous) (diff)

comment:27 by Pierre Labastie, 2 years ago

Owner: changed from Pierre Labastie to blfs-book
Status: assignednew

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

comment:28 by Douglas R. Reno, 23 months ago

Owner: changed from blfs-book to Douglas R. Reno
Status: newassigned

I'll take this ticket for 10.0

comment:29 by Douglas R. Reno, 23 months ago

Owner: changed from Douglas R. Reno to blfs-book
Status: assignednew

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

Giving back to the book.

comment:30 by Douglas R. Reno, 16 months ago

Milestone: hold10.1
Owner: changed from blfs-book to Douglas R. Reno
Status: newassigned

I'll do this ticket for 10.1.

comment:31 by Douglas R. Reno, 16 months ago

Milestone: 10.1hold
Owner: changed from Douglas R. Reno to blfs-book
Status: assignednew

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

comment:32 by ken@…, 13 months ago

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).

comment:33 by Douglas R. Reno, 13 months ago

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

comment:34 by Douglas R. Reno, 13 months ago

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.

in reply to:  33 ; comment:35 by ken@…, 13 months ago

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

in reply to:  35 comment:36 by Douglas R. Reno, 13 months ago

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

comment:37 by pierre, 9 months ago

Version: SVNgit

comment:38 by Douglas R. Reno, 4 months ago

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

Note: See TracTickets for help on using tickets.