You are not logged in.
2.7.1 released. Yay...
pacman -R xf86-video-intel
download
./configure
make
make install
reboot
Black screen with white cursor on the top right edge of the screen, typing username and password on blind, hd activity, gnome started, picture stays the same, white cursor, black screen. KMS is enabled...
reboot, boot with my 2.6.30-rc4 custom kernel, same problem...
reboot with live arch usb, mount /dev/sda1, disable gdm in rc.conf, restart, make uninstall, pacman -S xf86-video-intel, reboot, Yay!!!
Disaster, I just wonder if anybody else have the same problem...
Offline
Oops sorry, now I've noticed that default instalation path is /usr/local... gonna recompile with --prefix=/usr
Offline
It works, sorry but I'm so frustrated with intel drivers that first idea that cross my mind is that it's another bug and not my mistake... I hope that random freezing is fixed as they said it would with this driver version. I expect it soon in extra...
Offline
You should have simply changed the PKGBUILD via abs
Offline
You should have simply changed the PKGBUILD via abs
changing the PKGBULD and removing the patching section (apparently patches are already applied to 2.7.1) builds. i just cannot find the change log runs like 2.7.0 here... lets see how stable it is..
EDIT: i found the changelog (OHH SURPRISE!!) within the source code.
EDIT2: and here it is:
Bug fixes since 2.7.0:
* KMS: Hook up output properties for RANDR, (this allows output
properties to be controlled in the KMS case just as in the UMS
case). [Zhenyu Wang <zhenyu.z.wang@intel.com>]
* Fix multiplication error when computing required batch space.
This could fix any number of cases where the driver did
inexplicable things (due to having computed the wrong
size). [Keith Packard <keithp@keithp.com>]
* Hold reference to video binding table until all rects are
painted. This prevent general chaos in the buffer
manager. [Keith Packard <keithp@keithp.com>]
* Split i915 textured video commands to fit into batch
buffers. Video and 3D setup commands share the same batch
buffer, so without this fix, various problems could occur when
video and 3D clients were both heavily active at the same
time. [Keith Packard <keithp@keithp.com>]
* Fix crash with XV with large virtual display (> 2049). [Albert
Damen <albrt@gmx.net>]
* Provide missing value to 3D_STATE_VERTEX_BUFFERS command. We
don't know that this was causing any problem, but the change
does bring the driver into conformance with what the
specification says the hardware requires here. [Keith Packard
<keithp@keithp.com>]
considering the ammount of patch complaining there was, i believe there are 0 changes since 2.7.0 from the repos.
Last edited by eldragon (2009-05-13 13:03:04)
Offline
For now no freezes at least. Same crappy performance but they announced that the performance will stay the same and that these are only bugfixes... Still slow @ repainting message boxes...
Offline
Which problems do you have with intel driver?
With the last update, the X server freezes periodically after 1 or 2 minutes of work, and I need to switch from X server to console using CTRL-ALT-F1 to work again.
I hope to solve this problem with 2.7.1!!!!
Offline
I think it is very hard for everyone developping in the area of graphics (drivers, subsystems etc.) because of all the new stuff that is being incorporated as we speak. Everyone is developping towards a common goal, but somewhere along the way breakage has to happen due to the massive changes (XAA, EXA, UXA - hal - KMS - memory management - randr - etc.)
I believe this is all worth it and trust that the packages in core and extra are functional enough - it's your choice to for testing, so you should be expecting things to break...
Offline
It's true - 2.7.0-3 = 2.7.1 minus some documentation changes. Just look at the patch it contains in svn.
Offline
Which problems do you have with intel driver?
With the last update, the X server freezes periodically after 1 or 2 minutes of work, and I need to switch from X server to console using CTRL-ALT-F1 to work again.
I hope to solve this problem with 2.7.1!!!!
I had a similar problem. I couldn't work at all with such instable machine.
I was so frustrated that I gave up and installed Slackware 12.2.
But Slackware is not my distro, although it is a great one, so I after a couple of days I have installed arch64.
No freezes so far. I hope it will continue this way. No idea why arch64 is more stable, though.
Last edited by ArchArael (2009-05-13 14:56:22)
Offline
In my case it really helped to enable KMS. With 2.6.x KMS was buggy as hell but now I have some glitches without KMS, so maybe enabling KMS can help you?
Offline
This maybe off topic, but you know how you did pacman -R on the last intel driver? That make install will come back to haunt you
Offline
Why? I didn't understood you correctly...
Offline
Yes, this is very disappointing. The mailing list announcement states the following:
PS. The 2.7.1 release is equivalent (other than the version number) to
the 2.7.0.901 release candidate announced earlier.
It also states that:
We have verified that several of the reported bugs of GPU crashes,
(mouse continues to move, but otherwise X is totally unresponsive), are
fixed with the commit by Keith Packard in 2.7.1 to correct the
computation of the batch space required.
But I have been using 2.7.0.901 and have still been getting all sorts of crashes. Once I get to kernel 2.6.30 I can use the intel-gpu-tools described in the annoucement to report the bug:
If the crash persists, please attach the output of intel_gpu_dump
available here (and hopefully packaged in your distribution of choice
soon):git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools
(Requires Linux kernel >= 2.6.30)
Offline
Will we be able to change screen resolution now?
Offline
I dont think so if you use kms, those apps that run in resolution less than your native one still run windowed in full screen...
Offline
It's true - 2.7.0-3 = 2.7.1 minus some documentation changes. Just look at the patch it contains in svn.
Not exactly true: there's been a *huge* unnecessary code deletion.
My blog: blog.marcdeop.com
Jabber ID: damnshock@jabber.org
Offline
fphillips wrote:It's true - 2.7.0-3 = 2.7.1 minus some documentation changes. Just look at the patch it contains in svn.
Not exactly true: there's been a *huge* unnecessary code deletion.
thats a good thing...yet performance shouldnt change (and this is the case here).
Offline
Freezes are still occurring to me with 2.7.1 drivers...
This issue is too annoying, I'm going to try and downgrade to xf86-video-intel-legacy...
Offline
I havent had freezes with 2.7.1. Furthermore with 2.7.0 sometimes my laptop screen gets blank all of a sudden and then back to normal... I've tripped out that maybie the cable is damaged but it isn't, so my guess that driver caused it...
Offline
Furthermore with 2.7.0 sometimes my laptop screen gets blank all of a sudden and then back to normal... I've tripped out that maybie the cable is damaged but it isn't, so my guess that driver caused it...
I get this behavior under totally different drivers (radeon, fglrx). I wonder if it's actually a bug in the server itself.
Offline
combuster wrote:Furthermore with 2.7.0 sometimes my laptop screen gets blank all of a sudden and then back to normal... I've tripped out that maybie the cable is damaged but it isn't, so my guess that driver caused it...
I get this behavior under totally different drivers (radeon, fglrx). I wonder if it's actually a bug in the server itself.
does it have something to do with this?
Offline
ataraxia wrote:combuster wrote:Furthermore with 2.7.0 sometimes my laptop screen gets blank all of a sudden and then back to normal... I've tripped out that maybie the cable is damaged but it isn't, so my guess that driver caused it...
I get this behavior under totally different drivers (radeon, fglrx). I wonder if it's actually a bug in the server itself.
does it have something to do with this?
I don't think so. I don't run Gnome, and my DPMS is set to "Standby: 1200 Suspend: 1800 Off: 2400". When it happens, the affected display goes directly to the "off" state rather than to "standby". Even more weirdly, it seems to happen totally at random (4 times in one day, then not at all for several days. And it's only for one of my displays - the other stays on when it should.
Offline
i dont think the display driver has the hability to completely turn off the display.... id check the power cord....
Offline
I'm not sure, I run gnome and gnome-power-manager so maybe I'm affected by this issue too..
Offline