Re: [Spice-devel] [PATCH] make celt to be optional
On Tue, 2012-06-12 at 16:33 +0200, Christophe Fergeau wrote: On Tue, Jun 12, 2012 at 09:59:39AM -0400, Marc-André Lureau wrote: - Mensaje original - On Tue, Jun 12, 2012 at 09:11:24AM -0400, Marc-André Lureau wrote: As long as the bitstream is not frozen, we can't use opus, or we will have the same problems as with celt today. As I understand it, while the bitstream is not officially frozen yet, it's very unlikely to change before the real freeze (unless big last minute issues are fine), so an Opus mode (marked as no compat guarantees, use at your own risk, ...) will probably not cause significant compatibilities issues. That's just guesses. It's not about library API, but about bitstream. There is no guarantee. A guess supported by the slides at http://www.opus-codec.org/presentations/ , by various mailing posts from opus developers, ... Sticking to celt051 is still a safer alternative. Not suggesting dropping celt051 support upstream... Otherwise, how would you identify almost-frozen bitstream to frozen bitstream? You would have to identify by library version (erk!) and be compatible with the old and new bitstram (which might be complicated depending on library design), or be incompatible with the intermediate version, situation which we better avoid! We would make no guarantee with interoperability between binaries using different opus versions until the format is officially frozen. I agree there's a bit of uncertainty in this move, but I think that at this point it's a reasonable assumption that things will work, even with different opus versions. It seems like Opus is at a stage where we want to at least start adding support for it so we can switch to it by default as early as possible. Its not like this is a new idea, the plan was always to jump to a stable bitstream format when one appeared. However, that is imho a different issue than the celt051 support. A new release of spice client and server supporting opus does not magically make old servers and client disappear, so it would still be the case that e.g. debian spice client would get lame audio performance if connecting to say a RHEV spice client, or if some old client connects to a server running on debian. In time, it would perhaps make sense to drop celt051 support, but its seems pretty bad to release a client binary that doesn't do audio well with all currently existing deployed servers. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-common PATCH] python_modules/ptypes.py/EnumBaseType.c_enumname: add missing return to fix broken enums generation
--- python_modules/ptypes.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/python_modules/ptypes.py b/python_modules/ptypes.py index 132ba99..d9fbfe2 100644 --- a/python_modules/ptypes.py +++ b/python_modules/ptypes.py @@ -234,7 +234,7 @@ class EnumBaseType(Type): return codegen.prefix_camel(self.name) def c_enumname(self, value): -self.c_enumname_by_name(self.names[value]) +return self.c_enumname_by_name(self.names[value]) def c_enumname_by_name(self, name): if self.has_attr(prefix): -- 1.7.10.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-common PATCH] python_modules/ptypes.py/EnumBaseType.c_enumname: add missing return to fix broken enums generation
I don't see exactly what it will fixed, perhaps you should include a small example. But that looks like a typo and can't harm, ACK - Mensaje original - --- python_modules/ptypes.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/python_modules/ptypes.py b/python_modules/ptypes.py index 132ba99..d9fbfe2 100644 --- a/python_modules/ptypes.py +++ b/python_modules/ptypes.py @@ -234,7 +234,7 @@ class EnumBaseType(Type): return codegen.prefix_camel(self.name) def c_enumname(self, value): -self.c_enumname_by_name(self.names[value]) +return self.c_enumname_by_name(self.names[value]) def c_enumname_by_name(self, name): if self.has_attr(prefix): -- 1.7.10.1 ___ 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] Menubar toggle option
This very simple patch adds an option to toggle the menubar on spicy.
Helps maximize vertical resolution capacity without going fullscreen.
Please consider for inclusion.
jr
--
Joel W. Reed
Managing Partner
OpenArc, LLC
o: 724.234.1215
c: 412.212.8418
diff --git a/gtk/spicy.c b/gtk/spicy.c
index cbc702e..2eeed16 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -499,6 +499,15 @@ static void menu_cb_statusbar(GtkToggleAction *action, gpointer data)
g_key_file_set_boolean(keyfile, ui, statusbar, state);
}
+static void menu_cb_menubar(GtkToggleAction *action, gpointer data)
+{
+struct spice_window *win = data;
+gboolean state = gtk_toggle_action_get_active(action);
+
+gtk_widget_set_visible(win-menubar, state);
+g_key_file_set_boolean(keyfile, ui, menubar, state);
+}
+
static void menu_cb_about(GtkAction *action, void *data)
{
char *comments = _(gtk test client app for the\n
@@ -551,6 +560,9 @@ static gboolean window_state_cb(GtkWidget *widget, GdkEventWindowState *event,
toggle = gtk_action_group_get_action(win-ag, Statusbar);
state = gtk_toggle_action_get_active(GTK_TOGGLE_ACTION(toggle));
gtk_widget_set_visible(win-statusbar, state);
+toggle = gtk_action_group_get_action(win-ag, Menubar);
+state = gtk_toggle_action_get_active(GTK_TOGGLE_ACTION(toggle));
+gtk_widget_set_visible(win-menubar, state);
}
}
return TRUE;
@@ -656,6 +668,11 @@ static void restore_configuration(struct spice_window *win)
if (error == NULL)
gtk_widget_set_visible(win-statusbar, state);
g_clear_error(error);
+
+state = g_key_file_get_boolean(keyfile, ui, menubar, error);
+if (error == NULL)
+gtk_widget_set_visible(win-menubar, state);
+g_clear_error(error);
}
/* -- */
@@ -801,6 +818,11 @@ static const GtkToggleActionEntry tentries[] = {
.callback= G_CALLBACK(menu_cb_bool_prop),
},{
#endif
+.name= Menubar,
+.label = N_(Menubar),
+.callback= G_CALLBACK(menu_cb_menubar),
+.accelerator = shiftF7,
+},{
.name= Statusbar,
.label = N_(Statusbar),
.callback= G_CALLBACK(menu_cb_statusbar),
@@ -826,6 +848,7 @@ static char ui_xml[] =
/menu\n
menu action='ViewMenu'\n
menuitem action='Fullscreen'/\n
+ menuitem action='Menubar'/\n
menuitem action='Toolbar'/\n
menuitem action='Statusbar'/\n
/menu\n
@@ -1252,6 +1275,10 @@ static spice_window *create_spice_window(spice_connection *conn, int id, SpiceCh
state = gtk_widget_get_visible(win-statusbar);
gtk_toggle_action_set_active(GTK_TOGGLE_ACTION(toggle), state);
+toggle = gtk_action_group_get_action(win-ag, Menubar);
+state = gtk_widget_get_visible(win-menubar);
+gtk_toggle_action_set_active(GTK_TOGGLE_ACTION(toggle), state);
+
#ifdef USE_SMARTCARD
gboolean smartcard;
signature.asc
Description: OpenPGP digital signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk 2/3] Add a desktop-integration helper class
Hi - Mensaje original - Looks reasonable to me, however, I don't see why it should be in spice-glib, since it's very much desktop related. Wouldn't it make more sense in spice-gtk? I actually put it in spice-gtk at first, but that does not work very well because usb-device-manager needs access to the automount disable functionality. Ok Since it's not directly dependent and related to a particular spice session, it could perhaps even be a separate library (although for now, a few extra functions and dependency in spice-gtk is surely fine). There is various state inside, which needs to be coupled to some object, using the session for this seems best. Except setting/getting its own SpiceDesktopIntegration *desktop_integration; what does it need from SpiceSession? If I understand correctly, the changes made by desktop-integration are session-wide, so why having a 1-1 relation with each spice session? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Join spice-devel@lists.freedesktop.org
On Tue, Jun 12, 2012 at 06:02:45PM +0800, Xiang Hua wrote: to get information about all things related to the Spice project. thanks. Hua in Beijing You need to send a request through mailman, here: 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 2/2] Release 0.11.0
Hey, On Tue, Jun 12, 2012 at 03:01:54PM +0300, Alon Levy wrote: But I thought it doesn't break existing users. If it does that's not what I meant. I thought the important name was that before the .so, i.e. libspice-server, and that the dynamic linker will look for .1 and then if none found will use anything newer. Nope, it will look for an exact match for libspice-server.so.N, so if a binary was built against libspice-server.so.1, the binary won't run with anything different. If a library is ABI compatible with an older version but has newer interfaces, the soname must not change for older binaries to keep using it. Christophe pgpK9CAelrIH5.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 v2 2/2] Release 0.11.0
On Tue, Jun 12, 2012 at 08:52:19AM -0400, Alon Levy wrote: A second mistake, this was a result of -version-name and not libtool help being incorrect. So SONAME is indeed current-age. New question: is libspice-server.so.1.3.0 = 1.0.2 ? It should, even though we probably don't care ;) Christophe pgp0aLSPkoqfK.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [spice-common PATCH] python_modules/ptypes.py/EnumBaseType.c_enumname: add missing return to fix broken enums generation
On Thu, Jun 14, 2012 at 05:11:02AM -0400, Marc-André Lureau wrote: I don't see exactly what it will fixed, perhaps you should include a small example. But that looks like a typo and can't harm, ACK ./spice_codegen.py --generate-enums spice.proto spice-protocol/spice/enums.h Produces a file with many None's without this patch. I'll update the commit message. - Mensaje original - --- python_modules/ptypes.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/python_modules/ptypes.py b/python_modules/ptypes.py index 132ba99..d9fbfe2 100644 --- a/python_modules/ptypes.py +++ b/python_modules/ptypes.py @@ -234,7 +234,7 @@ class EnumBaseType(Type): return codegen.prefix_camel(self.name) def c_enumname(self, value): -self.c_enumname_by_name(self.names[value]) +return self.c_enumname_by_name(self.names[value]) def c_enumname_by_name(self, name): if self.has_attr(prefix): -- 1.7.10.1 ___ 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 1/3] spice-gtk-session: Only update usb auto-connect when doing auto-usb-redir
On Wed, Jun 13, 2012 at 07:07:21PM +0200, Hans de Goede wrote: Only update the UsbDeviceManager's auto-connect property when auto-usb-redir is set, otherwise leave it as is. This allows apps to control UsbDeviceManager's auto-connect directly, without it getting reset on every keyboard focus change. Ah nice, I got caught by that when adding usb controller support ;) http://git.fedorahosted.org/git/?p=virt-viewer.git;a=commit;h=37171c465fd762da6c398003340855cc7df062ac Christophe pgpXNwZwC927m.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] make celt to be optional
On Thu, Jun 14, 2012 at 10:14:36AM +0200, Alexander Larsson wrote: However, that is imho a different issue than the celt051 support. A new release of spice client and server supporting opus does not magically make old servers and client disappear, so it would still be the case that e.g. debian spice client would get lame audio performance if connecting to say a RHEV spice client, or if some old client connects to a server running on debian. In time, it would perhaps make sense to drop celt051 support, but its seems pretty bad to release a client binary that doesn't do audio well with all currently existing deployed servers. It all depends if we consider remote SPICE access with limited bandwidth and with audio needed will be an important use case that must run as good as possible. In my opinion, sound is most of the time not the most important thing if what you want is a remote desktop. It also won't be really noticeable on LAN, or in GNOME Boxes use case, ... What I gather from this thread is that we don't want anyone to use the fallback PCM code, which means we should deprecate it if that's really what we want... Maybe the clients could be patched to stop advertising raw PCM support? I don't know if no audio at all is more acceptable than not doing audio well in some cases. Christophe pgpyCBTY4WApX.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] Compute totalPixmapSize using the same logic as in dix/pixmap.c, rather than hard coding 100.
On Wed, Jun 13, 2012 at 05:04:12PM -0500, Jeremy White wrote: Looks good to me. This was found while building with a modified X server; one with a PixmapRec size of 224, not 64 :-/. --- src/qxl_driver.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/qxl_driver.c b/src/qxl_driver.c index 5519f57..135c269 100644 --- a/src/qxl_driver.c +++ b/src/qxl_driver.c @@ -1077,8 +1077,6 @@ qxl_screen_init(SCREEN_INIT_ARGS_DECL) ErrorF (allocated %d x %d %p\n, pScrn-virtualX, pScrn-virtualY, qxl-fb); #endif -pScreen-totalPixmapSize = 100; - pScrn-virtualX = pScrn-currentMode-HDisplay; pScrn-virtualY = pScrn-currentMode-VDisplay; @@ -1137,6 +1135,10 @@ qxl_screen_init(SCREEN_INIT_ARGS_DECL) DamageSetup(pScreen); +/* We need to set totalPixmapSize after setup_uxa and Damage, + as the privatessize is not computed correctly until then */ +pScreen-totalPixmapSize = BitmapBytePad((sizeof(PixmapRec) + dixPrivatesSize(PRIVATE_PIXMAP) ) * 8); + miDCInitialize(pScreen, xf86GetPointerScreenFuncs()); if (!miCreateDefColormap(pScreen)) goto out; -- 1.7.10 ___ 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] make celt to be optional
On Thu, 2012-06-14 at 12:31 +0200, Christophe Fergeau wrote: On Thu, Jun 14, 2012 at 10:14:36AM +0200, Alexander Larsson wrote: However, that is imho a different issue than the celt051 support. A new release of spice client and server supporting opus does not magically make old servers and client disappear, so it would still be the case that e.g. debian spice client would get lame audio performance if connecting to say a RHEV spice client, or if some old client connects to a server running on debian. In time, it would perhaps make sense to drop celt051 support, but its seems pretty bad to release a client binary that doesn't do audio well with all currently existing deployed servers. It all depends if we consider remote SPICE access with limited bandwidth and with audio needed will be an important use case that must run as good as possible. In my opinion, sound is most of the time not the most important thing if what you want is a remote desktop. It also won't be really noticeable on LAN, or in GNOME Boxes use case, ... What I gather from this thread is that we don't want anyone to use the fallback PCM code, which means we should deprecate it if that's really what we want... Maybe the clients could be patched to stop advertising raw PCM support? I don't know if no audio at all is more acceptable than not doing audio well in some cases. I don't know if that is true. If nothing else works then in some cases PCM is a good approach. However, maybe the client should warn about this and allow disabling audio? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-common PATCH 0/3] smartcard autogenerated sources fixes
The enums.h file hasn't been built since the spice.proto smartcard messages additions. Additionally it turns out enums.h generation was broken. Fixing for now means not redefining enums defined in libcacard/vsc ard_common.h (VSC_ATR etc) and not renaming SPICE_MSG_SMARTCARD_DATA to SPICE_MSG_SMARTCARD_MSG (even though the later is more correct). There is still an asymmetry - spice-gtk uses spice proto to parse and marshal smartcard messages, and spice-server uses libcacard. spice-common: Alon Levy (3): smartcard: build fixes for spice server spice-protocol/spice/enums.h: rebuild from spice.proto updated spice-protocol for smartcard enums non conflict with libcacard common/Makefile.am |5 - common/client_marshallers.h |2 +- spice-protocol |2 +- spice.proto |6 +++--- 4 files changed, 9 insertions(+), 6 deletions(-) spice-protocol: Alon Levy (1): enums.h: update for smartcard updated spice.proto spice/enums.h | 18 ++ 1 file changed, 18 insertions(+) -- 1.7.10.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-common PATCH 1/3] smartcard: build fixes for spice server
Define different enums that have a SPICE_ prefix to not conflict with same
value enums from libcacard/vsccard_common.h, and continue to use the same
SPICE_MSG_SMARTCARD_DATA and SPICE_MSGC_SMARTCARD_DATA enum that is used by the
server and clients (spice-gtk, spicec) alike.
---
common/client_marshallers.h |2 +-
spice.proto |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/client_marshallers.h b/common/client_marshallers.h
index f7322d1..1bd95ae 100644
--- a/common/client_marshallers.h
+++ b/common/client_marshallers.h
@@ -66,7 +66,7 @@ typedef struct {
void (*msgc_smartcard_atr)(SpiceMarshaller *m, VSCMsgATR *msg);
void (*msgc_smartcard_error)(SpiceMarshaller *m, VSCMsgError *msg);
void (*msgc_smartcard_header)(SpiceMarshaller *m, VSCMsgHeader *msg);
-void (*msgc_smartcard_msg)(SpiceMarshaller *m, SpiceMsgcSmartcard *msg,
SpiceMarshaller **reader_name_out);
+void (*msgc_smartcard_data)(SpiceMarshaller *m, SpiceMsgcSmartcard *msg,
SpiceMarshaller **reader_name_out);
void (*msgc_smartcard_reader_add)(SpiceMarshaller *m, VSCMsgReaderAdd
*msg);
#endif
} SpiceMessageMarshallers;
diff --git a/spice.proto b/spice.proto
index 71be9ac..a86bfa7 100644
--- a/spice.proto
+++ b/spice.proto
@@ -1139,7 +1139,7 @@ enum32 vsc_message_type {
APDU,
Flush,
FlushComplete
-} @prefix(VSC_);
+};
struct VscMessageHeader {
vsc_message_type type;
@@ -1170,7 +1170,7 @@ channel SmartcardChannel : BaseChannel {
uint32 reader_id;
uint32 length;
uint8 data[] @end;
-} @ctype(SpiceMsgSmartcard) msg = 101;
+} @ctype(SpiceMsgSmartcard) data = 101;
client:
message {
@@ -1184,7 +1184,7 @@ channel SmartcardChannel : BaseChannel {
case Error:
VscMessageError error;
} u @anon;
-} @ctype(SpiceMsgcSmartcard) msg = 101;
+} @ctype(SpiceMsgcSmartcard) data = 101;
message {
vsc_message_type type;
--
1.7.10.1
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-common PATCH 2/3] spice-protocol/spice/enums.h: rebuild from spice.proto
This file was hand generated until now, resulting in the wierd situation where it is different for spice-gtk and spice-server even though they both use the same spice-common and spice-protocol (or at least close) versions. This patch generates the enums.h files from spice-common. While that file is actually in the spice-protocol submodule, it cannot be generated from spice-protocol since it lacks access to spice.proto and spice_codegen.py. So in affect whenvever it will differ the spice-protocol module will become dirty and hence hopefully commited with the new enums.h. enums.h is generated from spice.proto is a superset of that generated from spice1.proto. --- common/Makefile.am |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/common/Makefile.am b/common/Makefile.am index 08c4b83..3210fc8 100644 --- a/common/Makefile.am +++ b/common/Makefile.am @@ -14,7 +14,7 @@ SERVER_MARSHALLERS = \ $(srcdir)/generated_server_marshallers.h\ $(NULL) -BUILT_SOURCES = $(CLIENT_MARSHALLERS) $(SERVER_MARSHALLERS) +BUILT_SOURCES = $(CLIENT_MARSHALLERS) $(SERVER_MARSHALLERS) $(top_srcdir)/spice-protocol/spice/enums.h noinst_LTLIBRARIES = libspice-common.la libspice-common-server.la libspice-common-client.la libspice_common_la_SOURCES = \ @@ -122,6 +122,9 @@ generated_server_marshallers.c: $(top_srcdir)/spice.proto $(MARSHALLERS_DEPS) generated_server_marshallers.h: $(top_srcdir)/spice.proto $(MARSHALLERS_DEPS) $(AM_V_GEN)$(PYTHON) $(top_srcdir)/spice_codegen.py --generate-marshallers $(STRUCTS) --server --include messages.h -H $ $@ /dev/null +$(top_srcdir)/spice-protocol/spice/enums.h: $(top_srcdir)/spice.proto $(MARSHALLERS_DEPS) + $(AM_V_GEN)$(PYTHON) $(top_srcdir)/spice_codegen.py --generate-enums $ $@ /dev/null + EXTRA_DIST = \ $(CLIENT_MARSHALLERS) \ $(SERVER_MARSHALLERS) \ -- 1.7.10.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-common PATCH 3/3] updated spice-protocol for smartcard enums non conflict with libcacard
--- spice-protocol |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/spice-protocol b/spice-protocol index bf0daeb..6bae9fd 16 --- a/spice-protocol +++ b/spice-protocol @@ -1 +1 @@ -Subproject commit bf0daeb3a3c834133e781439f76b1c702470581b +Subproject commit 6bae9fde0316b74433252bf324a114263d2dccc9 -- 1.7.10.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH spice-common] Makefile.am: fix .gitignore not being generated in spice-protocol/spice
By adding spice-protocol to SUBDIRS configure and make will be called in it. Spotted by Marc-André. --- Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 28450b4..3b3c88d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,7 +1,7 @@ NULL = ACLOCAL_AMFLAGS = -I m4 -SUBDIRS = python_modules common +SUBDIRS = python_modules common spice-protocol DIST_SUBDIRS = spice-protocol $(SUBDIRS) EXTRA_DIST = \ -- 1.7.10.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] make celt to be optional
On Thu, Jun 14, 2012 at 12:50:39PM +0200, Alexander Larsson wrote: On Thu, 2012-06-14 at 12:31 +0200, Christophe Fergeau wrote: What I gather from this thread is that we don't want anyone to use the fallback PCM code, which means we should deprecate it if that's really what we want... Maybe the clients could be patched to stop advertising raw PCM support? I don't know if no audio at all is more acceptable than not doing audio well in some cases. I don't know if that is true. If nothing else works then in some cases PCM is a good approach. However, maybe the client should warn about this and allow disabling audio? If this is good enough for you to avoid bad audio experience when celt isn't there, then yes this would good too. Christophe pgpkUpcc31Ykl.pgp Description: PGP signature ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-common PATCH] Makefile.am: now that spice_codegen.py is used add *.pyc to ignored files in root
--- Makefile.am |2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile.am b/Makefile.am index 3b3c88d..79f7903 100644 --- a/Makefile.am +++ b/Makefile.am @@ -10,6 +10,8 @@ EXTRA_DIST = \ spice1.proto\ $(NULL) +DISTCLEANFILES = *.pyc + MAINTAINERCLEANFILES = \ $(srcdir)/INSTALL \ $(srcdir)/aclocal.m4\ -- 1.7.10.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] make celt to be optional
Hi, What I gather from this thread is that we don't want anyone to use the fallback PCM code, which means we should deprecate it if that's really what we want... Maybe the clients could be patched to stop advertising raw PCM support? You can't, PCM is the baseline which isn't negotiated. You can only disconnect the sound channel. I don't know if no audio at all is more acceptable than not doing audio well in some cases. Of course you can warn if no codec could be negotiated and offer the option to disable sound. Not sure it is worth the trouble though, as far I know there is no data traveling the wire if the guest doesn't play audio. cheers, Gerd ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] make celt to be optional
Christophe Fergeau píše v Čt 14. 06. 2012 v 12:31 +0200: On Thu, Jun 14, 2012 at 10:14:36AM +0200, Alexander Larsson wrote: However, that is imho a different issue than the celt051 support. A new release of spice client and server supporting opus does not magically make old servers and client disappear, so it would still be the case that e.g. debian spice client would get lame audio performance if connecting to say a RHEV spice client, or if some old client connects to a server running on debian. In time, it would perhaps make sense to drop celt051 support, but its seems pretty bad to release a client binary that doesn't do audio well with all currently existing deployed servers. It all depends if we consider remote SPICE access with limited bandwidth and with audio needed will be an important use case that must run as good as possible. In my opinion, sound is most of the time not the most important thing if what you want is a remote desktop. It also won't be really noticeable on LAN, or in GNOME Boxes use case, ... What I gather from this thread is that we don't want anyone to use the fallback PCM code, which means we should deprecate it if that's really what we want... Maybe the clients could be patched to stop advertising raw PCM support? I don't know if no audio at all is more acceptable than not doing audio well in some cases. There was an interest in lossless audio for some medical application some time ago so support for explicit codec choice (and incoproration of FLAC or some better lossless codec, if any) would be a big improvement for some spice users. David Christophe ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-common] Makefile.am: fix .gitignore not being generated in spice-protocol/spice
- Mensaje original - By adding spice-protocol to SUBDIRS configure and make will be called in it. Spotted by Marc-André. --- Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 28450b4..3b3c88d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,7 +1,7 @@ NULL = ACLOCAL_AMFLAGS = -I m4 -SUBDIRS = python_modules common +SUBDIRS = python_modules common spice-protocol DIST_SUBDIRS = spice-protocol $(SUBDIRS) Can you check make distcheck? I wonder why I used DIST_SUBDIRS in the first place. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-gtk 2/3] Add a desktop-integration helper class
Hi, On 06/14/2012 11:28 AM, Marc-André Lureau wrote: Hi - Mensaje original - Looks reasonable to me, however, I don't see why it should be in spice-glib, since it's very much desktop related. Wouldn't it make more sense in spice-gtk? I actually put it in spice-gtk at first, but that does not work very well because usb-device-manager needs access to the automount disable functionality. Ok Since it's not directly dependent and related to a particular spice session, it could perhaps even be a separate library (although for now, a few extra functions and dependency in spice-gtk is surely fine). There is various state inside, which needs to be coupled to some object, using the session for this seems best. Except setting/getting its own SpiceDesktopIntegration *desktop_integration; what does it need from SpiceSession? Nothing. If I understand correctly, the changes made by desktop-integration are session-wide Correct. so why having a 1-1 relation with each spice session? We also need to undo the changes at some point in time, iow the desktop-integration objects lifetime needs to be coupled to *something*, and spice-session seems best for this. IE, think usage in python from virt-manager, when the vm viewing window is closed (which does not necessarily end the virt-manager process) we want to restore the settings. Regards, Hans ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH spice-common] Makefile.am: fix .gitignore not being generated in spice-protocol/spice
On Thu, Jun 14, 2012 at 08:28:24AM -0400, Marc-André Lureau wrote: - Mensaje original - By adding spice-protocol to SUBDIRS configure and make will be called in it. Spotted by Marc-André. --- Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 28450b4..3b3c88d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,7 +1,7 @@ NULL = ACLOCAL_AMFLAGS = -I m4 -SUBDIRS = python_modules common +SUBDIRS = python_modules common spice-protocol DIST_SUBDIRS = spice-protocol $(SUBDIRS) Can you check make distcheck? I wonder why I used DIST_SUBDIRS in the first place. broke it already with spice-protocol/spice/enums.h, thanks for pointing it out. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] RFC: spice-server default listen behaviour change
Hi, I learned few things about ipv6 lately. Most importantly about dual-socket that means that a process that opens ::0 automatically listens on both ipv4 _and_ ipv6 unless it sets IPV6_ONLY option of setsockopt() to 0. This is pretty important wrt dual-stack configurations because they can be implemented with just slight changes to spice server (unlike the old RFE requesting listening on multiple addresses): * when no addr= or ipvx options are set, listen on ::0 * when ipv4 and no addr= option is set, listen on 0.0.0.0 * when ipv6 is set, set IPV6_ONLY to 1 to make sure that spice server won't listen on ipv4 * when conflicting ipvx and addr= options are set, error out (this already works fine) This will affect upper layers though, given bugs like https://bugzilla.redhat.com/show_bug.cgi?id=832121 , but it seems to me like the step in the right direction. Any thoughts/comments before I file this as a bug? David -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] Further thoughts on the write polling in the xf86_spice_xql driver
Okay; I unimaginatively decided that would be Hard. Wouldn't that break the ABI, and therefore be rejected unilaterally? I'm willing to try to craft a patch and submit it; but maybe I just need encouragement grin. I started looking at this, talked to Dave Airlie and he suggested to ask on xorg-devel either Adam Jackson or Keith Packard about one of two suggested solutions I fielded, expand BlockHandler with a pReadmask or add a third callback (in addition to BlockHandler, WakeupHandler) BlockWriteHandler. The later won't break the internal Xorg / module ABI, but is a little ugly IMO. The former breaks it. I've started a conversation on the xorg-devel mailing list[1], and I'll follow up directly in irc with Adam and/or Keith if I don't get any answers. Could I ask that my last patch be committed regardless? You really cannot use Xspice if the large ping results in an EAGAIN result; the client just hangs. Cheers, Jeremy [1] http://lists.x.org/archives/xorg-devel/2012-June/031728.html ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] shift+f11 can not exit fullscreen
Thanks for your reply. However, I do not understand how does the virt-viewer work with spicy, I have generally review the source code of spicy and virt-viewer , and find not answer. Could you give me some docs about how do they work together ? thanks. 2012/6/14 David Jaša dj...@redhat.com Hi, flooding Controlled píše v Út 12. 06. 2012 v 13:10 +0800: Hi all: I am now using spice-gtk-0.12 on a linux client, when I run spicy -h 127.0.0.1 -p 5900, it connected successfully, and I pressed shift + f11, spicy window turned to be fullscreen, but when I pressed shift + f11 again in order to exit the fullscreen mode, it failed. I can confirm that this happens, you could file bug on fdo bugzilla to track it. The spicy is only the demonstrattion client though, try virt-viewer (0.5.3 and later) instead, full screen works there exactly as it should. David I debug the function menu_cb_fullscreen , and find that this function was only called once by the steps I metioned. It seems that menu_cb_fullscreen only to be called by not fullscreen to fullscreen, but not fullscreen to not fullscreen. Is there someone give me some help ? thanks. Yours. Flooding. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
