1. 06 Jan, 2021 1 commit
  2. 18 Dec, 2020 1 commit
  3. 17 Dec, 2020 3 commits
  4. 14 Dec, 2020 1 commit
  5. 08 Dec, 2020 1 commit
  6. 26 Nov, 2020 1 commit
    • Olivier Fourdan's avatar
      modesetting: Fix build with DebugPresent() enabled · 3ce05a44
      Olivier Fourdan authored and Peter Hutterer's avatar Peter Hutterer committed
      
      
      By default, the macro DebugPresent() is a no-op but it can be enabled
      at build time for debugging purpose.
      
      However, doing so prevents the code to build because one debug statement
      tries to make use of a non-existent variable:
      
        present.c: In function ‘ms_present_queue_vblank’:
        present.c:147:18: error: ‘vbl’ undeclared (first use in this function)
          147 |                  vbl.request.sequence));
              |                  ^~~
        present.c:49:32: note: in definition of macro ‘DebugPresent’
          49 | #define DebugPresent(x) ErrorF x
             |                                ^
      
      Fix the build with DebugPresent() by removing the vbl variable from the
      debug message.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      3ce05a44
  7. 25 Nov, 2020 2 commits
  8. 18 Nov, 2020 1 commit
    • Alan Coopersmith's avatar
      int10: wrap entire V_ADDR_R* macros in parens for safer expansion · e5386011
      Alan Coopersmith authored
      
      
      Resolves warnings from Oracle Parfait static analyser:
      
      Error: Misleading macro
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '|' operator has higher precedence than ternary '?:' operator inside macro body at line 431
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 431
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 442
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 442
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '|' operator has higher precedence than ternary '?:' operator inside macro body at line 443
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 441
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      e5386011
  9. 29 Oct, 2020 4 commits
  10. 25 Sep, 2020 2 commits
    • Kishore409's avatar
      modesetting: keep going if a modeset fails on EnterVT · efb3abdd
      Kishore409 authored and Martin Roukala's avatar Martin Roukala committed
      
      
      There was a time when setting a mode on a CRTC would not depend on the
      associated connector's state. If a mode had been set successfully once,
      it would mean it would work later on.
      
      This changed with the introduction of new connectors type that now
      require a link training sequence (DP, HDMI 2.0), and that means that
      some events may have happened while the X server was not master that
      would then prevent the mode from successfully be restored to its
      previous state.
      
      This patch relaxes the requirement that all modes should be restored on
      EnterVT, or the entire X-Server would go down by allowing modesets to
      fail (with some warnings). If a modeset fails, the CRTC will be
      disabled, and a RandR event will be sent for the desktop environment to
      fix the situation as well as possible.
      
      Additional patches might be needed to make sure that the user would
      never be left with all screens black in some scenarios.
      
      v2 (Martin Peres):
       - whitespace fixes
       - remove the uevent handling (it is done in a previous patch)
       - improve the commit message
       - reduce the size of the patch by not changing lines needlessly
       - return FALSE if one modeset fails in ignore mode
       - add comments/todos to explain why we do things
       - disable the CRTCs that failed the modeset
      Signed-off-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Closes: #1010
      efb3abdd
    • Martin Roukala's avatar
      modesetting: check the kms state on EnterVT · 293cf660
      Martin Roukala authored
      
      
      Normally, we would receive a uevent coming from Linux's DRM subsystem,
      which would trigger the check for disappearing/appearing resources.
      However, this event is not received when X is not master (another VT
      is selected), and so the userspace / desktop environment would not be
      notified about the changes that happened while X wasn't master.
      
      To fix the issue, this patch forces a refresh on EnterVT by splitting
      the kms-checking code from the uevent handling into its own (exported)
      function called drmmode_update_kms_state. This function is then called
      from both the uevent-handling function, and on EnterVT right before
      restoring the modes.
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      293cf660
  11. 24 Sep, 2020 2 commits
  12. 15 Sep, 2020 1 commit
    • Michel Dänzer's avatar
      Consolidate fourcc.h · add3df20
      Michel Dänzer authored
      Move the copy in hw/xfree86/common to include/, and remove the one in
      hw/kdrive/src/.
      
      Fixes DIX glamor code including an xfree86 DDX header.
      add3df20
  13. 08 Sep, 2020 3 commits
  14. 31 Aug, 2020 1 commit
  15. 31 Jul, 2020 1 commit
  16. 21 Jul, 2020 1 commit
    • Alex Goins's avatar
      randr: Re-add removed NULL checks to xf86RandR12.c · 495bf63a
      Alex Goins authored
      Commit 1e3f9ea1
      
       removed some NULL checks from xf86RandR12.c, on the premise that
      they can't be reached unless RandR has already been initialized. For threesuch
      calls, that's not true:
      
      xf86Crtc.c::xf86CrtcScreenInit():
      
          if (c == config->num_crtc) {
              xf86RandR12SetRotations(screen, RR_Rotate_0 | RR_Rotate_90 |
                                      RR_Rotate_180 | RR_Rotate_270 |
                                      RR_Reflect_X | RR_Reflect_Y);
              xf86RandR12SetTransformSupport(screen, TRUE);
          }
          else {
              xf86RandR12SetRotations(screen, RR_Rotate_0);
              xf86RandR12SetTransformSupport(screen, FALSE);
          }
      
      xf86Crtc.c::xf86CrtcCloseScreen():
      
          xf86RandR12CloseScreen(screen);
      
      This change adds checks back to xf86RandR12Set{Rotations,TransformSupport}() and
      xf86RandR12CloseScreen(), checking that xf86RandR12KeyRec has been registered.
      Without this, X will hit an assert that causes it to abort.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      495bf63a
  17. 12 Jul, 2020 1 commit
  18. 09 Jul, 2020 1 commit
  19. 05 Jul, 2020 1 commit
  20. 27 Jun, 2020 1 commit
  21. 24 Jun, 2020 1 commit
    • Martin Weber's avatar
      hw/xfree86: Avoid cursor use after free · 7ae221ad
      Martin Weber authored and Michel Dänzer's avatar Michel Dänzer committed
      
      
      During a VT-Switch a raw pointer to the shared cursor object
      is saved which is then freed (in case of low refcount) by a call to
      xf86CursorSetCursor with argument pCurs = NullCursor.
      This leads to a dangling pointer which can follow in a use after free.
      
      This fix ensures that there is a shared handle saved for the VT-Switch cycle.
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      7ae221ad
  22. 23 Jun, 2020 1 commit
  23. 03 Jun, 2020 1 commit
  24. 27 May, 2020 1 commit
    • Jan Beich's avatar
      glx: unbreak on Unix without /usr/include/drm · be731e0b
      Jan Beich authored
      In file included from ../glx/glxdri2.c:35:
      /usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
       #include <drm.h>
                ^~~~~~~
      In file included from ../glx/glxdriswrast.c:39:
      /usr/local/include/GL/internal/dri_interface.h:43:10: fatal error: 'drm.h' file not found
       #include <drm.h>
                ^~~~~~~
      be731e0b
  25. 11 May, 2020 1 commit
  26. 30 Apr, 2020 1 commit
    • Tobias Stoeckmann's avatar
      hw/xfree86: Support ACPI without APM. · 9890e912
      Tobias Stoeckmann authored and Adam Jackson's avatar Adam Jackson committed
      
      
      On systems with ACPI but disabled APM (e.g. --disable-linux-apm)
      the code does not compile due to preprocessor directives.
      
      If APM is disabled, the final return statement is considered to
      be part of ACPI's last if-statement, leading to a function which
      has no final return statement at all.
      
      I have refactored the code so ACPI and APM are independent of each
      other.
      Signed-off-by: Tobias Stoeckmann's avatarTobias Stoeckmann <tobias@stoeckmann.org>
      9890e912
  27. 10 Apr, 2020 1 commit
    • Michael Stapelberg's avatar
      Xorg: honor AutoRepeat option · 4f95d87d
      Michael Stapelberg authored
      
      
      This option was implemented before the drivers were split in ≈2006,
      and e.g. XWin still supports it.
      
      With this commit, Xorg regains support, so that the following configuration can
      be used to set the repeat rate for all keyboard devices without having to modify
      Xorg command-line flags or having to automate xset(1):
      
      Section "InputClass"
              Identifier "system-keyboard"
              MatchIsKeyboard "on"
              Option "XkbLayout" "de"
              Option "XkbVariant" "neo"
      	Option "AutoRepeat" "250 30"
      EndSection
      Signed-off-by: default avatarMichael Stapelberg <stapelberg@google.com>
      4f95d87d
  28. 13 Mar, 2020 2 commits
  29. 12 Feb, 2020 1 commit
    • Zoltán Böszörményi's avatar
      Fix modesetting device matching through kmsdev device path · 42aaf372
      Zoltán Böszörményi authored and Adam Jackson's avatar Adam Jackson committed
      
      
      xf86platformProbeDev didn't check the device path, fix it.
      
      This is a problem when trying to set up a non-PCI device via
      explicit xorg.conf.d configuration.
      
      An USB DisplayLink device, being non-PCI was always set up
      as a GPU device assigned to screen 0 instead of a regular
      framebuffer, potentially having its own dedicated screen,
      despite such configuration as below. Only the relevant parts
      of the configuration are quoted, it's part of a larger context
      with an Intel chip that has 3 outputs:
      * DP1 connected to an LCD panel,
      * VGA1 connected to an external monitor,
      * HDMI1 unconnected and having no user visible connector
      
      Section "ServerFlags"
              Option          "AutoBindGPU" "false"
      EndSection
      
      ...
      
      Section "Device"
              Identifier      "Intel2"
              Driver          "intel"
              BusID           "PCI:0:2:0"
              Screen          2
              Option          "Monitor-HDMI1" "HDMI1"
              Option          "ZaphodHeads" "HDMI1"
      EndSection
      
      Section "Device"
              Identifier      "UDL"
              Driver          "modesetting"
              Option          "kmsdev" "/dev/dri/card0"
              #BusID          "usb:0:1.2:1.0"
              Option          "Monitor-DVI-I-1" "DVI-I-1"
              Option          "ShadowFB" "on"
              Option          "DoubleShadow" "on"
      EndSection
      
      ...
      
      Section "Screen"
              Identifier      "SCREEN2"
              Option          "AutoServerLayout" "on"
              Device          "UDL"
              GPUDevice       "Intel2"
              Monitor         "Monitor-DVI-I-1"
              SubSection      "Display"
                      Modes   "1024x768"
                      Depth   24
              EndSubSection
      EndSection
      
      Section "ServerLayout"
              Identifier      "LAYOUT"
              Option          "AutoServerLayout" "on"
              Screen          0 "SCREEN"
              Screen          1 "SCREEN1" RightOf "SCREEN"
              Screen          2 "SCREEN2" RightOf "SCREEN1"
      EndSection
      
      On the particular machine I was trying to set up an UDL device,
      I found the following structure was being used to match
      the device to a platform device while I was debugging the issue:
      
      xf86_platform_devices[0] == Intel, /dev/dri/card1, primary platform device
      xf86_platform_devices[1] == UDL, /dev/dri/card0
      
      devList[0] == "Intel0", ZaphodHeads: DP1
      devList[1] == "Intel1", ZaphodHeads: VGA1
      devList[2] == "UDL"
      devList[3] == "Intel2", ZaphodHeads: HDMI1 (intended GPU device to UDL)
      
      When xf86platformProbeDev() matched the UDL device, the BusID
      check failed in both cases of:
      * BusID "usb:0:1.2:1.0" was specified
      * Option "kmsdev" "/dev/dri/card0" was specified
      
      As a result, xf86platformProbeDev() went on to call probeSingleDevice()
      with xf86_platform_devices[0] and devList[2], resulting in the
      UDL device being set up as a GPU device assigned to the first screen
      instead of as a framebuffer on the third screen as the configuration
      specified.
      
      Checking Option "kmsdev" in code code may be a layering violation.
      But the modesetting driver is actually part of the Xorg sources
      instead of being an external driver, so he "kmsdev" path knowledge
      may be used here.
      Signed-off-by: default avatarBöszörményi Zoltán <zboszor@pr.hu>
      42aaf372