1. 26 Jul, 2016 1 commit
  2. 13 Jul, 2016 2 commits
    • Bryce Harrington's avatar
      Require base-10 for strtol() calls · 375759e6
      Bryce Harrington authored
      The third arg to strtol() specifies the base to assume for the number.
      When 0 is passed, as is currently done in option-parser.c, hexadecimal
      and octal numbers are permitted and automatically detected and
      converted.
      
      This change is an expansion of f6051cba
      to cover the remaining strtol() calls in Weston, where the routine is
      being used to read fds and pids - which are always expressed in base-10.
      It also changes the calls in config-parser, used by
      weston_config_section_get_int(), which in turn is being used to read
      scales, sizes, times, rates, and delays; these are all expressed in
      base-10 numbers only.
      
      The benefit of limiting this to base-10 is to eliminate surprises when
      parsing numbers from the command line.  Also, by making the code
      consistent with other usages of strtol, it may make it possible to
      factor out the common code in the future.
      Signed-off-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      375759e6
    • Bryce Harrington's avatar
      1dbdc0bd
  3. 01 Jul, 2016 1 commit
    • Giulio Camuffo's avatar
      xwayland: make the plugin usable by libweston compositors · 9c764df0
      Giulio Camuffo authored
      This patch follows a similar approach taken to detach the backends from
      weston. But instead of passing a configuration struct when loading the
      plugin, we use the plugin API registry to register an API, and to get it
      in the compositor side.  This API allows to spawn the Xwayland process
      in the compositor side, and to deal with signal handling.  A new
      function is added in compositor.c to load and init the xwayland.so
      plugin.
      
      Also make sure to re-arm the SIGUSR1 when the X server quits.
      Signed-off-by: default avatarGiulio Camuffo <giuliocamuffo@gmail.com>
      [Pekka: moved xwayland/weston-xwayland.c -> compositor/xwayland.c]
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      9c764df0
  4. 27 Jun, 2016 1 commit
  5. 23 Jun, 2016 2 commits
  6. 17 Jun, 2016 2 commits
    • Pekka Paalanen's avatar
      main: report presentation clock resolution · be112d42
      Pekka Paalanen authored
      For debugging weird timing issues. If your clock resolution is
      unexpectedly e.g. 10 ms, you can be sure you will have strange timing
      issues. This is almost certainly caused by kernel misconfiguration.
      
      We rely on clock_getres() being available by the same thing that gets us
      clock_gettime(), so that no new configure.ac check is needed.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-By: default avatarDavid Fort <contact@hardening-consulting.com>
      be112d42
    • Pekka Paalanen's avatar
      compositor-fbdev: drop EGL support · e77f8ad7
      Pekka Paalanen authored
      EGL code was added to the fbdev backend in
      4aa756dc in 2013, apparently for running
      Weston on libhybris with Android hardware drivers.
      
      This actually had nothing to do with the fbdev backend, really. Fbdev
      was just a convenient platform to plug in the EGL init code and load
      GL-renderer. Fbdev itself was not used at all in this case.
      
      Fbdev should be forgotten and die, as we have better interfaces for
      accelerated rendering and for controlling displays. It may be a bit too
      harsh to remove the whole fbdev backend just yet, but let us at least
      simplify it this much.
      
      Fbdev+EGL has been the unholy union used by proprietary driver stacks of
      hardware vendors in the non-PC world as a quick and dirty way to get
      something out on the screen. In these cases it is actually the EGL
      implementation that does everything internally, fbdev is not needed.
      Fbdev was never meant for the sort anyway.
      
      If anyone still needs this use case, I recommend sticking with a
      outdated Weston to match your outdated platform. Or if you really
      insist, write a new backend that does not pretend to use fbdev and just
      initializes EGL and GL-renderer.
      
      Cc: Adrian Negreanu <groleo@gmail.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Quentin Glidic's avatarQuentin Glidic <sardemff7+git@sardemff7.net>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      e77f8ad7
  7. 06 Jun, 2016 3 commits
  8. 03 Jun, 2016 8 commits
  9. 11 May, 2016 8 commits
  10. 10 May, 2016 1 commit
    • Giulio Camuffo's avatar
      drm: port the drm backend to the new init api · 1c0e40d9
      Giulio Camuffo authored
      Preparing for libweston and for the separation of the code base into
      libweston vs. weston the compositor, we must remove all uses
      weston_config structures from the backends. We have decided that all
      option and config input happens in the compositor (main.c), and
      configuration is passed in for the backends as structs.
      
      Most other backends have already converted, and this patch converts the
      DRM-backend to the libweston-style init API.
      
      The libweston-style init API includes a header for each backend (here
      compositor-drm.h) defining the configuration interface. The compositor
      (main.c) prepares a configuration struct to be passed through libweston
      core to the backend during initialization.
      
      A complication with the DRM-backend is that outputs can be hotplugged,
      and their configuration needs to be fetched from the compositor
      (main.c). For this, the config struct contains a callback member. The
      output configuration API is subject to change later, this is just a
      temporary API to get libweston forward.
      
      As weston_compositor's user_data was not previously used for anything,
      and the output configuration callback needs data, the user_data is set
      to the 'config' pointer. This pointer is only used in
      drm_configure_output() in main.c.
      
      [Bryce: lots of stuff and rebasing]
      Signed-off-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      Reviewed-by: Quentin Glidic's avatarQuentin Glidic <sardemff7+git@sardemff7.net>
      Acked-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Tested-by: default avatarBenoit Gschwind <gschwind@gnu-log.net>
      [Pekka: write commit message]
      [Pekka: squash in "drm: Don't hang onto the backend config object
      post-backend_init" from Bryce Harrington]
      [Pekka: drop the compositor.h hunk]
      [Pekka: do not #include inside extern "C"]
      [Pekka: remove incorrect comment about weston_drm_backend_config
      ownership.]
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      1c0e40d9
  11. 03 May, 2016 2 commits
  12. 02 May, 2016 1 commit
  13. 29 Apr, 2016 1 commit
  14. 25 Apr, 2016 1 commit
  15. 18 Apr, 2016 3 commits
  16. 12 Jan, 2016 1 commit
  17. 30 Nov, 2015 1 commit
  18. 23 Oct, 2015 1 commit