SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Is this driver _better_ for anyone than 2.14.0? Speak now, because it is about to be reverted. I have not heard anything positive so far.
It fix several KDE relatated issues and I tested successfully on 17 i915 video / G31 based machines, with different mem/proc configuration. Of course, all desktops.
Technically, it's just a bug-fixes release, no serious enhancements.
Code:
Release 2.15.0 (2011-04-14)
==============================
We are pleased to announce this major release of the xf86-video-intel
driver, roughly on schedule at 3 months since 2.14.0. With the many bug
fixes in this release, we encourage everyone to upgrade to 2.14.
The priority for this quarter has been simply to be unexciting and stabilise
the driver further, seeking to capitalise upon the improvements elsewhere
in the stack.
Bugs fixed in this snapshot (compared to 2.14.903)
--------------------------------------------------
* Turn off relaxed fencing by default for older chipsets
This was continuing to destabilize those system, so for the release
we disabled the feature. If you wish to help us debug this, you can
re-enable the optimisation with Option "RelaxedFencing" "True".
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36147 <-- Not tested. Everything works fine.
* Build fix for xserver-1.7.7
* KDE glitches on SNB
[Technically fixed in the previous snapshot, but I'm really pleased
that this got fixed in time for the release!]
https://bugs.freedesktop.org/show_bug.cgi?id=35808 <-- personaly I experienced a crash in the past! KDM works fine again.
Snapshot 2.14.903 (2011-04-11)
==============================
This is the third release candidate in preparation for the upcoming
2.15.0 release. We will appreciate any feedback we can get from
testing of this snapshot.
There was a bit of churn since 2.14.902 as a potential fix for a
performance regression was tried but had to reverted when it was found to
cause glitches running Compiz on SandyBridge. Otherwise, there were just a
couple of fixes for building against old xservers and running on an
obscure chipset.
Bugs fixed in this snapshot (compared to 2.14.902)
--------------------------------------------------
* Prevent issuing an invalid scanline wait command
https://bugs.freedesktop.org/show_bug.cgi?id=35576 <-- possible crash, not personally experienced
* The 946GZ in not a 945, but a 965.
https://bugs.freedesktop.org/show_bug.cgi?id=35854 <-- possible crash, not personally experienced
* Fix tile sizes for gen2 (finally). <-- possible strange 'pictures'
* Allow building of recent dri2 changes against old xservers.
Snapshot 2.14.902 (2011-03-29)
==============================
This is the second release candidate in preparation for the upcoming
2.15.0 release. We will appreciate any feedback we can get from
testing of this snapshot.
As befits testing of release candidates, no major regression was found and
a couple more bugs have been fixed.
Bugs fixed in this snapshot (compared to 2.14.901)
--------------------------------------------------
* Clients disappearing with pending swaps
* Incorrect clipping of Xv output on i915 across extended desktops
https://bugs.freedesktop.org/show_bug.cgi?id=35346
* Introduction of a LinearFramebuffer option. (Defaults to tiled for
performance and power saving.)
Snapshot 2.14.901 (2011-03-02)
==============================
This is the first release candidate in preparation for the upcoming
2.15.0 release. We will appreciate any feedback we can get from
testing of this snapshot.
Still no further along my grandiose plans to improve Render performance,
aside from the performance tuning lower in the stack, instead we have had
a steady stream of bug fixes.
Bugs fixed in this snapshot (compared to 2.14.0)
------------------------------------------------
* Green pixels within partially off-screen video playback
https://bugs.freedesktop.org/show_bug.cgi?id=24767 <-- bad 'pictures'
* Defer creation of the glyph cache to generation startup
https://bugs.freedesktop.org/show_bug.cgi?id=33412 <-- personally, I experienced a crash in the past.
* Incorrect maximum addresses for video decoder state
https://bugs.freedesktop.org/show_bug.cgi?id=34017
* Failure to handle oversized temporary surfaces
https://bugs.freedesktop.org/show_bug.cgi?id=34399 <-- personally, I experienced a crash in the past.
* Relaxed tiling corruption on gen2
* Crash when destroying a foreign DRI drawable
https://bugs.freedesktop.org/show_bug.cgi?id=34787 <-- personally, I experienced a crash in the past.
As rest of used graphical stack for Intel target:
libdrm-2.4.25
Mesa-7.10.2
Last edited by Darth Vader; 04-18-2011 at 05:38 PM.
1 members found this post helpful.
Click here to see the post LQ members have rated as the most helpful post in this thread.
It fix several KDE relatated issues and I tested successfully on 17 i915 video / G31 based machines, with different mem/proc configuration. Of course, all desktops.
Technically, it's just a bug-fixes release, no serious enhancements.
Yes, that's the upstream story. So, are you saying that the previous Intel driver crashed FOR YOU, and this one does not? I'm just looking for some data here. Both the new driver and the old driver work fine for me. However, I was not getting crash reports on the previous driver, but there are some on the new one. Either way, these are the two drivers that will ship. I'm just wondering which one is the better default.
Yes, that's the upstream story. So, are you saying that the previous Intel driver crashed FOR YOU, and this one does not? I'm just looking for some data here. Both the new driver and the old driver work fine for me. However, I was not getting crash reports on the previous driver, but there are some on the new one. Either way, these are the two drivers that will ship. I'm just wondering which one is the better default.
For what it is worth, my experience is that the old driver is slightly less problematic although I experienced X crashes with both drivers. The difference is that I knew how to avoid the crash with the old Intel driver: don't run GL Xscreensavers when compositing is enabled. With the new driver, crashes are frequent, although not as predictable. Xscreensavers seem to cause a hard lock sometimes, but most of the time it runs fine (GL screensavers included). Other times, X crashes and dumps me at the console but I have seen no pattern for when.
Yes, that's the upstream story. So, are you saying that the previous Intel driver crashed FOR YOU, and this one does not? I'm just looking for some data here. Both the new driver and the old driver work fine for me. However, I was not getting crash reports on the previous driver, but there are some on the new one. Either way, these are the two drivers that will ship. I'm just wondering which one is the better default.
Yes, I experienced (some) problems with 2.14.0, avoided by 2.15.0. This driver version looks to work fine into i915 target.
Still, we talk about some typical 'company' computers, then a typical installation with no fancy graphics beyond these offered by KDE4, but very important, a functional KDM with no crashes.
As bottom line, give me one day, and I will watch especially these Intel computers. I will report again, tomorrow, any observed problem.
Is this driver _better_ for anyone than 2.14.0? Speak now, because it is about to be reverted. I have not heard anything positive so far.
Revert that sucker
GMA 3150 (Pineview), GMA950 and GMA X4500 (i915 driver), with 2.14 and mesa 7.10 work great in KDE with effects on for us. I've experienced the same window redraw hesitation with 2.15 as reported in another thread, with either version of Mesa and libdrm. The hesitation is far more profound on the 3150 and 950.
I did have to modify /etc/kde/kdm/kdmrc and set TerminateServer=True to avoid a KDM segfault on logout. Not sure what that's about - but seems to be common enough with Intel GPUs that Google was able to point me in the right direction.
---edit---
I should note - both drivers are stable. It just seems (to me) that 2.14 gives better performance. Wouldn't bother me if I had to install a different driver from testing. Not the first time this has happened with Intel
Last edited by disturbed1; 04-18-2011 at 06:47 PM.
I thought that new development features would be going into the 2.7.x branch... no?
No -- that won't be the case -- there's several things I (we) will be doing:
* Baselining 2.6.1 as "stable"
* Moving to Git
* NO MORE 2.7.X as "unstable"
* Incremental updates/topics developed on different branches
* Preview releases of proposed features/bugs.
* Code merged -- releases happen 2.6.2, 2.6.3, etc... 2.7.0
There'll be no longer this gulf between stable/unstable -- it's all going to be incremental from now on.
I only updated 2.7.0 as the unstable version wasn't still at 2.5.32.
I should note - both drivers are stable. It just seems (to me) that 2.14 gives better performance.
I believe, the both drivers will be at same performance if you chose to add into xorg.conf:
Code:
Option "RelaxedFencing" "True"
PS. This is just required to be added for new chipsets, to ensure stability on some old chipsets, nothing more. Just add this line in your video driver section and you'll be happy.
Last edited by Darth Vader; 04-18-2011 at 07:23 PM.
I belive, the both drivers will be at same performance if you chose to add into xorg.conf:
Code:
Option "RelaxedFencing" "True"
PS. This is just required to be added for new chipsets, to ensure stability on some old chipsets, nothing more. Just add this line in your video driver section and you'll be happy.
Ummm no -
Relaxed Fencing in enabled by default for Pineview + already, and disabled for older chipsets because it is buggy.
Quote:
Turn relaxed-fencing off by default for older (pre-G33) chipsets
There are still too many unresolved bugs, typically GPU hangs, that are related to using relaxed fencing (i.e. only allocating the minimal amount of memory required for a buffer) on older hardware, so turn off the feature by default for the release.
Well, considering how quickly 4^H2.6.1 was released, I think it's at least fair to say that 4^H2.6.0 was bleeding edge. If we see 4^H2.6.2 within a month, it's probably fair to say that about 4^H2.6.1, too.
Although I understand the reasoning, I'm not quite sure it applies to FVWM.
I've been running various "unstable" FVWM versions for the last 13.37 years or so, on Slackware versions 10.0, 10.2, and 12.2 with not a single issue.
In fact a lot of more active projects have often left me in the cold. KDE and mplayer pop in mind (but I'd hate to see them left out) and other more obscure software has found its way in Bob's den (e.g.virtuoso).
Anyway, 13.37 should be so close now, that it wouldn't be wise to delay it any longer, barring security issues.
Slackware current, kernel-2.6.38.3-smp, AlienBob's KDE-4.6.2, Mesa-7.10.2, libdrm-2.4.25 and a custom xf86-video-intel-2.15.0, compiled against libdrm-2.4.25.
Last night, very late, I forgot to mention that we use this option. I know, I know, in a Perfect World you do not need it, but the graphics stack is not perfect.
However, now I know that 'something strange will happen' without it.
Let me continue...
Another change, which is somewhat strange, is in /usr/bin/startkde:
Code:
#!/bin/sh
#
# DEFAULT KDE STARTUP SCRIPT ( 4.6.2 (4.6.2) )
#
# KWIN workaround
export KWIN_DIRECT_GL=1
if test "x$1" = x--failsafe; then
KDE_FAILSAFE=1 # General failsafe flag
KWIN_COMPOSE=N # Disable KWin's compositing
export KWIN_COMPOSE KDE_FAILSAFE
fi
# When the X server dies we get a HUP signal from xinit. We must ignore it
A rational explanation:
KWin uses OpenGL renderer string to get some information. But these happy lads from Mesa have decided to change the structure of this information.
With this parameter, we say to KWin, as it has direct rendering.
KWin with KWIN_DIRECT_GL parameter:
Code:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) G33 x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.10.2
Driver: Intel
GPU class: i915/i945
OpenGL version: 1.4
Mesa version: 7.10.2
X server version: 1.9.5
Linux kernel version: 2.6.38
Direct rendering: yes
Requires strict binding: yes
GLSL shaders: no
Texture NPOT support: yes
KWin without KWIN_DIRECT_GL parameter:
Code:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) G33 x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.10.2
Driver: Intel
GPU class: i915/i945
OpenGL version: 1.4
Mesa version: 7.10.2
X server version: 1.9.5
Linux kernel version: 2.6.38
Direct rendering: no
Requires strict binding: yes
GLSL shaders: no
Texture NPOT support: limited
Why do we need to properly inform KWin? For proper management of crisis situations. Read: crash.
And, mysteriously, the blur effect works again.
The third important element of our configuration is:
Finally, the system looks responsive, everything works. Let's try to ruin it!
We use three methods to break the system:
1. We watch a clip on Youtube in 720p HD format. Full-screen and back, is efficient enough 'to see the console'.
2. The glorious OpenGL screensaver. You can be sure that something bad will happen. Here, our favorite will be Atlantis.
3. Logout into KDM screen. But here we already know, 'we have problems'.
Phase 1.
Initial system.
1. The video runs smoothly, full screen and back.
2. We test Atlantis. The first test works, then, KWin crack, and he comes back, without 3D effects. The system is still perfectly functional, but KWin's effects are not enabled.
3. Logout works.
This is exactly the behavior you expect. KWin has to disable the OpenGL effects of a crash.
Phase 2.
We install the stock 2.15.0 video driver, and we comment TerminateServer. Reboot.
1. The video runs smoothly, full screen and back. But it has moments of stuttering when we get into full-screen.
2. No major changes on Atlantis. KWin crash on first shoot and it comes back without effects.
3. Logout fails and we see the console. Goodbye, KDM!
Overall, the system feels a bit slower.
Phase 3.
We install Mesa-7.9.2 and libdrm-2.4.23. Reboot.
1. No major changes.
2. No major changes.
3. No major changes.
Overall, the system feels yet slower.
Phase 4.
We install the stock 2.14.0 video driver. Reboot.
1. No major changes.
2. X server freeze! But console switching works. We go on first virtual console and we comment the KWIN_DIRECT_GL, then reboot.
3. Can not be tested.
Phase 5.
No changes after reboot.
1. No major changes. 3. Logout into KDM screen works again. Login again.
2. X server crash. We see the console.
Overall, the system not feels slower or faster.
Phase 6.
We activate the defaultScale method: Accurate.
1. The clip sees framed.
2. No changes.
3. No changes.
Overall, the system feels slooooooow.
--------------
That's it. It's time to repair this system.
Last edited by Darth Vader; 04-19-2011 at 01:53 PM.
Reason: Messed with libdrm version on Phase 3
Does anyone know what version of wicd is included in the next release?
There is a pretty wicked bug in 1.6x that makes it hard (some times imposible?) to connect to networks with hidden SSID. Also some networks with visible SSID showes as <hidden> and makes them difficult to connect to.
I haven't experienced any problems with wicd 1.7.
Last edited by Dinithion; 04-21-2011 at 05:14 AM.
Reason: Had to exploit the wicked pun.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
