KDE "display settings" control panel module displays empty window

Bug #1251140 reported by kolen
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
KDE Base Runtime
Fix Released
High
kde-runtime (Ubuntu)
Fix Released
Low
Harald Sitter

Bug Description

I started "Display settings" with entering "display" in alt+f2 dialog, and it displays empty screen.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: kde-runtime 4:4.11.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6
Uname: Linux 3.11.0-13-generic x86_64
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
Date: Thu Nov 14 11:07:38 2013
ExecutablePath: /usr/bin/kcmshell4
InstallationDate: Installed on 2013-10-23 (21 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
MarkForUpload: True
SourcePackage: kde-runtime
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
In , Sayantan Datta (kenzo-zombie) wrote :

After installing the fedora 19, kde desktop, i always find this error, that the display module is empty. I have tried restarting the pc, changing the graphics card (if it were a hardware problem), and even using another monitor.

Yes, I did not install any package after installing fedora. Just the default installation.

Reproducible: Always

Steps to Reproduce:
1. Install fedora 19, kde, or run from live disk
2. Go to display settings
Actual Results:
The display settings have nothing inside it, just the standard buttons, "ok", "cancel" etc.

Expected Results:
Show the current display options. The monitors attached.

Don't have any now, tell me which commands to run, i'll give the outputs.

Revision history for this message
In , adaptee (adaptee) wrote :

Fedora 19 seems to ship kscreen to replace the unmaintained krandr. Run "kcmshell4 --list | grep randr" to see whether kcm_randr is present in your system. But I'm confused by the screeshot.

Revision history for this message
kolen (incredible-angst) wrote :
Changed in kde-runtime:
importance: Unknown → High
status: Unknown → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in kde-runtime (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Arjunak234 (arjunak234-deactivatedaccount) wrote :

Created attachment 84243
Can someone verify whether this patch fixes the issue?

Revision history for this message
In , Harald Sitter (apachelogger) wrote :

from display.cpp:
  addTab( "randr", i18n( "Size && Orientation" ) );
  addTab( "nvidiadisplay", i18n( "Graphics Adaptor" ) );
  addTab( "nvidia3d", i18n( "3D Options" ) );
  addTab( "kgamma", i18n( "Monitor Gamma" ) );
  if ( QApplication::desktop()->isVirtualDesktop() )
    addTab( "xinerama", i18n( "Multiple Monitors" ) );
  addTab( "energy", i18n( "Power Control" ) );

so apparently kcm_display is a meta-kcm containing other KCMs, which in itself seems like a jolly bad idea (compared to systemsettings categories which work at runtime....).

the problem essentially is that (supposedly) neither of those KCMs is installed by fedora and kubuntu anymore (previously only krandr was and that is no replaced by kscreen). I think that pretty much proofs my point that the entire KCM is wrong.

regardless, the appropriate fix here is to add kscreen to the list of *possibley* KCMs to list.

p.s.: please also note that I absolutely did not manage to get this KCM to show up anywhere, so short of kcmshell4 display or krunner->display there appaers to be no way to actually access this thing.

p.p.s.: in the future please attach screenshots to the bug report directly (see the attachments box towards the bottom of the report page).

Revision history for this message
In , Harald Sitter (apachelogger) wrote :

fortunately changes to the way the sub-kcm names come to be tab names will cause at the very least fuzzy strings in the l10n which is not desired for stable changes I presume. therfore I do not see how to solve this issue for 4.11 (short of replacing randr with kscreen which from an upstream POV is wrong)...

best suggestion I have for distributions who use kscreen by default is to swap it in for randr in a distro patch against kcontrol/hardware/display.cpp. not perfectly covering all bases but at least works by default.

upstream I'd rather like the kcm to go away for plasma workspaces 2.

moving bug to general component.

Arjun Ak, please note that while your patch would fix the symptom at a high level it does not qualify for inclusion since the display KCM is not replaced by kscreen, krandr is, and since display is a meta-kcm for krandr&friends making it start *only* kscreen instead would make the KCM pointless.

Revision history for this message
In , Harald Sitter (apachelogger) wrote :
Changed in kde-runtime (Ubuntu):
status: Confirmed → Fix Committed
importance: Undecided → Low
assignee: nobody → Harald Sitter (apachelogger)
Changed in kde-runtime:
status: New → Unknown
Revision history for this message
In , U26 (u26) wrote :

So this was fixed with 4.11 ?

Changed in kde-runtime:
status: Unknown → Fix Released
Changed in kde-runtime (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.