Lost Desktop Effects - Intel 945GM video, Dell Latitude D620 [WORK-AROUND]

[horusfalcon]

It's been over a year since this last happened, I think, but, suddenly, I no longer have my desktop effects.  When I try to re-enable them from KDE 4 Control Center, KWin notifies me that a whole raft of my desktop effects cannot be enabled.

Now, I seem to recall having to delete the ~home/.kde4/share/config/kwin.rc file and restart KDE, but that does things I don't want to my desktop arrangements and customizations, so I dug into my current kwin.rc and compared it to my last backup.  Something jumped out at me right away.  What, pray, can anybody tell me, is this (I'm primarily interested in the last "paragraph")?

update_info=kwin_on_off.upd:kwin_on_off,kwin.upd:kde3.0r1,kwin_focus1.upd:kwin_focus1,kwin_focus2.upd:kwin_focus2,kwin3_plugin.upd:kde3.2

[$Version]
update_info=kwin_on_off.upd:kwin_on_off,kwin.upd:kde3.0r1,kwin_focus2.upd:kwin_focus2,kwin3_plugin.upd:kde3.2,kwin_focus1.upd:kwin_focus1,kwin_blacklist.upd:Blacklist-4.5

[Blacklist][Blur]
Advanced Micro Devices=DRI R600:-:7.8.1,DRI R600:-:7.8.2
Ati=Radeon HD 3650:-:3.3.9901
NVIDIA=GeForce 6150/PCI/SSE2:-:195

[Blacklist][Lanczos]
Advanced Micro Devices=DRI R600:-:7.8.1,DRI R600:-:7.8.2
Intel=GM45 Express Chipset GEM 20100328:-:7.8.2,GM45 Express Chipset GEM 20091221:-:7.7.1,965GM GEM 20100328 2010Q1:-:7.8.2,965GM

Now the driver set for my 945GM is the same as for the 965GM (namely, intel810), so I'm suspecting I was affected by this recent change?  

What was the reason for these blacklist stanzas?  Is this a work-around for a known issue, a security problem, or what?

Doing some reading I've found out that there is data in my ~home/.xsession-errors file that may be relevant:

Mesa DRI Intel(R) 945GM x86/MMX/SSE2
OpenGL version string:                  1.4 Mesa 7.11.2
OpenGL shading language version string: 1.20
Driver:                                 Intel
GPU class:                              i915/i945
OpenGL version:                         1.4
GLSL version:                           1.20
Mesa version:                           7.11.2
X server version:                       1.10.4
Linux kernel version:                   2.6.38
Direct rendering:                       yes
Requires strict binding:                yes
GLSL shaders:                           limited
Texture NPOT support:                   limited

I'm not sure how to proceed here:  should I "unblacklist" the Intel drivers already listed and see if it works (I think I will after I back up this file), or should I add another line to the blacklist?

Later On,
D

[kjpetrie]

http://blog.martin-graesslin.com/blog/2010/07/blacklisting-drivers-for-some-kwin-effects/ explains these sections well.

[Archie]

heya, if your desktop effects had worked before, perhaps you can first check Configure Your Desktop (SystemSettings) > Workspace Appearance and Behavior > Desktop Effects, and go to the Advanced tab. Play around with the Compositing type. Mine works with OpenGL. I'm not sure what works well with Intel ... but one thing for sure, you ain't losing for just trying.

[horusfalcon]

Hi, Gang,

Archie, I had seen the explanation to which you refer, and the grep instruction kinda threw me a curve, so I just opened up my .xsession-errors file in Kate and did some reading, then decided to comment out (precede with #) the lines under the [Blacklist][Lanczos] section relevant to my video card.  Voila, desktop effects are restored.

EDIT:  Per kjpetrie's sage counsel, I have replaced my user name with asterisks in this post.  I really should have known better.  Thanks for the catch!

Prior to the loss, my system had been using OpenGL for compositing, and I know from prior experience that Xrender doesn't support the features I want.  Fortunately, in my notes, I had recorded where to start looking (namely /home/*****/.kde4/share/config/kwinrc), so that saved me a bunch of time getting started on this one.

I don't think this really solves the problem or addresses my knowledge deficit to this point, though, so I'll read some more before I go ahead and mark this [SOLVED] in case there is more of significance to learn and I, maybe, decide to take a different route toward a better solution.

What threw me was this:  grep KWin::CompositingPrefs::detectDriverAndVersion ~/.xsession-errors

That bit with ~/ is a sort of shorthand, but should it not have read ~home/ instead of ~/ ?  When I executed the command as written above, it returned no result, and signaled no error, which is why, when I realized where .xsession-errors resides I executed the following:

grep KWin::CompositingPrefs::detectDriverAndVersion /home/*****/.xsession-errors

which still returned nothing.  An examination of the file, however, produced what I posted earlier.  I had a really rough midnight shift this past week, and it may be affecting how clearly I am thinking right now, so, if I did something stupid, I'm sorry.

I, perhaps, need to become more familiar with how to use grep and with what the Lanczos blacklist is actually there to achieve (some of what Mr. Graesslin said wasn't really all that understandable to me).

Anyhoo, I have a work-around for now, but am blissfully unaware of its unintended consequences.  That doesn't give me a warm, fuzzy feeling so I will be digging a little deeper, yeah.

Later On,
D

[kjpetrie]

Glad it works. If it works reliably the kwinrc must be blacklisting too widely or out of date, as your hardware clearly works. Maybe that's a message for the packager or the upstream patch contributor (wherever it came from).

~/ stands for the home directory of the user who calls it, in your case /home/horus/. They are the same. (Incidentally, never publish a real user name online, because someone can then try to brute-force the password. root is not allowed to log in remotely by default on pclos, but if someone can log in as another user, by sending one password every second for a number of months and there are programs that will do that, and then do the same with the su command until they break the root password, they will get in. What normally stops that is they have to guess the name and the password at the same time, and they have no clue which one was wrong. A good firewall also helps, of course, as does not running any remote log-in servers, but there might come a time when you need to access your machine remotely over the net, and then you would be vulnerable.)

If grep KWin::CompositingPrefs::detectDriverAndVersion ~/.xsession-errors did not produce any output, that simply means ~/.xsession-errors did not contain the string "KWin::CompositingPrefs::detectDriverAndVersion".

[Archie]

I'm also glad you got it sorted out. Supplementing the GUI with a bit of CLI can give users a warm, fuzz feeling.

Peace and much respect,
Archie