1. 29 Jan, 2019 1 commit
    • Jonathon Jongsma's avatar
      Send display_id down to the vdagentd daemon · 5ad18905
      Jonathon Jongsma authored
      Add a display_id field to the structure that we use to send down the
      list of guest display resolutions to the vdagentd daemon. This allows us
      to map the spice display id to the proper X display for determining
      mouse locations, etc.
      
      In the case where we have an mjpeg plugin running in the streaming
      agent, we have two spice displays representing the same guest display.
      In that scenario, the session agent may maintain the following guest
      output mapping:
       spice channel 0 (QXL) => X output 0
       spice channel 1 (streaming-agent) => X output 0
      
      While this is not necessarily a supported scenario, it would be nice if
      the cursor input worked properly in this case. The root problem is that
      when the session agent sends down the guest xorg resolutions to the
      system daemon, it simply loops through the list of xorg displays, and
      for each X display it looks up the first spice display ID associated
      with it and sends that down to the daemon. In the scenario mentioned
      above, since there is only a single X display configured (albeit
      represented by two different spice displays), we would send down a
      single display resolution to the system daemon:
       - { width=1280, height=1024, x=0, y=0, display_id=0 }
      
      Notice that there is no entry for display_id=1. When the agent receives
      a cursor input message for display channel 1, that message will get
      passed to the systemn daemon, which will attempt to look up display_id 1
      in order to convert the event coordinates to global coordinates. Finding
      no entry for display_id=1, the mouse events do not work.
      
      In this patch, when we want to send the guest resolutions down to the
      system daemon, we still loop through the list of X outputs, but for each
      output we also loop through the guest output mapping table and send a
      resolution structure down to the daemon for each registered output
      mapping.  This means that in the previously mentioned scenario, we would
      send down the following information:
       - { width=1280, height=1024, x=0, y=0, display_id=0 }
       - { width=1280, height=1024, x=0, y=0, display_id=1 }
      
       This means that when the client sends a mouse event for display_id=1,
       the system daemon knows the coordinates of the guest display associated
       with that ID and can process the mouse event properly.
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: default avatarJonathon Jongsma <jjongsma@redhat.com>
      5ad18905
  2. 28 Jan, 2019 1 commit
  3. 17 Jan, 2019 1 commit
  4. 18 May, 2017 1 commit
  5. 04 May, 2016 1 commit
    • Victor Toso's avatar
      session-info: check if session belongs to user · 4c0e9c96
      Victor Toso authored
      session-info back-ends such as console-kit and systemd-login have the
      concept of session's class which informs if session belongs to user or
      not [0]. We can disable features based on the session class.
      
      [0] Display-Managers are 'Greeter' and Display lock screens are
      'lock-screen'
      
      This patch introduces session_info_is_user() and disable file-xfer in
      case agent's session does not belong to the 'user' class. As the
      session-info data is hold by vdagentd, this patch also introduces
      VDAGENTD_FILE_XFER_DISABLE message to disable file-xfer that is done
      in vdagent.
      
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1328761Acked-by: default avatarJonathon Jongsma <jjongsma@redhat.com>
      4c0e9c96
  6. 11 Apr, 2016 1 commit
  7. 24 Apr, 2015 1 commit
  8. 06 Mar, 2013 1 commit
  9. 21 Feb, 2013 1 commit
  10. 22 Sep, 2011 1 commit
  11. 15 Jul, 2011 1 commit
  12. 04 Apr, 2011 1 commit
  13. 31 Mar, 2011 2 commits
  14. 01 Nov, 2010 1 commit
    • Hans de Goede's avatar
      vdagentd: change socket name · ba0bb9e7
      Hans de Goede authored
      Having a Unix Domain Socket directly under /tmp is a really bad idea
      (think symlink attacks). The standard solution for this is to create a
      subdir under /tmp. But since spice-vdagentd runs as root anyways we might
      just as well put it in another much safer place. So now the socket is:
      /var/run/spice-vdagentd/spice-vdagent-sock
      ba0bb9e7
  15. 30 Oct, 2010 1 commit
  16. 30 Sep, 2010 1 commit
    • Hans de Goede's avatar
      client -> guest copy paste wip · 052e2259
      Hans de Goede authored
      Also make the grab_clipboard message argument a list of supported types,
      rather then assuming that the clipboard will always contain only one
      type.
      052e2259
  17. 29 Sep, 2010 1 commit
  18. 28 Sep, 2010 1 commit
  19. 19 Sep, 2010 1 commit
  20. 14 Sep, 2010 1 commit
    • Hans de Goede's avatar
      Add unix domain client server support · 67f92ea6
      Hans de Goede authored
      To get a properly functioning agent we will need to split the functionality
      into a daemon (vdagentd, which has the rights to open the virtio device and to
      create fake input devices for the mouse) and into a client (vdagent) which
      runs under Xorg and thus can read / set things like the resolution and
      the clipboard and talks to the spice server / client through the daemon.
      
      Since we can have multiple xorg sessions active (through switch user for
      example), the daemon supports multiple agent connections. Security
      still needs to be filled in I'm afraid (see TODO).
      
      The protocol between the 2 is "described" in vdagentd-proto.h, currently there
      is only one vdagentd command, which allows vdagent to tell vdagentd the
      xorg screen resolution so that it knows what resolution to use for the
      fake absolute input device, and so that it can adjust that resolution
      if the xorg resolution changes.
      
      The client included in this commit is purely a test client, which
      just sends a hardcoded resolution once and then sits there and does nothing.
      67f92ea6