Re: [Spice-devel] [PATCH spice-gtk] usb: channel-new handler to be after default handlers

2015-04-29 Thread Zeeshan Ali (Khattak) 
On Wed, Apr 29, 2015 at 11:59 PM, Marc-André Lureau
 wrote:
> Client usually connect to channel-new to connect their
> handlers, such as open-fd.
>
> The usbmanager channel-new handler will call channel_connect() on usbredir
> channels, which may call open-fd.
>
> However, open-fd can be emitted before the client had a chance to
> connect their handlers (from the channel-new callback).
>
> Connecting after the default handler solves this case.
>
> Fixes:
> https://bugzilla.gnome.org/show_bug.cgi?id=748665
> ---

Not in a position to judge the code but I tested this and it makes
usb-redirection working again in Boxes.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCHv2] session: Improved docs for spice_session_connect()

2014-11-19 Thread Zeeshan Ali (Khattak) 
Make it clear that users of this function must provide additional
sockets for individual channels.
---
 gtk/spice-session.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gtk/spice-session.c b/gtk/spice-session.c
index 88bcacd..59f45bc 100644
--- a/gtk/spice-session.c
+++ b/gtk/spice-session.c
@@ -1322,8 +1322,16 @@ gboolean spice_session_connect(SpiceSession *session)
  * descriptor. This is useful if you create the fd yourself, for
  * example to setup a SSH tunnel.
  *
+ * Note however that additional sockets will be needed by all the channels
+ * created for @session so users of this API should hook into
+ * SpiceChannel::open-fd signal for each channel they are interested in, and
+ * create and pass a new socket to the channel using #spice_channel_open_fd, in
+ * the signal callback.
+ *
  * If @fd is -1, a valid fd will be requested later via the
- * SpiceChannel::open-fd signal.
+ * SpiceChannel::open-fd signal. Typically, you would want to just pass -1 as
+ * @fd this call since you will have to hook to SpiceChannel::open-fd signal
+ * anyway.
  *
  * Returns:
  **/
-- 
2.1.0

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH] session: Improved docs for spice_session_connect()

2014-11-19 Thread Zeeshan Ali (Khattak) 
Make it clear that users of this function must provide additional
sockets for individual channels.
---
 gtk/spice-session.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gtk/spice-session.c b/gtk/spice-session.c
index 88bcacd..cfc70bf 100644
--- a/gtk/spice-session.c
+++ b/gtk/spice-session.c
@@ -1322,8 +1322,16 @@ gboolean spice_session_connect(SpiceSession *session)
  * descriptor. This is useful if you create the fd yourself, for
  * example to setup a SSH tunnel.
  *
+ * Note however that additional sockets will be needed by all the channels
+ * created for @session so users of this API should hook into
+ * SpiceChannel::open-fd signal for each channel they are interested in, and
+ * create and pass a new socket to the channel using #spice_channel_open_fd, in
+ * the singal callback.
+ *
  * If @fd is -1, a valid fd will be requested later via the
- * SpiceChannel::open-fd signal.
+ * SpiceChannel::open-fd signal. Typically, you would want to just pass -1 as
+ * @fd this call since you will have to hook to SpiceChannel::open-fd signal
+ * anyway.
  *
  * Returns:
  **/
-- 
2.1.0

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] [PATCH] Provide a method to check if a USB device matches a specific class, subclass and protocol

2014-11-11 Thread Zeeshan Ali (Khattak) 
On Tue, Nov 11, 2014 at 2:29 PM, Fabiano Fidêncio  wrote:
> As we only can filter USB devices by their Classes and sometimes it is
> not enough (eg: I do not want to have Keyboard and Mouse, but want to
> have have Joysticks, being all of them part of HID Class), provide to
> the applications a way match the device itself with the desired Class,
> SubClass and Protocol, so the applications refine the filter provided
> by usbredir.

I don't think its a good idea to create a separate API for this on the
device level. I suggest either or both of following:

* Extend (if possible without breaking existing API) the existing
filtering mechanism for DeviceManager for this.
* Provide getters for all these properties on device level so Apps can
use that info for different things, including of course to filter
devices in a list.

> This patch was written based on 
> https://bugzilla.gnome.org/show_bug.cgi?id=698430
> Any suggestion to have a shorter short-log is welcome :-)

After all that practice with this in Boxes, I'm pretty sure you can do
much better if you just try a bit.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] Don't report IO error on clean guest shutdown

2014-09-15 Thread Zeeshan Ali (Khattak) 
On Mon, Sep 15, 2014 at 8:56 AM, Christophe Fergeau  wrote:
> On Fri, Sep 12, 2014 at 06:52:07PM +0100, Zeeshan Ali (Khattak) wrote:
>> Anyone up for review? It would be nice to get this in and (if
>> possible) even released before GNOME's code freeze break on Wednesday.
>> Won't be bad if release before 3.14 release in two weeks either.
>
> For what it's worth, spice-gtk is not really following GNOME release
> cycle, and even less its various freezes. I'll see what we can do with
> respect to releasing.

Yeah, I know but I was hoping some exceptions could be made here for
our dear Boxes project. :)

BTW, wouldn't be a bad idea for spice to follow GNOME release cycles,
unless its following another project's release cycle already.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] Don't report IO error on clean guest shutdown

2014-09-12 Thread Zeeshan Ali (Khattak) 
On Fri, Sep 12, 2014 at 7:20 PM, Fabiano Fidêncio  wrote:
>
>
> On Fri, Sep 12, 2014 at 7:52 PM, Zeeshan Ali (Khattak) 
> wrote:
>>
>> On Wed, Sep 10, 2014 at 3:52 PM, Zeeshan Ali (Khattak)
>>  wrote:
>> > On Wed, Sep 10, 2014 at 3:35 PM, Christophe Fergeau
>> >  wrote:
>> >> Since commit 9cf9ca434, spice_channel_iterate() will report a
>> >> SPICE_CHANNEL_ERROR_IO error to library users when
>> >> SpiceChannel::has_error is set. In particular, when the server side
>> >> closes its SPICE sockets because the VM is being shut down, an IO error
>> >> will get reported. Prior to this change, a channel-closed event was
>> >> reported on graceful VM shutdowns as there was
>> >> a g_socket_condition_check() guarding the emission of the IO error
>> >> signal.
>> >>
>> >> This commit readds the g_socket_condition_check() test, but only when
>> >> SpiceChannel::has_error is set.
>> >>
>> >> This fixes https://bugs.freedesktop.org/show_bug.cgi?id=83692
>> >> ---
>> >
>> > Just wanted to say that I tested this patch and it fixes the bug above.
>>
>> Anyone up for review? It would be nice to get this in and (if
>> possible) even released before GNOME's code freeze break on Wednesday.
>> Won't be bad if release before 3.14 release in two weeks either.
>
>
>
> I have considered your previous comment as an ACK.

You shouldn't, unless I explicitly use the term ACK (or mark patch as
commit* on bz). I'm not really a spice hacker to be able to ACK
patches.

> Anyway, ACK!

Thanks. :)

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] Don't report IO error on clean guest shutdown

2014-09-12 Thread Zeeshan Ali (Khattak) 
On Wed, Sep 10, 2014 at 3:52 PM, Zeeshan Ali (Khattak)
 wrote:
> On Wed, Sep 10, 2014 at 3:35 PM, Christophe Fergeau  
> wrote:
>> Since commit 9cf9ca434, spice_channel_iterate() will report a
>> SPICE_CHANNEL_ERROR_IO error to library users when
>> SpiceChannel::has_error is set. In particular, when the server side
>> closes its SPICE sockets because the VM is being shut down, an IO error
>> will get reported. Prior to this change, a channel-closed event was
>> reported on graceful VM shutdowns as there was
>> a g_socket_condition_check() guarding the emission of the IO error
>> signal.
>>
>> This commit readds the g_socket_condition_check() test, but only when
>> SpiceChannel::has_error is set.
>>
>> This fixes https://bugs.freedesktop.org/show_bug.cgi?id=83692
>> ---
>
> Just wanted to say that I tested this patch and it fixes the bug above.

Anyone up for review? It would be nice to get this in and (if
possible) even released before GNOME's code freeze break on Wednesday.
Won't be bad if release before 3.14 release in two weeks either.

-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] Don't report IO error on clean guest shutdown

2014-09-10 Thread Zeeshan Ali (Khattak) 
On Wed, Sep 10, 2014 at 3:35 PM, Christophe Fergeau  wrote:
> Since commit 9cf9ca434, spice_channel_iterate() will report a
> SPICE_CHANNEL_ERROR_IO error to library users when
> SpiceChannel::has_error is set. In particular, when the server side
> closes its SPICE sockets because the VM is being shut down, an IO error
> will get reported. Prior to this change, a channel-closed event was
> reported on graceful VM shutdowns as there was
> a g_socket_condition_check() guarding the emission of the IO error
> signal.
>
> This commit readds the g_socket_condition_check() test, but only when
> SpiceChannel::has_error is set.
>
> This fixes https://bugs.freedesktop.org/show_bug.cgi?id=83692
> ---

Just wanted to say that I tested this patch and it fixes the bug above.


-- 
Regards,

Zeeshan Ali (Khattak)

Befriend GNOME: http://www.gnome.org/friends/
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] Add vapi bindings generation

2011-10-26 Thread Zeeshan Ali (Khattak) 
Ack! Assuming you tested it locally.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-0.8] client: Plug some leaks

2011-08-17 Thread Zeeshan Ali (Khattak) 
On Wed, Aug 17, 2011 at 7:35 PM, Christophe Fergeau  wrote:
> Hey,

  Yo,

> These fixes duplicate fixes that already went into master :-/ See commits
> d7d0a3a98e and 0d4bd5504.

  Darn! Looks like you did a better job even. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-0.8] client: Plug some leaks

2011-08-17 Thread Zeeshan Ali (Khattak) 
From: "Zeeshan Ali (Khattak)" 

---
 client/red_channel.cpp|1 +
 client/x11/red_window.cpp |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/client/red_channel.cpp b/client/red_channel.cpp
index f4cdf52..ace4a03 100644
--- a/client/red_channel.cpp
+++ b/client/red_channel.cpp
@@ -192,6 +192,7 @@ void RedChannelBase::link(uint32_t connection_id, const 
std::string& password,
 }
 
 BIO_free(bioKey);
+EVP_PKEY_free(pubkey);
 
 recive((uint8_t*)&link_res, sizeof(link_res));
 if (link_res != SPICE_LINK_ERR_OK) {
diff --git a/client/x11/red_window.cpp b/client/x11/red_window.cpp
index d53a92f..f3ff95f 100644
--- a/client/x11/red_window.cpp
+++ b/client/x11/red_window.cpp
@@ -1313,6 +1313,7 @@ void RedWindow_p::move_to_current_desktop()
&bytes_after_return, &prop_return) == Success &&
  actual_type_return != None && 
actual_format_return == 32) {
 desktop = *(uint32_t *)prop_return;
+XFree(prop_return);
 } else {
 DBG(0, "get current desktop failed");
 }
-- 
1.7.6

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 1/2] Rename a function

2011-05-25 Thread Zeeshan Ali (Khattak) 
On Wed, May 25, 2011 at 12:39 PM, Alon Levy  wrote:
> On Wed, May 25, 2011 at 12:08:47AM +0300, Zeeshan Ali (Khattak) wrote:
>> This should be squashed into commit 27df918.
>
> If you are talking about a public git tree (i.e. gitorious) then squashing
> is a bad idea, it changes history for anyone that cloned that tree before.

  No, I'm talking about squashing it *before* it gets into spice-gtk
git master (preferably on my local machine). Actually I would have
already squashed it if I had been a bit patient before sending the
commit in question for review. :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk 2/2] Connect on recent connection item activation

2011-05-24 Thread Zeeshan Ali (Khattak) 
Now (commit 27df918) that we already gather connection information when
user (single)-clicks a recent connection item, we can safely use the
selected recent connection when user activates (double-clicks) it.
---
 gtk/spicy.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/gtk/spicy.c b/gtk/spicy.c
index 7b51216..45e16d9 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -182,6 +182,11 @@ static void 
recent_selection_changed_dialog_cb(GtkRecentChooser *chooser, gpoint
 
 gtk_recent_info_unref(info);
 }
+
+static void recent_item_activated_dialog_cb(GtkRecentChooser *chooser, 
gpointer data)
+{
+   gtk_dialog_response (GTK_DIALOG (data), GTK_RESPONSE_ACCEPT);
+}
 #endif
 
 static int connect_dialog(SpiceSession *session)
@@ -238,6 +243,8 @@ static int connect_dialog(SpiceSession *session)
 gtk_recent_chooser_set_local_only(GTK_RECENT_CHOOSER(recent), FALSE);
 g_signal_connect(recent, "selection-changed",
  G_CALLBACK(recent_selection_changed_dialog_cb), session);
+g_signal_connect(recent, "item-activated",
+ G_CALLBACK(recent_item_activated_dialog_cb), dialog);
 #endif
 /* show and wait for response */
 gtk_widget_show_all(dialog);
-- 
1.7.5.1

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk 1/2] Rename a function

2011-05-24 Thread Zeeshan Ali (Khattak) 
This should be squashed into commit 27df918.
---
 gtk/spicy.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gtk/spicy.c b/gtk/spicy.c
index cc30d54..7b51216 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -152,7 +152,7 @@ static struct {
 };
 
 #ifndef WIN32
-static void recent_item_activated_dialog_cb(GtkRecentChooser *chooser, 
gpointer data)
+static void recent_selection_changed_dialog_cb(GtkRecentChooser *chooser, 
gpointer data)
 {
 GtkRecentInfo *info;
 gchar *txt = NULL;
@@ -237,7 +237,7 @@ static int connect_dialog(SpiceSession *session)
 gtk_recent_chooser_set_filter(GTK_RECENT_CHOOSER(recent), rfilter);
 gtk_recent_chooser_set_local_only(GTK_RECENT_CHOOSER(recent), FALSE);
 g_signal_connect(recent, "selection-changed",
- G_CALLBACK(recent_item_activated_dialog_cb), session);
+ G_CALLBACK(recent_selection_changed_dialog_cb), session);
 #endif
 /* show and wait for response */
 gtk_widget_show_all(dialog);
-- 
1.7.5.1

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] Minor coding-style fix

2011-05-24 Thread Zeeshan Ali (Khattak) 
Don't use mix of tabs and spaces.
---
 gtk/spicy.c |  242 +-
 1 files changed, 121 insertions(+), 121 deletions(-)

diff --git a/gtk/spicy.c b/gtk/spicy.c
index bfa8189..cc30d54 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -104,12 +104,12 @@ static int ask_user(GtkWidget *parent, char *title, char 
*message,
 
 /* Create the widgets */
 dialog = gtk_dialog_new_with_buttons(title,
-parent ? GTK_WINDOW(parent) : NULL,
+ parent ? GTK_WINDOW(parent) : NULL,
  GTK_DIALOG_DESTROY_WITH_PARENT,
-GTK_STOCK_OK,
-GTK_RESPONSE_ACCEPT,
-GTK_STOCK_CANCEL,
-GTK_RESPONSE_REJECT,
+ GTK_STOCK_OK,
+ GTK_RESPONSE_ACCEPT,
+ GTK_STOCK_CANCEL,
+ GTK_RESPONSE_REJECT,
  NULL);
 gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_ACCEPT);
 area = gtk_dialog_get_content_area(GTK_DIALOG(dialog));
@@ -122,20 +122,20 @@ static int ask_user(GtkWidget *parent, char *title, char 
*message,
 gtk_entry_set_text(GTK_ENTRY(entry), dest);
 gtk_entry_set_activates_default(GTK_ENTRY(entry), TRUE);
 if (hide)
-   gtk_entry_set_visibility(GTK_ENTRY(entry), FALSE);
+gtk_entry_set_visibility(GTK_ENTRY(entry), FALSE);
 gtk_box_pack_start(GTK_BOX(area), entry, FALSE, FALSE, 5);
 
 /* show and wait for response */
 gtk_widget_show_all(dialog);
 switch (gtk_dialog_run(GTK_DIALOG(dialog))) {
 case GTK_RESPONSE_ACCEPT:
-   txt = gtk_entry_get_text(GTK_ENTRY(entry));
-   snprintf(dest, dlen, "%s", txt);
-   retval = 0;
-   break;
+txt = gtk_entry_get_text(GTK_ENTRY(entry));
+snprintf(dest, dlen, "%s", txt);
+retval = 0;
+break;
 default:
-   retval = -1;
-   break;
+retval = -1;
+break;
 }
 gtk_widget_destroy(dialog);
 return retval;
@@ -193,12 +193,12 @@ static int connect_dialog(SpiceSession *session)
 
 /* Create the widgets */
 dialog = gtk_dialog_new_with_buttons(_("Connect to SPICE"),
-NULL,
+ NULL,
  GTK_DIALOG_DESTROY_WITH_PARENT,
-GTK_STOCK_OK,
-GTK_RESPONSE_ACCEPT,
-GTK_STOCK_CANCEL,
-GTK_RESPONSE_REJECT,
+ GTK_STOCK_OK,
+ GTK_RESPONSE_ACCEPT,
+ GTK_STOCK_CANCEL,
+ GTK_RESPONSE_REJECT,
  NULL);
 gtk_dialog_set_default_response(GTK_DIALOG(dialog), GTK_RESPONSE_ACCEPT);
 area = gtk_dialog_get_content_area(GTK_DIALOG(dialog));
@@ -246,9 +246,9 @@ static int connect_dialog(SpiceSession *session)
 txt = gtk_entry_get_text(GTK_ENTRY(connect_entries[i].entry));
 g_object_set(session, connect_entries[i].prop, txt, NULL);
 }
-   retval = 0;
+retval = 0;
 } else
-   retval = -1;
+retval = -1;
 gtk_widget_destroy(dialog);
 return retval;
 }
@@ -386,9 +386,9 @@ static void menu_cb_about(GtkAction *action, void *data)
   "comments",comments,
   "copyright",   copyright,
   "logo-icon-name",  GTK_STOCK_ABOUT,
- "website", website,
+  "website", website,
   "version", PACKAGE_VERSION,
- "license", "LGPLv2.1",
+  "license", "LGPLv2.1",
   NULL);
 }
 
@@ -401,7 +401,7 @@ static gboolean delete_cb(GtkWidget *widget, GdkEvent 
*event, gpointer data)
 }
 
 static gboolean window_state_cb(GtkWidget *widget, GdkEventWindowState *event,
-   gpointer data)
+gpointer data)
 {
 struct spice_window *win = data;
 if (event->changed_mask & GDK_WINDOW_STATE_FULLSCREEN) {
@@ -513,75 +513,75 @@ static void restore_configuration(struct spice_window 
*win)
 
 static const GtkActionEntry entries[] = {
 {
-   .name= "FileMenu",
-   .label   = "_File",
+.name= "FileMenu",
+.label   = "_File",
 },{
-   .name= "FileRecentMenu",
-   .label   =

[Spice-devel] [PATCH spice-gtk] Get rid of redundant argument

2011-05-24 Thread Zeeshan Ali (Khattak) 
---
 gtk/spicy.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gtk/spicy.c b/gtk/spicy.c
index 262d465..bfa8189 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -184,7 +184,7 @@ static void 
recent_item_activated_dialog_cb(GtkRecentChooser *chooser, gpointer
 }
 #endif
 
-static int connect_dialog(GtkWidget *parent, SpiceSession *session)
+static int connect_dialog(SpiceSession *session)
 {
 GtkWidget *dialog, *area, *label;
 GtkTable *table;
@@ -193,7 +193,7 @@ static int connect_dialog(GtkWidget *parent, SpiceSession 
*session)
 
 /* Create the widgets */
 dialog = gtk_dialog_new_with_buttons(_("Connect to SPICE"),
-parent ? GTK_WINDOW(parent) : NULL,
+NULL,
  GTK_DIALOG_DESTROY_WITH_PARENT,
 GTK_STOCK_OK,
 GTK_RESPONSE_ACCEPT,
@@ -1096,7 +1096,7 @@ static void main_channel_event(SpiceChannel *channel, 
SpiceChannelEvent event,
 case SPICE_CHANNEL_ERROR_LINK:
 case SPICE_CHANNEL_ERROR_CONNECT:
 g_message("main channel: failed to connect");
-rc = connect_dialog(NULL, conn->session);
+rc = connect_dialog(conn->session);
 if (rc == 0) {
 connection_connect(conn);
 } else {
-- 
1.7.5.1

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH spice-gtk] RecentChooser should act on single-click

2011-05-24 Thread Zeeshan Ali (Khattak) 
Fill-in the connection dialog fields as soon user selects a recent
connection.
---
 gtk/spicy.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/gtk/spicy.c b/gtk/spicy.c
index 0120692..262d465 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -160,6 +160,8 @@ static void 
recent_item_activated_dialog_cb(GtkRecentChooser *chooser, gpointer
 SpiceSession *session = data;
 
 info = gtk_recent_chooser_get_current_item(chooser);
+if (info == NULL)
+return;
 
 uri = gtk_recent_info_get_uri(info);
 g_return_if_fail(uri != NULL);
@@ -234,7 +236,7 @@ static int connect_dialog(GtkWidget *parent, SpiceSession 
*session)
 gtk_recent_filter_add_mime_type(rfilter, "application/x-spice");
 gtk_recent_chooser_set_filter(GTK_RECENT_CHOOSER(recent), rfilter);
 gtk_recent_chooser_set_local_only(GTK_RECENT_CHOOSER(recent), FALSE);
-g_signal_connect(recent, "item-activated",
+g_signal_connect(recent, "selection-changed",
  G_CALLBACK(recent_item_activated_dialog_cb), session);
 #endif
 /* show and wait for response */
-- 
1.7.5.1

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [[PATCH] spice-gtk: ] Minor clean-up

2011-05-24 Thread Zeeshan Ali (Khattak) 
Prefer 'if/else' over 'switch' when dealing with only 2 possibilities.
---
 gtk/spicy.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/gtk/spicy.c b/gtk/spicy.c
index 82d8de2..0120692 100644
--- a/gtk/spicy.c
+++ b/gtk/spicy.c
@@ -239,18 +239,14 @@ static int connect_dialog(GtkWidget *parent, SpiceSession 
*session)
 #endif
 /* show and wait for response */
 gtk_widget_show_all(dialog);
-switch (gtk_dialog_run(GTK_DIALOG(dialog))) {
-case GTK_RESPONSE_ACCEPT:
+if (gtk_dialog_run(GTK_DIALOG(dialog)) == GTK_RESPONSE_ACCEPT) {
 for (i = 0; i < SPICE_N_ELEMENTS(connect_entries); i++) {
 txt = gtk_entry_get_text(GTK_ENTRY(connect_entries[i].entry));
 g_object_set(session, connect_entries[i].prop, txt, NULL);
 }
retval = 0;
-   break;
-default:
+} else
retval = -1;
-   break;
-}
 gtk_widget_destroy(dialog);
 return retval;
 }
-- 
1.7.5.1

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH] Prefer malloc() over calloc()

2011-05-18 Thread Zeeshan Ali (Khattak) 
On Wed, May 18, 2011 at 11:38 PM, Zeeshan Ali (Khattak)
 wrote:
> When only 1 element needs to be allocated, calloc() only makes the code
> *slightly* less readable.

  Please ignore this patch. I forgot that calloc also zero's out the memory.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH] Prefer malloc() over calloc()

2011-05-18 Thread Zeeshan Ali (Khattak) 
When only 1 element needs to be allocated, calloc() only makes the code
*slightly* less readable.
---
 src/console-kit.c |2 +-
 src/udscs.c   |6 +++---
 src/vdagent-virtio-port.c |2 +-
 src/vdagent-x11.c |2 +-
 src/vdagentd-uinput.c |2 +-
 src/vdagentd.c|4 ++--
 6 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/src/console-kit.c b/src/console-kit.c
index eb15939..5ec3643 100644
--- a/src/console-kit.c
+++ b/src/console-kit.c
@@ -43,7 +43,7 @@ struct console_kit *console_kit_create(FILE *errfile)
 DBusError error;
 char match[1024];
 
-ck = calloc(1, sizeof(*ck));
+ck = malloc(sizeof(*ck));
 if (!ck)
 return NULL;
 
diff --git a/src/udscs.c b/src/udscs.c
index c451855..52ef17c 100644
--- a/src/udscs.c
+++ b/src/udscs.c
@@ -94,7 +94,7 @@ struct udscs_server *udscs_create_server(const char 
*socketname,
 struct sockaddr_un address;
 struct udscs_server *server;
 
-server = calloc(1, sizeof(*server));
+server = malloc(sizeof(*server));
 if (!server)
 return NULL;
 
@@ -161,7 +161,7 @@ struct udscs_connection *udscs_connect(const char 
*socketname,
 struct sockaddr_un address;
 struct udscs_connection *conn;
 
-conn = calloc(1, sizeof(*conn));
+conn = malloc(sizeof(*conn));
 if (!conn)
 return NULL;
 
@@ -287,7 +287,7 @@ static void udscs_server_accept(struct udscs_server 
*server) {
 return;
 }
 
-new_conn = calloc(1, sizeof(*conn));
+new_conn = malloc(sizeof(*conn));
 if (!new_conn) {
 fprintf(server->errfile, "out of memory, disconnecting new client\n");
 close(fd);
diff --git a/src/vdagent-virtio-port.c b/src/vdagent-virtio-port.c
index 84e2e67..5fc5f0a 100644
--- a/src/vdagent-virtio-port.c
+++ b/src/vdagent-virtio-port.c
@@ -79,7 +79,7 @@ struct vdagent_virtio_port *vdagent_virtio_port_create(const 
char *portname,
 {
 struct vdagent_virtio_port *vport;
 
-vport = calloc(1, sizeof(*vport));
+vport = malloc(sizeof(*vport));
 if (!vport)
 return 0;
 
diff --git a/src/vdagent-x11.c b/src/vdagent-x11.c
index 795ed41..bee9676 100644
--- a/src/vdagent-x11.c
+++ b/src/vdagent-x11.c
@@ -173,7 +173,7 @@ struct vdagent_x11 *vdagent_x11_create(struct 
udscs_connection *vdagentd,
 XWindowAttributes attrib;
 int i, j, major, minor;
 
-x11 = calloc(1, sizeof(*x11));
+x11 = malloc(sizeof(*x11));
 if (!x11) {
 fprintf(errfile, "out of memory allocating vdagent_x11 struct\n");
 return NULL;
diff --git a/src/vdagentd-uinput.c b/src/vdagentd-uinput.c
index 54cccb0..e675bb8 100644
--- a/src/vdagentd-uinput.c
+++ b/src/vdagentd-uinput.c
@@ -45,7 +45,7 @@ struct vdagentd_uinput *vdagentd_uinput_create(const char 
*devname,
 {
 struct vdagentd_uinput *uinput;
 
-uinput = calloc(1, sizeof(*uinput));
+uinput = malloc(sizeof(*uinput));
 if (!uinput)
 return NULL;
 
diff --git a/src/vdagentd.c b/src/vdagentd.c
index be6ef1f..297d5f4 100644
--- a/src/vdagentd.c
+++ b/src/vdagentd.c
@@ -82,7 +82,7 @@ static void send_capabilities(struct vdagent_virtio_port 
*vport,
 uint32_t size;
 
 size = sizeof(*caps) + VD_AGENT_CAPS_BYTES;
-caps = calloc(1, size);
+caps = malloc(size);
 if (!caps) {
 fprintf(logfile,
 "out of memory allocating capabilities array (write)\n");
@@ -495,7 +495,7 @@ void agent_connect(struct udscs_connection *conn)
 uint32_t pid;
 struct agent_data *agent_data;
 
-agent_data = calloc(1, sizeof(*agent_data));
+agent_data = malloc(sizeof(*agent_data));
 if (!agent_data) {
 fprintf(logfile, "Out of memory allocating agent data, 
disconnecting\n");
 udscs_destroy_connection(&conn);
-- 
1.7.5.1

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] video passthrough ideas

2011-05-12 Thread Zeeshan Ali (Khattak) 
On Thu, May 12, 2011 at 6:56 PM, Marc-André Lureau  wrote:
> My concern for VAAPI though (and other acceleration API) is that it is not a 
> sink, which handle completely decoding and displaying. I understand it can 
> take care of some expensive operations, but the result probably has to be 
> returned to the server/guest.

  No, you don't get the decoded data back. If I understood correctly,
you get some kind of ID that you then pass to the different
post-processing libraries (GLX, X etc) for the actual rendering of
video. So yes, it *kinda* is a sink.

>> 2. GStreamer all the way: This is the idea that I originally came-up
>> with when Christophe suggested a "magic GStreamer element" on IRC. The
>
> This is indeed a solution we have discussed in the past. It has several 
> advantages:

  Now you tell me. :)

> - at the moment there are just too many video acceleration API to choose one, 
> so going higher level sounds reasonable
> - we have a fairly good idea how to do it, since we know GStreamer etc..
> - we could send the whole stream to the client, which give us same advantage 
> for audio, easy a/v sync, and a separate audio channel for free
> - it will work for any client platform  (spice-gtk already works with 
> GStreamer on Windows)
> - if the solution is proved to be robust and simple, for Windows, a 
> DirectShow sink could convert the stream to a GStreamer flow, which will be 
> handled in GDP the same way
> - for MacOS, I suppose we could also write a simple QuickTime component doing 
> the same conversion

  Cool, with all these advantages in mind, maybe we should just focus
on the practicalities of this approach and only come back to the other
options if we hit a snag on this one?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] video passthrough ideas

2011-05-12 Thread Zeeshan Ali (Khattak) 
On Thu, May 12, 2011 at 9:57 PM, Marc-André Lureau  wrote:
> Hi
>
> - Original Message -
>> b. GStreamer currently do no have working VAAPI plugins and AFAIK,
>> it won't have any for at least a few months more.
>
> What do you mean? It seems they exist according to the wiki: 
> http://www.freedesktop.org/wiki/Software/vaapi 
> (http://www.splitted-desktop.com/~gbeauchesne/gstreamer-vaapi/)

  Stress on the word "working" here. :) Try building them and/or see
how well they are maintained. There is no indication of even were the
VCS repository is. On top of that its GPL and uses FFMPEG, facts for
which gst guys won't accept merging these plugins into gst proper.

> Fluendo also has its commercial vaapi/vadpau plugins: 
> http://www.fluendo.com/press/fluendo-codec-pack-release-11-keeping-technologies-fast-pace/

   Hmm.. do we really want to depend on non-free plugins? :)

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] video passthrough ideas

2011-05-12 Thread Zeeshan Ali (Khattak) 
Hi everyone,
   As some of you already know, I've been looking into the needed
"video passthrough" feature: i-e sending the encoded stream to client
and decode it on client-side. Although I'm still investigating on how
to best handle this, I thought I already share my thoughts/findings so
far so if I'm going in the wrong directions, team members can
correct/guide me. Here is the two options I've been looking into:

1. VAAPI (Video Acceleration API): The idea here is to implement a
custom VAAPI driver for the guest that redirects all decoding/playback
calls to the client through a spice channel. On the client side, we
create a channel handler based on gstreamer and its playbin2 element.

Issues/challenges here are:

  a. We still need to figure out how our VAAPI driver running in
user-space (its loaded as shared-object in the application) will
communicate to the spice server running inside Qemu?

  b. GStreamer currently do no have working VAAPI plugins and AFAIK,
it won't have any for at least a few months more.

  c. Portability: As the name suggests, VAAPI is a very linux-specific AFAICT.

  d. Limited/fixed number of encodings supported: the profiles are
defined as enums and AFAICT you can't magically add profiles on the
fly.

  e. Haven't yet figured how the interaction with QXL/windowing-system
on client can/will work (i-e telling QXL to leave the part of the
screen where the video is being played on as blank etc), need to read
more of QXL and VAAPI code to figure i guess.

2. GStreamer all the way: This is the idea that I originally came-up
with when Christophe suggested a "magic GStreamer element" on IRC. The
idea here is pretty similar to the VAAPI one except that instead of
writing a VAAP driver, we write a gstreamer sink element that would
run on the guest. This sink element will send the gstreamer data
through spice-server to the client and the story on the client is then
very similar. Here we can make use of GStreamer Data Protocol (GDP)
for which there already exists elements to serialize/deserialize the
stream into/from. Here is the advantages that comes to mind of this
approach:

  a. We can make use of the dynamic nature of GStreamer and be able to
handle any media type for which the client has plugins for.

  b. GStreamer has been known to work on windows (and even Mac) so
this option SHOULD be more easily portable.

Issues/challenges here are:

  a. Same as issue 1.a above.

  b. GDP is unidirectional so we'll need to figure a way to serialize
upstream events from the client. Shouldn't be difficult though once we
know how to solve the previous issue.

  c. Same as 1.e above.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH] gtk: Remove redundant code

2011-05-10 Thread Zeeshan Ali (Khattak) 
No need to keep the code that it disabled since it harms readability.
Also remove the '#if 1' for same rationale.
---
 gtk/channel-display.c|3 +-
 gtk/channel-main.c   |6 
 gtk/coroutine_gthread.c  |4 ---
 gtk/coroutine_ucontext.c |5 ---
 gtk/decode-glz.c |4 ---
 gtk/spice-widget.c   |   67 --
 gtk/spicy.c  |   33 --
 7 files changed, 1 insertions(+), 121 deletions(-)

diff --git a/gtk/channel-display.c b/gtk/channel-display.c
index b3ac5c0..072373d 100644
--- a/gtk/channel-display.c
+++ b/gtk/channel-display.c
@@ -463,9 +463,8 @@ static void image_put_lossy(SpiceImageCache *cache, 
uint64_t id,
 SPICE_CONTAINEROF(cache, spice_display_channel, image_cache);
 display_cache_item *item;
 
-#if 1 /* TODO: temporary sanity check */
+/* TODO: temporary sanity check */
 g_warn_if_fail(cache_find(c->images, id) == NULL);
-#endif
 
 item = cache_add(c->images, id);
 item->ptr = pixman_image_ref(surface);
diff --git a/gtk/channel-main.c b/gtk/channel-main.c
index c33851c..6897a18 100644
--- a/gtk/channel-main.c
+++ b/gtk/channel-main.c
@@ -845,12 +845,6 @@ static void agent_display_config(SpiceMainChannel *channel)
 config.depth = c->display_color_depth;
 }
 
-#if 0 // TODO
-if (!_display_setting.is_empty()) {
-_agent_reply_wait_type = VD_AGENT_DISPLAY_CONFIG;
-}
-#endif
-
 SPICE_DEBUG("display_config: flags: %u, depth: %u", config.flags, 
config.depth);
 
 agent_msg_queue(channel, VD_AGENT_DISPLAY_CONFIG, 
sizeof(VDAgentDisplayConfig), &config);
diff --git a/gtk/coroutine_gthread.c b/gtk/coroutine_gthread.c
index 14231a0..0e30a9a 100644
--- a/gtk/coroutine_gthread.c
+++ b/gtk/coroutine_gthread.c
@@ -29,11 +29,7 @@ static GMutex *run_lock;
 static struct coroutine *current;
 static struct coroutine leader;
 
-#if 0
-#define CO_DEBUG(OP) fprintf(stderr, "%s %p %s %d\n", OP, g_thread_self(), 
__FUNCTION__, __LINE__)
-#else
 #define CO_DEBUG(OP)
-#endif
 
 static void coroutine_system_init(void)
 {
diff --git a/gtk/coroutine_ucontext.c b/gtk/coroutine_ucontext.c
index 91059ad..80b3246 100644
--- a/gtk/coroutine_ucontext.c
+++ b/gtk/coroutine_ucontext.c
@@ -71,13 +71,8 @@ int coroutine_init(struct coroutine *co)
return cc_init(&co->cc);
 }
 
-#if 0
-static __thread struct coroutine leader;
-static __thread struct coroutine *current;
-#else
 static struct coroutine leader;
 static struct coroutine *current;
-#endif
 
 struct coroutine *coroutine_self(void)
 {
diff --git a/gtk/decode-glz.c b/gtk/decode-glz.c
index 5a3e06a..f1dde6e 100644
--- a/gtk/decode-glz.c
+++ b/gtk/decode-glz.c
@@ -118,10 +118,6 @@ static void glz_decoder_window_add(SpiceGlzDecoderWindow 
*w,
 slot = img->hdr.id % w->nimages;
 }
 
-#if 0
-SPICE_DEBUG("%s: %d %" PRId64, __FUNCTION__, slot, img->hdr.id);
-#endif
-
 w->images[slot] = img;
 }
 
diff --git a/gtk/spice-widget.c b/gtk/spice-widget.c
index 5cfe811..6421973 100644
--- a/gtk/spice-widget.c
+++ b/gtk/spice-widget.c
@@ -327,7 +327,6 @@ static void try_keyboard_grab(SpiceDisplay *display)
 if (!d->mouse_have_pointer)
 return;
 
-#if 1
 /*
  * == DEBUG ==
  * focus / keyboard grab behavior is funky
@@ -348,7 +347,6 @@ static void try_keyboard_grab(SpiceDisplay *display)
__FUNCTION__);
 return;
 }
-#endif
 
 SPICE_DEBUG("grab keyboard");
 
@@ -614,14 +612,6 @@ static gboolean expose_event(GtkWidget *widget, 
GdkEventExpose *expose)
 SpiceDisplay *display = SPICE_DISPLAY(widget);
 spice_display *d = SPICE_DISPLAY_GET_PRIVATE(display);
 
-#if 0
-SPICE_DEBUG("%s: area %dx%d at %d,%d", __FUNCTION__,
-expose->area.width,
-expose->area.height,
-expose->area.x,
-expose->area.y);
-#endif
-
 if (d->mark == 0 || d->data == NULL)
 return false;
 
@@ -1964,63 +1954,6 @@ typedef enum SpiceLed {
 SCROLL_LOCK_LED,
 } SpiceLed;
 
-#if 0
-static guint get_modifier_mask(Display *x_display, KeySym modifier)
-{
-int mask = 0;
-int i;
-
-XModifierKeymap* map = XGetModifierMapping(x_display);
-KeyCode keycode = XKeysymToKeycode(x_display, modifier);
-if (keycode == NoSymbol) {
-return 0;
-}
-
-for (i = 0; i < 8; i++) {
-if (map->modifiermap[map->max_keypermod * i] == keycode) {
-mask = 1 << i;
-}
-}
-XFreeModifiermap(map);
-return mask;
-}
-
-static void set_keyboard_led(Display *x_display, SpiceLed led, int set)
-{
-guint mask;
-XKeyboardControl keyboard_control;
-
-switch (led) {
-case CAPS_LOCK_LED:
-if ((mask = get_modifier_mask(x_display, XK_Caps_Lock)) != 0) {
-XkbLockModifiers(x_display, XkbUseCoreKbd, mask, set ? mask : 0);
-}
-return;
-case NUM_LOCK_LED:
-if ((mask = get_modifier_mask(x_display, XK_Num_Lock)) != 0) {
-Xk

[Spice-devel] [PATCH] server: Unset executable bit of red_tunnel_worker.h

2011-05-04 Thread Zeeshan Ali (Khattak) 
---
 0 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100755 => 100644 server/red_tunnel_worker.h

diff --git a/server/red_tunnel_worker.h b/server/red_tunnel_worker.h
old mode 100755
new mode 100644
-- 
1.7.5

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH] Add vinagre module

2011-05-03 Thread Zeeshan Ali (Khattak) 
From: Zeeshan Ali (Khattak) 

---
 modulesets/spice.xml |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/modulesets/spice.xml b/modulesets/spice.xml
index 9603438..a640afd 100644
--- a/modulesets/spice.xml
+++ b/modulesets/spice.xml
@@ -23,6 +23,8 @@
   http://downloads.sourceforge.net/project/"/>
 
+  
 
   
 http://downloads.us.xiph.org/releases/celt/celt-0.5.1.3.tar.gz";
@@ -159,4 +161,11 @@
 
   
 
+  
+
+
+  
+
+  
+
 
-- 
1.7.5

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel