Bug 494967 - plasma fails to start after KDE-update to 4.2.2-2 (with QT 4.5) from updates-testing
plasma fails to start after KDE-update to 4.2.2-2 (with QT 4.5) from updates-...
Product: Fedora
Classification: Fedora
Component: kdebase-workspace (Show other bugs)
All Linux
low Severity urgent
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2009-04-08 16:41 EDT by Stefan Neufeind
Modified: 2009-07-05 08:44 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-05 08:28:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Problematic plasma-appletsrc (3.01 KB, application/octet-stream)
2009-04-08 19:12 EDT, Stefan Neufeind
no flags Details
Problematic plasmarc (1.71 KB, application/octet-stream)
2009-04-08 19:13 EDT, Stefan Neufeind
no flags Details

  None (edit)
Description Stefan Neufeind 2009-04-08 16:41:15 EDT
Tried updating KDE using update-testing. After problems with kdm fixed by using the koji-build mentioned in #494752 I was able to log into KDE again.

But plasma does not show up. Trying to start it by hand from a console gives:

plasma(3880): ""min" - conversion of "-1,-1" to QSizeF failed"
plasma(3880): ""max" - conversion of "-1,-1" to QSizeF failed"
plasma(3880): ""min" - conversion of "-1,-1" to QSizeF failed"
plasma(3880): ""max" - conversion of "-1,-1" to QSizeF failed"

Didn't find a workaround yet :-( And using KDE without plasma is not much fun :-(
Comment 1 Stefan Neufeind 2009-04-08 17:58:16 EDT
plasma started fine (even starting it by hand while KDE was already running) after simply moving/removing the plasma-configs:


Seems something changed from 4.2.1 to 4.2.2?
Comment 2 Rex Dieter 2009-04-08 18:27:25 EDT
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?
Comment 3 Stefan Neufeind 2009-04-08 19:12:27 EDT
Created attachment 338822 [details]
Problematic plasma-appletsrc
Comment 4 Stefan Neufeind 2009-04-08 19:13:01 EDT
Created attachment 338823 [details]
Problematic plasmarc
Comment 5 Kevin Kofler 2009-04-08 19:22:43 EDT
lines appear to be the offending ones.
Comment 6 Doncho N. Gunchev 2009-04-12 11:27:34 EDT
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...
Comment 7 Doncho N. Gunchev 2009-04-12 11:32:23 EDT
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.
Comment 8 Doncho N. Gunchev 2009-04-12 11:56:25 EDT
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.
Comment 9 Rex Dieter 2009-04-12 14:27:20 EDT
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.
Comment 10 Steven M. Parrish 2009-05-30 21:59:04 EDT
Going to close this since the issue is resolved.  Please feel free to reopen should it return
Comment 11 Stefan Neufeind 2009-06-19 08:04:30 EDT
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.
Comment 12 Steven M. Parrish 2009-07-05 08:28:36 EDT
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:


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:

XFree86 mailing lists:

Red Hat mailing lists:

Steven M. Parrish - KDE Triage Master
                  - PackageKit Triager
Fedora Bugzappers volunteer triage team
Comment 13 Stefan Neufeind 2009-07-05 08:44:27 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.