1. 07 Jan, 2020 2 commits
    • Roman Gilg's avatar
      fix(randr): make sure crtc exists · 05e361e5
      Roman Gilg authored
      When an output gets enabled we directly want to set the logical size. But at
      this point because of the order of calls in XRandRConfig the crtc is not yet
      set on the output.
      To fix this in a quick way just provide the free crtc as an argument. Long-term
      change the order of calls.
    • Roman Gilg's avatar
      feat: replace replication source with logical size API · 6a5a180b
      Roman Gilg authored
      Just overriding the logical size of an output that replicates another one is
      simpler than trying to send a relation between both objects to the display
      server and in case of X11 it is not possible.
      Wires up support for that in the X11 backend.
      Test Plan: Compiles. Wayland replication tested.
      Reviewers: #kwin
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D26309
  2. 05 Sep, 2019 1 commit
    • Roman Gilg's avatar
      RandR: Replicate outputs with XRender extension · 31d71564
      Roman Gilg authored
      This provides means to set replicas and queries them on X11 by transforming
      crtcs with the XRender extension.
      There is a heuristic at play to detect possible replications and currently
      the aspect ratio is not perserved but the image stretched. Using different
      values for the transformation matrix also the former should be possible.
      Test Plan: Manually together with patch to KScreen.
      Reviewers: #kwin, #plasma
      Subscribers: davidedmundson, plasma-devel
      Tags: #plasma
      Maniphest Tasks: T11222
      Differential Revision: https://phabricator.kde.org/D23663
  3. 02 Sep, 2019 1 commit
    • Roman Gilg's avatar
      XRandR: Generic code cleanup · 5ed9a35e
      Roman Gilg authored
      No functional changes, white space added where sensible, debug messages now
      without repetition of qCDebug(..) macros, modernized, keeps line limit.
      Test Plan: Compiles and KScreen runs on X11.
      Reviewers: #kwin
      Subscribers: plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D23647
  4. 02 Jul, 2018 1 commit
  5. 30 Oct, 2017 1 commit
  6. 20 Sep, 2017 1 commit
    • Christoph Lutz's avatar
      let's continue in debug code instead of returning from XRandRConfig::applyKScreenConfig · 8a89d204
      Christoph Lutz authored
      In XRandRConfig::applyKScreenConfig there is some debug code for a situation that should not really happen (but that was seen in the past) in which currentMode is NULL. After printing the debug info, the method directly returned from applyKScreenConfig, omitting all the other potentially useful initializations code that comes afterwards.
      From my POV this is wrong and we had situations in which desktop initialization works better if we don't return here. That's why I changed "return" into "continue".
      Analysis of the underlying inconsistency:
      The debugging led me from libkscreen to xrandr to libxrandr (XRRGetOutputInfo) to the kernel. Here I noticed the following things:
              1) outputInfo = XRRGetOutputInfo(outputId) returns some outputInfo that dosn't contain
                 the mode it should contain (concrete the ID 77). It was simply missing.
              2) crtcInfo = XRRGetCrtcInfo(outputInfo->crtc) But this crtcInfo-Objekt does reference
                 the mode 77: crtcInfo->mode is 77
              3) XRRGetScreenResourcesCurrent() also thinks that mode 77 should be present
              4) Because mode 77 was not in outputInfo, XRandROutput::updateModes could not re-add
                 this mode to the map m_modes and XRandROutput::currentMode() had to return NULL.
                 Nothing wrong in updateModes!
      Because libxrandr in 1) also delegates the above mentioned requests directly to the CRTC-driver of the kernel, I came to the conclusion that the inconsistency behind this situation comes from the kernel. It was also hard to reproduce on side of the kernel since multiple requests returned different results (kind of sporadic).
      As mentioned above, I could sporadically reproduce the inconsistency with kernel 3.13.0 and as I tried a newer kernel the issue seemed to be vanished. This is the point where I decided to not dig deeper into such an old kernel version.
      So in conclusion for me the underlying bug seems to be a kernel bug and not a libkscreen-bug. Maybe in the meanwhile nobody will ever cross the debug code again. BUT in my concrete situation libkscreen seems to be able to recover things from this inconsistency and "continuing" instead of "returning" simply improves the behaviour of the complete system.
      Test Plan:
      The concrete situation in which I regularily got this currentMode == NULL situation leads to the following bug:
            - kernel 3.13.0
            - physical pc with two displays, one 4:3 and the other 16:9 format
            - forced the system to always start in clone-mode if there is not
              yet a user profile --> we patched kscreen therefore
            - doing the following workflow:
                - log in --> sessions comes up in clone mode (as wished)
                - autorandr-gui --> "extended desktop - left"
                - press OK and DON't store the profile (so no change is stored)
                - log off
                - log in again
            - The following things happen:
                - Now we run into this "currentMode == NULL" situation (message in log file)
                - the screens come up in clone mode (as the previous settings were not saved)
                - BUG: the resolutions are wrong (parts from one of the two screens are cut).
                       applyKScreenConfig returned before it was finished.
      With this chage, this bug no longer occures and the resolution is as expected set to the best commonly available resolution.
      Reviewers: davidedmundson
      Reviewed By: davidedmundson
      Subscribers: davidedmundson, plasma-devel
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D6011
  7. 15 Aug, 2016 1 commit
    • Sebastian Kügler's avatar
      fix mode setting when output is already enabled · a7a6092d
      Sebastian Kügler authored
      This fixes setting mode when the output is enabled. In this case, we
      have to pick the mode of the KScreen::Config passed in. This falls
      back to preferred mode, which will practicably always be valid.
      If we consider the xOutput first, we pick the currently set mode and use
      that -- hence, nothing is going to be changed. If the display went
      through the enabled code path first, the xOutput won't have a mode
      already, which is corrected at that point.
      This fixes a regression introduced with f5380567.
      Thanks Raymond Wooninck for reporting and testing.
  8. 10 Aug, 2016 1 commit
    • Sebastian Kügler's avatar
      [xrandr backend] fall back to preferred mode, fix crash · f5380567
      Sebastian Kügler authored
      When enabling outputs, it's possible that a KScreen::Output's current
      mode is empty. In this case, it's logical and necessary to fall back to
      the output's preferred mode, instead of passing essentially
      QString().toInt() as mode id into xcb_randr_set_crtc_config().
      In the current code, kscreenOuput->currentMode()->size() can crash, this
      is fixed with this patch as well.
      This change makes enabling a VGA monitor to my docking station more reliable.
      Test Plan: Connected, disconnted, reconfigured a tv connected via HDMI.
      Reviewers: dvratil, graesslin
      Reviewed By: graesslin
      Subscribers: graesslin, plasma-devel, #plasma
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D2330
  9. 02 Aug, 2016 1 commit
    • Sebastian Kügler's avatar
      update CRTCs before enabling an output · c2e1becc
      Sebastian Kügler authored
      When connecting the docking station (Lenovo OneLink+), which has a VGA
      connected monitor attached, enabling a display usually fails. It
      complains about no CRTC being available (and indeed the available CRTCs
      don't have our output as possible output). Updating the CRTC before
      enabling an output makes this work for me.
      Note: it's not a problem when connecting via HDMI, this seems to be
      either unique to VGA or to the docking station. (Other dock users report
      similar behaviour).
      I'm being fairly liberal with update calls here, probably just doing it
      in enableOutput will work as well -- but I haven't extensively tested
      it. I don't know how expensive these calls are.
      On boot, my setup is still not restored, but at least with this patch
      manually enabling an output works reliably now.
      Test Plan:
      * rebooted with dock disconnected, can enable an output with this patch, would reliably fail without
      * rebooted with dock connected, still works
      * connected/disconnected/connected dock with output attached, works well
      Reviewers: dvratil, graesslin
      Reviewed By: graesslin
      Subscribers: graesslin, plasma-devel, #plasma
      Tags: #plasma
      Differential Revision: https://phabricator.kde.org/D2336
  10. 10 Mar, 2016 1 commit
  11. 13 Feb, 2016 1 commit
    • Daniel Vrátil's avatar
      XRandR: handle changeOutput() without CRTC better · d3c0b50e
      Daniel Vrátil authored
      It is possible that XRandROutput counterpart to KScreen::Output does not have
      a CRTC set while the KScreen::Output reports itself as enabled. This leads to
      changeOutput() hitting an assert, because we assumed that such case can never
      happen. Now we know it can, so instead when changeOutput() is called for an
      output without CRTC, we fallback to calling enableOutput().
      BUG: 344813
      FIXED-IN: 5.5.5
  12. 17 Jun, 2015 1 commit
  13. 18 May, 2015 1 commit
    • Daniel Vrátil's avatar
      XRandR: use intermediate screen size when applying config · d6233b63
      Daniel Vrátil authored
      We apply the screen size before we do any changes to outputs. In some cases the
      screen size for the new config is smaller than the current screen size (like when
      rotating an output), and it can happen that XSetScreenSize fails or applies only
      partially. To workaround that we first set an intermediate screen size which can
      fit both the current and the new config, then apply the output changes and then
      (if necessary) update the screen size once more to fix the new config precisely.
      This should fix some weird issues with screen size when rotating an external
  14. 30 Mar, 2015 1 commit
  15. 26 Mar, 2015 2 commits
  16. 06 Mar, 2015 1 commit
    • Daniel Vrátil's avatar
      XRandR: Port the XRandR backend from Xlib to XCB · 1597060c
      Daniel Vrátil authored
      The king is dead, long live the king. KScreen no longer links against libX11.
      As part of the porting I also moved the components which are shared between
      XRandR and XRandR1.1 backends to the backends directory, renamed them and
      wrapped the tools in xcbwrapper.h into XCB namespace.
      The XCB::Wrapper class is now also more versitile, thanks to some C++11 template
      magic it can now wrap arbitrary xcb structs and calls with arbitrary number of
      arguments. XCB::ScopedPointer is also available to prevent leaks.
  17. 29 Jan, 2015 1 commit
    • Daniel Vrátil's avatar
      Change the way we use XRandR events to reduce amount of X-calls · d7734339
      Daniel Vrátil authored
      Until now we only used the XRandR events to know that a change happened,
      then we went and queries X server for all the data to update our internal
      This patch changes the behaviour so that we actually take all the
      information available in the change event, and apply them to our cache,
      so that we don't have to perform X-calls to get information we already
      To make full use of the events, XRandRCrtc class is introduced. An XRandrCRTC
      object represents a single CRTC available on current machine. XRandRCrtc
      objects are either "disconnected", or are linked to a specific XRandROutput,
      to which they provide relevant information. Information availabe in
      RRCrtcChangeNotify  and RROutputChangeNotify events are then used to keep
      those up to date.
      Since we already have up-to-date CRTC information now, we can also get rid
      of the endless querying for free CRTCs when applying changes.
      All in all, this seems to improve the speed in which we are able to react
      to changes and reduces the X stutter caused by excessive queries to X. There
      is still problem in QXcbConnection which handles XCBRandR events in a rather
      ineffective way, causing huge delays and load on X, but that has to be fixed
      in Qt.
  18. 14 Jan, 2015 1 commit
  19. 20 Nov, 2014 2 commits
  20. 17 Nov, 2014 4 commits
  21. 30 Oct, 2014 1 commit
  22. 29 Oct, 2014 1 commit
  23. 22 Oct, 2014 2 commits
  24. 28 Jun, 2014 1 commit
  25. 05 May, 2014 1 commit
    • Aleix Pol Gonzalez's avatar
      Fix crash · 221dff2e
      Aleix Pol Gonzalez authored
      If we don't have a primary output, don't query it. Set a new primary
      output instead.
      Reviewed by Alex Fiestas
  26. 29 Apr, 2014 3 commits
  27. 01 Apr, 2014 1 commit
    • Daniel Vrátil's avatar
      Update XRandROutput after it's disabled so that cache is kept up-to-date · de38db6b
      Daniel Vrátil authored
      After disabling an output, we have to force-update the XRandROutput, because right
      after that we receive RRNotify_CRTCChange signal for that very output. This is
      propagated to users (like KCM), which then call canBeApplied(). canBeApplied()
      compares the KScreen::Config with the *outdated* XRandRConfig and that leads to
      a crash (because the XRandRConfig still claims that the output is enabled).
      By updating the cache right after we disable the output, when KCM calls canBeApplied(),
      it's Config is compared to an up-to-date Config and everything is fine.
      REVIEW: 117298
  28. 17 Nov, 2013 2 commits
  29. 14 Nov, 2013 2 commits
    • Àlex Fiestas's avatar
      Implement support for "outputRemoved" · 50d940e0
      Àlex Fiestas authored
      I haven't been able to test this since I lack the hardware, but I'm
      sure it won't affect systems without it (like mine).
    • Àlex Fiestas's avatar
      Add support for adding outputs · f9be9071
      Àlex Fiestas authored
      New intel driver adds virtual outputs, it starts with VIRUTAL1, when
      it is activated when it creates VIRTUAL2 and so on.
      This patch only adds "outputAdded", outputRemoved will come after.