Bug 494967

plasma started fine (even starting it by hand while KDE was already running) after simply moving/removing the plasma-configs:

/home/user/.kde4/share/config/plasmarc
/home/user/.kde4/share/config/plasma-appletsrc

Seems something changed from 4.2.1 to 4.2.2?

If you still have a copy of those config files, please post them.

No, nothing has changed really with plasma, it's more likely that qt-4.5 is stricter.  What plasma theme/style are you using?

Created attachment 338822 [details]
Problematic plasma-appletsrc

Created attachment 338823 [details]
Problematic plasmarc

Those:
max=-1,-1
min=-1,-1
lines appear to be the offending ones.

I had the same '-1,-1' lines but my problem was 100% CPU usage from plasma.

Moving away both files helped but also killed all extra panel...

One more observation - before I renamed/moved plasmarc plasma was endlessly doing poll and getting -1 (EAGAIN). Now it does poll only when something happens - pressing shift for example.

Finally, only removing the calendar widget from my second panel fixed everything. The max/min = '-1,-1' values do not cause any problem for me (kdebase-workspace-4.2.2-2.fc10.x86_64) when there or when removed, sorry for the spam.

The calender widget = 100% cpu thing is a separate issue, and there's an upstream report (and fix/patch).  I'll work to snag that.

Going to close this since the issue is resolved.  Please feel free to reopen should it return

Appears again for me from time to time. My special case is that I run the Nvidia-drivers (yes, proprietary stuff) in TwinView-mode. Using xrandr I then switch between a full view (both screens), only the external DVI-DFP and only the internal DFP (laptop-screen). Usually I work with the external DVI-connected DFP. But sometimes upon chaning the resolution with xrandr to the Laptop-screen I encounter that plasma died. And trying to start it again reveals that the settings-file seems to be broken then. Removing ~/.kde/share/config/plasmarc makes it start fine again. This definitely worked in the past (KDE 4.x), but does no more since a couple of releases.

Thanks for the report. We are sorry that we cannot help you with your problem, but we are not able to support binary-only drivers. If you would be able to reproduce this issue using only open source software, please, reopen this bug with the additional information, but in meantime I have no choice than to close this bug as CANTFIX (because we really cannot fix it).

The open source 'nouveau' driver (in package xorg-x11-drv-nouveau) is the recommended alternative for users of Nvidia graphic chips.  It is used by default in Fedora 11 and later if you remove any customizations that explicitly set the video driver.  The older "nv" driver may be needed in some cases.  It is also available in older Fedora releases.  Install the packages xorg-x11-drv-nouveau or xorg-x11-drv-nv and override the X server's default choice if necessary.  See https://fedoraproject.org/wiki/Features/NouveauAsDefault for more information.

If you used a non-packaged version of the driver from the Nvidia website please clean your system from additional libraries and software it installed. For users who are experiencing problems installing, configuring, or using the unsupported 3rd party proprietary "nvidia" video driver, Nvidia provides indirect customer support via an online web based support forum.  Nvidia monitors these web forums for commonly reported problems and passes them on to Nvidia engineers for investigation.  Once they've isolated a particular problem, it is often fixed in a future video driver update.

The NVNews Nvidia Linux driver forum is located at:

	http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14

Once you have reported this issue in the Nvidia web forums, others who may have experienced the particular problem may be able to assist.  If there is a real bug occuring, Nvidia will be able to determine this, and will likely resolve the issue in a future driver update for the operating system releases that they officially support.

While Red Hat does not support the proprietary nvidia driver, users requiring technical support may also find the various X.Org, XFree86, and Red Hat mailing lists helpful in finding assistance:

X.Org mailing lists:
	http://www.freedesktop.org/XOrg/XorgMailingLists

XFree86 mailing lists:
	http://www.xfree86.org/sos/lists.html

Red Hat mailing lists:
	https://listman.redhat.com/mailman/listinfo

-- 
Steven M. Parrish - KDE Triage Master
                  - PackageKit Triager
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Well, I experience the problemlem using a "TwinView"-Screen composed of my external DVI-connected monitor and the internal DFP (laptop). It occurs when using xrandr to switch between large TwinView-screen, only external and only internal display.

Since no "nv" or "nouveau" seem to work with my Nvidia NVS 135M yet *sigh* and none of them afaik support something similar to TwinView, I won't be able to reproduce it!


To me it looks like plasma doesn't really like switching the screens (while keeping plasma running), sets some values "out of range" after switch and when shutting down also writes back those "-1" into its configfile. As written, that occured after a specific KDE-update (since I usually track updates-testing closely). So from my point of view it might have something to do with plasma that should be possible to find out ... without starting the usual "binary-only"-flamewar. (Sorry if I misinterpreted your comment.)

One maybe interesting part from the xorg.conf: My modes are configured as

    Option         "metamodes" "DFP-0: 1440x900 +1680+0, DFP-1: 1680x1050 +0+0; DFP-0: 1440x900 +0+0, DFP-1:NULL; DFP-0: NULL, DFP-1: 1680x1050 +0+0"

Where DFP-0 is the internal flatpanal of the laptop. So maybe plasma has problems in the case where the DFP-1 is turned "off" and somewhere inbetween the offset of DFP-0 is moved?