Shared Desktop size

[rbeldin]

Hi...

I'm running 15.10 with the sipe-collab ppa but I have noticed the issue on other versions of the ppa. When someone shares a desktop with me and their screen is larger than mine, I will find that the xfreerdp client that pops up has no resize ability and no scrollbars. As a result, I typically lose some real-estate on the bottom of the screen. Is there some method to get the xfreerdp client to scale to the output resolution or add scrollbars?

Thanks,

Rick

[xhaakon]

Hi,

Scaling/scrolling isn't possible with xfreerdp client we have in PPA. I'll check if updating it to a more recent upstream version helps somehow.

[xnandersson]

It is not yet implemented.

On 15/02/16 15:56, Jakub Adam wrote:

Hi,

Scaling/scrolling isn't possible with xfreerdp client we have in PPA. I'll check if updating it to a more recent upstream version helps somehow.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-184238854.

[rbeldin]

That's a shame. I use a variety of rdp clients for connecting to various environments. The remmina project, for example, has an rdp plugin that supports scaling and scrolling. I suspect they render the rdp output on to an object that supports scaling and scrolling. My thought would be that a minimum implementation of this would would allow for scale-to-fit option and a 1:1 option. The 1:1 option could create the window in such a way that it is larger than the desktop, allowing someone to pan via the window manager if need be. My 2 cents.

Thanks for a great project. I'd be willing to test when there is something to test as I use this on a daily basis.

Thanks,

Rick

On 02/15/2016 10:04 AM, Niklas Andersson wrote:

It is not yet implemented.

On 15/02/16 15:56, Jakub Adam wrote:

Hi,

Scaling/scrolling isn't possible with xfreerdp client we have in PPA. I'll check if updating it to a more recent upstream version helps somehow.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-184238854.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-184245847.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[xnandersson]

Thanks a lot!

Looks like we should be able to see how Remmina is doing scaling then and perhaps even use the same code base :-)

Thanks for the tip.

Regards, Niklas

On 16/02/16 12:16, rbeldin wrote:

That's a shame. I use a variety of rdp clients for connecting to various environments. The remmina project, for example, has an rdp plugin that supports scaling and scrolling. I suspect they render the rdp output on to an object that supports scaling and scrolling. My thought would be that a minimum implementation of this would would allow for scale-to-fit option and a 1:1 option. The 1:1 option could create the window in such a way that it is larger than the desktop, allowing someone to pan via the window manager if need be. My 2 cents.

Thanks for a great project. I'd be willing to test when there is something to test as I use this on a daily basis.

Thanks,

Rick

On 02/15/2016 10:04 AM, Niklas Andersson wrote:

It is not yet implemented.

On 15/02/16 15:56, Jakub Adam wrote:

Hi,

Scaling/scrolling isn't possible with xfreerdp client we have in PPA. I'll check if updating it to a more recent upstream version helps somehow.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-184238854.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-184245847.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-184635229.

[xhaakon]

On 02/16/2016 12:16 PM, rbeldin wrote:

The remmina project, for example, has an rdp plugin that supports scaling and scrolling. I suspect they render the rdp output on to an object that supports scaling and scrolling.

Actually, Remmina RDP is built on top of libfreerdp as Sipe is, and thus it should be possible to use it instead of the minimalistic xfreerdp client, provided that Remmina knows how to connect to a local unix socket. And still if not, I guess it wouldn't be hard to implement ourselves.

That would solve our problem without a need to reinvent yet another client app. I'll put rebuilding Remmina with recent enough FreeRDP on my todo list.

[xnandersson]

Looks like this [1] is how Remmina handles it. Key-word: "autofit"

[1] https://github.com/FreeRDP/Remmina/blob/next/remmina/src/remmina_connection_window.c

[rbeldin]

I'm not very skilled at gtk programming, but from what I know of what is done for similar sorts of operations generally involves a container with scaling and drawing support being placed inside another window.

Full screen is generally achieved by reparenting to the root window or turning off window manager borders and resize handles.

A quick glance at the code suggests a couple of areas. This struct seems to be key:

typedef struct _RemminaConnectionObject { RemminaConnectionHolder* cnnhld;

RemminaFile* remmina_file;

/* A dummy window which will be realized as a container during initialize,

before reparent to the real window / GtkWidget window;

/* Containers for RemminaProtocolWidget:

RemminaProtocolWidget->aspectframe->viewport->scrolledcontainer->...->window / GtkWidget proto; GtkWidget* aspectframe; GtkWidget* viewport;

/* Scrolled containers */
GtkWidget* scrolled_container;

gboolean plugin_can_scale;

gboolean connected;

} RemminaConnectionObject;

The  remmina_connection_window_class_init() class seems to hold
key details on how the scaling window is created.

There are another couple of functions used to resize:

remmina_connection_holder_toolbar_autofit()

remmina_connection_holder_toolbar_autofit_restore()

remmina_connection_holder_check_resize()

There are some others, but these seem to be the ones where
most of the work is done.  A lot of the rest seems to be in
generating the interface and connecting the signals to objects.

The TRACE_CALL macro might be useful to figure out as that might
reveal the calling sequence.

My 2cents.

Rick

[xhaakon]

Thanks for your analysis. It indeed provides valuable insight as to how one would implement a new client that embeds libfreerdp and adds some widget controls in order to achieve scene scaling or resize. What I was trying to say in my previous comment, though, was that I'd like to reuse Remmina itself, not just some pieces of its code.

What Pidgin now does when it is about to show a remote screen is that it first establishes a TCP link with the presenter's Lync client and pipes whatever data is flowing through that connection (that is packets of RDP protocol) into a local UNIX socket (with a file somewhere in /run/user, not too important). Then, it spawns a separate xfreerdp process, which then reads and writes RDP data into that socket and isn't even aware it's in fact Sipe who forwards the data to its actual destination across the network. So there isn't any RDP client integrated in Pidgin. Pidgin merely takes care of establishing of the connection and leaves the RDP processing on a dedicated external application.

Similarly, if we could run 'remmina' process instead of 'xfreerdp' and have it connect to that local socket, we would get Lync application sharing inside Remmina window with all the benefits it brings - like scaling the image, running fullscreen, having scroll bars, etc. Once we pull that off, how exactly Remmina scales or scrolls the view will become just an implementation detail we won't really have to care about.

[rbeldin]

Oh, I didn't pick up on that idea. I thought you were talking about writing a plugin when you pointed at the source.

I think it might be possible. What bits of information do you pass along to xfreerdp? I've never looked into that.

remmina is more about the gui so the options you can pass to it are more limited:

rbeldin@rbeldin-8460p:~$ remmina --help Usage: remmina [OPTION...] - The GTK+ Remote Desktop Client

Help Options: -h, --help Show help options --help-all Show all help options --help-gtk Show GTK+ Options

Application Options: -a, --about Show about dialog -c, --connect=FILE Connect to a .remmina file -e, --edit=FILE Edit a .remmina file -n, --new Create a new connection profile -p, --pref=PAGENR Show preferences dialog page -x, --plugin=PLUGIN Execute the plugin -q, --quit Quit the application -s, --server=SERVER Use default server name -t, --protocol=PROTOCOL Use default protocol -i, --icon Start as tray icon -v, --version Show the application's version --display=DISPLAY X display to use

One perhaps kludgy way might be to create a .remmina file, which has the connection details.

For example for one rdp session I have defined, looks like this:

[remmina] sound=off sharefolder= name=remote-rdp-server-name console=0 cert_ignore=0 ssh_enabled=0 exec= clientname= loadbalanceinfo= server=remote-rdp-server-name colordepth=8 ssh_auth=0 group= sharesmartcard=0 quality=0 username= ssh_charset= ssh_loopback=0 password= ssh_username= gateway_server= disablepasswordstoring=0 execpath= gateway_usage=0 resolution= security= domain= precommand= ssh_server= shareprinter=0 protocol=RDP disableclipboard=0 ssh_privatekey= window_maximize=0 window_height=733 window_width=640 viewmode=1

Rick

On 02/17/2016 10:27 AM, Jakub Adam wrote:

Thanks for your analysis. It indeed provides valuable insight as to how one would implement a new client that embeds libfreerdp and adds some widget controls in order to achieve scene scaling or resize. What I was trying to say in my previous comment, though, was that I'd like to reuse Remmina /itself/, not just some pieces of its code.

What Pidgin now does when it is about to show a remote screen is that it first establishes a TCP link with the presenter's Lync client and pipes whatever data is flowing through that connection (that is packets of RDP protocol) into a local UNIX socket (with a file somewhere in /run/user, not too important). Then, it spawns a separate xfreerdp process, which then reads and writes RDP data into that socket and isn't even aware it's in fact Sipe who forwards the data to its actual destination across the network. So there isn't any RDP client integrated in Pidgin. Pidgin merely takes care of establishing of the connection and leaves the RDP processing on a dedicated external application.

Similarly, if we could run 'remmina' process instead of 'xfreerdp' and have it connect to that local socket, we would get Lync application sharing /inside/ Remmina window with all the benefits it brings - like scaling the image, running fullscreen, having scroll bars, etc. Once we pull that off, how exactly Remmina scales or scrolls the view will become just an implementation detail we won't really have to care about.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-185254582.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[xhaakon]

What bits of information do you pass along to xfreerdp?

Not much. If I recall correctly it's only the path to the unix socket (special file in /run/user) and a flag that disables encryption since Sipe already handles it. From that, xfreerdp negotiates everything else on its own. We had FreeRDP guys make some minor modifications to the client to make it possible, but now it works as any other remote connection, you only connect to a socket file instead of an IP address.

rbeldin@rbeldin-8460p:~$ remmina --help ...

If that -s argument is an address of the server, it might be enough. Generating that .remmina file on the fly would be a less elegant, but still viable option.

Question remains whether remmina would accept filesystem path instead of an IP address, but creating a patch for that should be easy because we know the underlying library (libfreerdp) already supports it.

There even is remmina-plugin-telepathy, only talks with Telepathy framework, which apparently handles connecting to the remote client and delegates painting of the remote view itself in a similar fashion as we do.

[xhaakon]

I played a bit with the idea and managed to get it working just as described - I have Pidgin opening Remmina which shows the remote application from Lync. You can scale, scroll, fullscreen the window just as with any other Remmina remote view.

It only doesn't accept Unix domain sockets, but for the proof of concept I used socat to pipe the data stream into a local TCP port. In the final implementation this can be handled directly in Sipe. Remmina version I used was installed directly from Debian repo, so we won't even need any rebuild against the latest libfreerdp. Makes everything simpler that I expected.

To clean up the code and make it ready for PPA should take only a couple of hours. I guess this is so far our best solution for adding some user-friendliness into our RDP viewer until perhaps Pidgin implements its own integrated solution. That will need much more time and effort though and I wouldn't hold my breath for it right now.

[rbeldin]

That is excellent news. I'll be happy to test the new ppa when it is ready.

On 02/18/2016 02:39 AM, Jakub Adam wrote:

I played a bit with the idea and managed to get it working just as described - I have Pidgin opening Remmina which shows the remote application from Lync. You can scale, scroll, fullscreen the window just as with any other Remmina remote view.

It only doesn't accept Unix domain sockets, but for the proof of concept I used |socat| to pipe the data stream into a local TCP port. In the final implementation this can be handled directly in Sipe. Remmina version I used was installed directly from Debian repo, so we won't even need any rebuild against the latest libfreerdp. Makes everything simpler that I expected.

To clean up the code and make it ready for PPA should take only a couple of hours. I guess this is so far our best solution for adding some user-friendliness into our RDP viewer until perhaps Pidgin implements its own integrated solution. That will need much more time and effort though and I wouldn't hold my breath for it right now.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-185582178.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[xhaakon]

Okay, it's deployed in PPA. Please update and test.

I still have some issues on 14.04, but with your 15.10 you should be fine.

[rbeldin]

Hmmm. first time someone shared a big desktop (dual 30" monitors) with me, it core dumped.

whoopsie was running and captured the core. I don't know if you want that but I can provide it separately if you like.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[rbeldin]

My colleague who I was testing this with was running Windows 7 on a screen that is:

 2560x1440  30 inch display

So greater than 1080p.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[rbeldin]

I had one successful sharing session from a Windows 7 user with a 1080p display. In that case, the screen shared properly and I was able to scale it and make it full screen with remmina. When he did this, remmina was already up and running.

[xhaakon]

first time someone shared a big desktop (dual 30" monitors) with me, it core dumped.

What did crash? Pidgin or Remmina?

whoopsie was running and captured the core. I don't know if you want that but I can provide it separately if you like.

Perhaps if you could just extract the stack trace from that core.

[xhaakon]

I experienced one crash in the morning while I was testing with a colleague. It can trigger when large amount of data is being sent through the RDP connection, and since that typically applies to sharing big screens, changes are it was the same segfault you have seen.

I'm working on a fix.

[rbeldin]

Looks like it was pidgin and not remmina. The core shows the following stack trace:

] (gdb) bt

0 0x00007fd0567a4267 in __GI_raise (sig=sig@entry=6) at

../sysdeps/unix/sysv/linux/raise.c:55

1 0x00007fd0567a5eca in __GI_abort () at abort.c:89

2 0x00007fd056dc6b15 in g_assertion_message () from

/lib/x86_64-linux-gnu/libglib-2.0.so.0

3 0x00007fd056dc6baa in g_assertion_message_expr ()

from /lib/x86_64-linux-gnu/libglib-2.0.so.0

4 0x00007fd033770679 in process_incoming_invite_call () from

/usr/lib/purple-3/libsipe.so

5 0x00007fd033743c04 in ?? () from /usr/lib/purple-3/libsipe.so

6 0x00007fd0570e8dee in pidgin_io_invoke (source=,

condition=, data=0x5603363943c0) at gtkeventloop.c:66

7 0x00007fd056da0eaa in g_main_context_dispatch () from

/lib/x86_64-linux-gnu/libglib-2.0.so.0

8 0x00007fd056da1250 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

9 0x00007fd056da1572 in g_main_loop_run () from

/lib/x86_64-linux-gnu/libglib-2.0.so.0

10 0x00007fd052ccf775 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0

11 0x00007fd05712f8c4 in pidgin_start (argc=1, argv=0x7ffc247b6708) at

libpidgin.c:850

12 0x00007fd05678fa40 in __libc_start_main (main=0x560333545930, argc=1,

argv=0x7ffc247b6708, init=, fini=, rtld_fini=, stack_end=0x7ffc247b66f8) at libc-start.c:289

13 0x00005603335459b9 in ?? ()

14 0x00007ffc247b66f8 in ?? ()

15 0x000000000000001c in ?? ()

16 0x0000000000000001 in ?? ()

17 0x00007ffc247b877a in ?? ()

18 0x0000000000000000 in ?? ()

(gdb) info threads Id Target Id Frame 16 Thread 0x7fcfa9940700 (LWP 10648) 0x00007fd05686a88d in poll () at ../sysdeps/unix/syscall-template.S:81 15 Thread 0x7fcfcffff700 (LWP 10646) 0x00007fd05686a88d in poll () at ../sysdeps/unix/syscall-template.S:81 14 Thread 0x7fcfa913f700 (LWP 10647) 0x00007fd05686a88d in poll () at ../sysdeps/unix/syscall-template.S:81 13 Thread 0x7fcfaba95700 (LWP 10649) 0x00007fd05686a88d in poll () at ../sysdeps/unix/syscall-template.S:81 12 Thread 0x7fcfdd60c700 (LWP 10645) syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 11 Thread 0x7fcfdca02700 (LWP 10643) syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 10 Thread 0x7fcfce7fc700 (LWP 10543) pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 9 Thread 0x7fcfcdffb700 (LWP 10544) pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 8 Thread 0x7fcfceffd700 (LWP 10542) pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 7 Thread 0x7fcfdec35700 (LWP 10535) 0x00007fd05686a88d in poll () at ../sysdeps/unix/syscall-template.S:81 6 Thread 0x7fcfed1ca700 (LWP 10534) pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 5 Thread 0x7fcfcf7fe700 (LWP 10541) pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 4 Thread 0x7fd040be3700 (LWP 10531) 0x00007fd05686a88d in poll () at ../sysdeps/unix/syscall-template.S:81 3 Thread 0x7fd03bfff700 (LWP 10532) 0x00007fd05686a88d in poll () at ../sysdeps/unix/syscall-template.S:81 2 Thread 0x7fd02dacf700 (LWP 10533) pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

• 1 Thread 0x7fd0574a2a80 (LWP 10530) 0x00007fd0567a4267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55

Most of the threads seem to be in poll() or waiting to reconvene.

Rick

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-186109160.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[xhaakon]

That failed assert in process_incoming_invite_call() is something different from what I mentioned in my post and fixed later today, but I had the very same crash today as well. It happened only once when I was testing something else and I wasn't able to reproduce it afterwards. At least I have a clue what I should look at...

Regarding Remmina, we've found out there is a bug with large screens which may appear cropped in your window. The actual size of the screen is preserved, but you'll see only black border instead of the right side and bottom of the image. If you have such issue, please install remmina from remmina-next PPA; it should include packages for 15.10.

Over the weekend or on Monday I'll put a copy of remmina-next package into sipe-collab PPA and make pidgin-sipe depend on it, so that the patched remmina is installed to the users by default.

[rbeldin]

Interesting behavior this am. I connected to a skype conference call that had a shared desktop and while the remmina window showed remote activity, the pidgin interface was frozen. I got no audio.

I then updated pidgin pidgin-sipe pidgin-data and remmina and now lync doesn't work. I got an error during the update: e root@rbeldin-8460p:/home/rbeldin# apt-get install pidgin pidgin-data pidgin-sipe remmina Reading package lists... Done Building dependency tree
Reading state information... Done pidgin-data is already the newest version. pidgin-data set to manually installed. pidgin is already the newest version. The following package was automatically installed and is no longer required: libvncclient0 Use 'apt-get autoremove' to remove it. The following extra packages will be installed: freerdp-shadow-x11 libfreerdp-client2 libfreerdp-server2 libfreerdp2 libjavascriptcoregtk-4.0-18 librdtk0 libwebkit2gtk-4.0-37 libwinpr1 remmina-common remmina-plugin-rdp remmina-plugin-vnc The following NEW packages will be installed: freerdp-shadow-x11 libfreerdp-client2 libfreerdp-server2 libfreerdp2 libjavascriptcoregtk-4.0-18 librdtk0 libwebkit2gtk-4.0-37 libwinpr1 The following packages will be upgraded: pidgin-sipe remmina remmina-common remmina-plugin-rdp remmina-plugin-vnc 5 upgraded, 8 newly installed, 0 to remove and 21 not upgraded. Need to get 19.7 MB of archives. After this operation, 79.1 MB of additional disk space will be used. Do you want to continue? [Y/n] y ,,,, y Get:1 http://us.archive.ubuntu.com/ubuntu/ wily/universe libjavascriptcoregtk-4.0-18 amd64 2.8.5+dfsg1-3 [2,055 kB] Get:2 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main libwinpr1 amd64 2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1 [257 kB] Get:3 http://us.archive.ubuntu.com/ubuntu/ wily/universe libwebkit2gtk-4.0-37 amd64 2.8.5+dfsg1-3 [15.8 MB] Get:4 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main libfreerdp2 amd64 2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1 [445 kB] Get:5 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main libfreerdp-server2 amd64 2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1 [54.7 kB] Get:6 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main librdtk0 amd64 2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1 [28.5 kB] Get:7 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main freerdp-shadow-x11 amd64 2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1 [47.9 kB] Get:8 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main libfreerdp-client2 amd64 2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1 [253 kB] Get:9 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main remmina-plugin-rdp amd64 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 [37.3 kB] Get:10 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main remmina-plugin-vnc amd64 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 [25.5 kB] Get:11 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main remmina amd64 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 [127 kB] Get:12 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main remmina-common all 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 [235 kB] Get:13 http://ppa.launchpad.net/sipe-collab/ppa/ubuntu/ wily/main pidgin-sipe amd64 1.20.1+collab-201602231455+3166~ubuntu15.10.1 [287 kB] Fetched 19.7 MB in 3s (5,251 kB/s)
Selecting previously unselected package libwinpr1:amd64. (Reading database ... 552537 files and directories currently installed.) Preparing to unpack .../libwinpr1_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb ... Unpacking libwinpr1:amd64 (2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1) ... dpkg: error processing archive /var/cache/apt/archives/libwinpr1_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libwinpr.so.1.1.0', which is also in package libfreerdp1:amd64 1.2.0~git20150207+dfsg-0utopic2 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Selecting previously unselected package libfreerdp2:amd64. Preparing to unpack .../libfreerdp2_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb ... Unpacking libfreerdp2:amd64 (2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1) ... Selecting previously unselected package libfreerdp-server2:amd64. Preparing to unpack .../libfreerdp-server2_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb ... Unpacking libfreerdp-server2:amd64 (2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1) ... Selecting previously unselected package librdtk0:amd64. Preparing to unpack .../librdtk0_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb ... Unpacking librdtk0:amd64 (2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1) ... Selecting previously unselected package freerdp-shadow-x11. Preparing to unpack .../freerdp-shadow-x11_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb ... Unpacking freerdp-shadow-x11 (2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1) ... Selecting previously unselected package libfreerdp-client2:amd64. Preparing to unpack .../libfreerdp-client2_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb ... Unpacking libfreerdp-client2:amd64 (2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1) ... Selecting previously unselected package libjavascriptcoregtk-4.0-18:amd64. Preparing to unpack .../libjavascriptcoregtk-4.0-18_2.8.5+dfsg1-3_amd64.deb ... Unpacking libjavascriptcoregtk-4.0-18:amd64 (2.8.5+dfsg1-3) ... Selecting previously unselected package libwebkit2gtk-4.0-37:amd64. Preparing to unpack .../libwebkit2gtk-4.0-37_2.8.5+dfsg1-3_amd64.deb ... Unpacking libwebkit2gtk-4.0-37:amd64 (2.8.5+dfsg1-3) ... Preparing to unpack .../remmina-plugin-rdp_1.1.2-sipe+855+next+201602231732~ubuntu15.10.1_amd64.deb ... Unpacking remmina-plugin-rdp (1.1.2-sipe+855+next+201602231732~ubuntu15.10.1) over (1.1.2-ppa1+805+next+201512171102~ubuntu15.04.1) ... Preparing to unpack .../remmina-plugin-vnc_1.1.2-sipe+855+next+201602231732~ubuntu15.10.1_amd64.deb ... Unpacking remmina-plugin-vnc (1.1.2-sipe+855+next+201602231732~ubuntu15.10.1) over (1.1.2-ppa1+805+next+201512171102~ubuntu15.04.1) ... Preparing to unpack .../remmina_1.1.2-sipe+855+next+201602231732~ubuntu15.10.1_amd64.deb ... Unpacking remmina (1.1.2-sipe+855+next+201602231732~ubuntu15.10.1) over (1.1.2-ppa1+805+next+201512171102~ubuntu15.04.1) ... Preparing to unpack .../remmina-common_1.1.2-sipe+855+next+201602231732~ubuntu15.10.1_all.deb ... Unpacking remmina-common (1.1.2-sipe+855+next+201602231732~ubuntu15.10.1) over (1.1.2-ppa1+805+next+201512171102~ubuntu15.04.1) ... Preparing to unpack .../pidgin-sipe_1.20.1+collab-201602231455+3166~ubuntu15.10.1_amd64.deb ... Leaving 'diversion of /usr/bin/pidgin to /usr/bin/pidgin.orig by pidgin-sipe' Unpacking pidgin-sipe (1.20.1+collab-201602231455+3166~ubuntu15.10.1) over (1.20.1+collab-201602220749+3165~ubuntu15.10.1) ... Processing triggers for bamfdaemon (0.5.2~bzr0+15.10.20150627.1-0ubuntu1) ... Rebuilding /usr/share/applications/bamf-2.index... Processing triggers for gnome-menus (3.13.3-6ubuntu1) ... Processing triggers for desktop-file-utils (0.22-1ubuntu3) ... Processing triggers for mime-support (3.58ubuntu1) ... Processing triggers for menu (2.1.47ubuntu1) ... Processing triggers for man-db (2.7.4-1) ... Processing triggers for hicolor-icon-theme (0.15-0ubuntu1) ... Errors were encountered while processing: /var/cache/apt/archives/libwinpr1_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)

Now:

root@rbeldin-8460p:/home/rbeldin# apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following package was automatically installed and is no longer required: libvncclient0 Use 'apt-get autoremove' to remove it. The following extra packages will be installed: libwinpr1 The following NEW packages will be installed: libwinpr1 0 upgraded, 1 newly installed, 0 to remove and 21 not upgraded. 12 not fully installed or removed. Need to get 0 B/257 kB of archives. After this operation, 926 kB of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 552631 files and directories currently installed.) Preparing to unpack .../libwinpr1_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb ... Unpacking libwinpr1:amd64 (2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1) ... dpkg: error processing archive /var/cache/apt/archives/libwinpr1_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/libwinpr.so.1.1.0', which is also in package libfreerdp1:amd64 1.2.0~git20150207+dfsg-0utopic2 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libwinpr1_2.0.0~git20160115.1.e2dbe5e+dfsg1-0~11~ubuntu15.10.1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)

[xhaakon]

Looks like unsuccessful update of FreeRDP from older version (there was a major update in the PPA today and some packages changed names and contents).

Please apt-get purge all packages from dpkg --list | grep -e winpr -e freerdp -e remmina. If you have remmina-next PPA, disable it. Then try to install remmina and pidgin-sipe once more.

[rbeldin]

Ok, I cleared that but the bug with the pidgin interface hanging while in a conference call is still happening. Audio is working and remmina is displaying cursor movements from the remote desktop. I cannot interact with the conversation or buddy list window.

Versions installed:

root@rbeldin-8460p:/home/rbeldin# dpkg -l | grep -E 'pidgin|remmina' ii pidgin 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 amd64 graphical multi-protocol instant messaging client for X ii pidgin-data 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 all multi-protocol instant messaging client - data files ii pidgin-dbg 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 amd64 Debugging symbols for Pidgin ii pidgin-sipe 1.20.1+collab-201602231455+3166~ubuntu15.10.1 amd64 Pidgin plugin for MS Office Communicator and MS Lync ii remmina 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 amd64 remote desktop client for GNOME desktop environment ii remmina-common 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 all common files for remmina remote desktop client ii remmina-plugin-rdp 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 amd64 RDP plugin for remmina remote desktop client ii remmina-plugin-vnc 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 amd64 VNC plugin for remmina remote desktop client

[rbeldin]

Interestingly, ctrl-tab in the conversation window will update the title bar of the conversation list with one of the tabs as if you could cycle through it.

Terminating remmina did not immediately terminate the skype session but it eventually core dumped.

Stack trace shows us here:

(gdb) bt

0 0x00007fa0f8f2a267 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55

1 0x00007fa0f8f2beca in __GI_abort () at abort.c:89

2 0x00007fa0f98b4dad in sighandler (sig=11) at libpidgin.c:153

3

4 0x00007fa0f3d557a9 in purple_media_stream_info (media=0x20, type=PURPLE_MEDIA_INFO_HANGUP,

session_id=0x0, participant=0x0, local=1) at media.c:747

5 0x00007fa0da00b97a in sipe_core_schedule_execute () from /usr/lib/purple-3/libsipe.so

6 0x00007fa0da024871 in ?? () from /usr/lib/purple-3/libsipe.so

7 0x00007fa0f9527913 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

8 0x00007fa0f9526eaa in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

9 0x00007fa0f9527250 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

10 0x00007fa0f9527572 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

11 0x00007fa0f5455775 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0

12 0x00007fa0f98b58d4 in pidgin_start (argc=1, argv=0x7ffdc6733bc8) at libpidgin.c:850

13 0x00007fa0f8f15a40 in __libc_start_main (main=0x56229f5f2930, argc=1, argv=0x7ffdc6733bc8,

init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdc6733bb8)
at libc-start.c:289

14 0x000056229f5f29b9 in ?? ()

15 0x00007ffdc6733bb8 in ?? ()

16 0x000000000000001c in ?? ()

17 0x0000000000000001 in ?? ()

18 0x00007ffdc673477a in ?? ()

19 0x0000000000000000 in ?? ()

[xhaakon]

@rbeldin the frozen Pidgin UI during incoming desktop shares should be now fixed in PPA.

[rbeldin]

Hi...

I've got the following pieces after updating this morning:

dpkg -l | grep -E 'pidgin|remmina' ii pidgin 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 amd64 graphical multi-protocol instant messaging client for X ii pidgin-data 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 all multi-protocol instant messaging client - data files ii pidgin-dbg 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 amd64 Debugging symbols for Pidgin ii pidgin-sipe 1.20.1+collab-201602241346+3171~ubuntu15.10.1 amd64 Pidgin plugin for MS Office Communicator and MS Lync ii remmina 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 amd64 remote desktop client for GNOME desktop environment ii remmina-common 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 all common files for remmina remote desktop client ii remmina-plugin-rdp 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 amd64 RDP plugin for remmina remote desktop client ii remmina-plugin-vnc 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 amd64 VNC plugin for remmina remote desktop client

I still have the frozen ui although remmina is still functional.

I'm going to let the conference call finish in the next 30 minutes
to see if it returns after the conference ends.

Rick

On 02/24/2016 09:10 AM, Jakub Adam wrote:

@rbeldin https://github.com/rbeldin the frozen Pidgin UI during incoming desktop shares should be now fixed in PPA.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-188271018.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[rbeldin]

Attaching to pidgin with gdb shows:

(gdb) bt

0 0x00007f2ff3dbfdad in write () at ../sysdeps/unix/syscall-template.S:81

1 0x00007f2ff405b582 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

2 0x00007f2ff401455c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

3 0x00007f2ff4018056 in g_main_context_dispatch () from

/lib/x86_64-linux-gnu/libglib-2.0.so.0

4 0x00007f2ff4018250 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0

5 0x00007f2ff4018572 in g_main_loop_run () from

/lib/x86_64-linux-gnu/libglib-2.0.so.0

6 0x00007f2feff46775 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-3.so.0

7 0x00007f2ff43a68d4 in pidgin_start (argc=1, argv=0x7fff551f1078) at

libpidgin.c:850

8 0x00007f2ff3a06a40 in __libc_start_main (main=0x557ec373b930

, argc=1,

argv=0x7fff551f1078, init=<optimized out>, fini=<optimized out>,

rtld_fini=, stack_end=0x7fff551f1068) at libc-start.c:289

9 0x0000557ec373b9b9 in _start ()

S (gdb) info thread Id Target Id Frame 33 Thread 0x7f2fdde5a700 (LWP 30386) "gmain" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 32 Thread 0x7f2fdd659700 (LWP 30387) "gdbus" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 31 Thread 0x7f2fcaa3d700 (LWP 30388) "pidgin.orig" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 30 Thread 0x7f2f8a138700 (LWP 30389) "pidgin.orig" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 29 Thread 0x7f2f7baf0700 (LWP 30390) "dconf worker" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 28 Thread 0x7f2f78883700 (LWP 30396) "pidgin.orig" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 27 Thread 0x7f2f63fff700 (LWP 30397) "pidgin.orig" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 26 Thread 0x7f2f637fe700 (LWP 30398) "pidgin.orig" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 25 Thread 0x7f2f62ffd700 (LWP 30399) "pidgin.orig" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 24 Thread 0x7f2f79c8e700 (LWP 1565) "rtpsession-rtcp" 0x00007f2ff3ae1951 in GI_ppoll ( fds=0x7f2f680010c0, nfds=1, timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56 23 Thread 0x7f2f7948d700 (LWP 1566) "appsrc0:src" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 22 Thread 0x7f2f7a48f700 (LWP 1567) "libnice agent t" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 21 Thread 0x7f2f7ac90700 (LWP 1568) "nicesrc0:src" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 20 Thread 0x7f2f4885e700 (LWP 1569) "nicesrc1:src" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 19 Thread 0x7f2f43fff700 (LWP 1570) "pidgin.orig" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 18 Thread 0x7f2f3bdf3700 (LWP 1571) "rtpsession-rtcp" 0x00007f2ff3ae1951 in GI_ppoll ( fds=0x7f2f680010c0, nfds=1, timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56 17 Thread 0x7f2f39bf5700 (LWP 1572) "threaded-ml" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 16 Thread 0x7f2f393f4700 (LWP 1573) "pidgindefaultau" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 15 Thread 0x7f2f38bf3700 (LWP 1574) "libnice agent t" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 14 Thread 0x7f2f27ffe700 (LWP 1575) "nicesrc2:src" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 13 Thread 0x7f2f277fd700 (LWP 1576) "nicesrc3:src" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 12 Thread 0x7f2f26ffc700 (LWP 1577) "pidgin.orig" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 11 Thread 0x7f2f267fb700 (LWP 1578) "audiosrc-ringbu" pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:143 10 Thread 0x7f2f25ffa700 (LWP 1579) "rtpjitterbuffer" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 ---Type to continue, or q to quit--- 9 Thread 0x7f2f257f9700 (LWP 1590) "timer" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 8 Thread 0x7f2f24ff8700 (LWP 1591) "rtpjitterbuffer" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 7 Thread 0x7f2f07fff700 (LWP 1593) "timer" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 6 Thread 0x7f2f077fe700 (LWP 1594) "threaded-ml" 0x00007f2ff3ae188d in poll () at ../sysdeps/unix/syscall-template.S:81 5 Thread 0x7f2f06ffd700 (LWP 1595) "queue0:src" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 4 Thread 0x7f2f067fc700 (LWP 1596) "liveadder0:src" 0x00007f2ff3ae1951 in __GI_ppoll ( fds=0x7f2f680010c0, nfds=1, timeout=, sigmask=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:56 3 Thread 0x7f2f057fa700 (LWP 1598) "dtmfsrc0:src" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 2 Thread 0x7f2f04ff9700 (LWP 1599) "rtpdtmfsrc0:src" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38

• 1 Thread 0x7f2ff4719a80 (LWP 30385) "pidgin.orig" 0x00007f2ff3dbfdad in write () at ../sysdeps/unix/syscall-template.S:81

On 02/24/2016 09:10 AM, Jakub Adam wrote:

@rbeldin https://github.com/rbeldin the frozen Pidgin UI during incoming desktop shares should be now fixed in PPA.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-188271018.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[rbeldin]

Observation - I had one of the IRC tabs active and I can see new activity but can't interact. UI events aren't making it to the interface. For example, if I resize the conversation window or cover it with another window it doesn't refresh properly.

On 02/24/2016 09:10 AM, Jakub Adam wrote:

@rbeldin https://github.com/rbeldin the frozen Pidgin UI during incoming desktop shares should be now fixed in PPA.

— Reply to this email directly or view it on GitHub https://github.com/tieto/sipe/issues/19#issuecomment-188271018.

Rick Beldin Linux ERT Tel: +1 770.343.0219 Email: rick.beldin@hpe.com Physical: 5555 Windward Parkway West, Alpharetta GA 30004

[rbeldin]

pidgin remained frozen after the conference ended.

I'm in a new conference call and audio-only is fine. I suspect that the remmina thread is blocking - perhaps because the remmina UI is trying to grab input. That would be a fundamental difference over how xfreerdp worked as there was no interface to that tool. I'm not that familiar with glib and how it handles multiple input main loops, but this seems like it might be one area of concern.

Would it be possible to have an option to select the client between remmina and xfreerdp, at least during development?

[xhaakon]

@rbeldin could you please check you're actually running the plugin you installed this morning?

I reproduced that problem and really think I fixed its root cause. I have just checked latest PPA in 15.04 VM and Pidgin consumes only few percent of CPU and remains responsive when Remmina is open.

[rbeldin]

I'm pretty sure I was running pidgin-sipe 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 when I had the problem. I just refreshed my repos and this is all I have available:

pidgin 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 pidgin-data 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 pidgin-dbg 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 pidgin-sipe 1.20.1+collab-201602241346+3171~ubuntu15.10.1 remmina 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 remmina-common 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 remmina-plugin-rdp 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 remmina-plugin-vnc 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1

The times this has happened to me, I joined a conference a minute or two late where sharing was already in progress. At that point I got two popups to accept sharing and audio. The sharing popup was on top so I probably accepted that first.

[xhaakon]

I suspect that the remmina thread is blocking - perhaps because the remmina UI is trying to grab input.

Remmina or xfreerdp run as separate forked processes and communicate with Pidgin only through a TCP socket. So, as far as Sipe is concerned, there's no difference between them.

pidgin-sipe 1.20.1+collab-201602241346+3171~ubuntu15.10.1 is the latest version. Maybe your problem shows only during multiuser conference, which is a scenario I haven't tested. I'll check that when I'm at work.

[xhaakon]

@rbeldin Could you maybe try if desktop sharing between two PCs also freezes the UI?

[rbeldin]

PC to PC audio conversation with a shared desktop worked fine.

[xhaakon]

@rbeldin Okay, that's an important finding, thanks!

[xhaakon]

I've been playing with a conference for about 15 minutes, doing various things in an attempt to get myself into a situation where Pidgin UI would become unresponsive, but so far I wasn't able to reproduce your problem.

Could you please run pidgin --debug and get some logs from your call? (You may send it to the email in my profile in order to avoid posting potentially private data on GitHub.)

Also, what kind of conference is it? How many participants are there? Is there a single presenter during the whole meeting, or is the remote desktop view switching between multiple people? Are you presenting at some point?

[rbeldin]

On 02/25/2016 02:44 AM, Jakub Adam wrote:

I've been playing with a conference for about 15 minutes, doing various things in an attempt to get myself into a situation where Pidgin UI would become unresponsive, but so far I wasn't able to reproduce your problem.

That sounds promising.  I don't know if this matters, but I generally
run a 3 monitor setup under KDE.  One of the perpetual oddities with
pidgin is that the popups for that application will appear in random
order on any of the screens, often under other windows.  This can
affect the order in which I accept them.  I mention that because
I know that I have tended to get the popup for the presentation
on top of the other and so tend to accept it first.

Could you please run |pidgin --debug| and get some logs from your call? (You may send it to the email in my profile in order to avoid posting potentially private data on GitHub.)

I'll do this for the next meeting I have.

Is there a provision in pidgin to direct logging to a specific
file?  Since I usually launch this from the KDE interface, there
is sometimes some stuff intermixed in .$HOME/xsession-errors, but
since it is intermixed with all the other stuff that KDE has
launched in the background and it lacks timestamps, it isn't
very useful.

During some sharing failures,  I have seen freerdp libraries
echo some data like this:

[12:44:50:303] [2029:2763] [INFO][com.freerdp.core.gcc] - Active rdp encryption level: NONE [12:44:50:303] [2029:2763] [INFO][com.freerdp.core.gcc] - Selected rdp encryption method: NONE [12:45:31:838] [2029:2029] [INFO][com.freerdp.server.shadow.x11] - X11 Extensions: XFixes: 1 Xinerama: 1 XDamage: 0 XShm: 0 [12:45:31:843] [2029:2029] [INFO][com.freerdp.core.listener] - Listening on socket /run/user/1000/sipe/applicationsharing-2029-F5F4gD2BDaE4FBi7933m5B42t95EDb2502x377Bx. [12:45:34:342] [2029:2779] [INFO][com.freerdp.core.connection] - Client Security: NLA:0 TLS:0 RDP:1 [12:45:34:342] [2029:2779] [INFO][com.freerdp.core.connection] - Server Security: NLA:0 TLS:1 RDP:1 [12:45:34:342] [2029:2779] [INFO][com.freerdp.core.connection] - Negotiated Security: NLA:0 TLS:0 RDP:1 [12:45:34:342] [2029:2779] [INFO][com.freerdp.core.nego] - Turning off encryption for local peer with standard rdp security [12:45:35:726] [2029:2779] [INFO][com.freerdp.core.connection] - Accepted client: vera [12:45:35:726] [2029:2779] [INFO][com.freerdp.core.connection] - Accepted channels: [12:45:35:726] [2029:2779] [INFO][com.freerdp.core.connection] - cliprdr [12:45:35:726] [2029:2779] [INFO][com.freerdp.core.gcc] - Active rdp encryption level: NONE [12:45:35:726] [2029:2779] [INFO][com.freerdp.core.gcc] - Selected rdp encryption method: NONE [12:49:24:181] [2029:2029] [INFO][com.freerdp.server.shadow.x11] - X11 Extensions: XFixes: 1 Xinerama: 1 XDamage: 0 XShm: 0 [12:49:24:187] [2029:2029] [INFO][com.freerdp.core.listener] - Listening on socket /run/user/1000/sipe/applicationsharing-2029-C752gF4F7a92FFi733Fm28CBt7BBCbB45Cx3FFCx. [12:49:28:668] [2029:2897] [INFO][com.freerdp.core.connection] - Client Security: NLA:0 TLS:0 RDP:1 [12:49:28:668] [2029:2897] [INFO][com.freerdp.core.connection] - Server Security: NLA:0 TLS:1 RDP:1 [12:49:28:668] [2029:2[12:49:30:325] [2029:2897] [ERROR][com.freerdp.client.shadow] - Client from is activated (1680x1050@32) [12:49:49:494] [2029:2897] [ERROR][com.freerdp.client.shadow] - Failed to check FreeRDP file descriptor [13:40:17:507] [5606:5675] [ERROR][com.freerdp.client.shadow] - Client from is activated (1600x900@32) [13:40:54:263] [5606:5675] [ERROR][com.freerdp.client.shadow] - Failed to check FreeRDP file descriptor

That kind of information would be very useful to collect in
a place separate from .xsession-errors.

Also, what kind of conference is it? How many participants are there? Is there a single presenter during the whole meeting, or is the remote desktop view switching between multiple people? Are /you/ presenting at some point?

Usually the conferences are initiated by Windows 7 or 8 users using
Skype for Business (less so with the older Lync client).    The number
of participants can range from 5 to 10 or more.  Usuallly people are
sharing an entire desktop as they have found that the performance is
better than single application sharing.

[xhaakon]

@rbeldin

popups for that application will appear in random order on any of the screens, often under other windows. This can affect the order in which I accept them.

I don't want to rule the possibility out completely, but I think the order in which you connect has little to do with the UI issue. Although it's not apparent from the user prespective, internally, audio and application sharing are handled very independently of each other and use completely separate TCP/UDP connections.

Is there a provision in pidgin to direct logging to a specific file? Since I usually launch this from the KDE interface, there is sometimes some stuff intermixed in .$HOME/xsession-errors

There's no way in Pidgin I know about to redirect logging to a file. Anyway, unless you run the application with --debug argument, only the most critical messages get printed to stdout (and thus appear in $HOME/.xsession-errors when you run Pidgin from KDE).

If you don't want to run pidgin manually from the shell each time, on Ubuntu with pidgin-sipe package installed, /usr/bin/pidgin is a shell script (which in turn executes the actual binary pidgin.orig), so you can put the desired configuration there. For example in order to redirect the whole output to a file in /tmp, edit /usr/bin/pidgin like this:

/usr/bin/pidgin.orig --debug $* > /tmp/pidgin.log 2>&1

(You'll probably need to replace that script after every package upgrade though.)

[xhaakon]

Fix for this crash on assertion failure has been deployed in the PPA.

[rbeldin]

I modified the pidgin script and stuffed it in my $HOME/Scripts directory and created a new icon called pidgin-debug to do logging by date:

`#!/bin/bash

CONF=/etc/default/pidgin-sipe

if [[ -r $CONF ]] then . $CONF fi

/usr/bin/pidgin.orig --debug $* > "$HOME/.pidgin-debug-date -I'minutes'.log" 2>&1 `

This should help keep logging available and separate different invocations of pidgin.

[rbeldin]

Before I do anything else, I want to validate what I have. I just did an apt-get update and upgrade and now have the following components:

pidgin 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 pidgin-data 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 pidgin-dbg 1:3.0.0~collab-0.20600+201602220831~ubuntu15.10.1 pidgin-sipe 1.20.1+collab-201602241346+3171~ubuntu15.10.1 remmina 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 remmina-common 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 remmina-plugin-rdp 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1 remmina-plugin-vnc 1.1.2-sipe+855+next+201602231732~ubuntu15.10.1

Oddly, pidgin-sipe wasn't upgraded. So I asked apt to install:

apt-get install pidgin-sipe Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: freerdp2-shadow-x11 The following packages will be REMOVED: freerdp-shadow-x11 The following NEW packages will be installed: freerdp2-shadow-x11 The following packages will be upgraded: pidgin-sipe 1 upgraded, 1 newly installed, 1 to remove and 3 not upgraded. Need to get 336 kB of archives. After this operation, 1,024 B of additional disk space will be used. Do you want to continue? [Y/n] n Abort.

Are freerdp-shadow-x11 and freerdp2-shadow-x11 incompatible? Which one should I be pulling in?

[xhaakon]

I want to validate what I have

Those packages are at their latest versions, except pidgin-sipe, which should be at version 1.20.1+collab-201602251145+3174~ubuntu15.10.1 (whose separate update you have aborted afterwards). You can always check what the latest packages are by looking here.

Are freerdp-shadow-x11 and freerdp2-shadow-x11 incompatible?

Freerdp2 Debian packaging is still a work in progress and in the development shapshot I uploaded lately, its maintainer has decided to rename some packages. Thus, freerdp2-shadow-x11 replacing freerdp-shadow-x11 is correct and intended behavior. You may safely proceed with that upgrade.

Oddly, pidgin-sipe wasn't upgraded.

That's how apt-get upgrade behaves, though -- it never removes packages when installing from the repository (which was the case of the last pidgin-sipe update, mandating a package be uninstalled before new version could be put in place). You have to apt-get dist-upgrade or (as you have done, but aborted) apt-get install a specific package in order to perform the package-removing upgrades.

[rbeldin]

Some feedback. I had a crash yesterday when a colleague shared a 4k desktop with me. Updating pidgin* and friends made that go away but I noticed the following:

• I could not receive a shared desktop if remmina was already running - I would get a connection timeout from gstreamer
• if I terminated the running remmina, then I could get a desktop from the user

Totally unrelated was the effect that if the user shared an application, in this case the VNC window to another system, I would get the full 4k in black and the application rendered in approximately the same location as it was on his desktop. (See attached) I am guessing that this may be the way the RDP sharing works as I have heard of people with Lync/Skype for Business complain that application sharing was slower than a full desktop. My guess is that a mask is generated for the application or region of interest but the size of the full desktop is sent.

[rbeldin]

The desktop sharing seems to be much more usable after several weeks of operation. Thanks very much for this enhancement.

[xhaakon]

The desktop sharing seems to be much more usable after several weeks of operation.

@rbeldin That's good to hear. Since the feature requested at the very beginning of this thread has been implemented, I'm leaning towards closing it. If you think there are still some issues that need our attention, please open separate tickets for them so that we can track them in a sensible way.