Age | Commit message (Collapse) | Author | Files | Lines |
|
The vdagent process currently exits with an error code set to 0 whenn
the virtio device cannot be opened (for example because it's missing).
This is not consistent with the other failures to startup which set the
exit code to 1. This commit ensures 1 is returned in this situation too.
Resolves: rhbz#1256704
|
|
This correctly fixes the leak from reverted patch
4835df0b642dfc963e7
==2648== HEAP SUMMARY:
==2648== in use at exit: 104,699 bytes in 1,459 blocks
==2648== total heap usage: 14,177 allocs, 12,718 frees, 1,190,456 bytes allocated
==2648==
==2648== 16 bytes in 1 blocks are definitely lost in loss record 16 of 130
==2648== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2648== by 0x10B530: agent_read_complete (vdagentd.c:715)
==2648== by 0x10E8DC: udscs_read_complete (udscs.c:460)
==2648== by 0x10EAFC: udscs_do_read (udscs.c:515)
==2648== by 0x10E490: udscs_client_handle_fds (udscs.c:349)
==2648== by 0x10E402: udscs_server_handle_fds (udscs.c:337)
==2648== by 0x10BAB1: main_loop (vdagentd.c:844)
==2648== by 0x10A3E6: main (vdagentd.c:974)
==2648==
==2648== LEAK SUMMARY:
==2648== definitely lost: 16 bytes in 1 blocks
==2648== indirectly lost: 0 bytes in 0 blocks
==2648== possibly lost: 41,483 bytes in 1,268 blocks
==2648== still reachable: 63,200 bytes in 190 blocks
==2648== suppressed: 0 bytes in 0 blocks
==2648== Reachable blocks (those to which a pointer was found) are not shown.
==2648== To see them, rerun with: --leak-check=full --show-leak-kinds=all
|
|
This reverts commit 4835df0b642dfc963e7cbaabfe93da86482f0b93.
uinput only holds reference to screen_info and should not free it.
The leak should be fixed somewhere else.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1262635
|
|
|
|
Compilation breaks with older gcc versions (gcc (GCC) 4.4.7 20120313
(Red Hat 4.4.7-11) on RHEL6) with the following error (due to the
additional use of -Werror in the default CFLAGS)
CC src/src_spice_vdagent-vdagent-x11-randr.o
cc1: warnings being treated as errors
src/vdagent-x11-randr.c: In function ‘vdagent_x11_randr_handle_event’:
src/vdagent-x11-randr.c:499: error: dereferencing pointer ‘sce’ does break strict-aliasing rules
src/vdagent-x11-randr.c:499: error: dereferencing pointer ‘sce’ does break strict-aliasing rules
src/vdagent-x11-randr.c:498: note: initialized from here
make: *** [src/src_spice_vdagent-vdagent-x11-randr.o] Error 1
Strict aliasing is not something we must have for the agent, and the
alternative would most likely involve an anonymous union, or some
casting. Given that this warning only occurs with these older compilers,
better to go with a fix as non-invasive as possible.
Resolves: https://bugs.freedesktop.org/show_bug.cgi?id=90981
|
|
Added by commits: 251637aa23 and 1c25f882a
|
|
spice-protocol newer than 0.12.7 is needed for the volume
synchronization bits.
|
|
Avoids a crash when running spice-vdagent with debug
Backtrace:
#0 0x0000003dcf647e2c in _IO_vfprintf_internal (s=<value optimized out>, format=<value optimized out>, ap=<value optimized out>) at vfprintf.c:1641
#1 0x0000003dcf6e4e90 in __vsyslog_chk (pri=<value optimized out>, flag=-1, fmt=0x40f360 "%p received %s, arg1: %u, arg2: %u, size %u", ap=0x7fffffffddc0) at ../misc/syslog.c:222
#2 0x0000003dcf6e50c0 in __syslog (pri=<value optimized out>, fmt=<value optimized out>) at ../misc/syslog.c:119
#3 0x000000000040c6da in udscs_read_complete (connp=0x610de8) at src/udscs.c:448
#4 0x000000000040c8d1 in udscs_do_read (connp=0x610de8) at src/udscs.c:500
#5 0x000000000040c303 in udscs_client_handle_fds (connp=0x610de8, readfds=0x7fffffffe0a0, writefds=0x7fffffffe020) at src/udscs.c:349
#6 0x0000000000403d74 in main (argc=3, argv=0x7fffffffe248) at src/vdagent.c:365
|
|
Include the capability of volume sync to set volume or mute to default
sink-input/source-output of guest.
|
|
This patch includes the vdagent-audio.[ch] files in order to
communicate with backend audio server.
The two functions provide a way to set volume and mute in the guest
by connecting to default mixer control in alsa which is 'Master' for
playback and 'Capture' for record.
|
|
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1086657
|
|
Make sure vdagent follows the current monitor configuration. This
solves a number of issue where the pointer input is off, because the
uinput tablet isn't reconfigured.
https://bugzilla.redhat.com/show_bug.cgi?id=1086657
|
|
GNOME will restore monitors.xml configuration whenever the timestamp
"config > change". The "change" timestamp is the last user applied
configuration, whereas the "config" timestamp is updated when
the screen is updated or ouput/crtc modes are added/removed.
These condition are triggered by vdagent during monitor config. Since we
can't control the timestamps (playing with delay will be inherently
event more racy), the only sane way I can think of is to disable gsd
behaviour. This can be achieved by deleting the ~/.config/monitors.xml,
which is the intended configuration to restore, so vdagent will override
whatever configuration was saved previously.
Somehow, if vdagent would be better integrated with gnome2, it would use
the gnome-rr and/or org.gnome.SettingsDaemon.XRANDR dbus
API. Thanksfully, in gnome3, the monitor auto-configuration has been
merged in.
https://bugzilla.redhat.com/show_bug.cgi?id=1086657
|
|
This is needed on 32 bit machines for drag and drop of large files (>2GB
to work). This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1206663
|
|
Since previous commit, vdagent_x11_set_monitor_config() will return
early if 'curr' is NULL so we don't need to explicitly check its value.
Issue reported by the Coverity checker.
|
|
get_current_mon_config() can return NULL, but
vdagent_x11_set_monitor_config() was calling it without checking if it's
NULL before dereferencing it.
This issue was pinpointed by Coverity.
|
|
The following leak is fixed by this patch:
==2648== HEAP SUMMARY:
==2648== in use at exit: 104,699 bytes in 1,459 blocks
==2648== total heap usage: 14,177 allocs, 12,718 frees, 1,190,456 bytes allocated
==2648==
==2648== 16 bytes in 1 blocks are definitely lost in loss record 16 of 130
==2648== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2648== by 0x10B530: agent_read_complete (vdagentd.c:715)
==2648== by 0x10E8DC: udscs_read_complete (udscs.c:460)
==2648== by 0x10EAFC: udscs_do_read (udscs.c:515)
==2648== by 0x10E490: udscs_client_handle_fds (udscs.c:349)
==2648== by 0x10E402: udscs_server_handle_fds (udscs.c:337)
==2648== by 0x10BAB1: main_loop (vdagentd.c:844)
==2648== by 0x10A3E6: main (vdagentd.c:974)
==2648==
==2648== LEAK SUMMARY:
==2648== definitely lost: 16 bytes in 1 blocks
==2648== indirectly lost: 0 bytes in 0 blocks
==2648== possibly lost: 41,483 bytes in 1,268 blocks
==2648== still reachable: 63,200 bytes in 190 blocks
==2648== suppressed: 0 bytes in 0 blocks
==2648== Reachable blocks (those to which a pointer was found) are not shown.
==2648== To see them, rerun with: --leak-check=full --show-leak-kinds=all
|
|
transferred
Once transferring multiple files is supported, do not bother the user
opening the file transfer directory for each file transferred, just do it
when the last file transfer is finished.
|
|
This commit sends back a VD_AGENT_FILE_XFER_STATUS_ERROR to clients which
try to transfer files when the agent disabled file transfers (for example
because there is no valid destination directory for the transferred files).
|
|
Currently, if no suitable destination directory can be found, the file
transfer code defaults to using '.' as the destination directory. As this
is unlikely to work, better to just disable file transfers when we end up
in such a situation. This currently happens when spawning spice-vdagent
from gdm where we don't want file transfers to be available anyway.
|
|
This commit only adds if (vdagent_file_xfers != NULL) {} checks before
calling into the file transfer code. This allows to disable file transfer
handling by setting this variable to NULL.
|
|
With the next commit, we won't always have a file xfer object available.
This next commit will make sure NULL is never passed to the public file
xfer functions, but it's safer to guard against that anyway in case
this gets broken in the future.
|
|
Many systems don't use rsyslog, others don't need seperate syslog files
for vdagent.
With systemd journal, It's possible to filter
spice-vdagent/spice-vdagentd log messages out of /var/log/messages:
journalctl SYSLOG_IDENTIFIER=spice-vdagent SLOG_IDENTIFIER=spice-vdagentd
This simplify spice-vdagent packaging and updates, since there are no
config files to deal with.
Related:
https://bugzilla.redhat.com/show_bug.cgi?id=1136881
|
|
This is to please vncviewer.
https://bugzilla.redhat.com/show_bug.cgi?id=1117764
|
|
Add TIMESTAMP handling,
This is to please vncviewer.
https://bugzilla.redhat.com/show_bug.cgi?id=1117764
|
|
Signed-off-by: Jeremy White <jwhite@codeweavers.com>
|
|
mainline.
This allows the vdagent to be used in the Xsetup phase of an xdm session;
otherwise, it's X11 connection fails because of the greeter display grab.
The issue is that we daemonize before attempting the X connection.
We then immediately exit the main process; xdm then goes on to invoke the
greeter which performs an exclusive grab on the X server, so the child
connection fails.
The change is to have the main process wait for up to 10 seconds for an 'all clear'
message from the client. This lets us return a correct status on a real X
error, as well as letting our child successfully connect to the X server.
Signed-off-by: Jeremy White <jwhite@codeweavers.com>
|
|
Signed-off-by: Jeremy White <jwhite@codeweavers.com>
|
|
gdm 3.1.90 (June 2011) changed the path where .desktop files which should
be autostarted with gdm needs to be located.
This used to be $(datadir)/gdm/autostart/LoginWindow and is now
$(datadir)/gdm/greeter/autostart.
This means that when running gdm in a VM in a recent distribution,
arbitrary resizing the VM window will not cause the resolution to be
adjusted. This used to be working in eg RHEL6.
This patch installs the .desktop file to both paths in order to work both
with older and newer gdms.
|
|
Some applications compute DPI based on physcial screen size. Currently,
the width is reported to be 270mm, regardless of the resolution. This
patch instead compute a physical screen size to have a constant DPI of
96. Of course, there are possible improvements to this approach (see
fixme), however, since that code is no longer executed with DRM driver,
I don't think we should invest more effort here (I guess DRM driver
relies on xrandr / gnome-settings-daemon to do the right thing, so
physical screen is updated)
https://bugzilla.redhat.com/show_bug.cgi?id=1066094
|
|
In certain configurations (Fedora 20 or RHEL7 guests on a RHEL6 host), this call
fails, which cause the vdagent to abort. This patch prevents the crash, though
arbitrary resizing is obviously still non-functional in this situation.
|
|
When running a guest using a KMS QXL driver on a RHEL6 hypervisor,
spice_vdagent would crash on resolution changes with:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 139 (RANDR)
Minor opcode of failed request: 21 (RRSetCrtcConfig)
Value in failed request: 0x0
Serial number of failed request: 75
Current serial number in output stream: 75
(if using a newer QEMU, this will not crash as the resolution codepath is
totally different, see red_dispatcher_use_client_monitors_config() in
spice-server, when using the UMS QXL driver, the crash will not happen
because of
http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=907d0ff0
).
This crash happens in vdagent_x11_set_monitor_config() because the X server
rejects the request because we are trying to set a CRTC to a size which is
bigger than the current screen (using 'screen' and 'CRTC' as in the RandR
spec at http://www.x.org/releases/X11R7.5/doc/randrproto/randrproto.txt ).
If we resize the screen before changing the CRTCs resolution, then this
error will no longer happen. However, if we first call XRRSetScreenSize()
and then XRRSetCrtcConfig(), the call to XRRSetScreeSize() will fail when
we try to make the screen smaller as there will be active CRTCs which would
be bigger than the screen.
In order to solve these issues, we follow the same process as what mutter
does in meta_monitor_manager_xrandr_apply_configuration()
https://git.gnome.org/browse/mutter/tree/src/core/monitor-xrandr.c#n689:
1. we disable the CRTCs which are off and the ones which are bigger than the
size we want to set the screen to.
2. we resize the screen with a call to XRRSetScreenSize().
3. we set each CRTCs to their new resolution.
|
|
Do not send clipboard data bigger than last received
VDAgentMaxClipboard.
There is no need to further limit at the session agent, since it is
already OOM safe, and since marhsalling/sending is local, that shouldn't
make any stability or speed difference that deserves the added
complexity.
|
|
|
|
Make it easier later to send customized clipboard message
|
|
|
|
|
|
|
|
Signed-off-by: Alon Levy <alevy@redhat.com>
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1003977
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Alon Levy <alevy@redhat.com>
|
|
This is used with Xspice. Fake means we open a pipe for write only, and
don't do any ioctls on it. Specifically it means the axis and buttons
have to be coordinated for now with Xspice (xf86-video-qxl).
Signed-off-by: Alon Levy <alevy@redhat.com>
|
|
Signed-off-by: Alon Levy <alevy@redhat.com>
|
|
Signed-off-by: Alon Levy <alevy@redhat.com>
|
|
Signed-off-by: Alon Levy <alevy@redhat.com>
|
|
Some bad clients, ie autocutsel, don't stick to the icccm spec, causing us to
flood the logs with error messages, turn these into debug messages instead,
so that they are only shown when debuggging / verbose logging is turned on.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Fedora for example bundles the SPICE agent by default; however, we
don't want to spew an error when running non-virtualized, or with
plain VNC.
Let's just silently exit; while we could change LOG_ERR -> LOG_INFO
or something, that's still pointless noise in most people's syslog.
Someone who was debugging a misconfigured SPICE setup would pretty
quickly notice that they were missing the virtio port.
(This patch is part of a larger initiative to reduce error
spew on default startup in common deployment scenarios such as
KVM+VNC.)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|