1. 23 Mar, 2017 5 commits
  2. 21 Mar, 2017 1 commit
  3. 20 Mar, 2017 1 commit
  4. 17 Mar, 2017 2 commits
    • Adam Jackson's avatar
      xfree86: Remove 24bpp pixmap format support (v2) · e33be78e
      Adam Jackson authored
      There's really no reason to pretend to support this, apps hate it, all
      we're doing is giving people a way to injure themselves. It doesn't work
      anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
      Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
      silently ignore the old options that would ask for it.
      
      The cirrus alpine driver has been updated to default to 16bpp, and both
      it and the i810 driver can now use the 32->24 conversion code in shadow
      if they want. All other drivers support 32bpp. Configurations that
      explicitly request 24bpp in order to fit in VRAM will be broken now
      though.
      
      v2: Fix command line options to silently ignore 24bpp rather than fail
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      e33be78e
    • Adam Jackson's avatar
      ephyr: Don't clobber bitsPerPixel when using glamor · 83c4297d
      Adam Jackson authored
      This ends up passing 0 as the bpp argument to fb screen setup, which is
      not really the best plan.
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      83c4297d
  5. 16 Mar, 2017 1 commit
  6. 15 Mar, 2017 2 commits
  7. 14 Mar, 2017 1 commit
    • Jon Turney's avatar
      xfree86: work around a sdksyms problem with gcc5 on Cygwin · bca22160
      Jon Turney authored
      The linemarkers in the preprocessor output from gcc5 on Cygwin have
      canonicalized paths to included files (e.g. xserver/build/../include/misc.h
      is canonicalized to xserver/build/include/misc.h). (see gcc svn rev 210264,
      which causes the transformation performed by -fcanonical-system-headers to
      be applied to all include pathnames)
      
      These canonicalized paths won't match $topdir, so sdksyms doesn't look at
      the contents of those headers for sdk exported symbols.
      
      Workaround this by canonicalizing all the paths we consider, using readlink.
      
      v2:
      Keep a cache of readlink results so it isn't quite so dreadfully slow.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      bca22160
  8. 09 Mar, 2017 1 commit
  9. 07 Mar, 2017 1 commit
  10. 06 Mar, 2017 1 commit
  11. 01 Mar, 2017 7 commits
  12. 28 Feb, 2017 1 commit
  13. 23 Feb, 2017 3 commits
    • Pekka Paalanen's avatar
      xwayland: use _XWAYLAND_ALLOW_COMMITS property · 9f4d308c
      Pekka Paalanen authored
      The X11 window manager (XWM) of a Wayland compositor can use the
      _XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends
      wl_surface.commit requests. If the property is not set, the behaviour
      remains what it was.
      
      XWM uses the property to inhibit commits until the window is ready to be
      shown. This gives XWM time to set up the window decorations and internal
      state before Xwayland does the first commit. XWM can use this to ensure
      the first commit carries fully drawn decorations and the window
      management state is correct when the window becomes visible.
      
      Setting the property to zero inhibits further commits, and setting it to
      non-zero allows commits. Deleting the property allows commits.
      
      When the property is changed from zero to non-zero, there will be a
      commit on next block_handler() call provided that some damage has been
      recorded.
      
      Without this patch (i.e. with the old behaviour) Xwayland can and will
      commit the surface very soon as the application window has been realized
      and drawn into.  This races with XWM and may cause visible glitches.
      
      v3:
      - introduced a simple setter for xwl_window::allow_commits
      - split xwl_window_property_allow_commits() out of
        xwl_property_callback()
      - check MakeAtom(_XWAYLAND_ALLOW_COMMITS)
      
      v2:
      - use PropertyStateCallback instead of XACE, based on the patch
        "xwayland: Track per-window support for netwm frame sync" by
        Adam Jackson
      - check property type is XA_CARDINAL
      - drop a useless memcpy()
      
      Weston Bug: https://phabricator.freedesktop.org/T7622Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      9f4d308c
    • Pekka Paalanen's avatar
      xwayland: fix 'buffer' may be used uninitialized warning · a6308cea
      Pekka Paalanen authored
      Fix the following warning due to --disable-glamor:
      
        CC       Xwayland-xwayland.o
      In file included from /home/pq/local/include/wayland-client.h:40:0,
                       from xwayland.h:35,
                       from xwayland.c:26:
      xwayland.c: In function ‘block_handler’:
      /home/pq/local/include/wayland-client-protocol.h:3446:2: warning: ‘buffer’ may be used uninitialized in this function [-Wmaybe-uninitialized]
        wl_proxy_marshal((struct wl_proxy *) wl_surface,
        ^
      xwayland.c:466:23: note: ‘buffer’ was declared here
           struct wl_buffer *buffer;
                             ^
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      a6308cea
    • Pekka Paalanen's avatar
      xwayland: refactor into xwl_window_post_damage() · f7b8560f
      Pekka Paalanen authored
      Refactor xwl_screen_post_damage() and split the window specific code
      into a new function xwl_window_post_damage().
      
      This is a pure refactoring, there are no behavioral changes. An assert
      is added to xwl_window_post_damage() to ensure frame callbacks are not
      leaked if a future patch changes the call.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      f7b8560f
  14. 16 Feb, 2017 7 commits
  15. 09 Feb, 2017 1 commit
  16. 08 Feb, 2017 5 commits
    • Olivier Fourdan's avatar
      xwayland: Apply output rotation for screen size · 058809c4
      Olivier Fourdan authored
      Previously, we would swap the width/height of the Xwayland output based
      on the output rotation, so that the overall screen size would match the
      actual rotation of each output.
      
      Problem is the RandR's ConstrainCursorHarder() handler will also apply
      the output rotation, meaning that when the output is rotated, the
      pointer will be constrained within the wrong dimension.
      
      Moreover, XRandR assumes the original output width/height are unchanged
      when the output is rotated, so by changing the Xwayland output width and
      height based on rotation, Xwayland causes XRandr to report the wrong
      output sizes (an output of size 1024x768 rotated left or right should
      remain 1024x768, not 768x1024).
      
      So to avoid this issue and keep things consistent between Wayland and
      Xwayland outputs, leave the actual width/height unchanged but apply the
      rotation when computing the screen size. This fixes both the output size
      being wrong in "xrandr -q" and the pointer being constrained in the
      wrong dimension with rotated with weston.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      058809c4
    • Olivier Fourdan's avatar
      xwayland: CRTC should support all rotations · afeace27
      Olivier Fourdan authored
      If the Wayland compositor sets a rotation on the output, Xwayland
      translates the transformation as an xrandr rotation for the given
      output.
      
      However, if the rotation is not supported by the CRTC, this is not
      a valid setup and xrandr queries will fail.
      
      Pretend we support all rotations and reflections so that the
      configuration remains a valid xrandr setup.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      afeace27
    • Svito's avatar
      xwayland: Add hack for FWXGA resolution #99574 · 1c78bec9
      Svito authored
      For some applications (like fullscreen games) it matters for XRandr
      resolution to be correctly set and equal to root window resolution.
      
      In XServer there is already hack for this, adapted it for XWayland.
      
      Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99574Signed-off-by: Svito's avatarSvitozar Cherepii <razotivs@gmail.com>
      Tested-by: Svito's avatarSvitozar Cherepii <razotivs@gmail.com>
      Acked-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      1c78bec9
    • Michael Thayer's avatar
      modesetting: allow switching from software to hardware cursors (v5). · eb04b201
      Michael Thayer authored
      Currently if modesetting ever fails to set a hardware cursor it will switch
      to using a software cursor and never go back.  Change this to only
      permanently switch to a software cursor if -ENXIO is returned (which means
      hardware cursors not supported), and to otherwise still try a hardware
      cursor first every time a new one is set.  This is needed because hardware
      may be able to handle some cursors in hardware and others not, or virtual
      hardware may be able to handle hardware cursors at some times and not
      others.
      
      Changes since v1, v2 and v3:
       * take into account the switch to load_cursor_argb_check
       * keep the permanent software cursor fall-back if -ENXIO is returned
       * move parts of v3 into separate patches
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Michael Thayer's avatarMichael Thayer <michael.thayer@oracle.com>
      eb04b201
    • Michael Thayer's avatar
      modesetting: Immediately handle failure to set HW cursor, v5 · ecd0a623
      Michael Thayer authored
      Based on v4 by Alexandre Courbot <acourbot@nvidia.com>
      
      There is currently no reliable way to report failure to set a HW
      cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM
      ioctl fails (which currently happens at least with modesetting on Tegra
      for format incompatibility reasons).
      
      As failures are currently handled by setting the HW cursor size to
      (0,0), the fallback to SW cursor will not happen until the next time the
      cursor changes and xf86CursorSetCursor() is called again. In the
      meantime, the cursor will be invisible to the user.
      
      This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and
      _xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans.
      This allows to propagate errors up to xf86CursorSetCursor(), which can
      then fall back to using the SW cursor immediately.
      
      v5:
       - Removed parts of patch already committed as part of 14c21ea1.
       - Adjusted code slightly to match surrounding code.
       - Effectively reverted af916477 which is made unnecessary by this patch.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Michael Thayer's avatarMichael Thayer <michael.thayer@oracle.com>
      ecd0a623