[obsolete]Potential solution for xf86-video-intel update issues

Ronin-Sage · 2008-12-03 18:14:53

WARNING: The status quo does *NOT* allow for a simple downgrade of these packages to get normal performance anymore, at least on my system. Since the introduction of the new hotplugging stuff, there's a lot of packages out there that were all upgraded to reflect this, it seems, so things may break if you only downgrade the packages I've listed here. In my case, keyboard input was broken, so this no longer works for me.

_____________________________

Basically, after upgrading xorg-server and several other packages, an issue arose involving TTM(or lack thereof). Hardware isn't my specialty, so I'm not that familiar with the terms, but from I what gathered, GEM technology superceded TTM in nearly xorg-related package's software, but xf86-video-intel, iirc, still relies on using TTM(I'd always get an error message complaining about no TTM support in glxgears). I followed the directions here, albeit replacing 3 things:(the original)

ninian wrote:

fmma wrote:
I have arch linux instaled on a hp 2133 mininote, which has a via chrome graphic chip. So far, I had X running with the "vesa" diver.
I saw now a new verion of the openchrome driver in the announcement section (openchrome 0.2.903-1), which I installed. Part of this process, the xorg-server was re-installed (now to xorg-server 1.5.3-2).
I had a similar situation with a Via-based laptop and although I eventually got the screen, keyboard and mouse working with X.Org 7.4, I had to give up on the touchpad which became completely unusable.
So, here's what I did to downgrade X.Org and recover to what was working before:
Uninstall all the new packages:
# pacman -Rs unichrome-dri libgl mesa xorg-server xf86-video-unichrome
and delete:
# rm /usr/lib/xorg/modules/extensions/libdri.so
then reinstall the older versions of the packages (use eg. http://archlinux.umflint.edu/extra/os/i686/ if necessary):
# pacman -U xorg-server... (1.4.2-2)
# pacman -U mesa... (7.0.3-3)
# pacman -U libgl... (7.0.3-2)
# pacman -U unichrome-dri... (7.0.3)
# pacman -U openchrome... (0.2.902-1)
Note that the new video package is 'xf86-video-openchrome', but the old one is just 'openchrome'.
Then of course add IgnorePkg=etc as required to your /etc/pacman.conf file to avoid future trouble.
I may not have shown the order or details of things 100% right above, but you should get the gist.
(Downgrading mesa and libgl allows glxinfo and glxgears to work again too.)
Hope this helps.

I changed unichrome-dri to intel-dri, openchrome to xf86-video-intel, and noted that /usr/lib/xorg/modules/extensions/libdri.so needed to be changed to /usr/local/lib/xorg/modules/extensions/libdri.so(IN MY CASE, mind you).

Now I can, for instance, get ~2100fps with glxgears with my laptop's graphics system(nothing new for me, just that I'd get ~60fps with the new xorg), which is Intel 945GM Chipset(950GMA)

I can't guarantee that this will work for others, but in my case, it did

_______

^Will very likely break keyboard-related stuff(read above).

Last edited by Ronin-Sage (2009-02-21 07:42:24)

Ronin-Sage · 2008-12-03 18:50:37

[UPDATE]

BTW, I'm not sure if this had anything to do with the (new?) xf86-input-synaptics, but I uninstalled and replaced that package w/ "synaptics"(from the repo hyper-linked above)

Xarathur · 2008-12-03 21:10:26

I think you made a mistake...

You have to ignore the TTM error. If the system doesn't support GEM, it uses the classic mode. There is no problem with that.

glxgears is not a benchmark. The new intel driver shows 60fps because it has VSYNC enabled by default, and this is to fix some video issues, like tearing.

Everything was working as expected.

Last edited by Xarathur (2008-12-03 21:10:52)

Ronin-Sage · 2008-12-04 22:40:29

The thing is, I thought it was just a glxgears issue(and I realize it's not a benchmark), however I ended up getting horrible performance with games after the update.

Lastebil · 2008-12-05 12:04:35

I have to disagree and state that 'everything was working as expected' is certainly not the case with my intel systems - any 3d accelleration that existed prior to the upgrade is now, essentially, gone. And I had been pleasantly surprized that the intel chipsets were capable of doing some limited 3d before.

So yes, there _is_ a problem with the 'classic mode' in that it reduces the performance of 3d on my intel-chipset based xorg desktops.

I'm hoping _downgrading_ xorg is not the actual solution to this (essentially what the original poster has done,) but as of right now, I'm seriously considering it. The sluggishness of the new intel drivers is unbearable in 3d applications. I also don't use HAL, so some of the new items in 1.5 aren't really applicable to my systems; but I'd still like to run 1.5 as it is the current version Arch is providing.

I also realize this is not an Arch issue, but it is something that we'll have to deal with until such time as the Intel driver regains it's 1.4 3d performance.

Onyros · 2008-12-05 15:21:46

Lastebil wrote:

I have to disagree and state that 'everything was working as expected' is certainly not the case with my intel systems - any 3d accelleration that existed prior to the upgrade is now, essentially, gone. And I had been pleasantly surprized that the intel chipsets were capable of doing some limited 3d before.
So yes, there _is_ a problem with the 'classic mode' in that it reduces the performance of 3d on my intel-chipset based xorg desktops.
I'm hoping _downgrading_ xorg is not the actual solution to this (essentially what the original poster has done,) but as of right now, I'm seriously considering it. The sluggishness of the new intel drivers is unbearable in 3d applications. I also don't use HAL, so some of the new items in 1.5 aren't really applicable to my systems; but I'd still like to run 1.5 as it is the current version Arch is providing.
I also realize this is not an Arch issue, but it is something that we'll have to deal with until such time as the Intel driver regains it's 1.4 3d performance.

I'm sad to tell you that downgrading IS the way to, right now. At least until the 2.6.28 kernel is out, which will include Intel's GEM support. And we'll have to see how it goes then, but I don't expect us to ever get the kind of performance we had with 7.3.

The newer Intel chipsets work pretty well with Intel's driver, but older, legacy chipsets are very, very problematic - and I mean anything that worked better with i810 than with Intel's driver before the upgrade, which is the case on my Intel 855GME chipset motherboard. I had to downgrade to Xorg 7.3 and back to i810 to get acceptable performance all around.

Last edited by Onyros (2008-12-05 15:22:42)

patroclo7 · 2008-12-05 16:25:06

The downgrade of performance is notable in any 3d application, and glxgears is perhaps not an accurate benchmark, but gives an idea

Onyros · 2008-12-05 16:54:40

In my case, even window drawing was much slower, painfully so, and I don't run many 3D apps for it to have made such a difference. I really hope it does get better once we have Intel's GEM.

Svlad Cjelli · 2008-12-05 17:16:02

+1
Me neither run any 3d-accelerated games, but the 3d-performance in daily use is really awful...

I really hope that the GEM-thing will solve my problems...

@onyros:

What do you mean with older chipsets?
I got a Intel X3100 (GM 960/965)...
Can i hope to have a better performance with 2.6.28?

And when is the new kernel actually expected to hit the repositories?

Svlad

Onyros · 2008-12-05 18:25:46

Svlad Cjelli wrote:

+1
Me neither run any 3d-accelerated games, but the 3d-performance in daily use is really awful...
I really hope that the GEM-thing will solve my problems...
@onyros:
What do you mean with older chipsets?
I got a Intel X3100 (GM 960/965)...
Can i hope to have a better performance with 2.6.28?
And when is the new kernel actually expected to hit the repositories?
Svlad

Svlad, the chipsets I tried update on are the mentioned 855GME on an Aopen Cube, the EEEPC 701's and the Asus N10JC (Intel 945GSE).

Integrated graphics worked much better on those last two, and horribly on the 855GME. But that doesn't mean it worked perfectly there, there was a notorious performance degradation. We'll see when 2.6.28 comes out, how GEM works out for us, there.

Unfortunately, the Asus N10JC also has a dedicated graphics chip... but as some other people have noticed, nVidia chips don't work well too well with the update as well

Let's hope for the best, I don't know the timetable for the new kernel in Arch, but I suppose it'll take some time, I know a one month period has been mentioned somewhere.

lonecat · 2008-12-05 18:43:46

IMO these upgrades are too early. There shouldn't be a "regression" on any update. I think it should've waited for the 2.28 kernel. And dropping support for nvidia 71xx just because it's old doesn't mean that won't matter. It DOES matter to the users that still use it. There must be a better solution than just "having to stick with it". Cmon, we all chose arch because we think it's the best, or because it suits our needs, but the devs should think on everyone, even on those who don't have access to newer hardware.
Don't get me wrong, I think the upgrade is a big step forward. But I think of this step as trying to run before even knowing how to walk. You'll probably fall the first time. I hope next update will solve all the problems listed here and in most posts on these last days.

Lastebil · 2008-12-06 01:10:34

I did regress, and the performance is quite noticable.

It's unfortunate that this needed to be done on these chipsets, but I can't really put any blame on anyone for 'upgrading too quickly' - as from what I've read in finding how to fix this, quite a bit was done to check to be sure things were going to _work._ And, yes, it did _work_ it is just that the 3d performance in my case, and in some others apparently, is very much a degredation in the system.

From what I see, the biggest difficulty lay in finding out how to do things when things went wrong; while the information was available in the wiki, it was not IMMEDIATELY obvious that the difficulties that were being seen had been addressed. For example, a user, seeing information on the new plugin setup for keyboard/mouse on the wiki might think "ok new plugin system, mentioned halfway down page. _I DON'T USE PLUGINS, WON'T AFFECT ME._" But, of course, it DOES, and it's a major change. Heck, even using the X -config method of making a xorg.conf file does not produce a working setup - and these are things that could have been better documented.

However, that's something that might have needed more testing. I'm not sure anyone saw this as as BIG a change as it was, and really it's been handled fairly well. It's not PERFECT, and certainly I wouldn't put up with this type of performance from a vendor who was charging me for it, but this is stuff folks are doing in their free time - and as such, I can't fault anyone for not spending a complete afternoon documenting everything that might go wrong on the wiki.

In my case, I guess I'm going to see if anyone needs further testing done WITH DOCUMENTATION OF POSSIBLE FIXES for the next upgrade, that of the kernel bit. I have an affected chipset, and I might have time to test. (Problem of course is 'might' - especially with holidays, work, etc.) But maybe a few of us affected can work to get this tested and documented as to the hows and whys - not a 'howto' that skips what the heck is going on, but more of an Arch document, that details not only what is happening, but why, and options.

For example, what to do if you don't use HAL. I don't use HAL. I don't need, or want the overhead of HAL. So this new system that plugs into HAL will be perhaps troublesome if not explained/researched well on my part.

Anyway long post, summary: It wasn't THAT bad. It could be better. Let's see what we can do for the upcoming thing to make it smoother for everyone.

whaler · 2008-12-06 16:26:00

Lastebil wrote:

Anyway long post, summary: It wasn't THAT bad. It could be better. Let's see what we can do for the upcoming thing to make it smoother for everyone.

I think it is pretty bad when X does not start after a -Syu. -Syu should be safe.

In this case (for vanilla ATI users, at least), simply commenting one line in xorg.conf was sufficient, but not at all obvious to casual users. The least we should expect is to get this information *officially* before "upgrading". As it happened, it can only mean that the maintainers had not tested the packages, or they forgot to put out a warning or they didn't care.

moljac024 · 2008-12-06 16:36:03

whaler wrote:

Lastebil wrote:
Anyway long post, summary: It wasn't THAT bad. It could be better. Let's see what we can do for the upcoming thing to make it smoother for everyone.
I think it is pretty bad when X does not start after a -Syu. -Syu should be safe.
In this case (for vanilla ATI users, at least), simply commenting one line in xorg.conf was sufficient, but not at all obvious to casual users. The least we should expect is to get this information *officially* before "upgrading". As it happened, it can only mean that the maintainers had not tested the packages, or they forgot to put out a warning or they didn't care.

There was and still is news about that on the front page.
And you needed to remove that line from xorg.conf because RgbPath is no longer specified for the new X server.
Pacman won't ever touch users config files.

Last edited by moljac024 (2008-12-06 16:53:51)

Onyros · 2008-12-06 16:57:02

moljac024 wrote:

There was and still is news about that on the front page.
And you needed to remove that line from xorg.conf because RgbPath is no longer specified for the new X server.
Pacman can't and won't ever touch users config files.

And I agree with that, completely. Then again, if the tools most people use to create a working X aren't updated as well (Xorg -configure or hwd -x) and won't produce a working config file, that's where there's something wrong.

I love the way Arch works, and these things will, at the very least, make us grow as users, learn from a few mistakes and generally help us go through much worse whenever it may come

No hand-holding whatsoever: Arch takes us for power users. And a power user won't update blindly. I respect that, information was available: it may not have been enough for... well, most people, from what we can gather from the forums. I think there should have been put some emphasis on updating the configuration tools most of us use, too. That's the only criticism I can think about, really. Apart from that, only thing I would have done differently as well, would be having a fallback option for Xorg 7.3, especially for people, like me, that are running on tight space and (perhaps stupidly) clean their package cache.

Last edited by Onyros (2008-12-06 16:58:40)

whaler · 2008-12-06 17:57:38

moljac024 wrote:

There was and still is news about that on the front page.
And you needed to remove that line from xorg.conf because RgbPath is no longer specified for the new X server.
Pacman won't ever touch users config files.

Really? Where?

Some days ago I read about upgrading to X.Org 7.4, here:

http://wiki.archlinux.org/index.php/Xor … otplugging for more information

As far as I can see, there is no mention about the mentioned line in xorg.conf.

One the following upgrades of this morning caused the problems I have mentioned above and elsewhere:

Proceed with installation? [Y/n] y
:: Retrieving packages from core...
automake-1.10.2-1-x... 553,3K
dbus-core-1.2.4-1-x... 370,6K
glib2-2.18.3-1-x86_64 2,4M
kernel26-2.6.27.7-1... 26,6M
man-pages-3.14-1-x86_64 4,2M
pciutils-3.0.3-1-x86_64 266,4K
wpa_supplicant-0.5.... 208,3K
:: Retrieving packages from extra...
xcb-util-0.3.1-1-x86_64 63,7K
cairo-1.8.4-1-x86_64 431,1K
clucene-0.9.21b-1-x... 1125,5K
dbus-1.2.4-1-x86_64 26,1K
dosfstools-3.0.1-1-... 71,0K
fftw-3.2-1-x86_64 2,9M
gpgme-1.1.7-2-x86_64 394,9K
gstreamer0.10-bad-0... 790,4K
xvidcore-1.2.0-1-x86_64 491,5K
gstreamer0.10-bad-p... 454,4K
gstreamer0.10-ffmpe... 2,2M
gstreamer0.10-good-... 836,8K
libsoup-2.24.2.1-1-... 290,4K
wavpack-4.50.1-1-x86_64 128,1K
esound-0.2.41-1-x86_64 93,4K
libv4l-0.5.7-1-x86_64 55,3K
gstreamer0.10-good-... 420,8K
gstreamer0.10-ugly-... 217,9K
gstreamer0.10-ugly-... 116,9K
pango-1.22.3-1-x86_64 673,1K
gtk2-2.14.5-1-x86_64 8,4M
imlib2-1.4.2-2-x86_64 759,1K
libdrm-2.3.1-2-x86_64 81,2K
libgl-7.2-1-x86_64 1058,4K
libspectre-0.2.2-1-... 34,3K
mesa-7.2-1-x86_64 716,6K
ntfs-3g-1.5130-1-x86_64 351,3K
p7zip-4.61-1-x86_64 1832,6K
policykit-0.9-7-x86_64 466,4K
poppler-0.10.1-1-x86_64 4,9M
poppler-qt-0.10.1-1... 208,8K
poppler-qt3-0.10.1-... 34,1K
smbclient-3.2.5-1-x... 14,5M
libpciaccess-0.10.5... 26,1K
xf86-video-ati-6.9.... 723,9K
xf86-video-vesa-2.0... 15,9K
xkeyboard-config-1.... 625,9K
xf86-input-evdev-2.... 12,7K
xorg-server-1.5.3-2... 4,9M
xproto-7.0.14-1-x86_64 77,6K
:: Retrieving packages from community...
arch-firefox-search... 1,6K
kchmviewer-4.0beta3-1 217,9K
checking package integrity...

***

I still think -Syu should be safe, or give explicit warnings, and I have not found any reference to the Rgb issue in xorg.conf on the front page.

Inkaine · 2008-12-06 18:10:50

To get back on the original topic a bit more, sadly the soon to be released kernel 2.6.28 (maybe already on monday?) won't be all that'll be needed. Yes, it will provide us with GEM - but we will need GEM-enabled libdrm and mesa as well. Not sure if we will get these recompiled together with the new kernel as well - and if the last publically released versions of these are enough anyways. All I've read about intel with GEM working was about compiles from git. But we can be hopeful to get decent 3D back by Christmas. For XServer 1.6 (with DRI2) and intel driver 2.6 are due for release before the end of the year.

Edit:

whaler wrote:

[..]

What does that have to do with the topic - and more importantly, why do you quote yourself again including a useless and huge pacman download list?

Last edited by Inkaine (2008-12-06 18:16:42)

lonecat · 2008-12-06 18:45:23

Lastebil wrote:

I did regress, and the performance is quite noticable.
It's unfortunate that this needed to be done on these chipsets, but I can't really put any blame on anyone for 'upgrading too quickly' - as from what I've read in finding how to fix this, quite a bit was done to check to be sure things were going to _work._ And, yes, it did _work_ it is just that the 3d performance in my case, and in some others apparently, is very much a degredation in the system.
From what I see, the biggest difficulty lay in finding out how to do things when things went wrong; while the information was available in the wiki, it was not IMMEDIATELY obvious that the difficulties that were being seen had been addressed. For example, a user, seeing information on the new plugin setup for keyboard/mouse on the wiki might think "ok new plugin system, mentioned halfway down page. _I DON'T USE PLUGINS, WON'T AFFECT ME._" But, of course, it DOES, and it's a major change. Heck, even using the X -config method of making a xorg.conf file does not produce a working setup - and these are things that could have been better documented.
However, that's something that might have needed more testing. I'm not sure anyone saw this as as BIG a change as it was, and really it's been handled fairly well. It's not PERFECT, and certainly I wouldn't put up with this type of performance from a vendor who was charging me for it, but this is stuff folks are doing in their free time - and as such, I can't fault anyone for not spending a complete afternoon documenting everything that might go wrong on the wiki.
In my case, I guess I'm going to see if anyone needs further testing done WITH DOCUMENTATION OF POSSIBLE FIXES for the next upgrade, that of the kernel bit. I have an affected chipset, and I might have time to test. (Problem of course is 'might' - especially with holidays, work, etc.) But maybe a few of us affected can work to get this tested and documented as to the hows and whys - not a 'howto' that skips what the heck is going on, but more of an Arch document, that details not only what is happening, but why, and options.
For example, what to do if you don't use HAL. I don't use HAL. I don't need, or want the overhead of HAL. So this new system that plugs into HAL will be perhaps troublesome if not explained/researched well on my part.
Anyway long post, summary: It wasn't THAT bad. It could be better. Let's see what we can do for the upcoming thing to make it smoother for everyone.

It wasn't meant to blame, that would be useless... I think we post because we can *suggest* other ways. It can be also used as brainstorming for next similar-case scenarios. We normal users non-developers, non-knowledge full guys, just normal people who use arch for their studies, games or something more desktop related, *should* contribute, at least with ideas, comments, and suggestions.

Again, don't get me wrong, I love how arch people do stuff. But that doesn't mean they're perfect. Therefore, some of us can post improvement suggestions.

The problem wasn't THAT bad, sure. But it was bad. And my point was, as stated by whaler, a pacman -Syu shouldn't bring any regression. In fact, if i knew that was going to happen I wouldn't have done it. I did it thinking the opposite would happen, hoping for a better, more secure system, and of course faster (who doesn't want that). It wasn't perfect, but that was expected, such as with major upgrades, for example think of a python 3.0 update... what would you expect? sure, python 3.0 will be faster, and better sure, but it also does not have backwards compatibility (as far as i know....please correct me if I'm wrong), therefore the apps you would expect to be faster, may even not run. That's no reason to blame anyone, since everyone is thinking of better software right? think about a possible solution. THAT'S the brainstorming I'm talking about. My 2 cents: the future is ready...then let's prepare for it

@Arch Devs: Thanks for the best linux Distro ever!

whaler · 2008-12-06 19:01:19

Inkaine wrote:

What does that have to do with the topic - and more importantly, why do you quote yourself again including a useless and huge pacman download list?

The latter is an obvious error on my part. I'll see if I can at least edit it smaller...

My comments are replies to claims made by others.

vader · 2008-12-10 10:00:18

Just thought I'd add to the discussion

I also upgraded xorg the other day and was shocked that it didn't boot, however it took all of about a minute to work out what was wrong (Xorg.log is a wonderful thing

Glxgears was also a shock, but a few minutes on google explained the vsync thing. I don't notice any real slowdown with games (open arena, tuxracer, bzflag...), but eduke32 won't go full screen - not a biggy.

On the plus side, there is no longer any screen corruption with menus, or starting games (sometimes tuxracer would corrupt fonts etc). I am using Xfce4, and menus would initially come up garbled, only to sort themselves out (few tenths of a second). Overall, I am not unhappy, compositing works better, games are still playable, there is no corruption - I just can't impress people with stunning glgears results (well for an eeepc anyway).

When .28 comes out, I'll recompile my kernel, and hopefully be pleasantly surprised. Still think Arch rocks!

cheers.

Slack · 2008-12-12 11:17:28

Thanks, I downgraded my system with those packages and the video is much better

hoschi · 2008-12-17 21:12:44

Thanks, I downgraded my system too!
Doubled performance in Quake3, wine and Counter-Strike are working again.

TO INTEL:
It is nice that you take care about your products and customers, but to hell:
NEVER AGAIN RELEASE SUCH A CRAP

punter · 2008-12-18 12:06:33

this is not good..... Arch can't expect users to upgrade, and then downgrade, and then upgrade again later - keeping in mind that these changes also involve changes in the config files.

anyways, i've upgraded and i have my config files changed to hot input plugs etc...

when can we expect the new kernel? and would that definitely solve the problem?
I have an Intel 945GM card.

cheers,
Shane

Spider.007 · 2008-12-18 22:10:38

I had a lot of trouble with the Xorg update as well; but don't we all use Archlinux because it is bleeding edge? Can we really blame archlinux-packagers for the problems that Intel or Xorg is causing? I don't think that's fair; especially since a often heard comment is that packages don't get released soon enough. I don't think Archlinux is to blame for these problems.

punter · 2008-12-20 15:05:09

Spider.007 wrote:

I had a lot of trouble with the Xorg update as well; but don't we all use Archlinux because it is bleeding edge? Can we really blame archlinux-packagers for the problems that Intel or Xorg is causing? I don't think that's fair; especially since a often heard comment is that packages don't get released soon enough. I don't think Archlinux is to blame for these problems.

I initially thought you had a good point, but then i thought a little bit more and realised that you deserve a bit of blaming yourself!
don't take this personally, it's addressed to all arch users who have your point of view:

i'm an ex-gentoo member. gentoo's goal is indeed to be bleeding edge, latest software, etc... but arch's goal isn't that at all!
in fact, i switched over (to arch) for the exact opposite reasons that you mentioned above!

let's have a look at arch's homepage:

You've reached the website for Arch Linux, a lightweight and flexible Linux® distribution that tries to Keep It Simple.

not a single word about latest or bleeding edge, but a clear point to simplicity.
next paragraph:

Currently we have official packages optimized for the i686 and x86-64 architectures....

so, arch is about lightness, flexibility, simplicity, and optimized packages....
it is NOT about latest, bleeding edge, kick-ass, configure everything, from-scratch, write-C/C++, etc

i made an effort to get my point across, because the user community needs to support the development team... and users (such as yourself) can pressue the developers to do what's un-intended (i.e. to force arch to compete with gentoo on latest / bleeding edge software).

Arch Linux

#1 2008-12-03 18:14:53

[obsolete]Potential solution for xf86-video-intel update issues

#2 2008-12-03 18:50:37

Re: [obsolete]Potential solution for xf86-video-intel update issues

#3 2008-12-03 21:10:26

Re: [obsolete]Potential solution for xf86-video-intel update issues

#4 2008-12-04 22:40:29

Re: [obsolete]Potential solution for xf86-video-intel update issues

#5 2008-12-05 12:04:35

Re: [obsolete]Potential solution for xf86-video-intel update issues

#6 2008-12-05 15:21:46

Re: [obsolete]Potential solution for xf86-video-intel update issues

#7 2008-12-05 16:25:06

Re: [obsolete]Potential solution for xf86-video-intel update issues

#8 2008-12-05 16:54:40

Re: [obsolete]Potential solution for xf86-video-intel update issues

#9 2008-12-05 17:16:02

Re: [obsolete]Potential solution for xf86-video-intel update issues

#10 2008-12-05 18:25:46

Re: [obsolete]Potential solution for xf86-video-intel update issues

#11 2008-12-05 18:43:46

Re: [obsolete]Potential solution for xf86-video-intel update issues

#12 2008-12-06 01:10:34

Re: [obsolete]Potential solution for xf86-video-intel update issues

#13 2008-12-06 16:26:00

Re: [obsolete]Potential solution for xf86-video-intel update issues

#14 2008-12-06 16:36:03

Re: [obsolete]Potential solution for xf86-video-intel update issues

#15 2008-12-06 16:57:02

Re: [obsolete]Potential solution for xf86-video-intel update issues

#16 2008-12-06 17:57:38

Re: [obsolete]Potential solution for xf86-video-intel update issues

#17 2008-12-06 18:10:50

Re: [obsolete]Potential solution for xf86-video-intel update issues

#18 2008-12-06 18:45:23

Re: [obsolete]Potential solution for xf86-video-intel update issues

#19 2008-12-06 19:01:19

Re: [obsolete]Potential solution for xf86-video-intel update issues

#20 2008-12-10 10:00:18

Re: [obsolete]Potential solution for xf86-video-intel update issues

#21 2008-12-12 11:17:28

Re: [obsolete]Potential solution for xf86-video-intel update issues

#22 2008-12-17 21:12:44

Re: [obsolete]Potential solution for xf86-video-intel update issues

#23 2008-12-18 12:06:33

Re: [obsolete]Potential solution for xf86-video-intel update issues

#24 2008-12-18 22:10:38

Re: [obsolete]Potential solution for xf86-video-intel update issues

#25 2008-12-20 15:05:09

Re: [obsolete]Potential solution for xf86-video-intel update issues

Board footer