1. 24 Jun, 2014 1 commit
  2. 07 Jun, 2014 1 commit
  3. 05 Jun, 2014 1 commit
  4. 02 Jun, 2014 1 commit
  5. 27 Apr, 2014 1 commit
    • Rob Clark's avatar
      default to stub int10 implementation on arm · b2419342
      Rob Clark authored
      There should be no reason to need a real int10 implementation on arm,
      and switching to stub is an easy way to fix:
      
        xf86x86emu.c: In function 'xf86Int10ExecSetup':
        xf86x86emu.c:56:9: error: unknown field 'xf_outb' specified in initializer
        xf86x86emu.c:57:9: error: unknown field 'xf_outw' specified in initializer
        xf86x86emu.c:58:9: error: unknown field 'xf_outl' specified in initializer
      
      which is caused by the following in compiler.h:
      
        #define outb xf_outb
        #define outw xf_outw
        #define outl xf_outl
      Signed-off-by: Rob Clark's avatarRob Clark <robdclark@gmail.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      b2419342
  6. 21 Apr, 2014 3 commits
  7. 18 Apr, 2014 1 commit
  8. 08 Apr, 2014 1 commit
  9. 03 Apr, 2014 2 commits
    • Kristian Høgsberg's avatar
      Xwayland DDX · 6e539d88
      Kristian Høgsberg authored
      Started out as an Xorg module to be used from Xorg drivers to let
      Xorg run under a wayland server.  The idea was to be able to reuse the
      2D acceleration from the Xorg driver.  Now with glamor being credible,
      a better plan is to just make Xwayland its own DDX, similar to Xwin
      and Xquartz.  This is a much better fit, as much of the code in the
      original approach had to hack around Xorg doing Xorg things like take
      over the VT, probe input devices and read config files.  Another big win
      is that Xwayland dosn't need to be setuid root.
      
      The Xwayland support for DRI3, Glamor and render nodes was done by
      Axel Davy <axel.davy@ens.fr>, who also did a lot of work on the rebase
      to the Xwayland DDX.
      
      Contributions from:
      
        Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
        Corentin Chary <corentin.chary@gmail.com>
        Daniel Stone <daniel@fooishbar.org>
        Kristian Høgsberg <krh@bitplanet.net>
        Robert Bragg <robert@linux.intel.com>
        Scott Moreau <oreaus@gmail.com>
        Tiago Vignatti <tiago.vignatti@intel.com>
        Giovanni Campagna <gcampagn@redhat.com>
        Jonas Ådahl <jadahl@gmail.com>
        Ray Strode <rstrode@redhat.com>
        Trevor McCort <tjmccort@gmail.com>
        Rui Matos <tiagomatos@gmail.com>
        Axel Davy <axel.davy@ens.fr>
        Jasper St. Pierre <jstpierre@mecheye.net>
      Signed-off-by: Kristian H. Kristensen's avatarKristian Høgsberg <krh@bitplanet.net>
      Reviewed-by: Axel Davy's avatarAxel Davy <axel.davy@ens.fr>
      6e539d88
    • Hans de Goede's avatar
      xf86LogInit: log to XDG_DATA_HOME when not running as root · 9d65c515
      Hans de Goede authored
      When no logfile was specified (xf86LogFileFrom == X_DEFAULT) and we're not
      running as root log to $XDG_DATA_HOME/xorg/Xorg.#.log as Xorg won't be able to
      log to the default /var/log/... when it is not running as root.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.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>
      9d65c515
  10. 01 Apr, 2014 1 commit
  11. 27 Mar, 2014 1 commit
  12. 25 Mar, 2014 1 commit
  13. 22 Mar, 2014 2 commits
  14. 12 Mar, 2014 1 commit
    • Hans de Goede's avatar
      Xorg: Add a suid root wrapper · e7b84ca4
      Hans de Goede authored
      With the recent systemd-logind changes it is possible to install the Xorg
      binary without suid root rights and still have everything working as it
      should *if* the user only has cards which are supported by kms.
      
      This commit adds a little suid root wrapper, which is a bit weird, first we
      strip the suid-root bit of the Xorg binary, and then we add a wrapper ?
      
      The function of this wrapper is to see if a system still needs root-rights,
      if it does not (it supports kms and the kms drivers are properly loaded),
      then it will immediately drop all elevated rights before executing the real
      Xorg binary. If it finds (some) cards which don't support kms, or no cards
      at all, then it will execute the Xorg server with elevated rights so that
      ie the nvidia binary driver and the vesa driver can keep working normally.
      
      To make it possible for security concious users who don't need the root
      rights to completely remove the wrapper, Xorg is started in a 3 step process
      when the wrapper is enabled during build time:
      
      1) A simple shell script which checks if the wrapper is there, if it is
        it executes the wrapper, if not it directly executes the real Xorg binary
      
      2) The wrapper gets executed, does its checks, normally drops all elevated
        rights and then executes the real Xorg binary
      
      3) The real Xorg binary does its thing
      
      This allows distributions to put the wrapper binary in a separate package, and
      will allow users to remove this package. IE the plan with Fedora is to make
      "legacy" drivers depend on the wrapper pkg, and since our default install
      contains some legacy drivers it will be part of the default install, but
      users can later yum remove it (which will also automatically remove the
      legacy driver packages as those won't work without it anyways).
      
      The wrapper is loosely modelled after the existing Debian Xwrapper, it
      uses the same config-file + config-file format, and also allows restricting
      Xserver execution (through the wrapper) to console users only.
      
      There also is a new needs_root_rights config file directive, which can
      be used to override the auto-detection the wrapper does.
      
      Hopefully this will allow Debian to replace their own wrapper with this
      upstream one.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      e7b84ca4
  15. 05 Mar, 2014 2 commits
  16. 03 Mar, 2014 1 commit
    • Hans de Goede's avatar
      systemd-logind: Add systemd-logind "core" · 82863656
      Hans de Goede authored
      This commits add the bulk of the systemd-logind integration code, but does
      not hook it up yet other then calling its init and fini functions, which
      don't do that much.
      
      Note the configure bits check for udev since systemd-logind use will only be
      supported in combination with udev. Besides that it only checks for dbus
      since all communication with systemd-logind is happening over dbus, so
      no further libs are needed.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      82863656
  17. 24 Feb, 2014 1 commit
  18. 15 Feb, 2014 1 commit
  19. 08 Feb, 2014 1 commit
  20. 07 Feb, 2014 1 commit
  21. 29 Jan, 2014 3 commits
  22. 27 Jan, 2014 2 commits
  23. 22 Jan, 2014 5 commits
  24. 12 Jan, 2014 1 commit
  25. 09 Jan, 2014 1 commit
  26. 27 Dec, 2013 1 commit
  27. 19 Dec, 2013 1 commit
  28. 18 Dec, 2013 1 commit
    • Eric Anholt's avatar
      Revert changes outside of glamor from the glamor branch. · 7982eca6
      Eric Anholt authored
      We want to merge the external glamor code to the xserver, with the
      internal history retained.  However, we don't want a bunch of
      non-building changes along the way, so remove all the build system and
      support code outside of glamor for now.
      7982eca6