Screen management got magic

As you may know Dan Vrátil and I are working in a brand new screen manager that will solve most of the issues that we currently have on the desktop, making the configuration of monitors either auto-magical or super simple.

We are trying be as smart as possible adapting the behavior of it to each use case making the configuration of monitors as simple as plugging them to your computer.

A video is worth more than a million words:

New KDE Screen Management from Àlex Fiestas on Vimeo.

The behaviors are still not finished and we may change our defaults based on feedback and field test, but eh! it is a start :p

I’d like to personally thanks Red Hat for sponsoring Dan and my employer BlueSystems for letting me squeeze some time to move this forward.

Finally if you want to get this working:

  1. Compile libkscreen
  2. Compile kscreen
  3. qdbus org.kde.kded /kded org.kde.kded.unloadModule randrmonitor
  4. qdbus org.kde.kded /kded org.kde.kded.setModuleAutoloading randrmonitor false
  5. qdbus org.kde.kded /kded org.kde.kded.loadModule kscreen

Enjoy !

  • Pingback: Screen management got magic - Bartle Doo()

  • Johan Ouwerkerk

    Can this be? Multi-monitor that “just works”? It sounds almost too good to be true. Thank you!

    So with that out of the way I’ve got a few questions: have you thought about the case in which I foolishly unplug the monitor while I had windows left on my external screen (say, when it “extends to the right”).

    Or what if more than one external monitor (i.e. VGA + HDMI or display port, KVM switches) are connected? Is it going to be a static layout or something like fvwm where each screen becomes a tile in a configured grid? What about virtual desktops? Would it be possible to assign a virtual desktop to a screen (or vice versa)?

    Integration with activities?

    … Again, thank you for working on this. Especially the fact that each monitor is going to use native resolution out-of-the-box, that should save the world a lot of sore eyes…

    • afiestas

      Right now the windows will be moved to the remaining active output, in the future we want to be able to scale them (in case the resolution changes) and keep the distance to the closer edge, again scaling if the resolution changes.

      I don’t completely understand the “VGA+HDMI+Display port + KVM switches”, can’t you explain further?

      Virtual desktop already work well with extended desktop.

      We don’t have any integration with activities planned, any suggestion of how you would do it?

      • Jojavi

        “We don’t have any integration with activities planned, any suggestion of how you would do it?”

        You are using the activity XXXXXX in the screen 1 and by default it is used by the screen 2 but if you go to the activities options in the screen 2 and you select a different activity YYYYYY screen 1 and 2 will use different activities. Because KDE will remember how was set the screen configuration when you unplug the screen… when you plug it that screen 2 will start that activity YYYYYY from the last time again (of course if that activity isn’t deleted by the user).
        If you can put widgets in the screen 2 and those widgets will be remembered the activities should too (perfect for “only multimedia” activities).

        I don’t find nothing strange in this behavior (what I don’t know is how hard can be done this improvement).

        • Jojavi

          I forgot to say the case when you want use again the same activity in both screens go to the options in the screen 2 and stop that activity, then the one selected should be the used in the Screen 1.

          • afiestas

            So basically what you want is using the set of monitors as “location” to know that you are “in that place” so activity X should be started?

            Sounds a good idea, can you report a bug and assign it as a wish for kscreen? We’ll talk with plasma team and talks things out.

      • Johan Ouwerkerk

        As for the VGA/HDMI/displayport/KVM switches: it looks like the current system was developed with the common case of 1 external monitor. I’m wondering how you intend to “scale” it when there are more monitors connected. Additionally there is of course the one desktop spanning multiple screens idea, i.e. what fvwm used to do with logical “screens” and more recently the “eyefinity” feature of some AMD cards + driver on Windows.

        As for activities: well there are two use-cases that I can see: first of all to assign a monitor/screen to an activity (or vice versa) like “this big screen is for presenting stuff on”, second to remember which window was on which screen as part of the activity session info, so if I switch between activities my windows are moved to the appropriate screens automatically.

        • afiestas

          The system is already prepare for more than 2 screens, right now we are extending to the right making the higher monitor the primary.

          I’m not sure that’s the best configuration but when it comes to more than 2 monitors… guessing the desired configuration is almost impossible.

      • eliasp

        A similar issue are Plasma applets placed on another screen.
        I’m not facing this issue anymore, as I have now a 2nd display at home, but before, it happened to me quite often that I had placed some notes and other widgets on the 2nd display (projector) during a workshop. Once I was back home, I realised I couldn’t access the applets anymore.

        I don’t know whether this would be something which could be handled by this project or if it would take some work on plasma-desktop to take care of this. Any idea?

        • afiestas

          Now the plasmoids will be moved so at the very least you don’t “lose them” but still the support is quite choppy.

          Sebas is working on a new container that will hopefully fix this by stop saving plasmoids with their absolute positions.

  • Martin Stolpe

    This is something which I was missing for a long time in KDE. Thanks for implementing this feature! I’m looing forward for this feature to be completed!

  • IAnjo

    Seems cool, but I guess I miss some kind of UI for all these steps, like modern laptops with windows seem to have.
    This way you could visually have hints for what is happening and for the different steps, a bit like the UI that pops up when you adjust the screen brightness or volume to give you feedback on what you just did.

    • afiestas

      Can’t agree more, that’s something we are currently implementing but it may not be in the first release.

    • george

      Very nice. About UI: I find an alt-tab-like behavour perfect (like the windows win+P combination).

    • Daniel Meissner

      That’s my thought exactly. I love the new features, can’t wait to see them on my machine. But since the workflow is a bit different from the usual “external / internal / clone display”, some visualization would be nice ;-)

  • Mirosław Zalewski

    This will be one of the greatest features of KDE. I think I will switch to Xfce few days before it get public, so I could switch back to KDE again ;) .

    IAnjo: there is a UI for this. It has been covered in earlier blog post:

  • netean

    Brilliant, thank you. This has been needed for a long time and it will be so good when it goes live.

    I know you said it was still in development, but even as it is now, a million Kilometers better than the existing system.

    Thank you


  • BajK

    What am I missing here?
    There are some errors in libkscreen/backends/xrandr/xrandr.cpp: In Elementfunktion »virtual KScreen::Config* XRandR::config() const«:
    that prevent me from compiling libkscreen

  • BajK

    Oh, and my question is: Does it also interface with Phonon? On a friend’s computer I saw, when he plugs in the HDMI cable, Windows 7 the display is extended to the right but also HDMI audio is set the default output so he can enjoy his videos easily. Plug it out again and the internal speakers are used again. I don’t want to have to change my Phonon profile to “HDMI out” all the time in Multi media settings when I want to have sound via HDMI. Of course this is not directly a screen management thing but you want to make stuff as easy as possible, right? :-)
    And from what I can tell there will be a plasmoid that allows you to easily choose common settings (Extend Left, Right, Projector only, etc) using clickable buttons. Would be cool to have this plasmoid opened up by the Change display button and then you can cycle through like you showed in the video (like Windows 7 when you press Meta+P) Awesome work, as always :-)

    • afiestas

      both things will be implemented sooner or later, specially the audio thing since it bugs me as well

  • mercurial vapor 9

    this blog is so good i would come here every dayasdf456sd4f6s4ad6f5

    • nn

      SPAM (check user URL)

  • Ivan

    Huge friggin’ like! (esp for the last configuration restored part)

    And cool that RH is sometimes involved in KDE – haven’t had a clue that it could happen :)

    • afiestas

      They do lots of work in hardware stuff, for example in powerdevil or libsolid :p

  • jonas lihnell

    Hi. Most people that have multiple screens available have habits. They usually know what configurations are useful to them and when you consider *all* possible usecases in one scroll-through-list of confgurations the people that only have one or a few cases that are valuable to them will be spending alot of time waiting for screens to reconfigure.

    I suggest the following solution to this problem:

    In the settings dialogs for managing screens you should list all the configurations and their sorted order and allow people to easily disable and enable use cases as well as sort them as they see fit.

    Once configured I would personally have:

    1. Clone
    2. Extend to the right

    and that’s it, and I wouldn’t have to go through all other use cases to reach “the other one” that I want.

    You should also take into consideration the ideas of work-flow across screens. If I move a movie to screen 2 and close my lid and you then move the movie to screen 1 and put screen 1 on my external monitor, what will happen when I open the lid? Allowing the user to enable/disable features is a highly appreciated feature, I hope you make this system configurable enough to not annoy the people who only want one or two of the good parts from it.

    • afiestas

      Well, we are KDE, we allow configuration :)
      I’m not sure we’ll put this in the main GUI since as you may know we are all about avoiding cluttering but I’m sure we can find a way of doing this (even if we have to resource to some easy json or javascript).

      • jonas lihnell

        I’m fine with just editing a settings file somewhere, but the majority of users would probably prefer to go to their system settings, selecting display and having it there somewhere.

  • Kevin Krammer

    One of my uses cases is using clone but not changing either screen’s resolution.
    I.e. the smaller resolution (usually the external device, e.g. projector) shows only a section of the higher resolution.

    I find this the best possible confiiguration for presentations, since I know exactly what is shown on the projector without having to turn my head or the need of a control monitor, but still having “private” screen sections for presentation notes, etc.

    • afiestas

      Do you think that this is a usecase valid for average users? I think it will be super confusing having the screen cloned but using different sizes.

      Anyway, you will always be able to configure this using the KCM and kscreen will remember the configuration next time you plug it.

      • BajK

        Actually I really liked that feature, I often put both screens on their native resolution, so one has the clipped content of the other, which is much nicer than that blurry out-of-aspect-ratio that you get when both are using the same resolution.

        • afiestas

          Well as I said this is possible with the configuration dialog, and once done the configuration will be remembered :)

  • dwio

    Awesome! When will it be released as stable and merged into the KDE SC?

    • afiestas

      I still have to talk with Dan, but my persona idea is to keep this as an external project as we do with BlueDevil, worked well so far for bluetooth :p

      If what you are asking is “When will it be stable” I hope that within a month.

      • mgraesslin

        I’d prefer to have it part of kde-workspace somehow so that we can easily drop all the current stuff. Doesn’t have to end in the same repo but at least on grouped together with the rest of the stuff.

        • Lukas Tinkl

          That’s my opinion as well, replace kephal & co by kscreen

        • afiestas

          We can get rid of them once kscreen is stable nevertheless (as we did with bluetooth), anyway it is not the moment of deciding that anyway :p lot of things to fix !

  • Pingback: Vídeo: El nuevo y mágico gestor de pantallas de KDE » KDE Blog()

  • Norman

    Wow! Really great! Thank you (and Dan Vrátil) for you work. I hope Dan is still very optimistic to get that hot stuff into 4.10 ;)

    • Dan Vratil

      We decided not to go for KDE 4.10 (it’s too late anyway), but ship it as separate packages for now. It will allow us faster release cycle (more new features, faster bugfixes) then we could if we were shipping with KDE.

      • eric

        thank you so much for this, i never understood why kde had such a bad external monitor manager! when do you plan to release the first package (for kubuntu)?

      • Markus S.

        faster bugfixes

        So you will release bugfixes more often than once per month? ;-)
        And who said you can’t do releases inbetween even as part of the SC? Marble did that at least once. It’s easier to package if one can simply grab a directory of tarballs instead of hunting down individual components.

        Anyway: Great work!

        • afiestas

          Nobody says that, but experience says that distribution won’t package the releases in between.

          It will be a package, probably within extragear, those things are orthogonal.

          • Markus S.

            My personal experience is that openSUSE totally forgot about new KDEWebKit releases and shipped outdated 1.2 packages long after 1.3 (and later even 1.3.1) were released.

            Just saying…

  • Pj

    That looks so awesome! It’s been really needed for quite some time!

    One thing I’d like to ask though: Will it be aware of the “location” you are? I mean, in some programs you can let the program pick your settings, depending on which network you are. That would be really awesome for e.g. laptops, when you change from work/university to home etc. and have a different screen configuration there!

    • afiestas

      That will only work in an ideal situation where you have the same monitors (or with the same features) all across your university or office.

      We’ll see, at the moment we remember configurations based on “group of monitors”, so if you always use the same monitor in the office or in the University kscreen will restore the configuration properly.

      • Pj

        This sounds even better! Thanks a lot again!

  • Blake

    Very nice. So is this replacing Xinerama? Hardware acceleration and compositioning still working?

    What about full screen applications, if I have a TV connected via HDMI and turn it on I’ll be able to drag the movie player to the right past my mother monitors and maximize?

    • afiestas

      Yes that works event without kscreen, thats thanks to kwin and xorg

      • Blake

        I’ve had nothing but terrible experiences with Xinerama in the past, so that’s amazing to hear.
        Just need some support for multiple graphics cards and I’ll be all over linux again in no time,

  • Pascal

    Very very nice!
    It would be cool if it could do some text on each screen so it is easy to identify the screens configuration. In your video you use the sticky notes, but to have On-Screen-Display text on each screen for five seconds would make it easier.
    [main screen] [right of main screen]

    • afiestas

      Indeed, we have planned something like this but it won’t probably come with the first release.

  • Thijs

    Very cool !

    One question regarding the lid closing: Does it also (optionally) inhibit sleep? One common use case for me is to plug my laptop in a docking station-like setup, so external monitor, keyboard, mouse, and work with that when I am in office or on the couch in front of the TV. Currently, I have to manually flip off sleep on lid closing to make this possible. I could use an activity for it, but I’d like to save those for the type of work I’m doing.

    • afiestas

      This will be implemented as well, but it doesn’t right now.

  • ben kevan

    I’d be interested in seeing how applications react to the removal of a screen. With applications that do pop-up, which one is primary? For example, Chromium pop-up go to screen 2 in current deployments of screen management in KDE.

    • afiestas

      Ideally applications should appear in the middle of the screen where your mouse is. This doesn’t work this way and we will have to fix it.

  • volker

    I followed your instructions to install kscreen, kded crashes immediately:

    Thread 1 (Thread 0x7f1164077780 (LWP 4113)):
    [KCrash Handler]
    #5 0x00007f112d49e950 in KScreen::Edid::hash() const () from /usr/lib64/
    #6 0x00007f112d6ad123 in ?? () from /usr/lib64/kde4/
    #7 0x00007f112d6ad1ee in ?? () from /usr/lib64/kde4/
    #8 0x00007f112d6abb3c in KScreenDaemon::applyConfig() () from /usr/lib64/kde4/
    #9 0x00007f112d6ac939 in KScreenDaemon::init() () from /usr/lib64/kde4/
    #10 0x00007f1162ceb0ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/
    #11 0x00007f1162ceb0ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/
    #12 0x00007f112d6b443f in ?? () from /usr/lib64/kde4/
    #13 0x00007f1162ceb0ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/
    #14 0x00007f115fa9516f in QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () from /usr/lib64/
    #15 0x00007f1162cea5de in QObject::event(QEvent*) () from /usr/lib64/
    #16 0x00007f1161e6385c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/

  • Loïc Yhuel

    After some problems, I got it working :)

    It seems to trigger bugs in modesetting (KMS ?) code, as I several times got black screens, solved by a VT switch.
    I loaded the module for the first time with the external monitor plugged, and on unplug it decided to disable the LVDS screen. Then, each time KDE was started, the LVDS (only screen connected) was disabled ! After enabling it with xrandr via ssh, going into display settings and applying the current configuration, it now works properly.

    • afiestas

      This sounds like a bug in our side rather than KMS, well we need more testing :p

  • Markus S.

    Looks nice. Any chance to get per-screen Gamma settings?
    Is the switch widget still in the KCM?

    PS: libkscreen is under GPL and not LGPL. Is that on purpose or just an oversight? LGPL for libraries sounds more natural to me. Maybe it could even clash if a new back-end was GPL-incompatible (who knows which technologies we’ll get in the future).

    • afiestas

      More of an oversight, will talk with the other author and re-licence it.

  • Daniel Nicoletti

    Congrats, it’s already looking awesome!
    It’s really great to see in the video that the switch display
    key now has a use.
    A thing I’d really like it to have is that if you keep
    holding the FN key you had a OSD so that you could
    go switching to the presets, like ALT + TAB:
    so you navigate between clone, switch primary,
    se as left… and so on, and the OSD title could show
    if the screen is the primary one…


    • afiestas

      Not sure if we can or we should use the switch display since some of these keys are implemented poorly doing hardware tricks and it may get messy (my dell XPS1330 always emits events twice for that key).

      But yes, alt+tab thing is something we are going to do.

  • Pingback: KDE: Nueva manera de configurar las pantallas y monitores()

  • Diane Trout

    Thank you so much! This was one of the major features I was missing from Unity. (I plug my laptop into displays all the time).

    (Also more or less works on debian wheezy with kde 4.8.4. Only issue I had was after following the qdbus instructions to switching from xrandrmonitor to kscreen the first time both screens went blank long enough that I felt like rebooting. The system came back up correctly after the reboot.)

    • afiestas

      you need qjson 0.8.1 mind that

  • Felix

    Awesome project! I was quite surprised, that it “just works” on my 4.9.4. machine. And on Arch already so easy to install with yaourt :)

    Just one thing: When running through the different settings with the display buttons, opened windows end updifferently. Once windows landed on the external monitor (e.g. by cloning the output), they stay there ond won’t get back to the laptop screen, even if the laptop screen becomes the primary monitor with the taskbar again.
    I think that it would be a good idea to put them on the primary screen, when unsure. For example, when moving from cloned to etend-to-left mode, all windows should be on the main screen.

    Keep up the good work! Really love it!

  • dan

    Nice, thanks! Could you tell me how to compile this packages (libkscreen, kscreen)?

  • Cédric

    Hello, I don’t know the internal of kscreen, but the “remember the last config” is really a good idea, do you think it is possible the get some sort of id of the plugged screen to have different settings for each connected device ?
    For exemple, when I plug a second monitor, I’d like kscreen remember that I want to extend the desktop, but when I plug a videoprojector, I want a clone mode.
    Would be a very nice addition.

    By the way, I sometime work with an extend on top configuration, I did not see it in the presentation video, will it be available, even if only in advanced options ?

    • BajK

      That’s exactly what this is all about. It will default to “Extend to the right” but when you have plugged in your projector and choose “Clone”, then, whenever you plug in your projector, it will identify it (using the EDID which also carries some unique serial number) and say “Ah, it’s your projector” and use Clone (or whatever you configured your projector to be) mode.

  • Onno Molenkamp

    This is exactly what I was missing in KDE. Great!

    When I loaded kscreen for the first time, kded crashed immediately:

    Thread 1 (Thread 0x7f02fbac2780 (LWP 16316)):
    [KCrash Handler]
    #5 0x00007f02bee9d1b0 in KScreen::Mode::refreshRate() const () from /usr/lib64/
    #6 0x00007f02bf0d2a4e in ?? () from /usr/lib64/kde4/
    #7 0x00007f02bf0d0f72 in KScreenDaemon::saveCurrentConfig() () from /usr/lib64/kde4/
    #8 0x00007f02fa72f5de in QObject::event(QEvent*) () from /usr/lib64/
    #9 0x00007f02f98a885c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/
    #10 0x00007f02f98accda in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/
    #11 0x00007f02fb4bca86 in KApplication::notify(QObject*, QEvent*) () from /usr/lib64/
    #12 0x00007f02fa71abfe in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/
    #13 0x00007f02fa71e561 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/
    #14 0x00007f02fa748f83 in ?? () from /usr/lib64/
    #15 0x00007f02f5e443b5 in g_main_context_dispatch () from /usr/lib64/
    #16 0x00007f02f5e446e8 in ?? () from /usr/lib64/
    #17 0x00007f02f5e447a4 in g_main_context_iteration () from /usr/lib64/
    #18 0x00007f02fa749116 in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib64/
    #19 0x00007f02f9948bee in ?? () from /usr/lib64/
    #20 0x00007f02fa71994f in QEventLoop::processEvents(QFlags) () from /usr/lib64/
    #21 0x00007f02fa719bd8 in QEventLoop::exec(QFlags) () from /usr/lib64/
    #22 0x00007f02fa71e878 in QCoreApplication::exec() () from /usr/lib64/
    #23 0x00007f02e8c6da30 in kdemain () from /usr/lib64/
    #24 0x0000000000408856 in _start ()

    I can’t reproduce this crash.

    When I closed the lid of my laptop, the internal screen seemed to be disabled as expected, but plasma didn’t recognize this: windows and the panel weren’t moved to the external screen. The krandr tray icon did show that the internal screen was disabled.

    xrandr output:

    Screen 0: minimum 320 x 200, current 3600 x 1200, maximum 16384 x 16384
    LVDS connected (normal left inverted right x axis y axis)
    1680×1050 59.9 +

    DisplayPort-0 connected 1920×1200+1680+0 (normal left inverted right x axis y axis) 546mm x 352mm
    1920×1200 60.0*+

    I had to run “xrandr –output LVDS –off” to get it right:

    Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384
    LVDS connected (normal left inverted right x axis y axis)
    1680×1050 59.9 +

    DisplayPort-0 connected 1920×1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm
    1920×1200 60.0*+

  • volker

    I recompiled in debug mode, another crash dump:

    #5 0x00007fc60aeca950 in KScreen::Edid::hash() const () from /usr/lib64/
    #6 0x00007fc60b0d9346 in Serializer::currentId () at kscreen/kded/serializer.cpp:46
    #7 0x00007fc60b0d94dd in Serializer::configExists () at kscreen/kded/serializer.cpp:58
    #8 0x00007fc60b0d7c79 in KScreenDaemon::applyConfig (this=this@entry=0x1e51eb0) at kscreen/kded/daemon.cpp:76
    #9 0x00007fc60b0d83e9 in KScreenDaemon::init (this=0x1e51eb0) at kscreen/kded/daemon.cpp:68
    #10 0x00007fc6237430ff in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/

  • Anselmo L. S. Melo

    Great job!
    I’ve just compiled libkscreen-git and kscreen-git on ArchLinux, ran the qdbus commands and made a quick test. Works like a charm!

  • Pingback: KDE Gains "Magic Monitor" Functionality With New KScreen()

  • volker

    I debugged a little more and found out:

    quint8 *XRandR::outputEdid(int outputId, size_t &len)

    in xrandr.cpp always returns 0

  • Pingback: Testing KScreen packages available for openSUSE - Bartle Doo()

  • Zardoz

    Quick questions:
    – If I go to configuration and I set to Extend to the upper side, it will rememeber it ?
    – There is a way to change the default behaviour of Extend to the right to Extend to the upper side ?
    – It works with VGA output and ATI cards (fglrx and the open source driver)?
    – You try it with touch screens ? Actually which my notebook, when I extend the screen the touch screen input not noticed it and works in a bizarre way.

  • Joe

    Awesome! This is the worst thing in Linux for years. Multiple monitors in Windows has “just worked” for over a decade. This is exactly what I wanted for Christmas! Thanks.

  • AlpheraZ

    Sad sad and painful reminders off just how much behind Linux id compared TO osx or windoz….

  • j

    Great work for make benefit glorious nation of KDE!

    Maybe you can spare a thought on my multi-monitor issue.

    I set myself up with 2xgtx460 and three monitors. The issue was as follows: The middle monitor was a 21″ – the main work and gaming area. The smaller monitors on the side were 19″, one pivoted 90 and the other one 270 degrees, displaying nagios, chats, weather and whatnot.
    Because the middle monitor was obviously the one to burn the most gpu, i wanted it to have a dedicated gtx, while the side monitors had to share the second one.

    Setting this up was not too straightforward. Failing around in kde’s monitor settings, xrandr and nvidia-settings, i had to resort to manually editing xorg.conf. Which of course does not mean I got it to do what I had imagined. The side monitors mostly panicked on the fact that there was another monitor from another card between them. And then you try to figure out the optimal subset of getting hardware acceleration, being able to move windows from one monitor to another, or getting fullscreen flash and games to appear on the center monitor? Ain’t this boogie a mess. Some of it seemed to be driver’s problem, some of it X’s, some might even be the kernel. But I sure am glad someone is interested in this area…

  • Flex

    My use case: I come with my laptop and plug an external (big) monitor to it.
    What I want to happen is that:

    1) monitor will be the primary screen (with the taskbar etc)
    2) laptop’s lcd will be the extension if to left (or right)

    Is this supported (it was the other way in video)?

    • Dan Vratil

      If you are not happy with the magic, you can open Display Configuration KCM and configure it all manually. After applying changes, the configuration will be stored as default for these monitors and next time you plug the external monitor in, it will restore your configuration.

  • Pingback:

  • Joshua

    Any thoughts on handling USB video adapters for a multi-monitor setup? Last I checked X-Windows in general has trouble with them because it initializes the video before it initializes any USB devices.

  • Jacson Querubin

    Congrats Guys!

    Thanks Blue Systems and RH to sponsor this!

    Can’t wait to see major distros having this on default.

    Hope you guys test 3, 4 monitors and other type of displays.

    Cheers from Brazil!.

  • Papierkorb

    Please, for the sake of open source (and my nerves), please also provide a URL to watch the video without flash. Vimeo crashes each time i press play.

  • Fleck

    Hmm, maybe also behavior list, where you can create your own default list… :D Sorry if I am repeating, did not read all the comments! :)

  • derek

    What if I want the extended monitor (screen2) to be up? That’s what I’ve used most recently when writing reports. My setup is similar to to video, where the extended monitor is positioned so it is over my laptop display, so extending up is natural. I realize that it isn’t common, and I wasn’t sure it was possible, but Windows 7 actually handled it without giving me grief.

    With all of the improvements coming out of KDE I may actually jump ship from my current Gnome classic setup.

    • BajK

      Screen above another works but screws up Plasma panels somehow unfortunately (ie. maximized windows covering the panel). I wanted to use it so I have my notebook on my lap and the monitor at the end of the couch configred above but didn’t work well. I even managed to loose the Bouncing ball, it fell off the screen, lol.

  • aidaho

    Great work! Thank you!

    I have two questions:
    1. What happens when user hits desktop pager on one of the screens?
    2. What about multihead support?

    • aidaho

      >I have two questions:
      And a third one, if it please you:
      3. Can we have a separate color profiles for different outputs, like in krandrtray from Trinity Desktop Environment?

    • aidaho

      >2. What about multihead support?
      Ouch, I meant multiple video adapters usecase.

  • Sharuzzaman

    Wow! Very cool. Keep it going. I really love to see KDE got an improvement like this.

  • ClausP

    This looks really great, especially since it tries to be “clever” and pick useful defaults.
    One use case which I often use is not shown in the video: using the external monitor as the primary screen (with the panel and what not) and the laptop screen as the secondary. Maybe it is just left out of the video, but it would be a nice to have that option as well (perhaps presented as a choice for the when selecting right-of and left-of scenarios in order to keep the number of options to “toggle” through fairly low)

  • FreeMinded

    Great! Looking forward to have this on my Laptop. Thanks a lot for your work!