Skip to content
Snippets Groups Projects
  1. May 10, 2018
  2. May 09, 2018
    • Aaron Plattner's avatar
      meson: Fix module_dir configuration (v2) · b6bf68b8
      Aaron Plattner authored and Adam Jackson's avatar Adam Jackson committed
      
      meson.build has code to set the module_dir variable to
      ${libdir}/xorg/modules if the module_dir option string is empty.
      However, this has several problems:
      
      1. The variable is only used for an unused @moduledir@ substitution in
         the man page. The rule for xorg-server.pc uses option('module_dir')
         directly instead.
      2. The 'module_dir' option has a default value of 'xorg/modules' so the
         above rule doesn't do anything by default.
      3. The xorg-server.pc rule uses ${exec_prefix}/option('module_dir'), so
         the effect of #2 is that the default moduledir is different between
         autoconf and meson. E.g. if ${prefix} is /X, then you get
      
           autoconf: moduledir=/X/lib/xorg/modules
           meson:    moduledir=/X/xorg/modules
      
      Fix this by using the module_dir variable when generating xorg-server.pc, and by
      using join_paths() to assign module_dir unconditionally.
      
      v2: Keep the 'xorg/modules' default path, but use join_paths() unconditionally (Thierry Reding)
      
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      b6bf68b8
  3. May 08, 2018
  4. May 07, 2018
    • Roman Gilg's avatar
      xwayland: persistent window struct on present · cf838f5c
      Roman Gilg authored and Adam Jackson's avatar Adam Jackson committed
      
      Instead of reusing xwl_window introduce a persistent window struct for every
      window, that asks for Present flips.
      
      This struct saves all relevant data and is only freed on window destroy.
      
      Signed-off-by: default avatarRoman Gilg <subdiff@gmail.com>
      Tested-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      cf838f5c
    • Mario Kleiner's avatar
      modesetting: Fix and improve ms_kernel_msc_to_crtc_msc() · c9afd8cb
      Mario Kleiner authored and Adam Jackson's avatar Adam Jackson committed
      
      The old 32-Bit wraparound handling didn't actually work, due to some
      integer casting bug, and the mapping was ill equipped to deal with input
      from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's
      introduced in Linux 4.15.
      
      For 32-Bit truncated input from pageflip events and old vblank events
      and old drmWaitVblank ioctl, implement new wraparound handling, which
      also allows to deal with wraparound in the other direction, e.g., if a
      32-Bit truncated sequence value is passed in, whose true 64-Bit
      in-kernel hw value is within 2^30 counts of the previous processed
      value, but whose 32-bit truncated sequence value happens to lie just
      above or below a 2^32 boundary, iow. one of the two values 'sequence'
      vs. 'msc_prev' lies above a 2^32 border, the other one below it.
      
      The method is directly translated from Mesa's proven implementation of
      the INTEL_swap_events extension, where a true underlying 64-Bit wide
      swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB
      truncated SBC transported over the X11 protocol wire. Same conditions
      apply, ie. successive true 64-Bit SBC values are close to each other,
      but don't always get received in strictly monotonically increasing
      order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx:
      Handle out-of-sequence swap completion events correctly. (v2)") for
      explanation.
      
      Additionally add a separate path for true 64-bit msc input originating
      from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and
      corresponding 64-bit vblank events. True 64-bit msc's don't need
      remapping and must be passed through.
      
      As a reliability bonus, they are also used here to update the tracking
      values msc_prev and ms_high with perfect 64-Bit ground truth as baseline
      for mapping msc from pageflip completion events, because pageflip events
      are always 32-bit wide, even when the new kernel api's are used. Because
      each pageflip(-event) is always preceeded close in time (and vblank
      count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence
      query as part of DRI2 or DRI3+Present swap scheduling, we can be certain
      that each pageflip event will get its truncated 32-bit msc remapped
      reliably to the true 64-bit msc of flip completion whenever the sequence
      api is available, ie. on Linux 4.15 or later.
      
      Note: In principle at least the 32-bit mapping path could also be
      backported to earlier server branches, as this seems to be broken for at
      least server 1.16 to 1.19.
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Michel Dänzer <michel.daenzer@amd.com>
      c9afd8cb
    • Mario Kleiner's avatar
      modesetting: Remove ms_crtc_msc_to_kernel_msc(). · 73f0ed2d
      Mario Kleiner authored and Adam Jackson's avatar Adam Jackson committed
      
      The function is ported from intel-ddx uxa backend around 2013, where its
      stated purpose was to apply a vblank_offset to msc values to correct for
      problems with those kernel provided msc values. Some (somewhat magic and
      puzzling to myself) heuristic tried to guess if provided values were
      unreasonable and tried to adapt the corrective vblank_offset to account
      for that.
      
      Except: It wasn't applied to kernel provided msc values, but the values
      delivered by clients via DRI2 or Present, so valid client targetmsc
      values, e.g., requesting a vblank event > 1000 vblanks in the future,
      triggered the offset correction in arbitrarily wrong ways, leading to
      wrong msc values being returned and thereby vblank events queued to the
      kernel for the wrong time. This causes glXSwapBuffersMscOML and
      glXWaitForMscOML to swap / return immediately whenever a swap/wait in >
      1000 vblanks is requested.
      
      The original code was also written to only deal with 32 bit mscs, but
      server 1.20 modesetting ddx can now use new Linux 4.15+ kernel vblank
      api to process true 64 bit msc's, which may confuse the heuristic even
      more due to 32 bit integer truncation/wrapping.
      
      This code caused various problems in the intel-ddx in the past since
      year 2013, and was removed there in 2015 by Chris Wilson in commit
      42ebe2ef9646be5c4586868cf332b4cd79bb4618:
      
      "    uxa: Remove the filtering of bogus Present MSC values
      
          If the intention was to filter the return values from the kernel, the
          filtering would have been applied to the kernel values and not to the
          incoming values from Present. This filtering introduces crazy integer
          promotion and truncation bugs all because Present feeds garbage into its
          vblank requests.
      
      "
      
      Indeed, i found a Mesa bug yesterday which can cause Mesa's
      PresentPixmap request to spuriously feed garbage targetMSC's into the
      driver under some conditions. However, while other video drivers seem to
      cope relatively well with that, modesetting ddx causes KDE-5's
      plasmashell to lock up badly quite frequently, and my suspicion is that
      the code removed in this commit is one major source of the extra
      fragility.
      
      Also my own tests fail for any swap scheduled more than 1000 vblanks
      into the future, which is not uncommon for some scientific applications.
      
      Iow. modesetting's swap scheduling seems to be more robust without this
      function afaics.
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Keith Packard <keithp@keithp.com>
      Tested-by: default avatarMike Lothian <mike@fireburn.co.uk>
      73f0ed2d
    • Aaron Plattner's avatar
      meson: Set XCONFIGFILE to 'xorg.conf' instead of '/etc/xorg.conf' · f5ded22e
      Aaron Plattner authored and Adam Jackson's avatar Adam Jackson committed
      
      The autoconf build hard-codes XCONFIGFILE to just 'xorg.conf':
      
       XF86CONFIGFILE="xorg.conf"
       AC_DEFINE_DIR(XCONFIGFILE, XF86CONFIGFILE, [Name of configuration file])
      
      Later, the X server passes that into DoSubstitution() which expands the path:
      
       DoSubstitution(template="/etc/X11/%X", ..., XConfigFile="xorg.conf")
      
      This returns "/etc/X11/xorg.conf".
      
      The Meson build, on the other hand, sets XCONFIGFILE to
      join_paths(get_option('sysconfdir'), 'xorg.conf'). If sysconfdir is /etc, this
      results in '/etc/xorg.conf', resulting in DoSubstitution returning
      '/etc/X11/etc/xorg.conf'.
      
      Fix this by just hard-coding XCONFIGFILE to 'xorg.conf'.
      
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: default avatarThierry Reding <treding@nvidia.com>
      f5ded22e
    • Aaron Plattner's avatar
      meson: Define DEFAULT_LIBRARY_PATH as join_paths(get_option('prefix'), get_option('libdir')) · 1a3e4a2f
      Aaron Plattner authored and Adam Jackson's avatar Adam Jackson committed
      
      'libdir' defaults to 'lib', so running X -showDefaultLibPath just prints 'lib'
      instead of '/usr/lib' or '/usr/local/lib'. Use joint_paths() to get the correct
      full path.
      
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: default avatarThierry Reding <treding@nvidia.com>
      1a3e4a2f
    • Anuj Phogat's avatar
      dri2: Sync i965_pci_ids.h from mesa · 1dcd784a
      Anuj Phogat authored and Adam Jackson's avatar Adam Jackson committed
      
      Copied from Mesa with no modifications.
      
      Gives us Cofeelake platform names updates and sync on Kaby Lake,
      Ice Lake PCI IDs.
      
      Acked-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Signed-off-by: default avatarAnuj Phogat <anuj.phogat@gmail.com>
      1dcd784a
  5. May 02, 2018
  6. Apr 30, 2018
  7. Apr 25, 2018
    • Adam Jackson's avatar
    • Mario Kleiner's avatar
      dri3: Fix DRI3.2 support for drivers other than modesetting-ddx. · 352a5ac8
      Mario Kleiner authored and Adam Jackson's avatar Adam Jackson committed
      
      Both xf86-video-intel and xf86-video-nouveau cause OpenGL clients to
      fail when used with DRI3 on server 1.20 with Mesa 18.1.
      
      Reason is that the servers DRI3 version is now unconditionally reported
      as DRI3 1.2 to 1.2 capable clients. This causes clients using Mesa 18.1
      to use the new DRI 3.2 requests DRI3GetSupportedModifiers,
      DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx do not
      support the needed hooks like info->pixmap_from_fds or
      info->get_formats, info->get_modifiers. Unfortunately we can't simply
      report the servers DRI3 version as 1.0 in this case, as the reported
      version can not be specific to a X-Screen, and different screens may
      have drivers with different capabilities.
      
      Luckily the server has fallbacks to ->pixmap_from_fd, ->fd_from_pixmap,
      and simply reporting an empty set of supported modifiers for the
      DRI3GetSupportedModifiers request if the ddx doesn't support DRI 3.2.
      
      Clients like Mesa 18.1's dri3 loader respond to the empty set of
      reported modifiers by falling back to a dri driver selected buffer
      format (image->createImageWithModifiers responds to a NULL modifier_list
      by acting like ->createImage()). This works, but Mesa 18.1 will still
      try to use the DRI3PixmapFromBuffers request to create the corresponding
      pixmap, just passing in a modifier that corresponds to whatever tiling
      the dri driver selected by default. To prevent this request - and
      thereby the client - from failing with a BadImplementation error, remove
      the check for modifier == DRM_MOD_FORMAT_INVALID in the pixmap_from_fd
      fallback path of dri3_pixmap_from_fds() and trust that if we hit the
      fallback path then the client will have passed a buffer with some driver
      specific default tiling that can be handled by pixmap_from_fd.
      
      Another approach would be for Mesa's dri3 loader to keep track how a
      buffer was created (with explicit modifiers or not), and then call
      DRI3PixmapFromBuffers or DRI3PixmapFromBuffer, but then any future DRI3
      client implementation would need to be fixed, so the server side is
      probably the better place for this.
      
      Tested on Intel Ivybridge and NVidia Pascal.
      
      Fixes: 6e7c40f6 ("dri3: Add multi-planar/modifier buffer requests")
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Daniel Stone <daniels@collabora.com>
      Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Tested-by: default avatarMike Lothian <mike@fireburn.co.uk>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      352a5ac8
  8. Apr 24, 2018
    • Adam Jackson's avatar
      xserver 1.20 RC5 · c6ab2102
      Adam Jackson authored
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
    • Daniel Stone's avatar
      dri3: Don't call vfuncs on old DRI3 screens · c593d843
      Daniel Stone authored and Adam Jackson's avatar Adam Jackson committed
      
      Only call the get_supported_modifiers vfunc if the DRI3 screen struct is
      sufficiently new.
      
      Signed-off-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      c593d843
    • Lyude Paul's avatar
      xwayland: Add glamor egl_backend for EGLStreams · 54ac0971
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed
      
      This adds initial support for displaying Xwayland applications through
      the use of EGLStreams and nvidia's custom wayland protocol by adding
      another egl_backend driver. This also adds some additional egl_backend
      hooks that are required to make things work properly.
      
      EGLStreams work a lot differently then the traditional way of handling
      buffers with wayland. Unfortunately, there are also a LOT of various
      pitfalls baked into it's design that need to be explained.
      
      This has a very large and unfortunate implication: direct rendering is,
      for the time being at least, impossible to do through EGLStreams. The
      main reason being that the EGLStream spec mandates that we lose the
      entire color buffer contents with each eglSwapBuffers(), which goes
      against X's requirement of not losing data with pixmaps.  no way to use
      an allocated EGLSurface as the storage for glamor rendering like we do
      with GBM, we have to rely on blitting each pixmap to it's respective
      EGLSurface producer each frame. In order to pull this off, we add two
      different additional egl_backend hooks that GBM opts out of
      implementing:
      
      - egl_backend.allow_commits for holding off displaying any EGLStream
        backed pixmaps until the point where it's stream is completely
        initialized and ready for use
      - egl_backend.post_damage for blitting the content of the EGLStream
        surface producer before Xwayland actually damages and commits the
        wl_surface to the screen.
      
      The other big pitfall here is that using nvidia's wayland-eglstreams
      helper library is also not possible for the most part. All of it's API
      for creating and destroying streams rely on being able to perform a
      roundtrip in order to bring each stream to completion since the wayland
      compositor must perform it's job of connecting a consumer to each
      EGLstream. Because Xwayland has to potentially handle both responding to
      the wayland compositor and it's own X clients, the situation of the
      wayland compositor being one of our X clients must be considered. If we
      perform a roundtrip with the Wayland compositor, it's possible that the
      wayland compositor might currently be connected to us as an X client and
      thus hang while both Xwayland and the wayland compositor await responses
      from eachother. To avoid this, we work directly with the wayland
      protocol and use wl_display_sync() events along with release() events to
      set up and destroy EGLStreams asynchronously alongside handling X
      clients.
      
      Additionally, since setting up EGLStreams is not an atomic operation we
      have to take into consideration the fact that an EGLStream can
      potentially be created in response to a window resize, then immediately
      deleted due to another pending window resize in the same X client's
      pending reqests before Xwayland hits the part of it's event loop where
      we read from the wayland compositor. To make this even more painful, we
      also have to take into consideration that since EGLStreams are not
      atomic that it's possible we could delete wayland resources for an
      EGLStream before the compositor even finishes using them and thus run
      into errors. So, we use quite a bit of tracking logic to keep EGLStream
      objects alive until we know the compositor isn't using them (even if
      this means the stream outlives the pixmap it backed).
      
      While the default backend for glamor remains GBM, this patch exists for
      users who have had to deal with the reprecussion of their GPU
      manufacturers ignoring the advice of upstream and the standardization of
      GBM across most major GPU manufacturers. It is not intended to be a
      final solution to the GBM debate, but merely a baindaid so our users
      don't have to suffer from the consequences of companies avoiding working
      upstream. New drivers are strongly encouraged not to use this as a
      backend, and use GBM like everyone else. We even spit this out as an
      error from Xwayland when using the eglstream backend.
      
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Acked-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      54ac0971
    • Lyude Paul's avatar
      xwayland: Add xwayland-config.h · 994f7810
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed
      
      Just a small autogenerated header that will soon contain more then just
      one macro.
      
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      994f7810
    • Lyude Paul's avatar
      xwayland: Decouple GBM from glamor · 1545e2db
      Lyude Paul authored and Adam Jackson's avatar Adam Jackson committed
      
      This takes all of the gbm related code in wayland-glamor.c and moves it
      into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
      Additionally, we add the egl_backend struct into xwl_screen in order to
      provide hooks for alternative EGL backends such as nvidia's EGLStreams.
      
      Signed-off-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: Lyude Paul's avatarLyude Paul <lyude@redhat.com>
      Reviewed-by: default avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      1545e2db
    • Adam Jackson's avatar
      vfb: Fix man page in re depth · d2d664df
      Adam Jackson authored
      
      32 is not a valid depth, and the default is now 24 not 8.
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: default avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      d2d664df
    • Adam Jackson's avatar
      glx: Require depth > 12 for GLX visuals · 79a71375
      Adam Jackson authored
      
      fb is happy to do TrueColor to 8bpp drawables, but mesa is not. Depth 12
      is the biggest pseudocolor anyone ever really did, and 15 is the least
      truecolor.
      
      Without this Xvfb at depth 8 would "have" GLX, but no vendors
      would actually back any of the screens. libGL will attempt to call
      GLXQueryServerString to figure out the GLX version, and vnd will throw
      an error because there's no vendor to dispatch that to, and then clients
      crash.
      
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      79a71375
    • Adam Jackson's avatar
Loading