1. 23 Mar, 2017 2 commits
  2. 21 Mar, 2017 1 commit
  3. 20 Mar, 2017 1 commit
  4. 17 Mar, 2017 1 commit
    • 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
  5. 16 Mar, 2017 1 commit
  6. 15 Mar, 2017 1 commit
  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. 01 Mar, 2017 2 commits
  9. 16 Feb, 2017 7 commits
  10. 09 Feb, 2017 1 commit
  11. 08 Feb, 2017 4 commits
    • 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
    • Michael Thayer's avatar
      xfree86: Immediately handle failure to set HW cursor, v5 · c02f6a68
      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: Updated the patch to apply to current git HEAD, split up into two
      patches (server and modesetting driver) and adjusted the code slightly
      to match surrounding code.  I also removed the new exported function
      ShowCursorCheck(), as instead just changing ShowCursor() to return Bool
      should not affect its current callers.
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: Michael Thayer's avatarMichael Thayer <michael.thayer@oracle.com>
      c02f6a68
    • Adam Jackson's avatar
      dri1: Remove some dead event code · e50da501
      Adam Jackson authored
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.com>
      e50da501
  12. 06 Feb, 2017 3 commits
  13. 01 Feb, 2017 1 commit
    • Michel Dänzer's avatar
      loader: Handle mod->VersionInfo == NULL · 45e0eb4b
      Michel Dänzer authored
      This can happen when a module fails to load:
      
      Program received signal SIGSEGV, Segmentation fault.
      UnloadModule (_mod=0x5555559d9280) at ../../../../hw/xfree86/loader/loadmod.c:848
      848	    name = mod->VersionInfo->modname;
      (gdb) bt
      #0  UnloadModule (_mod=0x5555559d9280) at ../../../../hw/xfree86/loader/loadmod.c:848
      #1  0x00005555555ddd1b in LoadModule (module=module@entry=0x5555559c7ce0 "fbdev", options=0x0, modreq=modreq@entry=0x0, errmaj=errmaj@entry=0x7fffffffe8ec) at ../../../../hw/xfree86/loader/loadmod.c:824
      #2  0x00005555555edfe9 in xf86LoadModules (list=list@entry=0x5555559dcf50, optlist=optlist@entry=0x0) at ../../../../hw/xfree86/common/xf86Init.c:1506
      #3  0x00005555555ee7bc in InitOutput (pScreenInfo=pScreenInfo@entry=0x5555559abf80 <screenInfo>, argc=argc@entry=4, argv=argv@entry=0x7fffffffeb18) at ../../../../hw/xfree86/common/xf86Init.c:484
      #4  0x00005555555a885c in dix_main (argc=4, argv=0x7fffffffeb18, envp=<optimized out>) at ../../dix/main.c:197
      #5  0x00007ffff5d582b1 in __libc_start_main (main=0x555555593130 <main>, argc=4, argv=0x7fffffffeb18, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffeb08) at ../csu/libc-start.c:291
      #6  0x000055555559316a in _start ()
      
      Fixes: 8e83eacb ("loader: Remove unused path and name from ModuleDescPtr")
      Signed-off-by: Michel Dänzer's avatarMichel Dänzer <michel.daenzer@amd.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>
      45e0eb4b
  14. 25 Jan, 2017 14 commits