1. 23 Feb, 2017 4 commits
  2. 17 Feb, 2017 3 commits
  3. 11 Jan, 2017 20 commits
    • Adam Jackson's avatar
      xserver 1.19.1 · ad2facda
      Adam Jackson authored
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      ad2facda
    • Keith Packard's avatar
      AttendClient of grab-pervious client must queue to saved_ready_clients [v2] · 82dcb68a
      Keith Packard authored
      A client which is attended while a grab is blocking execution of its
      requests needs to be placed in the saved_ready_clients list so that it
      will get scheduled once the grab terminates. Otherwise, if the client
      never sends another request, there is no way for it to be placed in
      the ready_clients list.
      
      v2: Wrap comment above mark_client_saved_ready.
          Remove test for OS_COMM_IGNORED which will always be true.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99333Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      (cherry picked from commit 785053d0)
      82dcb68a
    • Qiang Yu's avatar
      randr: fix xserver crash when xrandr setprovideroutputsource · 14516988
      Qiang Yu authored
      xrandr --setprovideroutputsource <screen> <gpu screen>
      Xorg: ../../../xserver/dix/dispatch.c:4018: AttachOutputGPU:
      Assertion `new->isGPU' failed.
      
      GPUScreen is not allowed to be sink output.
      Signed-off-by: default avatarQiang Yu <Qiang.Yu@amd.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 555e0a42)
      14516988
    • Qiang Yu's avatar
      xfree86: fix wrong usage of xf86optionListMerge · 3381e2c2
      Qiang Yu authored
      Signed-off-by: default avatarQiang Yu <Qiang.Yu@amd.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 10125106)
      3381e2c2
    • Michel Dänzer's avatar
      present: Only call present_flip_notify if vblank->queued == FALSE · 27a2772c
      Michel Dänzer authored
      We are no longer using the present_flip_queue list only for presents
      which have already been submitted to the driver for page flipping, but
      also for those which we are queueing up to be flipped later, marked
      with vblank->queued == TRUE. We were incorrectly calling
      present_flip_notify for such entries, failing the assertion in
      present_flip_notify (or presumably resulting in other undesirable
      behaviour with assertions disabled).
      
      Reproduction recipe: Run the JavaFX test case referenced by
      https://bugs.freedesktop.org/show_bug.cgi?id=98831#c6 and alt-tab out
      of it while it's fullscreen. May take a few attempts to hit the
      assertion failure.
      
      Fixes: bab0f450 ("present: Fix presentation of flips out of order")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98854Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      (cherry picked from commit e473b2bc)
      27a2772c
    • Kai-Heng Feng's avatar
      edid: Add quirk for ADA 1024x600 7" display. · 943e3cbe
      Kai-Heng Feng authored
      Detailed mode reports 108 mm x 68 mm which is for smaller display.
      Maximum image size reports 15 cm x 10 cm which aligns with its physical
      size, use this size instead.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      (cherry picked from commit 9874f73e)
      943e3cbe
    • Peter Hutterer's avatar
      os: return 0 from check_timers if we touched any of them · cb3057da
      Peter Hutterer authored
      Fixes a regression introduced in 0b2f3083. If a driver posts input
      events during a timer function (wacom and synaptics do this during tap
      timeouts), ProcessInputEvents() is not called for these events. There are no
      new events on any fds, so the events just sit in the queue waiting for
      something else to happen.
      
      Fix this by simply returning 0 from check_timers if we ran at least one of
      them or reset them all. This way the callers ospoll_wait will exit and
      continue with normal processing.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      cb3057da
    • Michal Srb's avatar
      db03742c
    • Hans De Goede's avatar
      glamor: Trust eglGetPlatformDisplayEXT if it exists · 862c1c43
      Hans De Goede authored
      If the libEGL we are using has eglGetPlatformDisplayEXT, yet it still
      returns NULL, then this very likely means that it does not support the
      type (e.g. EGL_PLATFORM_GBM_MESA) passed in, and then returning NULL is
      the right thing to do.
      
      This avoids falling back to an eglGetDisplay() implementation which does
      not understands the passed in gbm handle, treats it as a pointer to
      something else completely, followed by a crash sooner or later.
      
      Specifically this fixes using the nvidia binary driver, with nvidia's
      libEGL + the modesetting driver on a secondary GPU crashing inside
      glamor_egl_init() sometimes.
      
      [1.19: squash in typo fix from 29a4f3db - ajax]
      
      Cc: Eric Anholt <eric@anholt.net>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      (cherry picked from commit 05e19644)
      862c1c43
    • Mihail Konev's avatar
      os,dix: Depend custom libs on libs, not objects · 8790bd99
      Mihail Konev authored
      The custom os/os.O library reuses *.o files of os/libos.la.
      
      The current rule assumes automake puts all the objects into per-target
      am__*_la_OBJECTS variable.  At least with AC_REPLACE_FUNCS, this no
      longer holds (as wanted objects are put into LTLIBOBJS instead).
      
      Depend on automake's result, the *.la library instead, to express demand
      of any its dependencies being built.
      
      Should be fixing randomly occuring "undefined reference to `strlcpy'"
      errors when linking Xvfb and other DDX-es that could use os.O.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarMihail Konev <k.mvc@ya.ru>
      (cherry picked from commit 5b74e260)
      8790bd99
    • Ben Crocker's avatar
      Fix a segfault that occurs if xorg.conf.d is absent: · 8cf47472
      Ben Crocker authored
      In InitOutput, if xf86HandleConfigFile returns CONFIG_NOFILE
      (which it does if no config file or directory is present), the
      autoconfig flag is set, causing xf86AutoConfig to be called
      later on.
      
      xf86AutoConfig calls xf86OutputClassDriverList via the
      call tree:
      
      xf86AutoConfig =>
        listPossibleVideoDrivers =>
          xf86PlatformMatchDriver =>
            xf86OutputClassDriverList
      
      and xf86OutputClassDriverList attempts to traverse a linked list
      that is a member of the XF86ConfigRec struct pointed to by the
      global xf86configptr, which is NULL at this point because the
      XF86ConfigRec struct is only allocated (by xf86readConfigFile)
      AFTER the config file and directory have been successfully
      opened; the CONFIG_NOFILE return from xf86HandleConfigFile
      occurs BEFORE the call to xf86readConfigFile which allocates
      the XF86ConfigRec struct.
      
      Rx: In read.c (for symmetry with xf86freeConfig, which already
      appears in this file), add a new function xf86allocateConfig
      which tests the value of xf86configptr and, if it's NULL,
      allocates the XF86ConfigRec struct and deposits the pointer
      in xf86configptr.  In xf86Parser.h, add a prototype for the
      new xf86allocateConfig function.
      
      Back in read.c, #include "xf86Config.h".  In xf86readConfigFile,
      change the open-code call to calloc to a call to the new
      xf86allocateConfig function.
      
      In xf86AutoConfig.c, add a call to the new xf86allocateConfig function
      to the beginning of xf86AutoConfig to make sure the XF86ConfigRec struct
      is allocated.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Ben Crocker's avatarBen Crocker <bcrocker@redhat.com>
      (cherry picked from commit 8b335d90)
      8cf47472
    • Pekka Paalanen's avatar
      test: fix distributing scripts · 06a3e7ef
      Pekka Paalanen authored
      Fix the following error on 'make distcheck':
      
      make[6]: *** No rule to make target 'scripts/xvfb-piglit.sh', needed by 'scripts/xvfb-piglit.sh.log'.  Stop.
      make[6]: Leaving directory '/home/pq/git/xserver/xorg-server-1.19.99.1/_build/sub/test'
      Makefile:1367: recipe for target 'check-TESTS' failed
      
      The setup to trigger this is:
        $ ./configure --prefix=/home/pq/local --disable-docs
        --disable-devel-docs --enable-xwayland --disable-xorg --disable-xvfb
        --disable-xnest --disable-xquartz --disable-xwin --enable-debug
      
      SCRIPT_TESTS is populated conditionally, but we should distribute the
      scripts in any case.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      (cherry picked from commit b365c5d1)
      06a3e7ef
    • Adam Jackson's avatar
      composite: Fix repaint of borders (v2) · 543287e6
      Adam Jackson authored
      When going from border width zero to a non-zero border width, the
      Composite extension is informed via the ConfigNotify callback. The
      call-chain looks like this: compConfigNotify -> compReallocPixmap ->
      compSetPixmap -> TraverseTree -> compSetPixmapVisitWindow. However, at
      this time, pWindow->borderWidth was not yet updated. Thus, HasBorder()
      is false and the window border will not be repainted.
      
      To fix this, thread the new bw through to the window visitor, and
      inspect that rather than HasBorder(). For the other callers of
      compSetPixmap the border does not change size, so we can pass
      pWin->borderWidth instead.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98499Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      (cherry picked from commit f3187551)
      543287e6
    • Hans de Goede's avatar
      randr: rrCheckPixmapBounding: do not shrink the screen_pixmap · c24c9cc9
      Hans de Goede authored
      The purpose of rrCheckPixmapBounding is to make sure that the
      screen_pixmap is *large* enough for the slave-output which crtc is
      being configured.
      
      However until now rrCheckPixmapBounding would also shrink the
      screen_pixmap in certain scenarios leading to various problems.
      
      For example: Take a laptop with its internalscreen on a slave-output and
      currently disabled and an external monitor at 1920x1080+0+0.
      Now lets say that we want to drive the external monitor at its native
      resolution of 2560x1440 and have the internal screen mirror the top left
      part of the external monitor, so we run:
      
        $ xrandr --output eDP --mode 1920x1080 --pos 0x0 --output HDMI \
        --mode 2560x1440 --pos 0x0
      
      Here xrandr utility first calls RRSetScreenSize to 2560x1440, then it
      calls RRSetCrtc 1920x1080+0+0 on the eDP, since this is a slave output,
      rrCheckPixmapBounding gets called and resizes the screen_pixmap to
      1920x1080, undoing the RRSetScreenSize. Then RRSetCrtc 2560x1440+0+0
      gets called on the HDMI, depending on crtc->transforms this will
      either result in a BadValue error from ProcRRSetCrtcConfig; or
      it will succeed, but the monitor ends up running at 2560x1440
      while showing a 1920x1080 screen_pixmap + black borders on the right
      and bottom. Neither of which is what we want.
      
      This commit removes the troublesome shrinking behavior, fixing this.
      
      Note:
      
      1) One could argue that this will leave us with a too large screen_pixmap
      in some cases, but rrCheckPixmapBounding only gets called for slave
      outputs, so xrandr clients already must manually shrink the screen_pixmap
      after disabling crtcs in normal setups.
      
      2) An alternative approach would be to also call rrCheckPixmapBounding
      on RRSetCrtc on normal (non-slave) outputs, but that would result in
      2 unnecessary resizes of the screen_pixmap in the above example, which
      seems undesirable.
      
      Cc: Nikhil Mahale <nmahale@nvidia.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      (cherry picked from commit a46afee8)
      c24c9cc9
    • Hans de Goede's avatar
      randr: rrCheckPixmapBounding: Do not substract crtc non 0 x,y from screen size · 26132f57
      Hans de Goede authored
      The purpose of rrCheckPixmapBounding is to make sure that the
      screen_pixmap is large enough for the slave-output which crtc is
      being configured.
      
      This should include crtc->x and crtc->y, otherwise the crtc might
      still end up scanning out an area outside of the screen-pixmap.
      
      For example: Take a laptop with an external monitor on a slave-output at
      1920x1080+0+0 and its internal-screen at 3840x2160+1920+0 and in
      gnome-settings-daemon move the external monitor to be on the ri ght of
      the internal screen rather then on the left. First g-s-d will do a
      RRSetScreenSize to 5760*2160 (which is a nop), then it calls RRSetCrtc
      to move the slave output to 1920x1080+3840+0, since this is a slave
      output, rrCheckPixmapBounding gets called, since the 2 crtcs now overlap
      the code before this commit would shrinks the screen_pixmap to 3180*2160.
      Then g-s-d calls RRSetCrtc to move the internal screen to 3180*2160+0+0.
      
      And we end up with the slave-output configured to scan-out an area
      which completely falls outside of the screen-pixmap (and end up with
      a black display on the external monitor).
      
      This commit fixes this by not substracting the x1 and y1 coordinates
      of the union-ed region when determining the new screen_pixmap size.
      
      Cc: Nikhil Mahale <nmahale@nvidia.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      (cherry picked from commit 3b624aa9)
      26132f57
    • Olivier Fourdan's avatar
      xwayland: Fix use after free of cursors · 6c51845e
      Olivier Fourdan authored
      Sometimes, Xwayland will try to use a cursor that has just been freed,
      leading to a crash when trying to access that cursor data either in
      miPointerUpdateSprite() or AnimCurTimerNotify().
      
      CheckMotion() updates the pointer's cursor based on which xwindow
      XYToWindow() returns, and Xwayland implements its own xwl_xy_to_window()
      to fake a crossing to the root window when the pointer has left the
      Wayland surface but is still within the xwindow.
      
      But after an xwindow is unrealized, the last xwindow used to match the
      xwindows is cleared so two consecutive calls to xwl_xy_to_window() may
      not return the same xwindow.
      
      To avoid this issue, update the last_xwindow based on enter and leave
      notifications instead of xwl_xy_to_window(), and check if the xwindow
      found by the regular miXYToWindow() is a child of the known last
      xwindow, so that multiple consecutive calls to xwl_xy_to_window()
      return the same xwindow, being either the one found by miXYToWindow()
      or the root window.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Tested-by: default avatarVít Ondruch <vondruch@redhat.com>
      Tested-by: default avatarSatish Balay <balay@fastmail.fm>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      (cherry picked from commit 59ad0e6a)
      6c51845e
    • Olivier Fourdan's avatar
      glamor: restore vfunc handlers on init failure · b711efb0
      Olivier Fourdan authored
      In glamor_init(), if the minimum requirements are not met, glamor may
      fail after setting up its own CloseScreen() and DestroyPixmap()
      routines, leading to a crash when either of the two routines is called
      if glamor failed to complete its initialization, e.g:
      
        (EE) Backtrace:
        (EE) 0:  Xwayland (OsSigHandler+0x29)
        (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0)
        (EE) 2: Xwayland (glamor_sync_close+0x2a)
        (EE) 3: Xwayland (glamor_close_screen+0x52)
        (EE) 4: Xwayland (CursorCloseScreen+0x88)
        (EE) 5: Xwayland (AnimCurCloseScreen+0xa4)
        (EE) 6: Xwayland (present_close_screen+0x42)
        (EE) 7: Xwayland (dix_main+0x4f9)
        (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf1)
        (EE) 9:  Xwayland (_start+0x2a)
      
      Restore the previous CloseScreen() and DestroyPixmap() vfunc handlers in
      case of failure when checking for the minimum requirements, so that if
      any of the requirement is not met we don't leave the CloseScreen() and
      DestroyPixmap() from glamor handlers in place.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      (cherry picked from commit f43207c1)
      b711efb0
    • Peter Hutterer's avatar
      Xi: when creating a new master device, update barries for all clients · 201ff45c
      Peter Hutterer authored
      The previous code only worked when the barrier was created by the same client
      as the one calling XIChangeDeviceHierarchy.
      
      http://bugzilla.redhat.com/show_bug.cgi?id=1384432Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      (cherry picked from commit d6a6e1d6)
      201ff45c
    • Rui Tiago Matos's avatar
      xwayland: Don't send KeyRelease events on wl_keyboard::leave · 738c17b7
      Rui Tiago Matos authored
      Commits 81601564 and
      fee0827a made it so that
      wl_keyboard::enter doesn't result in X clients getting KeyPress events
      while still updating our internal xkb state to be in sync with the
      host compositor.
      
      wl_keyboard::leave needs to be handled in the same way as its
      semantics from an X client POV should be the same as an X grab getting
      triggered, i.e. X clients shouldn't get KeyRelease events for keys
      that are still down at that point.
      
      This patch uses LeaveNotify for these events on wl_keyboard::leave and
      changes the current use of KeymapNotify to EnterNotify instead just to
      keep some symmetry between both cases.
      
      On ProcessDeviceEvent() we still need to deactivate X grabs if needed
      for KeyReleases.
      Signed-off-by: Rui Tiago Matos's avatarRui Matos <tiagomatos@gmail.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit 5611585b)
      738c17b7
    • Rhys Kidd's avatar
      test: Fix stray Makefile reference to removed os test · cd8f43e1
      Rhys Kidd authored
      Fixes the following warning:
      
      test/Makefile.am:69: warning: variable 'os_LDADD' is defined but no program or
      test/Makefile.am:69: library has 'os' as canonical name (possible typo)
      
      Introduced upon the removal of test/os in:
      
      commit 6a5a4e60
      Author: Keith Packard <keithp@keithp.com>
      Date:   Tue Dec 8 14:39:46 2015 -0800
      
          Remove SIGIO support for input [v5]
      
          This removes all of the SIGIO handling support used for input
          throughout the X server, preparing the way for using threads for input
          handling instead.
      
          Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
          to stub functions input_lock/input_unlock so that we don't lose this
          information.
      
          xfree86 SIGIO support is reworked to use internal versions of
          OsBlockSIGIO and OsReleaseSIGIO.
      
          v2: Don't change locking order (Peter Hutterer)
          v3: Comment weird && FALSE in xf86Helper.c
              Leave errno save/restore in xf86ReadInput
              Squash with stub adding patch (Peter Hutterer)
          v4: Leave UseSIGIO config parameter so that
              existing config files don't break (Peter Hutterer)
          v5: Split a couple of independent patch bits out
              of kinput.c (Peter Hutterer)
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: Rhys Kidd's avatarRhys Kidd <rhyskidd@gmail.com>
      Reviewed-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit cf886078)
      cd8f43e1
  4. 13 Dec, 2016 1 commit
    • Adam Jackson's avatar
      Revert "damage: Make damageRegionProcessPending take a damage not a drawable" · d6da2086
      Adam Jackson authored
      The commit message makes the assertion that the code below damage is not
      allowed to change whether there's a damage monitor for the drawable.
      That turns out not to be the case! exa's mixed code, at least, will
      create and destroy a damage in PrepareAccess. The destroy path can then
      be catastrophic, as damageRegionProcessPending will attempt to
      RegionEmpty memory from the middle of a freed block.
      
      I'd wanted that invariant for performance, but faster isn't worth
      broken, so revert it. I think what exa's doing is reasonable, so the
      better way to improve performance for the unmonitored case is to either
      revisit dynamically wrapping into the GC, or inline damage into dix.
      
      This reverts commit 4e124203.
      
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389886Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      (cherry picked from commit 32e632e8)
      d6da2086
  5. 15 Nov, 2016 2 commits
  6. 02 Nov, 2016 1 commit
    • Timo Aaltonen's avatar
      dri2: Sync i965_pci_ids.h from mesa · 7513da40
      Timo Aaltonen authored
      Import changes from these mesa commits:
      85ea8deb26da420 i965: Removing PCI IDs that are no longer listed as Kabylake.
      bdff2e554735ed9 i956: Add more Kabylake PCI IDs.
      f1fa8b4a1ca73fa i965/bxt: Add 2x6 variant
      d1ab544bb883d04 i965/chv: Display proper branding
      20e8ee36627f874 i965/skl: Update Skylake renderer strings
      644c8a515192d28 i965/skl: Add two missing device IDs
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarTimo Aaltonen <tjaalton@ubuntu.com>
      7513da40
  7. 01 Nov, 2016 1 commit
  8. 28 Oct, 2016 6 commits
  9. 27 Oct, 2016 1 commit
  10. 26 Oct, 2016 1 commit