plasma-desktop (KDE factory) acting up?

[Duncan]

Alex Schuster posted on Sun, 31 Oct 2010 20:51:12 +0100 as excerpted:

>> FWIW, it's rather old (4.2 era, when I was switching from kde3 to kde4
>> and still had elements of both installed and running, together), but I
>> still use a generally similar arrangement to the one in the screen shot
>> here:
>> 
>> http://members.cox.net/pu61ic.1inux.dunc4n/
>> 
>> I still have dual monitors in stacked config, tho I'm now running
>> slightly shorter ones, standard US 1080p HD, so the overall resolution
>> is 1920x2160.
> 
> Cool, now this is huge! Um, are these monitors _physically_ on top of
> each other, or side by side?

_Physically_ =:^)

With my last CRTs, I had a 22 inch and a 21 inch (~54 cm), both running at 
1600x1200 (I tried 2048x1536 for awhile, but that was really stretching 
the capacities of the monitors and 1600x1200 was actually clearer, so 
that's what I ended up using), with one physically stacked on the other 
using a couple books as spacers (no stand on the top one, the bottom one 
with a level enough top to make it possible) to get the tilt right.

Of course, 21/22 inch CRTs weigh more than 50 lbs/25 kgs each and are 
quite bulky, so it was quite the sight to see!

My current setup uses dual 22 inch (56 cm) LED backlit LCDs.  They're 
"light as a feather" and very thin -- about 3.5 inch (9 cm) thick at the 
center but mostly about 3/4 inch thick (~2 cm).

I'm using "ball joint" style mounts, actually three of them (not two), one 
on each end of a board mounting the monitors, with one in the center of 
the board mounting the board to the wall.  So each one has independent 
tilt and rotate, with the wall mount enabling me to rotate the entire 
thing by 90 degrees if desired (plus further tilt), so I can switch from 
stacked monitors in landscape mode to side-by-side in portrait, if desired.

(I'm thinking about getting much bigger monitors, actually HDTVs at the 
same 1920x1080 resolution, 37-42 inch (94-107 cm), as big as will 
comfortably fit in the allotted space.  These would again be stationary, 
since they're too big to rotate in the space allotted anyway as well as 
being rather too heavy and awkward to rotate at that size, but they'd very 
nicely fill my wall, and at that size, who /cares/ if they rotate!? =:^)

>> Likely as a result of the additional screen space the dual monitors
>> gives me, I don't actually use as many desktops as I might.
> 
> I might somehow live with only four then.

Once you have the extra screen real-estate to work with, much as you 
mention with the multiple desktops, I don't believe you'll ever go back!

FWIW, my first multiple-screen layout was back in 1998 or so, using MS 
Windows 98.  I had a 19" as my main monitor (CRT of course back then), and 
purchased used a cheap second monitor, 12" or so, at 800x600, that I could 
run my system monitor and a desktop toolbar (MS term, "panel" in *ix 
terms) or two on, getting them off my working desktop.  So I've been using 
the same general strategy for over a decade now.

That old 19" had died by the time I switched to Linux in 2001. (I'd been 
thinking about it for awhile, but the mandatory activation in eXPrivacy 
pushed me over, ironically, given that it was supposed to be anti-piracy 
but would have pushed me /to/ piracy otherwise, since I wasn't about to 
allow MS to dictate whether I could run my desktop or not -- I've always 
said that MS was demonstrated as waaay too good a competitor to have even 
/thought/ about that sort of inconvenience for their user base, given they 
got where they were partly over earlier software requiring dongles, etc, 
because theirs didn't, so regardless of what they argued about monopoly in 
court, that move CONCLUSIVELY demonstrated by ACTION what they actually 
believed -- that they had a monopolistic lock on things so strong they 
could get away with abusing their customers -- but it was at that point I 
became an *eX*-customer!!)  So by then I was actually running TRIPLE 
stacked monitors, all 17" IIRC, at 1024x768 each.  One of my first tasks 
on Linux was learning how to manually configure xf86config (the 
predecessor of xorg.conf) to get all three monitors, two on one card, the 
third on a second card, all working at once, in xinerama mode, stacked 
config.  Unfortunately the automated config tools of the time couldn't 
deal with more than a single monitor, so it HAD to be configured manually. 
=:^(

>> In addition to the several yasp-scripted sysmon
>> plasmoid instances (including one tailing syslog)
> 
> Does the one tailing syslog work like tail --follow=name? That is, when
> the file gets renamed due to log rotation, does it show the new file? My
> plasmoid shows metalog's /var/log/everything/current, but once per day
> this file gets renamed and an empty one is created, which the plasmoid
> does not show then.
> 
> Oh, wait - I googled the yasp plasmoid, downloaded it, and found a tail
> -f command in the yasp_scripts/systemmonitor.script file. So that would
> be easy to change. Oh, there's a directory named duncan-yasp-scripts :)

Yes, all the scripts in that dir are mine. =:^)  I've updated mine locally 
a bit since, including adding one that adapts the previously existing 
syslog tail script that you found, to my own needs.  (Altho here, I don't 
log-rotate the gentoo-default messages log by period, but rather, at boot 
and at shutdown, with an entry in /etc/conf.d/local that moves the files 
to boot and run subdirs.  Then I clean them out manually, every six months 
or so.  /var/log is a separately mounted filesystem, 1.5 gigs IIRC, so I 
don't have to worry about runaway logging using up all available space on 
the rootfs or something.  But since I do boot and shutdown rotation, I 
don't have to worry about that --follow=name bit.)

What's so great about yasp-scripted is that while it does require knowing 
a /bit/ about at /least/ shell scripting if /nothing/ else, since it uses 
the STDOUT of literally any command you care to run, it's as flexible as 
the number of commands one can run on the commandline! =:^)  And if one's 
actually a programmer as well, so can design their own programs to run on 
the command line, not just script together preexisting commands, the 
flexibility is literally unlimited!

I was suitably impressed, enough to not only create my own set of scripts, 
but to submit them to the author, so now they're shipped with the plasmoid 
as further examples. =:^)  BTW, I also subscribe to the comment feed for 
the plasmoid, and along with the author, answer questions as I can.  (I'm 
not a programmer tho, only a sysadmin/bash-scripter, so I let him deal 
with that side of things.)  Open source contribution, people contributing 
back according to the skills they have, at its best. =:^)

> I don't use this feature that often, but I like it, it is very
> convenient sometimes. One of the many things I would miss when going
> away from KDE.
> Even cooler is the feature I mentioned that allows to group windows
> together.

I've seen the window grouping feature mentioned, but apparently, it's not 
implemented in my chosen window decoration (kde2), so I don't use it.  I 
did try switching to a dec that allowed it, but didn't find it all 
/that/ useful for my work flow, and found the limitations (likely early 
implementation bugs, to eventually be worked out) like the fact that kwin 
won't remember the un-grouped window size and return to it when a window 
is returned to un-grouped, rather more frustrating than the level of 
benefit it brought me, at least in the short term trial.  So I returned to 
my old config.

If at some point my chosen window dec gets the grouping feature, or I move 
on to something else, I'll certainly try grouping again, and hopefully 
it'll remember the ungrouped size by then, but as of 4.5.0 or 4.5.1, 
whenever it was that I tried it, it wasn't something I really found 
useful, so...

>> I say "almost-maximized", because I use custom kwin window rules to
>> keep those apps a title-bar's height shorter than full maximized.
>> That way, I can run a half-maxed browser/konsole/whatever on the same
>> bottom monitor and still conveniently click-raise either the
>> almost-maximized app or the other one, without trouble (focus follows
>> mouse policy, click-to-raise, additionally, window transparency allows
>> me to focus the "underneath" app and work in it "thru" the on-top app,
>> when necessary -- this is why I find transparency almost indispensable
>> now).
> 
> Nice.

Yes.  I actually came up with the idea after I found myself maximizing 
vertically, then dragging the window up slightly, so the titlebar was in 
the upper monitor, thus allowing me to use the same offset positioning 
focus technique by using the upper monitor as well as the working 
monitor.  I found myself using it frequently enough when I had a full-
bottom-monitor app running, that I wanted it automated.  What I came up 
with was configuring the apps I always ran maximized (typically multi-pane 
apps like mail, news and feed-readers), to run /almost/ maximized instead, 
so the titlebars of vertically maxed windows would show above the almost-
maximized ones, and I wouldn't have to do the drag-to-slight-offset thing.

The drag-to-side-half-maximize (aka side-docked) thing was what ultimately 
triggered me to do it, tho, because I really like that format for browsing 
and konsole, etc, and kwin /does/ remember the "normal" size and return to 
it as soon as you drag the window off of the side.  Which was frustrating, 
as that was the size I wanted, but as soon as I tried to offset the window 
just onto the top monitor for the offset focus effect, kwin would return 
it to normalized, and I'd have to manually configure the window size back 
to what it had just been when it had been side-docked!  Soon I realized 
that if the maximized windows weren't actually /quite/ maximized, then 
they'd not interfere with the side-docked windows, and all would work as I 
wanted.  And I already knew just how to fix that, using the window rules, 
so I did! =:^)

BTW, when one's already configuring almost-maximized, it's simple enough 
to also check the "no border" option, thus eliminating the titlebar 
entirely.  If almost-maximized is the same size as maximized minus the 
titlebar, no actual window space is lost.  Effectively, then, one ends up 
with something that operates almost like grouped windows with the group 
maximized would operate, but with a twist, there's two or three windows, 
but one is full-maximized, the other two half-maximized.

Perhaps that's another reason I didn't find grouped windows as useful as I 
might have, I came up with something similar on my own, but something that 
operated a bit more in line with my own work flow.  (That was a fresh 
insight just as I wrote the above.  Such insights are one of the benefits 
of discussions like this -- I get such fresh insights often enough while 
writing such replies to justify the definitely non-trivial time spent 
making them! =:^)

> Here: AMD Athlon 4850e dual core @ 2.5 GHz.

If you're dual-core, that's additional reason you shouldn't be seeing such 
a slow-down -- single-CPU really does limit things.  (FWIW, that switch to 
dual-socket back in 2003/2004 was really liberating in that respect, and 
the switch to dual-cores in the same two sockets made things even better.  
But beyond quad-core, at least until better use of real multi-threading 
designed for multi-core becomes much more common, going above 4 cores 
would I believe be about like going to 8 gig RAM was for me, nice, 
especially on from-source distributions like Gentoo, but not something I 
actually use that much other than while compiling, etc.  Above quad-core, 
I think most people will see more immediate effect by putting those 
additional transistors to other uses, bigger L2/L3 cache, arguably, on-
board graphics, etc.  Time will tell, I suppose, and we're already seeing 
it tho upto 8-core there's /some/ additional benefit to more cores, but 
even at that and certainly above that, until programming methods change, 
the extra transistor budget can IMO be better used for other things.  But 
from experience, the update to quad cores is still a quite marked 
improvement that you can look forward to.)

> Wow, that's a difference. I have swappiness=20 already. I will try
> compcache (compressed swap space in RAM, just read about that), let's
> see what this gives.

I haven't tried zram/compcache/etc yet, but I've been following 
developments with some interest.  I'd be interested in your experience.

Meanwhile, something I didn't mention earlier, as it's obviously not your 
problem, but it /does/ change the dynamics of swap and is one reason I use 
swappiness=100:

I'm running four same-size hard drives, using md/kernel RAID.  Most of the 
system is RAID-1, with stuff like the portage tree RAID-0, since I'm a bit 
squeezed on space (they're only 300 gig drives) so the 4X size increase 
over RAID-1 for that is useful, and it's easily downloaded again if the 
RAID-0 dies anyway, so redundancy isn't really needed.

For swap, tho, I use four equally sized partitions, one on each drive, 
using the priority= option set equal for all of them.  What the kernel 
does in that case is automatically stripe them as RAID-0, but without me 
actually configuring them as RAID-0.  So I effectively get 4X drive speed 
on my swap. =:^)

When I set that up, I realized that it was now faster to read/write swap 
than it was to read data in from the mainly RAID-1 main storage, so 
swappiness=100 to encourage the system to actually use swap instead of 
dumping cache and having to read back in the data that it dumped from 
cache, made a lot of sense! =:^)

As I said I don't actually use swap much, due to the 6 or 8 gigs of RAM, 
and not having whatever problem it is you're seeing, but when I do, having 
that 4X drive speed swap is very nice, and actually makes going a gig into 
swap semi-bearable, since it reads in and out at 4X single-drive speed. 
=:^)

(Conversely, I was originally using RAID-6 for the main system, and I 
found to my surprise that even for reads, the RAID-1 is as fast or faster 
in my usage than the theoretically double-speed 4-spindle RAID-6, because 
the kernel I/O scheduler is VERY efficient at parallel jobbing the RAID-1 
reads and my typical usage apparently parallels much better than I had 
expected.)

>> 1)  With a few noted exceptions, my general work pattern closes apps
>> when not in use.
> 
> Not here. I got used to not closing applications, just in case I might
> need them later. This used to work very well, and I think it should. An
> application that is not being used should get swapped out when memory is
> needed, and as long as there is enough swap, there should be no problem.

You're right, there /should/ be no problem.

Actually, with 4 gig plus of RAM, cache should be big enough that in many 
cases, even closed apps will still be in cache and thus not actually have 
to be read back off of disk when reopened, and at least here, I've 
certainly found that to be the case -- one of the reasons I haven't 
switched to leaving apps open more, even when swap should be faster than 
reading it back off of disk for the reasons explained above.

But your case is definitely abnormal, because you've got a memory hog 
that's throwing everything off.  I can't say for certain as your usage is 
enough different than mine to not be directly comparable, but a gig 
resident for plasma-desktop... I'm betting there's a bug you're hitting 
there SOMEWHERE!

> But even when I close additional stuff that is not in the saved session,
> this does not seem to help much. I think, I will have to explore this
> further.

I don't think it'll help much, directly, but what I'd do in your situation 
is try different things until I found what in the world is memory-hogging 
like that, and then see if I could fix that.  But we already know that 
plasma-desktop is one such hog that needs addressed, somehow.

Anyway, a bit of experimentation, closing things, etc, until you find the 
problem, can't be a bad idea, even if it doesn't help much, directly (with 
perhaps, one or two MAJOR exceptions, if you do find the, or a 
contributor, problem).

> Oh, I have many more. Currently, chromium uses 1125 MB. I wrote a little
> shell script that totals the RSS column in the ps aux output.
> 
>> I also don't run servantware (in the context of the sig) apps, so no
>> flash or the like to bug out on me. =:^)
> 
> I don't like flash, but I don't want to miss it either, so I have it
> activated :-/  nspluginviewer often takes lots of CPU, so I kill it
> regularly. The red circles with the white X inside on my desktop are for
> this. I press this about a dozen times a day.

That sounds like a hack I'd do. =:^)  Actually, a few years ago, back in 
kde 3.5 era, when it was just beginning to use xorg's composite extension, 
for a release cycle or so there was a bug that I ended up working around 
in a very similar way.  I forgot what it was called, but kde's composite 
helper would cause X to eat more and more memory (memory leak, the same 
issue I suspect you're experiencing elsewhere), until it would run into a 
ulimit I'd set and crash.

But well before that happened, things would start getting wonky, and after 
I figured out what whas happening when things started going wonky, I'd hit 
the magic killall icon, triggering the script I'd setup to kill kde's 
composite helper and bring things back to normal.

Great minds think alike. =:^)

> Sorry, I see I forgot to write something about that. I was composing a
> similar text in a forum, and got confused.
> pasma-desktop started using > 1G of memory aftert the last upgrade from
> 4.5.1 to 4.5.2. When I logged into KDE after the upgrade, the usual
> KDE-is-starting animations appeared, but when it disappeared, I got a
> black background, and thought something went seriously well. But after
> some minutes, all plasma stuff appeared.
> When I watch the process with top while starting (or restarting after a
> crash), I see memory climbing, until it is at 1.3G, and then I have my
> plasma desktop back.
> 
> So, this problem is new, but before, with KDE 4.5.1, I also experienced
> swapping already, and things were slow. Maybe not _that_ slow as they
> are now.

OK, you definitely have some sort of memory leak or the like with plasma-
desktop 4.5.2, then.

To help isolate the problem, did you change CFLAGS or gcc versions between 
4.5.1 and 4.5.2?

> Hm. I switched to chromium for the reason, that konqueror had a serious
> bug 3-4 months ago. About once per day, I suddenly could not move the
> focus away from konqueror. Or, more specific, from the last widget/area
> inside konqueror that I used. So I could do things in the current tab,
> but not switch them, or access the menu bar. I could switch applications
> by keyboard shortcut, but then this application was only partially
> functional. Took me a while until I found out this is linked to
> konqueror. Finally, I dumped it, and tried chromium, after someone on
> gentoo-user suggested it as being fast. And it was, and actually it used
> less memory than konqueror! Flash worked fine (it also does in
> konqueror, but at that time it didn't), and I did not have a single
> chromium crash since then.

Sounds like chromium is working well for you, then. =:^)

Meanwhile, however, yes, I experienced what I believe to be the same bug 
myself.  It's fixed, and oh, the relief! =:^)  FWIW, at least as I 
experienced the bug (or with the bug I experienced, if different), the 
problem was related to mouse grabs.  Unfortunately, based on what I've 
read, the way X's mouse grabs work, if the mouse is grabbed and not 
released, even killing the app won't fix the issue, and then, restarting X 
is the /only/ way to fix it, since the app isn't even around any longer to 
release its grab.  That seems like a mighty stupid way to implement mouse 
grabs, such that if the app crashes or is killed before the release, the 
only fix is restarting X, but it's apparently part of the X protocol 
legacy, to the point where fixing it would break various apps that depend 
on it working the way it does now. <shrug>

Given the stupidity of the mouse grab implementation, I guess we're lucky 
that *ix and FLOSS in general is as stable as it is... Imagine having to 
deal with the issue constantly, as misbehaving or crashing apps grabbed 
and wouldn't let go...

In my case, the problem seemed to occur most frequently when I hit the 
middle mouse button, pasting into a text input box or the like.  After I 
figured that out, I simply tried not to do that, thus making the problem 
at least survivable until the upgrade that fixed the issue.

> I'm thinking about going back to konqueror, which I still like more. But
> what I like about chromium is that it saves all open tabs when logging
> out, and when I restart it, all is as it was before. Konqueror does
> something similar in KDE4, when I log into KDE I am asked whether I want
> to restore the last session. But it does not work that well, and it
> would open konquerors additionally to the ones saved in my session.

Look for KDE's session management features to become MUCH more common (and 
MUCH less buggy in implementation) over time, as it's one of the *BIG* 
focuses of the plasma project at this time.  Their vision involves merging 
session management with activities, such that each activity will know the 
apps that were running in it, and automatically restart them when it is 
activated.  (BTW, that's one of the reasons they don't want activities 
tied to desktops too strongly, their vision involves apps on all the 
desktops, with the session save and restore linked to the activity, not 
the desktop.)

Simply restoring a set of apps works, to some extent, now.  But the real 
challenge is managing the state, so not only will konqueror (for example) 
restart, but it'll restart with the same web page (and history) loaded on 
each tab, etc.  Similarly, konsole will restart with the same shell 
command history loaded... tho there's complications to work out with 
managing root shells along with their authentication, etc.

(This is why, while I use kde auto-session-save-and-restore functionality 
now, I have konsole, among others, in my session ignore list.  Simply 
restoring a new console session isn't useful to me at all, and is more 
trouble than benefit, when a new konsole window is a couple keystrokes 
away, due to hotkey launcher setup I have configured.)

When/if they get it all working according to their vision, it'll be great, 
but there's quite an extended coding (and debugging) journey to complete, 
before then.

>> 2) I'm running gcc 4.5.1 here, with --as-needed in my LDFLAGS (it's
>> there on Gentoo by default now, but that's a rather new change so if
>> you've not done a full emerge --emptytree @world in awhile...).
> 
> I'm using gcc 4.4.5 and have --as-needed in LDFLAGS, but while I do
> @world updates quite often, I never used --emptytree on this system. I
> Installed it in June when I went from i686 to amd64, using gcc 4.4.4.

Well, if you installed with gcc 4.4.4 and are on 4.4.5 now, then unless 
you did it for other reasons, there's really no need to have done an
--emptytree yet, since that's just a bugfix upgrade in any case.  If you'd 
started with 4.3.x and were now on 4.4.x, however...

I guess that answers the question I asked above about gcc version, tho.  
But changes in cflags might still be an issue.  And while we're on the 
topic, what about revdep-rebuild?  FWIW, I run it as part of the process 
after every upgrade.  (I also always use --update --deep --newuse, and run 
--depclean afterward, as well.)

Meanwhile, I've been running this system since 2004 and gcc 3.something, 
so obviously, I've done a few gcc feature upgrades since then, and when I 
do, I do try to do an --emptytree rebuild, just to keep issues to a 
minimum (as well as ensure that I /can/ build the entire system with the 
new gcc).

> This has been discussed several times on the gentoo-user mailing list,
> and the general consensus there is that recompilation of the whole
> system is not necessary normally, only when the ABI changes, which
> happened the last time when gcc went from 3.3 to 3.4.

True to some extent.

But, remember that libstdc++ is part of gcc, too.  GCC's C++ side 
(including libstdc++) isn't NEARLY as stable as the general C side, and 
with KDE and QT being C++...

However, it's still the case that between micro/bugfix upgrades, an --
emptytree rebuild shouldn't be necessary.  And since that's all you've 
done with the system in question, newly installed with gcc 4.4.4 and now 
on 4.4.5, barring some exotically wicked bug, no --emptytree rebuild 
should have been needed.

But of course what we have here is /exactly/ some exotically wicked bug, 
in plasma-desktop, as it happens.  It's extremely unlikely to have been 
triggered by that gcc upgrade, but at this point, the possibility hasn't 
been eliminated, even if it's very unlikely.

BTW, the thought occurs to me... if 4.5.1 was reasonably fine, but 4.5.2 
is so bad, for whatever bugged out reason, what's the possibility of going 
back to 4.5.1?  If you use FEATURES=buildpkg, you likely even still have 
the binpkgs around, and can do the downgrade without having to recompile 
anything. (I'm on record multiple times as stating that FEATURES=buildpkg 
is my favorite underused portage feature, for a whole list of reasons I'll 
skip ATM, but they're certainly more than simply the rollback ability 
we're talking here.  =:^)

Seriously.  4.5.3 will hopefully have fixed the issue, or 4.6 if it's 
something inherent in where they took 4.5, and in the mean time, 4.5.1 is 
still the 4.5 feature series, so unless there's another bugfix in 4.5.2 
that you can't live without, why not revert, temporarily?

> But hey, why not, my system is running all the time anyway, so even if
> it slows thinsg down, I can let it compile while I am sleeping. I heard
> sone good things about th enew gcc, but thought I'd wait until it is
> considered stable. But when your experiences are good, I'll give it a
> try. So, I would add the graphite USE flag, and add -floop-interchange
> -floop-strip-mine -floop-block to my CFLAGS? I just read that (again) in
> a thread on gentoo-amd64, you were involved there, too :)  Not sure if I
> also should add the lto USE flag and add -flto to CFLAGS as also
> sugestend in the thread.

I'd recommend a bit of caution there, especially since you have an 
existing bug you're trying to work out.  Yes, upgrading to gcc 4.5.1 is a 
reasonable thing to try (especially since gcc-config allows switching 
between gcc versions), and recompiling all of kde with it.  But I'd be a 
bit cautious about trying new CFLAGS that may introduce new bugs.  It 
seems you've got a load on your plate there already.  As you no doubt 
noted from my post to that thread, I did a straight across switch, not 
changing any CFLAGS at all.  It worked well for me, and I can always try 
the new flags later if I want to, but at least now I know for sure that 
any problems it might bring are related to the new CFLAGS, as the system 
builds and functions fine with the old ones.  If you upgrade gcc and 
change CFLAGS at the same time, you do save an extra rebuild with the new 
CFLAGS if everything works, but if something goes wrong, you don't know 
which it was that caused it, the new gcc, or the new CFLAGS.  So better to 
do one at a time.  That's my experience and recommendation, anyway.

>> 3) I know from personal experience that graphics hardware and drivers
>> make a **HUGE** difference in how well kde4 runs.

>> My graphics card is a Radeon hd4650

>> xf86-video-ati-6.13.2
>> xorg-server-1.9.1
>> mesa-7.9
>> libdrm-2.4.22
>> kernel (linus mainline) 2.6.36 (actually a few git commits back
>> from that, 2.6.36-rc8 plus a few commits

> ATI Radeon HD 3200

Well, we know it's not the known Intel graphics issues, then... but 
there's (less severe) known Radeon freedomware drivers issues as well.  
But the latest graphics stack is said to resolve some of that, and with a 
single issue I'll describe below, there's a couple effects that don't work 
quite right or at all, but I can keep them disabled, and no further issues.

> xf86-video-ati-6.13.2
> xorg-server-1.7.7-r1
> mesa-7.8.2
> libdrm-2.4.22
> 
> I had tried newer X servers, but than I had X crash after a minute. And
> I'm not satisfied with the radeon drivers either, I get lots of graphics
> distortion when scrolling in applications. This gets better when I turn
> desktop effects off, which is bad because I like them. Maybe I should
> try the fglrx closed-source driver again, but I had much problems with
> that (but this were older versions), there seemed to be a memory leak,
> and all the swapping was even worse than now.

The single issue I mentioned above is a kernel bug.  4.6.35 was great, but 
a fix in both the early 4.6.36 cycle (before rc1) **AND** in the stable 
4.6.35.x releases (so it's breakage in the STABLE KERNEL SERIES!!), kills 
things for me.  With a single post-2.6.35 git commit reverted, however, 
I'm reasonably fine.

FWIW, the bug is very possibly AGP related, and could well be specific to 
the old AMD 8000 series chipset.  It's also possible it's specific to 
later runs of the Radeon rv730, as the "fix" in the commit I'm rolling 
back was supposed to work around a chip errata in the r700 series, that 
mine, for whatever reason, doesn't seem to have.  The effect is that kde 
dies just after it hits the desktop -- x comes up and I get the kde splash 
screen, but just as it fades out and I see the desktop, everything 
freezes, including the "background-busy" cursor.  I'd normally try magic-
SRQ to get back to the text console, but my keyboard has a hardware issue 
(a bad membrane trace) ATM and the SRQ key doesn't work, so I don't know 
for sure if it's only X that locks up or the whole kernel.  I just bought 
a conductive trace pen to repair the bad keyboard trace, after which I'll 
try to get active on the bug again.  FWIW:

https://bugzilla.kernel.org/show_bug.cgi?id=19002

But back to your case.  It's quite possible that later versions of
xorg-server have fixed whatever it was you had trouble with.  Also note 
that it's switching to udev from hal for input-hotplugging.  The result is 
that you configure that in xorg.conf once again (instead of having to edit 
extremely obscure xml based hal fdi files, I'm DEFINITELY glad that's over 
with!), using a slightly different syntax than the previous input-device 
syntax used.  Also, 1.8 adds /etc/X11/xorg.conf.d/ directory support.  
Basically, instead of a single xorg.conf file, you now can split it into 
multiple files located in this dir, making configuring MUCH easier!  So if 
you can possibly switch to at least xorg-server 1.8, it's worth doing so.  
I'd try both the 1.8.2 and 1.9.1 that are in-tree.  Hopefully one or the 
other works.

> I'm using tuxonice-sources-2.6.34-36. Oh, Tux On Ice. Another of these
> things I put some time into, and that just don't work well. But this is
> the wrong list for this.

I'd also consider upgrading to 2.6.35.  Note that the bug above does not 
affect 2.6.35 itself, but it DOES affect stable series 2.6.35.1 and 
beyond, and 2.6.36.  Very possibly you won't have the bug, especially if 
you graphics are on PCI-E, not the AGP mine are, in which case 
2.6.35.whatever or 2.6.36 will hopefully work for you as well.  Of course, 
if you're on AGP and see that bug above, I'd certainly appreciate a second 
report of it added to my bug filing.

>> I'm seeing the comic-strip-plasmoid related crashes here as well.
> 
> Only the plasmoid, or the plasma-desktop process?

Well, with plasma, everything runs in the same process/thread, so if one 
crashes, it generally takes all of plasma with it, and this is no 
exception.  (That's the one bad side about having all of plasma as a 
single single-threaded app, with all the plasmoids being plugins.  If one 
misbehaves, and that one can be from kdelook or wherever, it takes the 
whole thing with it.  One would think that especially with chromium doing 
the whole every tab in its own isolated VM thing, the plasma folks would 
have chosen a model with better memory and process protection, but... one 
would obviously think wrong in that case...)

>> I have a suspicion that I've not had time to verify.
>> 
>> What version of cairo are you running?  Here:
>> 
>> cairo-1.10.0-r3
> 
> Same here.
> 
>> Apparently cairo 1.10 "changed ownership semantics" in some way vs.
>> previous versions.  That's in quotes because it's very close to the
>> words used by the dev that traced down the non-kde bug I mentioned, and
>> I don't know enough about cairo to have a clue.  But I do know that
>> when he adapted his code to work with the new semantics, it did away
>> with the problem.
>> 
>> Now, if I'm not mistaken, cairo originated as a gtk/gnome vector
>> graphics rendering library, but it's used more widely now, including,
>> it would seem according to equery depends, qt-gui and thus kde.
>> 
>> What I suspect but haven't yet verified is whether masking
>> ~cairo-1.10.0, thus forcing a downgrade to cairo-1.8.10, suddenly
>> resolves this bad comic- strip-plasmoid crashing issue!
>> 
>> Perhaps you could try it and see?
> 
> I did so and logged out and in into KDE. I tried all the comics,
> including the 'Perls Before Swine' compic that never showed something
> (BTW, could you try if this one works for you?), looked good. But then,
> it finally crashed after some more playing with it. That is,
> plasma-desktop crashed, not only this plasmoid.
> BTW2, another annoying thing is that it doe snot keeps the size I give
> it, and gets really small when I change the comic. I always view them
> with the middle mouse button.

So you were able to eventually make it crash, but it wasn't as sensitive 
to crashing as it seems with cairo-1.8.10?

I guess I'll have to roll back cairo myself, and see if it helps me too.  
If it does, we're likely onto something!

>> Moving the plasmoids between activities... used to be possible using
>> the zooming interface, I think, but I don't know how to do it using the
>> new interface.  Of course it should be possible by directly editing
>> that file mentioned above, changing the numbers appropriately, but
>> that's definitely "advanced users only" territory, given the hassle
>> involved ans risk of totally screwing the entire plasma config if one
>> isn't careful.
> 
> Yeah. And I always fear that I make a slight mistake that might trigger
> all sorts of weird side effects, and I will never know.

Yeah.  Surely, at some point they /will/ come up with a more "robust" 
solution in that regard.  As I mentioned earlier, simply splitting the 
single file into a directory and file hierarchy would greatly simplify 
editing AND make things more robust, as well.

> Well, many many thanks for your large mail and the ideas! At least it
> will give me an improved syslog monitor :)

Yeah.  If you find yasp-scripted even half as useful as I have, you'll 
soon find you don't want to do without it! =:^)

Meanwhile, there's an even more powerful option called super-karamba as 
well.  It originated in kde3 as its own independent app, but I never used 
it there.  In kde4, plasma-desktop has direct support for super-karamba 
themes, and I did a bit of research on it before I found yasp-scripted.

But being a bit more advanced, it has a number of more advanced options as 
well, and at the time, I had a number of other kde3 -> kde4 upgrade and app 
substitution issues on my plate to worry about, so I took the simpler yasp-
scripted way out.

However, I've always though that at some point I'll probably look at 
superkaramba again, and switch to it.  FWIW, the ideas are /very/ similar, 
similar types of graphs, etc.  But where yasp-scripted only has vertical 
stacking, which simply matches the ordering of indvidual elements in its 
script file, superkaramba has both vertical and horizontal layout elements 
in its script (in superkaramba, they're called themes) format, with the 
effect being that instead of running about eight different yasp-scripted 
instances, since it only has vertical layout, I could probably do all of 
that with a single superkaramba theme.  Another difference is that 
superkaramba themes can be nested, including other superkaramba themes.  
Both of these features make it a bit more complex to learn, but rather 
more powerful, and I suspect my resource usage would go down some using a 
single plasma-native superkaramba theme plasmoid, compared to the eight I 
run now, with the same layout.  The final difference that I'm aware of is 
that superkaramba (and plasma-desktop, since it does superkaramba themes)
has its own python interpreter builtin, so if you already know and use 
python (it's on my list to learn, I'm reasonable at bash, and was 
reasonable at visual basic back before I dropped servantware, but I don't 
claim anything else), advanced superkaramba themes/scripts should be a 
snap! =:^)

But otherwise the format of the scripts/themes is very similar, as are the 
displays created, and I expect that the knowledge I've gotten from the 
simpler yasp-scripted will transfer quite easily to superkaramba, when I 
decide I'm ready.  Actually, I don't expect the scripts to be terribly 
difficult to port, either, because they /are/ so similar, but I've not 
taken a second look at superkaramba to confirm that, since I actually 
learned yasp-scripted, so it's possible it'll be more complex to port than 
I expect, at this point.

So superkaramba's definitely on my list, but it's not something I'm 
operational on at this point, for sure.  But it's another thing you might 
well find interesting, if you're already finding yasp-scripted 
interesting, which seems to be the case. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.