Re: [Spice-devel] [PATCH 3/3] Add VD_AGENT_CAP_MAX_CLIPBOARD support
On 01/07/2014 01:28 AM, Marc-André Lureau wrote:
ping
Looks good to me.
On Thu, Nov 14, 2013 at 5:03 PM, Marc-André Lureau
marcandre.lur...@gmail.com wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
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.
---
src/vdagentd.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/vdagentd.c b/src/vdagentd.c
index 2eb97cb..1098fb6 100644
--- a/src/vdagentd.c
+++ b/src/vdagentd.c
@@ -74,6 +74,7 @@ static int agent_owns_clipboard[256] = { 0, };
static int quit = 0;
static int retval = 0;
static int client_connected = 0;
+static int max_clipboard = -1;
/* utility functions */
/* vdagentd - spice-client communication handling */
@@ -98,6 +99,7 @@ static void send_capabilities(struct vdagent_virtio_port
*vport,
VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_CLIPBOARD_SELECTION);
VD_AGENT_SET_CAPABILITY(caps-caps,
VD_AGENT_CAP_SPARSE_MONITORS_CONFIG);
VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_GUEST_LINEEND_LF);
+VD_AGENT_SET_CAPABILITY(caps-caps, VD_AGENT_CAP_MAX_CLIPBOARD);
vdagent_virtio_port_write(vport, VDP_CLIENT_PORT,
VD_AGENT_ANNOUNCE_CAPABILITIES, 0,
@@ -369,6 +371,13 @@ int virtio_port_read_complete(
vdagent_virtio_port_reset(vport, VDP_CLIENT_PORT);
do_client_disconnect();
break;
+case VD_AGENT_MAX_CLIPBOARD:
+if (message_header-size != sizeof(VDAgentMaxClipboard))
+goto size_error;
+VDAgentMaxClipboard *msg = (VDAgentMaxClipboard *)data;
+syslog(LOG_DEBUG, Set max clipboard: %d, msg-max);
+max_clipboard = msg-max;
+break;
default:
syslog(LOG_WARNING, unknown message type %d, ignoring,
message_header-type);
@@ -453,6 +462,12 @@ int do_agent_clipboard(struct udscs_connection *conn,
case VDAGENTD_CLIPBOARD_DATA:
msg_type = VD_AGENT_CLIPBOARD;
data_type = header-arg2;
+if (max_clipboard != -1 size max_clipboard) {
+syslog(LOG_WARNING, clipboard is too large (%d %d),
discarding,
+ size, max_clipboard);
+virtio_write_clipboard(selection, msg_type, data_type, NULL, 0);
+return 0;
+}
break;
case VDAGENTD_CLIPBOARD_RELEASE:
msg_type = VD_AGENT_CLIPBOARD_RELEASE;
--
1.8.3.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Fw: Re: multiple client connect spice-server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2014 01:10 PM, Lindsay Mathieson wrote: On Tue, 7 Jan 2014 10:38:26 AM David Ja?a wrote: No, only one client can connect at the same time. David On Út, 2014-01-07 at 10:05 +0800, hhb584520 wrote: how to multiple spice clients can connect to spice server at one time? It can be done: http://www.spice-space.org/page/Features/MultipleClients That page clearly says it is not recommended for anything but testing, it is broken by design and needs more work, I would only recommend it for someone who plans to develop it further. Worked for me, but haven't heavily tested it. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS0nJtAAoJEGSFt2Lm6PXuDS8H/1+XycKEKm0EyqoN/DkXTkTy AxstQmNV8t8CEhI0fBUy3A6WutkB/Zie+trAKDECYG4zoR8y4PhZ90iKoNOBXsTK H9wi/9ug4Bvc5B6wfTiMpz8GafwyZ/i86o1b0KlxM53YpDUc+GUUz72D+DoJWJQ5 UTaqdiWkklqsWbqe2UQUWft1Fdi95ZSX1gUS7xaS/NcICu2O03++vGjV1ZPNv8G+ d6sLjprApJG5w9OJU+ABJRv+XmWA1tBYlRQKpPED+XSg6uiIsGwKtD1x6CQWGQYt sBzGnewr+2zz3dpm53AwOA9DJXCt4+pufrfADiH+y3N44SMY85lwolE6t+eTpAI= =CQ2L -END PGP SIGNATURE- ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH 03/17] Move sync_write* to reds_stream.h
On 01/07/2014 01:14 PM, Christophe Fergeau wrote:
They are renamed to reds_stream_write*
You also changed the return type for reds_stream_write_all (was
sync_write) to bool, which is now being cast to int in some code paths.
Not an objection, but perhaps worth a later patch (unless it's already
addressed, I'm commenting while reading so haven't read the later
patches yet).
---
server/reds.c| 78
server/reds_stream.c | 28 +++
server/reds_stream.h | 5
3 files changed, 57 insertions(+), 54 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 81e90f3..ce8bb97 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1395,24 +1395,6 @@ int reds_handle_migrate_data(MainChannelClient *mcc,
SpiceMigrateDataMain *mig_d
return TRUE;
}
-static int sync_write(RedsStream *stream, const void *in_buf, size_t n)
-{
-const uint8_t *buf = (uint8_t *)in_buf;
-
-while (n) {
-int now = reds_stream_write(stream, buf, n);
-if (now = 0) {
-if (now == -1 (errno == EINTR || errno == EAGAIN)) {
-continue;
-}
-return FALSE;
-}
-n -= now;
-buf += now;
-}
-return TRUE;
-}
-
static void reds_channel_init_auth_caps(RedLinkInfo *link, RedChannel
*channel)
{
if (sasl_enabled !link-skip_auth) {
@@ -1473,13 +1455,13 @@ static int reds_send_link_ack(RedLinkInfo *link)
BIO_get_mem_ptr(bio, bmBuf);
memcpy(ack.pub_key, bmBuf-data, sizeof(ack.pub_key));
-if (!sync_write(link-stream, header, sizeof(header)))
+if (!reds_stream_write_all(link-stream, header, sizeof(header)))
goto end;
-if (!sync_write(link-stream, ack, sizeof(ack)))
+if (!reds_stream_write_all(link-stream, ack, sizeof(ack)))
goto end;
-if (!sync_write(link-stream, channel_caps-common_caps,
channel_caps-num_common_caps * sizeof(uint32_t)))
+if (!reds_stream_write_all(link-stream, channel_caps-common_caps,
channel_caps-num_common_caps * sizeof(uint32_t)))
goto end;
-if (!sync_write(link-stream, channel_caps-caps, channel_caps-num_caps
* sizeof(uint32_t)))
+if (!reds_stream_write_all(link-stream, channel_caps-caps,
channel_caps-num_caps * sizeof(uint32_t)))
goto end;
ret = TRUE;
@@ -1500,7 +1482,7 @@ static int reds_send_link_error(RedLinkInfo *link,
uint32_t error)
header.minor_version = SPICE_VERSION_MINOR;
memset(reply, 0, sizeof(reply));
reply.error = error;
-return sync_write(link-stream, header, sizeof(header))
sync_write(link-stream, reply,
+return reds_stream_write_all(link-stream, header, sizeof(header))
reds_stream_write_all(link-stream, reply,
sizeof(reply));
}
@@ -1522,7 +1504,7 @@ static void reds_info_new_channel(RedLinkInfo *link,
int connection_id)
static void reds_send_link_result(RedLinkInfo *link, uint32_t error)
{
-sync_write(link-stream, error, sizeof(error));
+reds_stream_write_all(link-stream, error, sizeof(error));
}
int reds_expects_link_id(uint32_t connection_id)
@@ -1977,18 +1959,6 @@ static inline void async_read_clear_handlers(AsyncRead
*obj)
reds_stream_remove_watch(obj-stream);
}
-#if HAVE_SASL
-static int sync_write_u8(RedsStream *s, uint8_t n)
-{
-return sync_write(s, n, sizeof(uint8_t));
-}
-
-static int sync_write_u32(RedsStream *s, uint32_t n)
-{
-return sync_write(s, n, sizeof(uint32_t));
-}
-#endif
-
static void async_read_handler(int fd, int event, void *data)
{
AsyncRead *obj = (AsyncRead *)data;
@@ -2157,14 +2127,14 @@ static void reds_handle_auth_sasl_step(void *opaque)
if (serveroutlen) {
serveroutlen += 1;
-sync_write(link-stream, serveroutlen, sizeof(uint32_t));
-sync_write(link-stream, serverout, serveroutlen);
+reds_stream_write_all(link-stream, serveroutlen, sizeof(uint32_t));
+reds_stream_write_all(link-stream, serverout, serveroutlen);
} else {
-sync_write(link-stream, serveroutlen, sizeof(uint32_t));
+reds_stream_write_all(link-stream, serveroutlen, sizeof(uint32_t));
}
/* Whether auth is complete */
-sync_write_u8(link-stream, err == SASL_CONTINUE ? 0 : 1);
+reds_stream_write_u8(link-stream, err == SASL_CONTINUE ? 0 : 1);
if (err == SASL_CONTINUE) {
spice_info(%s, Authentication must continue (step));
@@ -2182,7 +2152,7 @@ static void reds_handle_auth_sasl_step(void *opaque)
}
spice_info(Authentication successful);
-sync_write_u32(link-stream, SPICE_LINK_ERR_OK); /* Accept auth */
+reds_stream_write_u32(link-stream, SPICE_LINK_ERR_OK); /* Accept
auth */
/*
* Delay writing in SSF encoded until
Re: [Spice-devel] [PATCH 16/17] Introduce reds_stream_set_channel()
On 01/07/2014 01:14 PM, Christophe Fergeau wrote:
---
server/reds.c| 6 +++---
server/reds_stream.c | 9 +
server/reds_stream.h | 2 ++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index a993f2c..c6983d8 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1416,9 +1416,9 @@ static void reds_info_new_channel(RedLinkInfo *link,
int connection_id)
if (reds_stream_is_ssl(link-stream)) {
reds_stream_set_info_flag(link-stream,
SPICE_CHANNEL_EVENT_FLAG_TLS);
}
-link-stream-info-connection_id = connection_id;
-link-stream-info-type = link-link_mess-channel_type;
-link-stream-info-id = link-link_mess-channel_id;
+reds_stream_set_channel(link-stream, connection_id,
+link-link_mess-channel_type,
+link-link_mess-channel_id);
reds_stream_push_channel_event(link-stream,
SPICE_CHANNEL_EVENT_INITIALIZED);
}
diff --git a/server/reds_stream.c b/server/reds_stream.c
index d2c05d9..6af3cd1 100644
--- a/server/reds_stream.c
+++ b/server/reds_stream.c
@@ -282,6 +282,15 @@ static void reds_stream_set_socket(RedsStream *stream,
int socket)
stream-info-plen_ext);
}
+
+void reds_stream_set_channel(RedsStream *stream, int connection_id,
+ int channel_type, int channel_id)
+{
+stream-info-connection_id = connection_id;
+stream-info-type = connection_id;
+stream-info-id = channel_type;
type became id.
+}
+
RedsStream *reds_stream_new(int socket)
{
RedsStream *stream;
diff --git a/server/reds_stream.h b/server/reds_stream.h
index add9b2e..64657c2 100644
--- a/server/reds_stream.h
+++ b/server/reds_stream.h
@@ -81,6 +81,8 @@ void reds_stream_free(RedsStream *s);
void reds_stream_push_channel_event(RedsStream *s, int event);
void reds_stream_remove_watch(RedsStream* s);
+void reds_stream_set_channel(RedsStream *stream, int connection_id,
+ int channel_type, int channel_id);
RedsStream *reds_stream_new(int socket);
bool reds_stream_is_ssl(RedsStream *stream);
RedsStreamSslStatus reds_stream_ssl_accept(RedsStream *stream);
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH spice-common] RFC: spice.proto: add webdav channel
This channel provides a webdav server (rfc4918). This allows various
guest or remote system that support webdav to access a folder shared by
the client (some agent can be used to proxy the requests on a local port
for example). The webdav server may also be accessed by an hypervisor as
a remote filesystem interface, which can then be accessed by the guest
via other means (fs/fat emulation, mtp device, etc)
Due to the usage of a single channel stream and the need for concurrent
requests, webdav clients streams are multiplexed. Each client stream is
framed within 64k max messages (in little-endian)
int64client_id
uint16 size
char data[size]
A new client_id indicates a new connection. A new communication stream
with the webdav server should be started. A client stream message of
size 0 indicates a disconnection of client_id. This multiplexed
communication happens over the channel data message.
Only when the port is opened may the communication be started.
A closed port event should close all currently known multiplexed
connections.
Why WebDAV?
webdav is supported natively by various OS for a long time (circa
Windows XP). It has several open-source implementations and a variety of
tools exist. A webdav implementation can be tested and used without a
Spice server or any virtualization (this also permit sharing the
implementation with other projects in the future, such as GNOME). It is
an IETF open standard and thus thoroughly specified.
The basic requirements for an efficient remote filesystem are provided
by the standard (pipelining, concurrency, caching, copy/move, partial
io, compression, locking ...) While other features are easily possible
via extensions to the protocol (common ones are executable attributes,
or searching for example).
Given the requirements, and the popularity of http/webdav, I believe it
is the best candidate for Spice remote filesystem support.
Other alternatives (adhoc, p9, smb2, sftp) have been studied and
discarded so far since they do not match in term of features or
requirements.
---
spice.proto | 4
1 file changed, 4 insertions(+)
diff --git a/spice.proto b/spice.proto
index 67b3803..316d287 100644
--- a/spice.proto
+++ b/spice.proto
@@ -1352,6 +1352,9 @@ channel PortChannel : SpicevmcChannel {
} event;
};
+channel WebDAVChannel : PortChannel {
+};
+
protocol Spice {
MainChannel main = 1;
DisplayChannel display;
@@ -1363,4 +1366,5 @@ protocol Spice {
SmartcardChannel smartcard;
UsbredirChannel usbredir;
PortChannel port;
+WebDAVChannel webdav;
};
--
1.8.4.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH server] Associate org.spice-space.webdav.0 port to webdav channel
For example, with qemu, a webdav channel can be created this way:
-chardev spiceport,name=org.spice-space.webdav.0,...
And redirected to a virtio port:
-device virtserialport,...,name=org.spice-space.webdav.0
---
server/reds.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/server/reds.c b/server/reds.c
index 2a0002b..2c63154 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -3668,7 +3668,11 @@ static int
spice_server_char_device_add_interface(SpiceServer *s,
dev_state = spicevmc_device_connect(char_device,
SPICE_CHANNEL_USBREDIR);
}
else if (strcmp(char_device-subtype, SUBTYPE_PORT) == 0) {
-dev_state = spicevmc_device_connect(char_device, SPICE_CHANNEL_PORT);
+if (strcmp(char_device-portname, org.spice-space.webdav.0) == 0) {
+dev_state = spicevmc_device_connect(char_device,
SPICE_CHANNEL_WEBDAV);
+} else {
+dev_state = spicevmc_device_connect(char_device,
SPICE_CHANNEL_PORT);
+}
}
if (dev_state) {
@@ -4206,6 +4210,7 @@ SPICE_GNUC_VISIBLE int
spice_server_set_channel_security(SpiceServer *s, const c
[ SPICE_CHANNEL_SMARTCARD] = smartcard,
#endif
[ SPICE_CHANNEL_USBREDIR ] = usbredir,
+[ SPICE_CHANNEL_WEBDAV ] = webdav,
};
int i;
--
1.8.4.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [WIP spice-gtk 1/4] port: send opened a port-event signal on init
From: Marc-André Lureau marcandre.lur...@redhat.com If the port is already opened, emit a opened port-event on init. This simplifies user code to only handle port events. --- gtk/channel-port.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gtk/channel-port.c b/gtk/channel-port.c index 11948bb..0a8b37f 100644 --- a/gtk/channel-port.c +++ b/gtk/channel-port.c @@ -249,9 +249,12 @@ static void port_handle_init(SpiceChannel *channel, SpiceMsgIn *in) g_return_if_fail(c-name == NULL); c-name = g_strdup((gchar*)init-name); -g_object_notify(G_OBJECT(channel), port-name); port_set_opened(self, init-opened); +if (init-opened) +emit_main_context(channel, SPICE_PORT_EVENT, SPICE_PORT_EVENT_OPENED); + +g_object_notify_main_context(G_OBJECT(channel), port-name); } /* coroutine context */ -- 1.8.4.2 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [WIP spice-gtk 0/4] Add webdav channel
From: Marc-André Lureau marcandre.lur...@redhat.com Hi, This is the work in progress of a webdav channel implementation for spice-gtk. See spice.proto RFC and commit comments for more details. To test the channel, launch qemu with org.spice-space.webdav.0 port redirected to virtio, ex: -device virtserialport,..,chardev=charchannel1,name=org.spice-space.webdav.0 -chardev spiceport,name=org.spice-space.webdav.0,id=charchannel1 Then connect with spice-gtk and run while true ; do spice-webdavd -p 8000 ; done in guest. You can then access dav://localhost:8000 or browse the remote filesystems in nautilus. gvfs-fuse can be used to mount the filesystem for applications that do not support gio. The server can be used and tested independantly with the webdav-server tool. Marc-André Lureau (4): port: send opened a port-event signal on init spicy: do not flush and disconnect all kind of ports Add SpiceVMC GIOStream WIP: webdav channel configure.ac |5 + gtk/Makefile.am| 19 +- gtk/channel-base.c | 48 + gtk/channel-port.c | 38 +- gtk/channel-webdav.c | 582 + gtk/channel-webdav.h | 82 ++ gtk/map-file |1 + gtk/spice-channel-priv.h |8 + gtk/spice-channel.c|6 + gtk/spice-client.h |1 + gtk/spice-glib-sym-file|2 + gtk/spice-gtk-session.c|1 - gtk/spice-session-priv.h |2 + gtk/spice-session.c|4 +- gtk/spicy.c|3 +- gtk/vmcstream.c| 532 + gtk/vmcstream.h| 81 ++ gtk/webdav/Makefile.am | 43 + gtk/webdav/guuid.c | 471 gtk/webdav/guuid.h | 105 ++ gtk/webdav/test-start | 141 +++ gtk/webdav/webdav-server.c | 197 +++ gtk/webdav/webdav.c| 2855 gtk/webdav/webdav.h| 44 + spice-common |2 +- 25 files changed, 5233 insertions(+), 40 deletions(-) create mode 100644 gtk/channel-webdav.c create mode 100644 gtk/channel-webdav.h create mode 100644 gtk/vmcstream.c create mode 100644 gtk/vmcstream.h create mode 100644 gtk/webdav/Makefile.am create mode 100644 gtk/webdav/guuid.c create mode 100644 gtk/webdav/guuid.h create mode 100755 gtk/webdav/test-start create mode 100644 gtk/webdav/webdav-server.c create mode 100644 gtk/webdav/webdav.c create mode 100644 gtk/webdav/webdav.h -- 1.8.4.2 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [WIP spice-gtk 2/4] spicy: do not flush and disconnect all kind of ports
From: Marc-André Lureau marcandre.lur...@redhat.com
Some ports may want to live a bit longer, such as following webdav.
---
gtk/spicy.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gtk/spicy.c b/gtk/spicy.c
index dff9d44..39ff0e3 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -1475,6 +1475,7 @@ static void port_opened(SpiceChannel *channel, GParamSpec
*pspec,
/* only send a break event and disconnect */
if (g_strcmp0(name, org.spice.spicy.break) == 0) {
spice_port_event(port, SPICE_PORT_EVENT_BREAK);
+spice_channel_flush_async(channel, NULL, port_flushed_cb, conn);
}
/* handle the first spicy port and connect it to stdin/out */
@@ -1485,8 +1486,6 @@ static void port_opened(SpiceChannel *channel, GParamSpec
*pspec,
if (port == stdin_port)
goto end;
-
-spice_channel_flush_async(channel, NULL, port_flushed_cb, conn);
} else {
if (port == stdin_port)
stdin_port = NULL;
--
1.8.4.2
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [WIP vdagent] Add spice-webdavd
This daemon publishes a local port to proxy a webdav server served over
/dev/virtio-ports/org.spice-space.webdav.0 (See spice-common protocol
documentation for details of this channel)
The service is announced over avahi/mdns, so that applications such as
nautilus can quickly notice existence of a new remote filesystem.
---
Makefile.am | 6 +-
configure.ac| 4 +-
src/spice-webdavd.c | 611
3 files changed, 619 insertions(+), 2 deletions(-)
create mode 100644 src/spice-webdavd.c
diff --git a/Makefile.am b/Makefile.am
index 74cc313..6832f22 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,7 +2,7 @@ ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
NULL =
bin_PROGRAMS = src/spice-vdagent
-sbin_PROGRAMS = src/spice-vdagentd
+sbin_PROGRAMS = src/spice-vdagentd src/spice-webdavd
src_spice_vdagent_CFLAGS = $(X_CFLAGS) $(SPICE_CFLAGS) $(GLIB2_CFLAGS)
src_spice_vdagent_LDADD = $(X_LIBS) $(SPICE_LIBS) $(GLIB2_LIBS)
@@ -27,6 +27,10 @@ src_spice_vdagentd_SOURCES += src/dummy-session-info.c
endif
endif
+src_spice_webdavd_CFLAGS = $(WEBDAVD_CFLAGS) $(PIE_CFLAGS)
+src_spice_webdavd_LDADD = $(WEBDAVD_LIBS) $(PIE_LDFLAGS)
+src_spice_webdavd_SOURCES = src/spice-webdavd.c
+
noinst_HEADERS = src/glib-compat.h \
src/session-info.h \
src/udscs.h \
diff --git a/configure.ac b/configure.ac
index 79905a8..b6dc823 100644
--- a/configure.ac
+++ b/configure.ac
@@ -76,10 +76,12 @@ AC_ARG_ENABLE([static-uinput],
[enable_static_uinput=$enableval],
[enable_static_uinput=no])
-PKG_CHECK_MODULES([GLIB2], [glib-2.0 = 2.12])
+PKG_CHECK_MODULES(GLIB2, [glib-2.0 = 2.12])
PKG_CHECK_MODULES(X, [xfixes xrandr = 1.3 xinerama x11])
PKG_CHECK_MODULES(SPICE, [spice-protocol = 0.12.5])
+PKG_CHECK_MODULES(WEBDAVD, [gio-unix-2.0 avahi-gobject avahi-client])
+
if test $with_session_info = auto || test $with_session_info =
systemd; then
PKG_CHECK_MODULES([LIBSYSTEMD_LOGIN],
[libsystemd-login = 42],
diff --git a/src/spice-webdavd.c b/src/spice-webdavd.c
new file mode 100644
index 000..e371e6e
--- /dev/null
+++ b/src/spice-webdavd.c
@@ -0,0 +1,611 @@
+#include stdlib.h
+#include gio/gio.h
+#include gio/gunixsocketaddress.h
+
+#include avahi-gobject/ga-client.h
+#include avahi-gobject/ga-entry-group.h
+
+typedef struct _OutputQueue {
+GOutputStream *output;
+gboolean flushing;
+guint idle_id;
+GQueue *queue;
+} OutputQueue;
+
+typedef struct _OutputQueueElem {
+OutputQueue *queue;
+const guint8 *buf;
+gsize size;
+GFunc cb;
+gpointer user_data;
+} OutputQueueElem;
+
+static
+OutputQueue* output_queue_new(GOutputStream *output)
+{
+OutputQueue *queue = g_new0(OutputQueue, 1);
+
+queue-output = g_object_ref(output);
+queue-queue = g_queue_new();
+
+return queue;
+}
+
+static
+void output_queue_free(OutputQueue *queue)
+{
+g_warn_if_fail(g_queue_get_length(queue-queue) == 0);
+g_warn_if_fail(!queue-flushing);
+g_warn_if_fail(!queue-idle_id);
+
+g_queue_free_full(queue-queue, g_free);
+g_clear_object(queue-output);
+g_free(queue);
+}
+
+static gboolean
+output_queue_idle(gpointer user_data);
+
+static void
+output_queue_flush_cb(GObject *source_object,
+ GAsyncResult *res,
+ gpointer user_data)
+{
+GError *error = NULL;
+OutputQueueElem *e = user_data;
+OutputQueue *q = e-queue;
+
+q-flushing = FALSE;
+g_output_stream_flush_finish(G_OUTPUT_STREAM(source_object),
+ res, error);
+if (error)
+g_warning(error: %s, error-message);
+
+g_clear_error(error);
+
+if (!q-idle_id)
+q-idle_id = g_idle_add(output_queue_idle, q);
+
+g_free(e);
+}
+
+static gboolean
+output_queue_idle(gpointer user_data)
+{
+OutputQueue *q = user_data;
+OutputQueueElem *e;
+GError *error = NULL;
+
+if (q-flushing) {
+g_debug(already flushing);
+q-idle_id = 0;
+return FALSE;
+}
+
+e = g_queue_pop_head(q-queue);
+if (!e) {
+g_debug(No more data to flush);
+q-idle_id = 0;
+return FALSE;
+}
+
+g_debug(flushing % G_GSIZE_FORMAT, e-size);
+g_output_stream_write_all(q-output, e-buf, e-size, NULL, NULL, error);
+if (error)
+goto err;
+else if (e-cb)
+e-cb(q, e-user_data);
+
+q-flushing = TRUE;
+g_output_stream_flush_async(q-output, G_PRIORITY_DEFAULT, NULL,
output_queue_flush_cb, e);
+
+return TRUE;
+
+err:
+g_warning(error: %s, error-message);
+g_clear_error(error);
+
+q-idle_id = 0;
+return FALSE;
+}
+
+static void
+output_queue_push(OutputQueue *q, const guint8 *buf, gsize size,
+ GFunc pushed_cb, gpointer user_data)
+{
+OutputQueueElem *e = g_new(OutputQueueElem, 1);
+
+e-buf = buf;
+e-size = size;
+e-cb = pushed_cb;
+e-user_data = user_data;
+
Re: [Spice-devel] Spice bug62033, Gnome bug 680195 rework: new inhibitors for desktop effects
Ping... On Tue, Dec 31, 2013 at 2:28 AM, Fedor Lyakhov fedor.lyak...@gmail.com wrote: Hi all, I've sent a preview patch of this work. Please confirm 1) the names of the bus, interface, object path 2) the interface itself (currently 3 read-only properties: Connected, Type and Speed) 3) I'm not sure whether lazy generation of GDBusNodeInfo from introspection XML (as static char *) is acceptable - or should I use gdbus-codegen? My next steps include: 1. Implement export of actual properties, i.e. connection status, connection type (local/remote) and speed (in kbps). The idea is that clients are expected to use Speed to judge upon disabling some features like animations. 2. Implement signal on properties changed 3. Other TODOs (GIO 2.32 thread API change, error handling, doc comments etc.) On Mon, Dec 16, 2013 at 2:12 PM, Marc-André Lureau mlur...@redhat.com wrote: Hi - Original Message - Hi everyone, As we've decided a while ago (ITT), I'm looking into implementing a DBus interface for spice-vdagent (session-level) using GDbus API from GIO, and have run into following shortcomings: 1. vdagent is single-threaded and blocks on select() for udscs I/O 2. vdagent isn't GLib-based A simplest solution I'm going to try first: 1. Add GLib main loop in the vdagent main thread 2. Create a separate GThread for all current I/O Will such change be acceptable? Next steps I can think of: 1. Use GSource to attach current udscs I/O to GMainLoop 2. Move most of current udscs messages to DBus - probably need to keep using udscs for xfer for performance reasons. What do you think? Using GLib for main loop would be a good step forward. I am not sure using a separate thread for current IO is needed, but it might make it easier for a first step? thanks! -- Best regards, Fedor -- Best regards, Fedor ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
