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.
