Re: [Spice-devel] Building Spice in an IDE
Hi, While Eclipse has support for C/C++ development, IMHO it is fairly poor compared to other IDEs designed for C/C++ only. Personally I use KDevelop, and haven't seen any issues with using it for Spice development. Probably Qt Creator will work as well... On Mon, Feb 24, 2014 at 7:06 PM, Alon Levy al...@redhat.com wrote: On 02/01/2014 12:54 AM, Wade Johnson wrote: Hi, I am trying to build Spice in Eclipse and make a test environment, but I am having some issues mostly with some dependencies not being resolved, and some constant definitions not being found. Are there any pointers or build guides to getting Spice set up in Eclipse that you guys have? I haven't tried doing that. If you are building spice-server you need to do git submodule init; git submodule update and you need to install some dependencies - pixman mainly, opus. In summary, if you post a specific error message it would help. The wiki has the development instructions here: http://www.spice-space.org/page/Building_Instructions (pointed to from main page via http://www.spice-space.org/page/DeveloperStartPage) Thanks, Wade Johnson ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -- Best regards, Fedor ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] volume can't be set
- Original Message -
Thanks for your respone!
It's strange that client can play audio, but can't set volume.
I have renamed the \lib\gstreamer-0.10\libgstdirectsoundsink.dll, the result
is no audio can play.
Right, if the client can play audio, then it is very likely that the plugin is
there.
Where did you get remote-viewer from? http://virt-manager.org/download/?
I have no idea what the problem is. May I verifiy the directsoundsink element
have been included?
Thanks!
2014-02-24 20:06 GMT+08:00 Marc-André Lureau mlur...@redhat.com :
- Original Message -
Hi all!
I connected Spice server by windows spice client which is complied by
mingw32, and set the volume.
But the volume didn't change.
the code form:
https://gitorious.org/spice-gtk/spice-gtk-elmarco/source/f270119352604755a13fcc87783127c3d96c4f61:gtk/spice-gstaudio.c
create pipe code:
if (pipeline == NULL)
pipeline = g_strdup_printf(appsrc is-live=1 do-timestamp=0 caps=\%s\
name=\appsrc\ ! queue !
audioconvert ! audioresample ! autoaudiosink name=\audiosink\,
audio_caps);
SPICE_DEBUG(audio pipeline: %s, pipeline);
p-playback.pipe = gst_parse_launch(pipeline, error);
if (p-playback.pipe == NULL) {
g_warning(Failed to create pipeline: %s, error-message);
goto lerr;
}
p-playback.src = gst_bin_get_by_name(GST_BIN(p-playback.pipe), appsrc);
p-playback.sink = gst_bin_get_by_name(GST_BIN(p-playback.pipe),
audiosink);
set volume code:
GstElement *e;
if (GST_IS_BIN(p-playback.sink))
e = gst_bin_get_by_interface(GST_BIN(p-playback.sink),
GST_TYPE_STREAM_VOLUME);
else
e = g_object_ref(p-playback.sink);
I have debuged the code. when the volume was set, the e returned NULL.
Is it a bug?
If you don't have a sink, it means you are missing gstreamer plugins.
On Windows, you need the directsoundsink element (from gst-plugins-good). It
implements the volume property.
cheers
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] How to start with Spice Development?
On 02/17/2014 08:14 PM, Jeremy White wrote: On 02/17/2014 08:44 AM, Alf G. wrote: Hi, I am very interested to delve into spice and perhaps do some work on it. What is the best way to start? Can I use the documents on spice-space.org/documentation.html http://spice-space.org/documentation.html as base or are they not at all up to date? Is the spice-project written in pure C or also are there C++ parts? That's great, and welcome! I think the documentation is pretty out of date. It's certainly a good start, and the core concepts in the protocol haven't changed, but the web site is well behind the code. The code is mostly C; there is a (deprecated) client written in C++. There is also a Javascript web client. I'd recommend that your first action is to pick an interesting use case, and get it working with code from git. So either qemu + windows guest, or qemu + linux guest, or pure Xspice. From there, it gets trickier. I don't think we have a set of 'easy' projects to start with. The links on the devel page don't take you to a list of open bugs, but this link should work: https://bugs.freedesktop.org/buglist.cgi?query_format=specificorder=relevance%20descbug_status=__open__product=Spice Welcome! This link is for the freedesktop bugs, but there are also a considerable number of bugs on the Red Hat bugtracker: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDclassification=Fedoracomponent=spicecomponent=spice-gtkcomponent=virt-viewercomponent=spice-html5component=spice-parentcomponent=spice-protocolcomponent=spice-vdagentcomponent=spice-xpicomponent=xorg-x11-drv-qxllist_id=2259049product=Fedoraquery_format=advanced That is incomplete - qemu is not in there, but it includes many unrelated bugs. Most Spice developers work for Red Hat, and they have internal bug trackers as well that track their priorities. But I have found them to be quite friendly and welcoming. They're often helpful on the #spice channel on irc as well. Cheers, Jeremy ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] How to drag a folder from client to guest?
- Original Message - On Tue, Feb 25, 2014 at 6:03 AM, Marc-André Lureau mlur...@redhat.com wrote: Hi - Original Message - Probably the function of copying has three defects: i)For some languages,there is a mis-encoding of file name I have solved by myself...(under some circumstance) Yeah, I remember your patch, but you didn't follow up, right? Are you still working on this? Aha:) I have followed your advices, but the effect is the same with I have patched I don't have good environment to do more test...So I still need to read source code deeply! ii)Can't drag multi-files I'm glad to see the following in source code: /* At the moment, the copy() method is limited to a single file, support for copying multi-files will be implemented later. */ g_return_if_fail(sources[1] == NULL); iii)But, it doesn't support for drag folder Is there TODO I don't find? Or any ideas about solution? Imho, dragging files/folder shouldn't be done via a Spice copy protocol. Instead, Spice should learn to implement drag and drop. Afaik this should be doable, but nobody worked on it. Actually, I'm always curious if copying muti-files/folder can be done by compressing to a zip/... before transfering ..of course, it's not a cool solution... Compression can be handled by a remote filesystem protocol. Imho, we shouldn't reimplement something like scp/rsync in Spice. Otoh, you might be interested in the sharing folder functionality. It allows you to have a folder on the client mounted/visible directly in the guest. From there copy will work like a regular guest operation, with guest UI etc. Here's a particular requirement that files can ONLY be draged from local to guest.. You mean currently? Yes, it's a known limitation. However, with the shared folder, you can copy to and from the client folder. This function is mostly ready, and I will submit a new patch this week (I'll add you in CC). I'm really appreciate to hear that, thx a lot:) ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH spice-gtk] display: fix crash when releasing primary surface
Since 1fcaaa15f8aca362f9e6afc87fb43cfbccf6ff62, display_surface is allocated using gslice. However MSG_DISPLAY_MODE handler didn't allocate using GSlice. This can eventually lead to a crash when freeing, such as: Thread no. 1 (6 frames) #2 g_slice_free1 at gslice.c:1097 #3 iter_remove_or_steal at ghash.c:787 #4 clear_surfaces at /lib64/libspice-client-glib-2.0.so.8 #5 spice_display_channel_finalize at /lib64/libspice-client-glib-2.0.so.8 #7 spice_channel_delayed_unref at /lib64/libspice-client-glib-2.0.so.8 #12 gtk_main at gtkmain.c:1158 https://bugzilla.redhat.com/show_bug.cgi?id=1069546 --- gtk/channel-display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gtk/channel-display.c b/gtk/channel-display.c index e464abf..96fd764 100644 --- a/gtk/channel-display.c +++ b/gtk/channel-display.c @@ -886,7 +886,7 @@ static void display_handle_mode(SpiceChannel *channel, SpiceMsgIn *in) g_warn_if_fail(c-mark == FALSE); -surface = spice_new0(display_surface, 1); +surface = g_slice_new0(display_surface); surface-format = mode-bits == 32 ? SPICE_SURFACE_FMT_32_xRGB : SPICE_SURFACE_FMT_16_555; surface-width = mode-x_res; -- 1.8.5.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] How to drag a folder from client to guest?
On Tue, Feb 25, 2014 at 6:15 PM, Marc-André Lureau mlur...@redhat.com wrote:
- Original Message -
On Tue, Feb 25, 2014 at 6:03 AM, Marc-André Lureau mlur...@redhat.com
wrote:
Hi
- Original Message -
Probably the function of copying has three defects:
i)For some languages,there is a mis-encoding of file name
I have solved by myself...(under some circumstance)
Yeah, I remember your patch, but you didn't follow up, right? Are you still
working on this?
Aha:) I have followed your advices, but the effect is the same with I
have patched
I don't have good environment to do more test...So I still need to
read source code deeply!
ii)Can't drag multi-files
I'm glad to see the following in source code:
/* At the moment, the copy() method is limited to a single file,
support for copying multi-files will be implemented later. */
g_return_if_fail(sources[1] == NULL);
iii)But, it doesn't support for drag folder
Is there TODO I don't find? Or any ideas about solution?
Imho, dragging files/folder shouldn't be done via a Spice copy protocol.
Instead, Spice should learn to implement drag and drop. Afaik this should
be doable, but nobody worked on it.
Actually, I'm always curious if copying muti-files/folder can be done
by compressing to a zip/... before transfering ..of course, it's not a
cool solution...
Compression can be handled by a remote filesystem protocol. Imho, we
shouldn't reimplement something like scp/rsync in Spice.
yeah, BTW, in spice-gtk-0.23/gtk/channel-main.c, if I change it like
the following, then muti-files copying works!
---g_return_if_fail(sources[1] == NULL);
if (!c-agent_connected) {
g_simple_async_report_error_in_idle(G_OBJECT(channel),
callback,
user_data,
SPICE_CLIENT_ERROR,
SPICE_CLIENT_ERROR_FAILED,
The agent is not connected);
return;
}
+++ int cnt = 0;
+++ while(NULL != sources[cnt]){
file_xfer_send_start_msg_async(channel,
--- sources[0],
+++sources[cnt],
flags,
cancellable,
progress_callback,
progress_callback_data,
callback,
user_data);
+++ ++cnt;
+++}
I think it over, and don't the reason RedHat doesn't support
muti-files copying...
Further, if g_file_get_path(sources[cnt]) is a folder, I can copy all
files by DFS/BFS, then folder copying also can be supported
Any idea?
Otoh, you might be interested in the sharing folder functionality. It
allows you to have a folder on the client mounted/visible directly in the
guest. From there copy will work like a regular guest operation, with
guest UI etc.
Here's a particular requirement that files can ONLY be draged from
local to guest..
You mean currently? Yes, it's a known limitation. However, with the shared
folder, you can copy to and from the client folder.
I mean this's my requirement, so the shared folder is not adaptable for me
This function is mostly ready, and I will submit a new patch this week (I'll
add you in CC).
I'm really appreciate to hear that, thx a lot:)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] How to drag a folder from client to guest?
- Original Message -
On Tue, Feb 25, 2014 at 6:15 PM, Marc-André Lureau mlur...@redhat.com
wrote:
- Original Message -
On Tue, Feb 25, 2014 at 6:03 AM, Marc-André Lureau mlur...@redhat.com
wrote:
Hi
- Original Message -
Probably the function of copying has three defects:
i)For some languages,there is a mis-encoding of file name
I have solved by myself...(under some circumstance)
Yeah, I remember your patch, but you didn't follow up, right? Are you
still
working on this?
Aha:) I have followed your advices, but the effect is the same with I
have patched
I don't have good environment to do more test...So I still need to
read source code deeply!
ii)Can't drag multi-files
I'm glad to see the following in source code:
/* At the moment, the copy() method is limited to a single file,
support for copying multi-files will be implemented later. */
g_return_if_fail(sources[1] == NULL);
iii)But, it doesn't support for drag folder
Is there TODO I don't find? Or any ideas about solution?
Imho, dragging files/folder shouldn't be done via a Spice copy
protocol.
Instead, Spice should learn to implement drag and drop. Afaik this
should
be doable, but nobody worked on it.
Actually, I'm always curious if copying muti-files/folder can be done
by compressing to a zip/... before transfering ..of course, it's not a
cool solution...
Compression can be handled by a remote filesystem protocol. Imho, we
shouldn't reimplement something like scp/rsync in Spice.
yeah, BTW, in spice-gtk-0.23/gtk/channel-main.c, if I change it like
the following, then muti-files copying works!
---g_return_if_fail(sources[1] == NULL);
if (!c-agent_connected) {
g_simple_async_report_error_in_idle(G_OBJECT(channel),
callback,
user_data,
SPICE_CLIENT_ERROR,
SPICE_CLIENT_ERROR_FAILED,
The agent is not connected);
return;
}
+++ int cnt = 0;
+++ while(NULL != sources[cnt]){
file_xfer_send_start_msg_async(channel,
--- sources[0],
+++sources[cnt],
flags,
cancellable,
progress_callback,
progress_callback_data,
callback,
user_data);
+++ ++cnt;
+++}
I think it over, and don't the reason RedHat doesn't support
muti-files copying...
What has redhat to do with this? It's made by a contributor, and not a
supported feature in redhat products.
Further, if g_file_get_path(sources[cnt]) is a folder, I can copy all
files by DFS/BFS, then folder copying also can be supported
Any idea?
Sure, everything is possible. Now, thinking about what make sense and where we
want to go, I think this is not the way to go. But talking is cheap, patches
welcome.
Otoh, you might be interested in the sharing folder functionality. It
allows you to have a folder on the client mounted/visible directly in
the
guest. From there copy will work like a regular guest operation, with
guest UI etc.
Here's a particular requirement that files can ONLY be draged from
local to guest..
You mean currently? Yes, it's a known limitation. However, with the shared
folder, you can copy to and from the client folder.
I mean this's my requirement, so the shared folder is not adaptable for me
I don't understand you. If you need to copy to the client, or from the client,
a shared folder will let you do that.
The current drag and drop support is a easy file copy operation from client to
guest, quite far from a real drag and drop.
This function is mostly ready, and I will submit a new patch this week
(I'll
add you in CC).
I'm really appreciate to hear that, thx a lot:)
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] migration: Don't assert() if MIGRATE_DATA comes before attaching the agent
Hey,
On Mon, Feb 24, 2014 at 08:26:34PM +0100, Marc-André Lureau wrote:
On Mon, Feb 24, 2014 at 6:44 PM, Christophe Fergeau cferg...@redhat.com
wrote:
During seamless migration, after switching host, if a client was connected
during the migration, it will have data to send back to the new
qemu/spice-server instance. This is handled through MIGRATE_DATA messages.
SPICE char devices use such MIGRATE_DATA messages to restore their state.
However, the MIGRATE_DATA message can arrive any time after the new qemu
instance has started, this can happen before or after the SPICE char
devices have been created. In order to handle this, if the migrate data
arrives early, it's stored in reds-agent_state.mig_data, and
attach_to_red_agent() will restore the agent state as appropriate.
Unfortunately this does not work as expected as expected. If
attach_to_red_agent() is called before the MIGRATE_DATA message reaches the
server, all goes well, but if MIGRATE_DATA reaches the server before
attach_to_red_agent() gets called, then some assert() get triggered in
spice_char_device_state_restore():
((null):32507): Spice-ERROR **:
char_device.c:937:spice_char_device_state_restore: assertion
`dev-num_clients == 1 dev-wait_for_migrate_data' failed
Thread 3 (Thread 0x7f406b543700 (LWP 32543)):
Thread 2 (Thread 0x7f40697ff700 (LWP 32586)):
Thread 1 (Thread 0x7f4079b45a40 (LWP 32507)):
What happens is that dev-wait_for_migrate_data is unconditionally cleared
when
completing handling of the MIGRATE_DATA message, so it's FALSE when
Isn't it going to be still FALSE after this patch?
spice_char_device_state_restore() is called. Moreover, dev-num_clients is
also 0 as this is only increased by spice_char_device_start() which
spice_server_char_device_add_interface() calls after
attach_to_red_agent()/spice_char_device_state_restore() have been called.
I don't see how this could have changed either.
This commit changes the logic in spice_server_char_device_add_interface(),
and when there is migrate data pending in reds-agent_state.mig_data, we
only attempt to restore it after successfully initializing/starting the
needed char device.
Sorry, I must be tired reading the server code, but I don't see how
this could change the race you described above. I am surely missing
something :)
I'll have to improve the commit log as I had to reproduce the bug and poke
at the code some more in order to answer your comments :(
See below for answers to your comments above
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035184
---
server/reds.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 1f02553..217c74e 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -2856,16 +2856,7 @@ static SpiceCharDeviceState
*attach_to_red_agent(SpiceCharDeviceInstance *sin)
state-read_filter.discard_all = FALSE;
reds-agent_state.plug_generation++;
-if (reds-agent_state.mig_data) {
-spice_assert(reds-agent_state.plug_generation == 1);
-reds_agent_state_restore(reds-agent_state.mig_data);
-free(reds-agent_state.mig_data);
-reds-agent_state.mig_data = NULL;
-} else if
(!red_channel_waits_for_migrate_data(reds-main_channel-base)) {
-/* we will assoicate the client with the char device, upon
reds_on_main_agent_start,
- * in response to MSGC_AGENT_START */
-main_channel_push_agent_connected(reds-main_channel);
-} else {
+if (red_channel_waits_for_migrate_data(reds-main_channel-base) ||
reds-agent_state.mig_data) {
Note the added || reds-agent_state.mig_data here. agent_state.mig_data
will be non-NULL iff we got a MIGRATE_DATA message before calling
attach_to_red_agent(). The whole block is:
if (red_channel_waits_for_migrate_data(reds-main_channel-base) ||
reds-agent_state.mig_data) {
spice_debug(waiting for migration data);
if (!spice_char_device_client_exists(reds-agent_state.base,
reds_get_client())) {
int client_added;
client_added = spice_char_device_client_add(reds-agent_state.base,
This call to spice_char_device_client_add() will cause dev-num_clients to
increase
reds_get_client(),
TRUE, /* flow control */
REDS_VDI_PORT_NUM_RECEIVE_BUFFS,
REDS_AGENT_WINDOW_SIZE,
~0,
TRUE);
and this last argument set to TRUE is 'int wait_for_migrate_data' and its
value is assigned to dev-wait_for_migrate_data.
So thanks to the added condition, the char device is in the state
Re: [Spice-devel] [PATCH spice-gtk] display: fix crash when releasing primary surface
On Tue, Feb 25, 2014 at 11:45:39AM +0100, Marc-André Lureau wrote: Since 1fcaaa15f8aca362f9e6afc87fb43cfbccf6ff62, display_surface is allocated using gslice. However MSG_DISPLAY_MODE handler didn't allocate using GSlice. This can eventually lead to a crash when freeing, such as: ACK Christophe Thread no. 1 (6 frames) #2 g_slice_free1 at gslice.c:1097 #3 iter_remove_or_steal at ghash.c:787 #4 clear_surfaces at /lib64/libspice-client-glib-2.0.so.8 #5 spice_display_channel_finalize at /lib64/libspice-client-glib-2.0.so.8 #7 spice_channel_delayed_unref at /lib64/libspice-client-glib-2.0.so.8 #12 gtk_main at gtkmain.c:1158 https://bugzilla.redhat.com/show_bug.cgi?id=1069546 --- gtk/channel-display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gtk/channel-display.c b/gtk/channel-display.c index e464abf..96fd764 100644 --- a/gtk/channel-display.c +++ b/gtk/channel-display.c @@ -886,7 +886,7 @@ static void display_handle_mode(SpiceChannel *channel, SpiceMsgIn *in) g_warn_if_fail(c-mark == FALSE); -surface = spice_new0(display_surface, 1); +surface = g_slice_new0(display_surface); surface-format = mode-bits == 32 ? SPICE_SURFACE_FMT_32_xRGB : SPICE_SURFACE_FMT_16_555; surface-width = mode-x_res; -- 1.8.5.3 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel pgpIsMLrUoBO4.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk] RFC: populate all clipboards
On Mon, Feb 24, 2014 at 06:33:34AM -0500, Marc-André Lureau wrote:
On Thu, Feb 20, 2014 at 04:15:51PM +0100, Marc-André Lureau wrote:
Nevertheless, this is a proof of concept, when setting
SPICE_CLIPBOARD_FILL_ALL=1, all implemented clipboards will be
populated by spice-gtk.
Has this been requested when using linux clients with linux guests? If it's
only useful for Windows clients/linux guests, shouldn't we set both
selection and clipboard in the linux guest when filling the windows
clipboard, and just keep the regular behaviour in all other cases?
The proposal is to implement SPICE_CLIPBOARD_FILL_ALL=1 that will sync
all clipboards: keep it simple. I don't fancy more having special cases
OS / direction.
Well, this env variable really is an unbreak my app option, which people
need to know about, so this needs to be documented, this can't be switched
at runtime, ...
I'd just replace the if (g_getenv(...)) {} with some kind of if
(os_is_win32()) which is probably closer to the expected behaviour as
Windows does not have the clipboard/selection distinction.
Christophe
pgpljHPMvUxKE.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk] RFC: populate all clipboards
- Original Message -
On Mon, Feb 24, 2014 at 06:33:34AM -0500, Marc-André Lureau wrote:
On Thu, Feb 20, 2014 at 04:15:51PM +0100, Marc-André Lureau wrote:
Nevertheless, this is a proof of concept, when setting
SPICE_CLIPBOARD_FILL_ALL=1, all implemented clipboards will be
populated by spice-gtk.
Has this been requested when using linux clients with linux guests? If
it's
only useful for Windows clients/linux guests, shouldn't we set both
selection and clipboard in the linux guest when filling the windows
clipboard, and just keep the regular behaviour in all other cases?
The proposal is to implement SPICE_CLIPBOARD_FILL_ALL=1 that will sync
all clipboards: keep it simple. I don't fancy more having special cases
OS / direction.
Well, this env variable really is an unbreak my app option, which people
need to know about, so this needs to be documented, this can't be switched
at runtime, ...
I don't think it should be enabled by default. It really breaks some use cases!
(like doing regular 2 clipboards manipulations in guests)
This is all wrong, I think we should solve this elsewhere really. Just because
we can do something doesn't mean we should do it.
I'd just replace the if (g_getenv(...)) {} with some kind of if
(os_is_win32()) which is probably closer to the expected behaviour as
Windows does not have the clipboard/selection distinction.
Please discuss your proposal in the bug with the reporter/requester. I'll do
the same once I figure a different solution that doesn't involve Spice.
Christophe
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk] RFC: populate all clipboards
On Tue, Feb 25, 2014 at 10:36:56AM -0500, Marc-André Lureau wrote:
I'd just replace the if (g_getenv(...)) {} with some kind of if
(os_is_win32()) which is probably closer to the expected behaviour as
Windows does not have the clipboard/selection distinction.
Please discuss your proposal in the bug with the reporter/requester. I'll
do the same once I figure a different solution that doesn't involve
Spice.
I guess you are looking for something like
http://docs.kde.org/stable/en/kde-workspace/klipper/clipboard-modes.html
wikipedia also mentions parcellite and glipper, but I don't know if they
can do what you are after.
xsel also lets you add data to whatever clipboard you want, but this would
be a manual process.
Christophe
pgp1_y7yi4KIK.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk] RFC: populate all clipboards
On Tue, Feb 25, 2014 at 10:36:56AM -0500, Marc-André Lureau wrote: Well, this env variable really is an unbreak my app option, which people need to know about, so this needs to be documented, this can't be switched at runtime, ... I don't think it should be enabled by default. It really breaks some use cases! (like doing regular 2 clipboards manipulations in guests) No idea how often people are going to want to use the 2 separate clipboards with different data, nor if they are going to try to do this from Windows? Christophe pgpdihMhOLscZ.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] volume can't be set
Yes, I have installed virt-viewer 0.6.0 Win x86 MSI from
http://virt-manager.org/download/, and tried to set volume, but the volume
couldn't be set too.
2014-02-25 17:53 GMT+08:00 Marc-André Lureau mlur...@redhat.com:
- Original Message -
Thanks for your respone!
It's strange that client can play audio, but can't set volume.
I have renamed the \lib\gstreamer-0.10\libgstdirectsoundsink.dll, the
result
is no audio can play.
Right, if the client can play audio, then it is very likely that the
plugin is there.
Where did you get remote-viewer from? http://virt-manager.org/download/?
I have no idea what the problem is. May I verifiy the directsoundsink
element
have been included?
Thanks!
2014-02-24 20:06 GMT+08:00 Marc-André Lureau mlur...@redhat.com :
- Original Message -
Hi all!
I connected Spice server by windows spice client which is complied by
mingw32, and set the volume.
But the volume didn't change.
the code form:
https://gitorious.org/spice-gtk/spice-gtk-elmarco/source/f270119352604755a13fcc87783127c3d96c4f61:gtk/spice-gstaudio.c
create pipe code:
if (pipeline == NULL)
pipeline = g_strdup_printf(appsrc is-live=1 do-timestamp=0 caps=\%s\
name=\appsrc\ ! queue !
audioconvert ! audioresample ! autoaudiosink name=\audiosink\,
audio_caps);
SPICE_DEBUG(audio pipeline: %s, pipeline);
p-playback.pipe = gst_parse_launch(pipeline, error);
if (p-playback.pipe == NULL) {
g_warning(Failed to create pipeline: %s, error-message);
goto lerr;
}
p-playback.src = gst_bin_get_by_name(GST_BIN(p-playback.pipe),
appsrc);
p-playback.sink = gst_bin_get_by_name(GST_BIN(p-playback.pipe),
audiosink);
set volume code:
GstElement *e;
if (GST_IS_BIN(p-playback.sink))
e = gst_bin_get_by_interface(GST_BIN(p-playback.sink),
GST_TYPE_STREAM_VOLUME);
else
e = g_object_ref(p-playback.sink);
I have debuged the code. when the volume was set, the e returned NULL.
Is it a bug?
If you don't have a sink, it means you are missing gstreamer plugins.
On Windows, you need the directsoundsink element (from
gst-plugins-good). It
implements the volume property.
cheers
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
