1. 12 Apr, 2019 3 commits
  2. 08 Mar, 2019 5 commits
  3. 01 Mar, 2019 3 commits
  4. 27 Feb, 2019 2 commits
  5. 25 Feb, 2019 1 commit
    • Jakub Janků's avatar
      x11: invalidate requests for targets on grab from client · 3aff7839
      Jakub Janků authored
      If XSetSelectionOwner() is invoked during the time
      we are waiting for the requested clipboard targets,
      the targets we eventually receive are no longer valid.
      
      To solve this, ignore the same count of target notifications
      as we expected at the time we received grab from the client.
      
      Otherwise we end up in a situation when vdagent holds
      the clipboard grab in the guest but cannot provide data to the
      apps that request it - this can be observed in the log:
      
          clipboard: received selection request event for target *, while not owning client clipboard
      Signed-off-by: Jakub Janků's avatarJakub Janků <jjanku@redhat.com>
      Acked-by: 's avatarVictor Toso <victortoso@redhat.com>
      3aff7839
  6. 22 Feb, 2019 1 commit
    • Jakub Janků's avatar
      clipboard: cancel request for targets on grab from client · 783ceece
      Jakub Janků authored
      If gtk_clipboard_set_with_data() is invoked between
      gtk_clipboard_request_targets() and the
      GtkClipboardTargetsReceivedFunc callback,
      the targets we eventually receive are no longer valid.
      
      To solve this, cancel the request in vdagent_clipboard_grab().
      
      Otherwise we end up in a situation when vdagent holds
      clipboard grab in the guest but cannot provide data to the
      apps that request it - this can be observed in the log:
      
          CRITICAL **: 20:48:55.782: clipboard_get_cb: assertion 'c->selections[sel_id].owner == OWNER_CLIENT' failed
      Signed-off-by: Jakub Janků's avatarJakub Janků <jjanku@redhat.com>
      Acked-by: 's avatarVictor Toso <victortoso@redhat.com>
      783ceece
  7. 20 Feb, 2019 1 commit
  8. 05 Feb, 2019 1 commit
  9. 31 Jan, 2019 2 commits
  10. 30 Jan, 2019 1 commit
  11. 29 Jan, 2019 8 commits
    • Jonathon Jongsma's avatar
      Send device info to agent when it connects · 67f3a09c
      Jonathon Jongsma authored
      Previously, the device info was only sent from the daemon to the session
      agent when we receive the device info message from the host. That means
      that if the session agent exits and reconnects, the session agent will
      not have the device info necessary to translate spice display IDs to
      guest device outputs. This patch saves the last device info message that
      was received from the host, and re-sends it to the session agent when it
      reconnects.
      
      NOTE: this may not be necessary if the server simply re-sends a device
      info message when it detects that the agent has connected...
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      67f3a09c
    • 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: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      5ad18905
    • Jonathon Jongsma's avatar
      Use new function in vdagent_x11_send_daemon_guest_xorg_res() · 5374fcc5
      Jonathon Jongsma authored
      Rather than getting the current guest resolution in a
      VDAgentMonitorsConfig struct and then translating it to a new struct
      type for sending down to the daemon, simply use the new function that
      was factored out in a previous commit and populate the message struct
      directly.
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      5374fcc5
    • Jonathon Jongsma's avatar
      Factor a function out of get_current_mon_config() · 254b5472
      Jonathon Jongsma authored
      When sending the guest xorg resolution to the vdagentd daemon, we get
      the current resolution with this function, which returns a
      VDAgentMonitorsConfig structure that must then be converted to the
      structure that we send to the daemon. Rather than re-using this function
      that returns the wrong type, factor out most of the functionality into a
      separate function. This function can be used by a new function to return
      a type appropriate for sending the xorg resolution to the daemon.
      
      This is necessary because in the next few commits I'll be changing the
      vdagentd protocol to send an additional display_id parameter to the
      daemon.
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      254b5472
    • Jonathon Jongsma's avatar
      Use guest output map to determine xrandr output · d48945fd
      Jonathon Jongsma authored
      instead of using the spice display id directly as the xrandr output,
      look it up using our new guest output map
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      d48945fd
    • Jonathon Jongsma's avatar
      Make clearer distinctions between output ids · 0e7e7b66
      Jonathon Jongsma authored
      There are basically three ways to refer to an output within vdagent:
        - The index of the array of MonitorConfig message. This is essentially
          a "spice display id"
        - the index of the array of xrandr outputs. This is the "output index"
        - the xrandr output id. This is the "output ID"
      
      Previously, the "spice display id" and the "output index" were treated
      as synonymous. But in order to support more complciated setups with
      multiple display devices, etc, we need to differentiate these ideas more
      clearly. This patch simply renames some variables and a function so that
      we can tell more easily which one of these concepts we are dealing with.
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      0e7e7b66
    • Jonathon Jongsma's avatar
      Look up and store xrandr output in display map · 353592e8
      Jonathon Jongsma authored
      Instead of storing each device address and device display ID in the hash
      table, simply use the lookup_xrandr_output_for_device_info() function to
      look up the ID of the xrandr output and store that in the hash table.
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      353592e8
    • Jonathon Jongsma's avatar
      Add lookup_xrand_output_for_device_info() · 8dc49074
      Jonathon Jongsma authored
      Add a function to look up an xrandr output for a given device display
      id. This uses sysfs and the drm subsystem to lookup information about a
      graphics device output. It then compares the drm output name to xrandr
      output names to try to match that device output to an xrandr output.
      This is necesary for guests that have multiple graphics devices.
      Acked-by: Lukáš Hrázký's avatarLukáš Hrázký <lhrazky@redhat.com>
      Signed-off-by: 's avatarJonathon Jongsma <jjongsma@redhat.com>
      8dc49074
  12. 28 Jan, 2019 1 commit
  13. 26 Jan, 2019 1 commit
  14. 17 Jan, 2019 1 commit
  15. 16 Jan, 2019 7 commits
  16. 15 Jan, 2019 1 commit
  17. 08 Jan, 2019 1 commit