Skip to content

V
vd_agent
Switch branch/tag
  1. 05 Feb, 2019 1 commit
  3. 31 Jan, 2019 2 commits
  5. 30 Jan, 2019 1 commit
  7. 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: default 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: default 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: default 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: default 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: default 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: default 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: default 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: default avatarJonathon Jongsma <jjongsma@redhat.com>
      8dc49074
  9. 28 Jan, 2019 1 commit
  11. 26 Jan, 2019 1 commit
  13. 17 Jan, 2019 1 commit
  15. 16 Jan, 2019 7 commits
  17. 15 Jan, 2019 1 commit
  19. 08 Jan, 2019 2 commits
  21. 07 Jan, 2019 2 commits
  23. 04 Jan, 2019 5 commits
  25. 03 Jan, 2019 2 commits
  27. 20 Dec, 2018 1 commit
  29. 19 Dec, 2018 2 commits
  31. 15 Dec, 2018 1 commit
  33. 16 Nov, 2018 2 commits