Installing rawhide packages? (xorg-drv-intel)

[davidy]

Hi I was interested in updating to the xorg intel drivers 2.8.0 which apparently has non-tearing fullscreen composited videos. This would make my life better since I can watch videos while compiz is on.

I have enabled the rawhide repository, and can install the package through yumex. However, i noticed no dependency information was in the repository, and I was afraid of breaking X or kernel by having bad versions. Before I installed (was at the yes/no stage), I saw it didn't autoslurp new X and kernel.

Is there some way to just update this package and all its dependencies without going full rawhide?

[Hlingler]

I have enabled the rawhide repository... and I was afraid of breaking X or kernel by having bad versions.You should be afraid... if you install ANY rawhide packages onto a nice, clean F11 OS, then expect problems.

Go to Fedora Project's Koji build system, and grab whatever you want from there - preferably built for your Fedora Release (F11 ???), and don't get any "Trash" or "Red-Lined" builds because (surprise !!!) they're failures. If necessary: get the F12 ("rawhide") SRPM and re-build it against your OS (you may need to 'tweak' the spec file: compare if necessary to the latest F11 spec file, hammer out the differences manually). You'd need the usual compilers, RPM DevTools, plus a full suite of X Development Libraries & etc.

Start here: http://koji.fedoraproject.org/koji/packageinfo?packageID=7794

V

[Robert2]

the latest xorg-x11-drv-intel package is not yet available, the version in rawhide is a pre-release.

If you want to try, you should pull down at least the kernel, libdrm and xorg-x11-drv-intel. In addition you might want to also pull down the latest mesa, although the version in F11 should be new enough according to the Intel requirements, and hope that none of it hoses your system as rawhide is currently a bit... raw.

yum --enablerepo=rawhide update kernel\* libdrm xorg-x11-drv-intel

Note, if you have a non-PAE 32-bit system, you might have to specifically pull down kernel.i686 from rawhide, as I noticed on my system it was not getting installed due to the change from i586 -> i686 as the arch.

[Demz]

Hi I was interested in updating to the xorg intel drivers 2.8.0 which apparently has non-tearing fullscreen composited videos. This would make my life better since I can watch videos while compiz is on.

I have enabled the rawhide repository, and can install the package through yumex. However, i noticed no dependency information was in the repository, and I was afraid of breaking X or kernel by having bad versions. Before I installed (was at the yes/no stage), I saw it didn't autoslurp new X and kernel.

Is there some way to just update this package and all its dependencies without going full rawhide?

yes there is, dont use rawhide.

[Robert2]

I tried it on my F11 install. But the latest 2.6.31 kernel from rawhide is throwing an exception, real early in the boot process. The effect of this is that graphics are working on the primary display but I cannot configure any other displays, in fact xrandr is claiming I only have one display and all modes are at 0 Hz. Other then that it seems to work.

The below is on a ThinkPad T60 with Intel 945GM


input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:02/input/input6
ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: power state changed by ACPI to D0
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64

=============================================
[ INFO: possible recursive locking detected ]
2.6.31-0.86.rc3.git5.fc12.x86_64 #1
---------------------------------------------
work_for_cpu/84 is trying to acquire lock:
(&adap->bus_lock){+.+...}, at: [<ffffffffa0012880>] i2c_transfer+0x83/0x146 [i2c_core]

but task is already holding lock:
(&adap->bus_lock){+.+...}, at: [<ffffffffa0012880>] i2c_transfer+0x83/0x146 [i2c_core]

other info that might help us debug this:
1 lock held by work_for_cpu/84:
#0: (&adap->bus_lock){+.+...}, at: [<ffffffffa0012880>] i2c_transfer+0x83/0x146 [i2c_core]

stack backtrace:
Pid: 84, comm: work_for_cpu Not tainted 2.6.31-0.86.rc3.git5.fc12.x86_64 #1
Call Trace:
[<ffffffff810955bf>] __lock_acquire+0xb84/0xc0e
[<ffffffff81095737>] lock_acquire+0xee/0x12e
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffff81013a90>] ? restore_args+0x0/0x30
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffff814f16ab>] __mutex_lock_common+0x5b/0x3bf
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffff8109387f>] ? mark_lock+0x3c/0x253
[<ffffffff814f1b32>] mutex_lock_nested+0x4f/0x6b
[<ffffffffa0012880>] ? i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffffa0012880>] i2c_transfer+0x83/0x146 [i2c_core]
[<ffffffffa006de65>] intel_sdvo_write_cmd+0x82/0xf7 [i915]
[<ffffffffa006f610>] intel_sdvo_master_xfer+0xa9/0xdc [i915]
[<ffffffffa001289d>] i2c_transfer+0xa0/0x146 [i2c_core]
[<ffffffffa0037d77>] drm_do_probe_ddc_edid+0x62/0xb2 [drm]
[<ffffffffa0037dfb>] drm_ddc_read_edid+0x34/0xed [drm]
[<ffffffffa0037f87>] drm_get_edid+0xd3/0x190 [drm]
[<ffffffffa006f802>] intel_sdvo_detect+0x9f/0xf0 [i915]
[<ffffffffa00360de>] drm_helper_probe_single_connector_modes+0x97/0x253 [drm]
[<ffffffffa00362ed>] drm_helper_probe_connector_modes+0x53/0xa0 [drm]
[<ffffffffa00367b0>] drm_helper_initial_config+0x39/0x1b0 [drm]
[<ffffffffa0056ab8>] i915_driver_load+0xa84/0xb0e [i915]
[<ffffffffa002c948>] drm_get_dev+0x3b9/0x4d0 [drm]
[<ffffffff814f09ff>] ? thread_return+0x4e/0xd3
[<ffffffff8107a025>] ? do_work_for_cpu+0x0/0x50
[<ffffffffa00775a2>] i915_pci_probe+0x28/0xfc [i915]
[<ffffffff812897af>] local_pci_probe+0x2a/0x42
[<ffffffff8107a04c>] do_work_for_cpu+0x27/0x50
[<ffffffff8107f339>] kthread+0xa5/0xad
[<ffffffff8101412a>] child_rip+0xa/0x20
[<ffffffff81013a90>] ? restore_args+0x0/0x30
[<ffffffff8107f294>] ? kthread+0x0/0xad
[<ffffffff81014120>] ? child_rip+0x0/0x20
async/0 used greatest stack depth: 3744 bytes left
Console: switching to colour frame buffer device 175x65
[drm] TMDS-15: set mode 1600x1200 21
[drm] LVDS-8: set mode 1400x1050 23
[drm] fb0: inteldrmfb frame buffer device
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

[Robert2]

Forgot to mention the RPM packages involved

kernel-2.6.31-0.86.rc3.git5.fc12.x86_64
xorg-x11-drv-intel-2.8.0-0.3.fc12.x86_64
libdrm-2.4.12-0.2.fc12.x86_64
xorg-x11-server-Xorg-1.6.2-2.fc11.x86_64

[Robert2]

Some additional testing shows that the exception does not occur when booting without external display. But when booting with only the LVDS I get severe screen corruption when GDM starts.

For now I backleveled xorg-x11-drv-intel and libdrm to regular F11 versions again. I might try again when the actual 2.8 version of the Intel driver is available in rawhide.

[Robert2]

I opened a bugreport for the EDID backtrace since it is a 2.6.31 kernel issue, and I am also getting it on a full rawhide system.
https://bugzilla.redhat.com/show_bug.cgi?id=513404

[davidy]

Ok thanks for the replies, I might stick with the current system. Im afraid if I trash the kernel, i might not be able to boot to a level where I can revert the packages. I might wait a few months and go ubuntu 9.10 and install the bleeding edge ppas. I will really miss plymouth though ;(

[phoenixpb]

Ok thanks for the replies, I might stick with the current system. Im afraid if I trash the kernel, i might not be able to boot to a level where I can revert the packages. I might wait a few months and go ubuntu 9.10 and install the bleeding edge ppas. I will really miss plymouth though ;(

i use clonezilla to backup my whole system
i have a picture of fedora 11 stable one picture of windows xp and one picture for fedora 12
i can make all the tests i want if something wrong would append i have just to restore the backup of the system (more or less 10 mins)
works with ext3 ext4 fat and so on..
i use version clonezilla-live-1.2-2-25

[jteb]

Just my two cents. I've been using X from git for a long time and didn't have any problems. Except for a few times, when someone did a wrong commit (can't blame them). Though every time that happened, which is only 3 time in the last 9 months or so, it was fixed the next day.

I'm running rawhide, but I like running the X stack from git, as it makes my i915G work with compiz way faster than with the Fedora supplied stack.

If you want to give it a try, I've composed a Python script, based on the bash script on x.org, to compile the whole stack.
Script attached. Rename it to build.py (or just build) and chmod +x it.

Just change it to your needs, all the configuration options are at the top of the script.

Run
$ ./build init
$ ./build modules
$ ./build main
to get the thing running.

You should not set the prefix to /usr right away though, but install in some alternate folder to test the build. If it works, set the prefix to /usr, rebuild and reboot.

Cheers,
Jan

P.S, I know my CFLAGS, CXXFLAGS, MAKEFLAGS, et al are insane. They work just nice for me, so any comments about them are not needed.

[STEVE555]

Hi to all,
I've read this thread with great interest.So I downloaded the build.txt and edited it with a few changes to the ./configure options in Mesa and instead of getting xf86-video-intel,I replaced it xf86-video-nouveau.

After I edited the build.txt,I named as build.py and made it executable.I also created a folder called build and put the edited file in there.

So I ran the three build.py options.When I got to ./build.py main,it couldn't find the xf86-video-nouveau folder.So I just copied the one I have downloaded from git into the build folder and it ran fine.

So I then logged out of my session,seleted console login from K.D.M,and logged into tty3.

I then ran the command:startx -- /opt/build/bin/Xorg
But it came up with this error:

This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.6.99.1
Release Date: (unreleased)
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.31-0.125.4.2.rc5.git2.fc12.i686 i686
Current Operating System: Linux mernivia 2.6.31-0.125.4.2.rc5.git2.fc12.i686 #1 SMP Tue Aug 11 21:20:05 EDT 2009 i686
Build Date: 13 August 2009 12:57:29PM

Current version of pixman: 0.15.21
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Aug 13 13:06:08 2009
(==) Using config file: "/etc/X11/xorg.conf"

Backtrace:
0: /opt/build/bin/Xorg(xorg_backtrace+0x37) [0x80a0c67]
Illegal instruction at address 0x80c0c07

Fatal server error:
Caught signal 4 (Illegal instruction). Server aborting


Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
Please also check the log file at "/var/log/Xorg.0.log" for additional information.

(WW) xf86CloseConsole: KDSETMODE failed: Bad file descriptor
(WW) xf86CloseConsole: VT_GETMODE failed: Bad file descriptor


Can anybody help me to resolve this little problem?

Regards,
STEVE555

[SlowJet]

xorg-x11-drv-intel-2.8.0-6.fc12.i686
xorg-x11-server-common-1.6.2-3.fc11.i586
kernel-PAE-2.6.30.4-25.fc11.i686

Programs may or may not play well together but I doubt they could destroy each other.

SJ

[STEVE555]

Hi Slowjet,
I had just built Xorg from the git repository using the script provided by jteb.
I have specifically made a build folder,and put in opt/build as the install directory.

Thankfully,that was a wise move.
Regards,
STEVE555