From esarmien at g.harvard.edu Wed Jul 17 01:28:38 2019 From: esarmien at g.harvard.edu (Evan Sarmiento) Date: Tue, 16 Jul 2019 20:28:38 -0400 Subject: [winswitch] HTML5 client encodings Message-ID: <75A34177-2579-46E9-ADE1-C19A59E95080@getmailspring.com> Hi, I installed xpra-x264 encoding package from the xpra repo but it appears that the HTML5 client is not using them. >From xpra info: client.window.1.encodings.non-video=('png', 'webp', 'rgb32', 'jpeg') Also connect.html only lists JPEG, PNG, Raw RGB. Am I missing something here? Best, Evan From antoine at nagafix.co.uk Wed Jul 17 04:08:12 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 17 Jul 2019 11:08:12 +0800 Subject: [winswitch] HTML5 client encodings In-Reply-To: <75A34177-2579-46E9-ADE1-C19A59E95080@getmailspring.com> References: <75A34177-2579-46E9-ADE1-C19A59E95080@getmailspring.com> Message-ID: <3775c9ab-2830-c0db-e6d5-29c34f8e42df@nagafix.co.uk> On 17/07/2019 02:28, Evan Sarmiento via shifter-users wrote: > Hi, > > I installed xpra-x264 encoding package from the xpra repo but it appears that the HTML5 client is not using them. You're not specifying which version or distribution you are using, but generally speaking there is no need to install extra packages, the x264 dependencies should be installed automatically with 'xpra'. > From xpra info: > client.window.1.encodings.non-video=('png', 'webp', 'rgb32', 'jpeg') That's telling you which encodings can be used for non-video areas. You should also see something like: client.window.1.encodings.video=('h264', 'mpeg1') Meaning that the server may use h264 or mpeg1 for sending video. When h264 is actually used, you should be able to see: client.window.1.encoder=x264 The full list of encodings supported by the server can be seen with: $ xpra info | grep "^encodings=" And for clients: xpra info | grep -E "^client.*encodings=" > Also connect.html only lists JPEG, PNG, Raw RGB. Am I missing something here? 'auto' will select the best encoding automatically, this is the best choice and this will use video encodings when needed. It may be slightly confusing but it doesn't really make sense to offer an 'h264' option here as this would end up doing what 'auto' does: for many screen updates, using h264 doesn't make sense. Cheers, Antoine > Best, > Evan > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From esarmien at g.harvard.edu Wed Jul 17 17:15:00 2019 From: esarmien at g.harvard.edu (Evan Sarmiento) Date: Wed, 17 Jul 2019 12:15:00 -0400 Subject: [winswitch] HTML5 websocket timeouts Message-ID: <367721D6-F671-45A5-998A-40947B4BF5A6@getmailspring.com> Hi, Is there a way to configure the HTML5 client to allow for socket timeouts of greater than it's default value? I am encountering sudden websocket disconnects every so often, which automatically reloads / reconnects - works fine. Is there some configurable value that would persist in attempting to maintain that connection on the client side? Thanks Evan From antoine at nagafix.co.uk Wed Jul 17 17:53:32 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 17 Jul 2019 23:53:32 +0700 Subject: [winswitch] HTML5 websocket timeouts In-Reply-To: <367721D6-F671-45A5-998A-40947B4BF5A6@getmailspring.com> References: <367721D6-F671-45A5-998A-40947B4BF5A6@getmailspring.com> Message-ID: On 17/07/2019 18:15, Evan Sarmiento via shifter-users wrote: > Hi, > > Is there a way to configure the HTML5 client to allow for socket timeouts of greater than it's default value? It depends which timeout is being triggered. What is the server log saying? You may want to enable the HTML5 client's "network" debug logging to get more details. > I am encountering sudden websocket disconnects every so often, which automatically reloads / reconnects - works fine. Is there some configurable value that would persist in attempting to maintain that connection on the client side? Assuming that the disconnection is from ping timeouts, you can try setting: XPRA_PING_TIMEOUT=300 xpra start .. But the default is already 60 (seconds), and if ping packets take over a minute to do the roundtrip, then re-connecting is a reasonable thing to do to try to recover. Cheers, Antoine > Thanks > Evan > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From perry at piermont.com Wed Jul 17 20:39:53 2019 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 17 Jul 2019 15:39:53 -0400 Subject: [winswitch] problems under Ubuntu Message-ID: <20190717153953.71eae6bc@jabberwock.cb.piermont.com> Under Ubuntu 19.04, "Disco Dingo", I get the following behavior and things kind of go south from there. (The messages appear to be logged to the terminal after the xpra session disconnects from the tty.) $ xpra start :100 --start=xterm $ 2019-07-17 15:35:13,128 Warning: failed to create script directory '/run/user/1000/xpra': 2019-07-17 15:35:13,128 [Errno 2] No such file or directory: '/run/user/1000/xpra' 2019-07-17 15:35:13,128 ($XDG_RUNTIME_DIR has not been created?) Any thoughts on how to debug this? I've seen mention of problems like this in the bug database but they seem long closed... -- Perry E. Metzger perry at piermont.com From antoine at nagafix.co.uk Thu Jul 18 09:32:16 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 18 Jul 2019 15:32:16 +0700 Subject: [winswitch] problems under Ubuntu In-Reply-To: <20190717153953.71eae6bc@jabberwock.cb.piermont.com> References: <20190717153953.71eae6bc@jabberwock.cb.piermont.com> Message-ID: <279186e3-d0a1-63d2-8973-8a8cc416ea1d@nagafix.co.uk> On 17/07/2019 21:39, Perry E. Metzger via shifter-users wrote: > Under Ubuntu 19.04, "Disco Dingo", I get the following behavior and > things kind of go south from there. (The messages appear to be > logged to the terminal after the xpra session disconnects from the > tty.) > > $ xpra start :100 --start=xterm > $ 2019-07-17 15:35:13,128 Warning: failed to create > script directory '/run/user/1000/xpra': 2019-07-17 15:35:13,128 > [Errno 2] No such file or directory: '/run/user/1000/xpra' 2019-07-17 > 15:35:13,128 ($XDG_RUNTIME_DIR has not been created?) > > Any thoughts on how to debug this? I've seen mention of problems like > this in the bug database but they seem long closed... Many modern desktop applications rely on the XDG_RUNTIME_DIR directory, xpra does since before v1.0. This directory is normally created when you login. Terminal logins, ssh logins and display manager logins should all be creating this directory for you. My guess is that you're not logging in normally but faking the login using something like 'su'. Possible solutions: * use a login system that creates the required directory instead of su * start xpra via its system-wide proxy: "--start-via-proxy=yes" (the system wide proxy runs as root and takes care of creating proper login sessions and the required directories) * don't use XDG_RUNTIME_DIR at all: the run-xpra script is not a huge problem (it is rarely used - you can ignore that warning) but you will need to put your server sockets somewhere else too, either by adding "--socket-dirs=/tmp" to all your xpra commands or by making this change permanent with: "echo socket-dirs=/tmp > /etc/xpra/conf.d/90_override_socket_dirs.conf". (as root) * or more simply, just add your users to the "xpra" group and the sockets will be created in "/run/xpra" - this is the most expedient solution. Cheers, Antoine From kaefert at gmail.com Thu Jul 18 09:38:03 2019 From: kaefert at gmail.com (=?UTF-8?Q?Thomas_K=C3=A4fer?=) Date: Thu, 18 Jul 2019 10:38:03 +0200 Subject: [winswitch] eclipse via xpra problem Message-ID: Hi there! I've been trying to use eclipse via xpra and found that the editor area is often overlayed with a flashing gray box, in between for a few tens of a seconds I can sometimes see the real content. This behavior makes the setup unusable sadly. Can somebody help me debug this? Client is xpra v2.5.1-r22432 Server is xpra v2.5.1-r22431 Thanks, Kind regards Thomas K?fer From antoine at nagafix.co.uk Thu Jul 18 09:50:45 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 18 Jul 2019 15:50:45 +0700 Subject: [winswitch] eclipse via xpra problem In-Reply-To: References: Message-ID: <4c4ca839-8106-7b81-1383-d86d86883bfd@nagafix.co.uk> On 18/07/2019 10:38, Thomas K?fer via shifter-users wrote: > Hi there! > > I've been trying to use eclipse via xpra and found that the editor area is > often overlayed with a flashing gray box, in between for a few tens of a > seconds I can sometimes see the real content. This behavior makes the setup > unusable sadly. > Can somebody help me debug this? This sounds like a very debilitating bug. I'm not seeing any problems here with Fedora. Can you please provide more details as per: https://xpra.org/trac/wiki/ReportingBugs And ideally file a ticket for this bug. > Client is xpra v2.5.1-r22432 > Server is xpra v2.5.1-r22431 Try updating to the latest version. Cheers, Antoine > > Thanks, > Kind regards > Thomas K?fer > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From perry at piermont.com Thu Jul 18 16:18:50 2019 From: perry at piermont.com (Perry E. Metzger) Date: Thu, 18 Jul 2019 11:18:50 -0400 Subject: [winswitch] problems under Ubuntu In-Reply-To: <279186e3-d0a1-63d2-8973-8a8cc416ea1d@nagafix.co.uk> References: <20190717153953.71eae6bc@jabberwock.cb.piermont.com> <279186e3-d0a1-63d2-8973-8a8cc416ea1d@nagafix.co.uk> Message-ID: <20190718111850.271bcce8@jabberwock.cb.piermont.com> On Thu, 18 Jul 2019 15:32:16 +0700 Antoine Martin via shifter-users wrote: > On 17/07/2019 21:39, Perry E. Metzger via shifter-users wrote: > > Under Ubuntu 19.04, "Disco Dingo", I get the following behavior > > and things kind of go south from there. (The messages appear to be > > logged to the terminal after the xpra session disconnects from the > > tty.) > > > > $ xpra start :100 --start=xterm > > $ 2019-07-17 15:35:13,128 Warning: failed to create > > script directory '/run/user/1000/xpra': 2019-07-17 15:35:13,128 > > [Errno 2] No such file or directory: '/run/user/1000/xpra' > > 2019-07-17 15:35:13,128 ($XDG_RUNTIME_DIR has not been created?) > > > > Any thoughts on how to debug this? I've seen mention of problems > > like this in the bug database but they seem long closed... > Many modern desktop applications rely on the XDG_RUNTIME_DIR > directory, xpra does since before v1.0. > > This directory is normally created when you login. Terminal logins, > ssh logins and display manager logins should all be creating this > directory for you. > My guess is that you're not logging in normally but faking the login > using something like 'su'. No, I'm just logging in using ssh. It's a stock Ubuntu 19.04 machine, too. Any ideas why it might not be creating the directory? Or at least how to figure out what might be going wrong? Perry -- Perry E. Metzger perry at piermont.com From perry at piermont.com Thu Jul 18 18:52:05 2019 From: perry at piermont.com (Perry E. Metzger) Date: Thu, 18 Jul 2019 13:52:05 -0400 Subject: [winswitch] problems under Ubuntu In-Reply-To: <279186e3-d0a1-63d2-8973-8a8cc416ea1d@nagafix.co.uk> References: <20190717153953.71eae6bc@jabberwock.cb.piermont.com> <279186e3-d0a1-63d2-8973-8a8cc416ea1d@nagafix.co.uk> Message-ID: <20190718135205.6cad6481@jabberwock.cb.piermont.com> On Thu, 18 Jul 2019 15:32:16 +0700 Antoine Martin via shifter-users wrote: > On 17/07/2019 21:39, Perry E. Metzger via shifter-users wrote: > > Under Ubuntu 19.04, "Disco Dingo", I get the following behavior > > and things kind of go south from there. (The messages appear to be > > logged to the terminal after the xpra session disconnects from the > > tty.) > > > > $ xpra start :100 --start=xterm > > $ 2019-07-17 15:35:13,128 Warning: failed to create > > script directory '/run/user/1000/xpra': 2019-07-17 15:35:13,128 > > [Errno 2] No such file or directory: '/run/user/1000/xpra' > > 2019-07-17 15:35:13,128 ($XDG_RUNTIME_DIR has not been created?) > > > > Any thoughts on how to debug this? I've seen mention of problems > > like this in the bug database but they seem long closed... > Many modern desktop applications rely on the XDG_RUNTIME_DIR > directory, xpra does since before v1.0. > > This directory is normally created when you login. Terminal logins, > ssh logins and display manager logins should all be creating this > directory for you. > My guess is that you're not logging in normally but faking the login > using something like 'su'. I'm using ssh to log in; the problem turned out to be with the three-way interaction of sshd, pam, and systemd. (The complexity of even login in modern Linux has gotten out of control.) Anyway, I figured it out. Thanks for the hint that it had something to do with behavior at login, that helped. Perry -- Perry E. Metzger perry at piermont.com From kaefert at gmail.com Fri Jul 19 09:26:53 2019 From: kaefert at gmail.com (=?UTF-8?Q?Thomas_K=C3=A4fer?=) Date: Fri, 19 Jul 2019 10:26:53 +0200 Subject: [winswitch] eclipse via xpra problem In-Reply-To: <4c4ca839-8106-7b81-1383-d86d86883bfd@nagafix.co.uk> References: <4c4ca839-8106-7b81-1383-d86d86883bfd@nagafix.co.uk> Message-ID: Hi there! thanks for your reply! Sorry for not having provided more details in my first mail. I've upgraded my client to the latest version = the AUR package xpra-svn which now gives this version info: xpra v3.0-runknownM This sadly brought no improvement. I can't update the server right now, maybe I will do so next Tuesday when I'm at the machine. The client is an Manjaro KDE installation, the server's OS is Linux Mint 19.1 I didn't change anything about xpra's config. I'm starting xpra sessions using xpra start --ssh="ssh -x" ssh:[SERVER-IP] --start=gnome-terminal detach them using the GUI behind the notification-icon and reattach them using xpra attach --ssh="ssh -x" ssh:[SERVER-IP] The server has 3 physical screens, though I don't believe this should matter when not using xpra to get access to the desktop but only applications. xpra info on the server gives: https://pastebin.com/nivgJ4DK Disconnecting & re-connecting doesn't change the issue. The issue is quite easy reproducible for me, happens nearly immediatly once I start eclipse. Kind regards, Thomas K?fer Am Do., 18. Juli 2019 um 10:50 Uhr schrieb Antoine Martin via shifter-users : > On 18/07/2019 10:38, Thomas K?fer via shifter-users wrote: > > Hi there! > > > > I've been trying to use eclipse via xpra and found that the editor area > is > > often overlayed with a flashing gray box, in between for a few tens of a > > seconds I can sometimes see the real content. This behavior makes the > setup > > unusable sadly. > > Can somebody help me debug this? > This sounds like a very debilitating bug. I'm not seeing any problems > here with Fedora. > Can you please provide more details as per: > https://xpra.org/trac/wiki/ReportingBugs > And ideally file a ticket for this bug. > > > Client is xpra v2.5.1-r22432 > > Server is xpra v2.5.1-r22431 > Try updating to the latest version. > > Cheers, > Antoine > > > > > Thanks, > > Kind regards > > Thomas K?fer > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Fri Jul 19 10:15:08 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 19 Jul 2019 16:15:08 +0700 Subject: [winswitch] eclipse via xpra problem In-Reply-To: References: <4c4ca839-8106-7b81-1383-d86d86883bfd@nagafix.co.uk> Message-ID: On 19/07/2019 15:26, Thomas K?fer via shifter-users wrote: > Hi there! > > thanks for your reply! Sorry for not having provided more details in my > first mail. > I've upgraded my client to the latest version = the AUR package xpra-svn > which now gives this version info: > xpra v3.0-runknownM Looks like the AUR package build is incorrect, it should be showing the revision number above and not "runknownM". > This sadly brought no improvement. Updating the server might help. (the client code is relatively simpler and somewhat less bug prone) > I can't update the server right now, maybe I will do so next Tuesday when > I'm at the machine. > The client is an Manjaro KDE installation, the server's OS is Linux Mint > 19.1 (..) > The issue is quite easy reproducible for me, happens nearly immediatly once > I start eclipse. Can you reproduce this bug using a supported distribution? See: https://xpra.org/trac/wiki/Platforms I've tried it on Ubuntu 19.04 and to be able to get it to run at all I've had to set: GTK_IM_MODULE=ibus eclipse& (looks like they've left "xim" input completely broken) Maybe that will help? Apart from that, I can use eclipse locally without problems. Tested on both: Ubuntu 19.04 and Fedora 30.. Cheers, Antoine From me.xpra at cgf.cx Mon Jul 22 07:19:58 2019 From: me.xpra at cgf.cx (Christopher Faylor) Date: Mon, 22 Jul 2019 02:19:58 -0400 Subject: [winswitch] Using xpra with steam and amd64gpu on linux Message-ID: <20190722061958.GA15477@ednor.casa.cgf.cx> I recently had an off-the wall idea to use xpra with steam on my local machine to achieve some degree of isolation from my normal X-Server. I'd like my game (a windows game which works great under steam) to be able to work in another workspace without interfering with my normal work. Running steam in another workspace somewhat works but there is bleedover with mouse events sometimes. My mouse cursor gets changed and moved randomly, which is pretty annoying. xpra works really well with virtualgl so I was hoping that I could run the game using that to get acceptable levels of performance but, while demo things like "/usr/bin/glxsphere" work amazingly well, steam fails to run anything due to this error: vulkan: No DRI3 support detected - required for presentation Note: you can probably enable DRI3 in your Xorg config vulkan: No DRI3 support detected - required for presentation Note: you can probably enable DRI3 in your Xorg config Could not find both graphics and present queues I've tried running xpra with a dummy driver via: xpra start :100 --xvfb='Xorg -noreset +extension DRI3 +extension GLX +extension RANDR +extension RENDER -config xdummy.conf' (xdummy.conf uses the dummy driver). but that didn't help and I didn't really expect it to. I don't think I'm going to be able to get beyond the DRI3 hurdle but I thought I'd ask just in case there is a trick that would get this working. cgf From antoine at nagafix.co.uk Mon Jul 22 10:55:18 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 22 Jul 2019 16:55:18 +0700 Subject: [winswitch] Using xpra with steam and amd64gpu on linux In-Reply-To: <20190722061958.GA15477@ednor.casa.cgf.cx> References: <20190722061958.GA15477@ednor.casa.cgf.cx> Message-ID: <8cf58ee1-e870-8a71-c0dd-166ed77ebd9a@nagafix.co.uk> On 22/07/2019 13:19, Christopher Faylor via shifter-users wrote: > I recently had an off-the wall idea to use xpra with steam on my local > machine to achieve some degree of isolation from my normal X-Server. > I'd like my game (a windows game which works great under steam) to be > able to work in another workspace without interfering with my normal work. > Running steam in another workspace somewhat works but there is bleedover > with mouse events sometimes. My mouse cursor gets changed and moved > randomly, which is pretty annoying. > > xpra works really well with virtualgl so I was hoping that I could run > the game using that to get acceptable levels of performance but, while > demo things like "/usr/bin/glxsphere" work amazingly well, steam fails > to run anything due to this error: > > vulkan: No DRI3 support detected - required for presentation > Note: you can probably enable DRI3 in your Xorg config > vulkan: No DRI3 support detected - required for presentation > Note: you can probably enable DRI3 in your Xorg config > Could not find both graphics and present queues > > I've tried running xpra with a dummy driver via: > > xpra start :100 --xvfb='Xorg -noreset +extension DRI3 +extension GLX +extension RANDR +extension RENDER -config xdummy.conf' > > (xdummy.conf uses the dummy driver). > > but that didn't help and I didn't really expect it to. > > I don't think I'm going to be able to get beyond the DRI3 hurdle but I > thought I'd ask just in case there is a trick that would get this > working. It may be worth asking this question on the Xorg or Steam mailing lists. They are more likely to know what API steam expects and what virtual framebuffers like Xvfb or Xdummy are able to provide. VirtualGL works great for OpenGL acceleration, but if you're game requires Vulkan then you're probably out of luck as it does not seem possible to write a VirtualVulkan equivallent at this point: https://github.com/VirtualGL/virtualgl/issues/37 Even if you did get past this hurdle, there are other challenges for running games: * input devices: latency issues, support for devices beyond just mouse and keyboard * grabs and screen resizing etc Not impossible, but certainly challenging. Cheers, Antoine > > cgf From me.xpra at cgf.cx Mon Jul 22 19:11:32 2019 From: me.xpra at cgf.cx (Christopher Faylor) Date: Mon, 22 Jul 2019 14:11:32 -0400 Subject: [winswitch] Using xpra with steam and amd64gpu on linux In-Reply-To: <8cf58ee1-e870-8a71-c0dd-166ed77ebd9a@nagafix.co.uk> References: <20190722061958.GA15477@ednor.casa.cgf.cx> <8cf58ee1-e870-8a71-c0dd-166ed77ebd9a@nagafix.co.uk> Message-ID: <20190722181132.GA2494@ednor.casa.cgf.cx> On Mon, Jul 22, 2019 at 04:55:18PM +0700, Antoine Martin via shifter-users wrote: >On 22/07/2019 13:19, Christopher Faylor via shifter-users wrote: >> I recently had an off-the wall idea to use xpra with steam on my local >> machine to achieve some degree of isolation from my normal X-Server. >> I'd like my game (a windows game which works great under steam) to be >> able to work in another workspace without interfering with my normal work. >> Running steam in another workspace somewhat works but there is bleedover >> with mouse events sometimes. My mouse cursor gets changed and moved >> randomly, which is pretty annoying. >> >> xpra works really well with virtualgl so I was hoping that I could run >> the game using that to get acceptable levels of performance but, while >> demo things like "/usr/bin/glxsphere" work amazingly well, steam fails >> to run anything due to this error: >> >> vulkan: No DRI3 support detected - required for presentation >> Note: you can probably enable DRI3 in your Xorg config >> vulkan: No DRI3 support detected - required for presentation >> Note: you can probably enable DRI3 in your Xorg config >> Could not find both graphics and present queues >> >> I've tried running xpra with a dummy driver via: >> >> xpra start :100 --xvfb='Xorg -noreset +extension DRI3 +extension GLX +extension RANDR +extension RENDER -config xdummy.conf' >> >> (xdummy.conf uses the dummy driver). >> >> but that didn't help and I didn't really expect it to. >> >> I don't think I'm going to be able to get beyond the DRI3 hurdle but I >> thought I'd ask just in case there is a trick that would get this >> working. >It may be worth asking this question on the Xorg or Steam mailing lists. >They are more likely to know what API steam expects and what virtual >framebuffers like Xvfb or Xdummy are able to provide. Thanks. I'm not sure it's worth the effort though. >VirtualGL works great for OpenGL acceleration, but if you're game >requires Vulkan then you're probably out of luck as it does not seem >possible to write a VirtualVulkan equivallent at this point: >https://github.com/VirtualGL/virtualgl/issues/37 Thanks again! I missed this in my many hours of googling. >Even if you did get past this hurdle, there are other challenges for >running games: >* input devices: latency issues, support for devices beyond just mouse >and keyboard >* grabs and screen resizing >etc I don't *think* that this would be an issue for my particular use case since I'm not going to be actually actively playing the game. I won't bore you with details about what I need this for though. :-) Thanks for the, as always, timely insight. cgf From antoine at nagafix.co.uk Tue Jul 23 17:45:19 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 23 Jul 2019 23:45:19 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.5.3: many fixes, none critical Message-ID: <20329382-9b87-7262-91ac-a1f14ccb7466@nagafix.co.uk> Hi, Just like the previous update, this is a collection of fixes that had accumulated, updating is recommended but none of the bugs are critical. The main areas with fixes this time around are: HTML5 client, socket layer (ssl, websockets, delays, mdns, warnings, etc), clipboard, shadow servers, python3 compatibility fixes, a smattering of X11 issues, and some more cosmetic or packaging issues. The "ping latency" bug could explain some of the latency spiraling out of control that had been reported in the past, but the 2.5.x already included enough counter measures to mitigate the symptoms. Hopefully, this should be the last release from the 2.5.x branch before the 3.0 LTS release. Full release notes: * fix HTML5 MSIE 11 detection * fix HTML5 path of audio script for IE * fix HTML5 CapsLock and NumLock state detection * fix HTML5 desktop server screen size not resizing to match window * fix shadow servers display resizing not being propagated * fix scroll encoding with multi monitor shadow servers * fix handling of uncompressed window icon pixel data * fix handling of unicode values for desktop names * fix remote ssh failures with python3-only installations * fix '_monitor' subcommand with python3 clients * fix client ping latency calculations * fix non-strict ssl host key not honoured with wss connections * fix handling of websocket and ssl traffic with unix-domain sockets * fix ssl and websocket connection upgrades with python3 servers * fix handling of websocket ping packets * fix unnecessary delay in initial connection handling * fix incorrect disconnections with non-UI clients * fix spurious socket warnings * fix distro information shown for proxied connections * fix invalid mdns records for rfb connections (desktop and shadow) * fix GTK3 signal handling before the main loop is running * fix file descriptor leak when running child commands * fix clipboard-direction setting not propagated to the client * fix clipboard datatype shortcut not taken due to a typo * fix clipboard bugs with python3 builds, invalid atoms * fix overzealous cleanup code in X11 root property handler * fix Xresources debug logging and error handler * fix errors during cleanup: close display later * fix uinput device mode with python3 servers * fix errors if md5 is not available: use sha1 * fix default build options for RedHat * fix typos in man page and docstrings * silence annoying atk warnings * avoid running invalid lpinfo commands * improve compatibility with 'xpra top' * make it possible to skip opengl probing during server startup * add missing modal-window entry in man page * reduce weak RPM dependencies on gnome components The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From kaefert at gmail.com Tue Jul 23 18:05:01 2019 From: kaefert at gmail.com (=?UTF-8?Q?Thomas_K=C3=A4fer?=) Date: Tue, 23 Jul 2019 19:05:01 +0200 Subject: [winswitch] eclipse via xpra problem In-Reply-To: References: <4c4ca839-8106-7b81-1383-d86d86883bfd@nagafix.co.uk> Message-ID: Hi there Antoine! I've managed to upgrade my xpra server to v2.5.2-r22875 However, that didn't solve the problem. Your other hint, starting eclipse like that: GTK_IM_MODULE=ibus eclipse worked wonders. No more gray box overlaying my text editors inside eclipse! thank you!!! Kind regards Thomas K?fer Am Fr., 19. Juli 2019 um 11:15 Uhr schrieb Antoine Martin via shifter-users : > On 19/07/2019 15:26, Thomas K?fer via shifter-users wrote: > > Hi there! > > > > thanks for your reply! Sorry for not having provided more details in my > > first mail. > > I've upgraded my client to the latest version = the AUR package xpra-svn > > which now gives this version info: > > xpra v3.0-runknownM > Looks like the AUR package build is incorrect, it should be showing the > revision number above and not "runknownM". > > > This sadly brought no improvement. > Updating the server might help. (the client code is relatively simpler > and somewhat less bug prone) > > > I can't update the server right now, maybe I will do so next Tuesday when > > I'm at the machine. > > The client is an Manjaro KDE installation, the server's OS is Linux Mint > > 19.1 > (..) > > The issue is quite easy reproducible for me, happens nearly immediatly > once > > I start eclipse. > Can you reproduce this bug using a supported distribution? See: > https://xpra.org/trac/wiki/Platforms > > I've tried it on Ubuntu 19.04 and to be able to get it to run at all > I've had to set: > GTK_IM_MODULE=ibus eclipse& > (looks like they've left "xim" input completely broken) > Maybe that will help? > > Apart from that, I can use eclipse locally without problems. > Tested on both: Ubuntu 19.04 and Fedora 30.. > > Cheers, > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Tue Jul 23 18:40:44 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 24 Jul 2019 00:40:44 +0700 Subject: [winswitch] eclipse via xpra problem In-Reply-To: References: <4c4ca839-8106-7b81-1383-d86d86883bfd@nagafix.co.uk> Message-ID: <71f53ac1-c89d-8c7d-1b85-f0aad66f9511@nagafix.co.uk> On 24/07/2019 00:05, Thomas K?fer wrote: > Hi there Antoine! > > I've managed to upgrade my xpra server to v2.5.2-r22875 > However, that didn't solve the problem. > > Your other hint, starting eclipse like that: > GTK_IM_MODULE=ibus eclipse > worked wonders. No more gray box overlaying my text editors inside > eclipse! thank you!!! Glad to hear that. We may try to change the default to IBus for the next release: http://xpra.org/trac/ticket/2359#comment:1 This is going to require quite a bit of testing to validate the change, your feedback helps. Do you have an ibus-daemon running? Does it belong to another session perhaps? If that's the case, terminating the other session may kill the ibus-daemon and that may crash eclipse in your xpra session.. or just break keyboard input. Cheers, Antoine From wolfram.humann at gmail.com Wed Jul 31 14:41:23 2019 From: wolfram.humann at gmail.com (Wolfram Humann) Date: Wed, 31 Jul 2019 15:41:23 +0200 Subject: [winswitch] Downgrading xpra Message-ID: I've been using xpra 1.0.x before on an older workstation and 2.5.3 on the current workstation. My impression is that the old version was running smoother and had less network problems. That may be true or not!! I just wanted to try it out. So I yum remove-ed the current version and some dependencies and tried sudo yum install xpra-1.0.13 and got Loaded plugins: langpacks, search-disabled-repos RHEL7-ATE_Workstation_tools | 1.5 kB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package xpra.x86_64 0:1.0.13-1.r21370.el7_6 will be installed --> Processing Dependency: xpra-common = 1.0.13-1.r21370.el7_6 for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: python2-xxhash for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libvpx-xpra for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libswscale.so.5(LIBSWSCALE_5)(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libavutil.so.56(LIBAVUTIL_56)(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libavcodec.so.58(LIBAVCODEC_58)(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: ffmpeg-xpra for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libvpx.so.5()(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libswscale.so.5()(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libavutil.so.56()(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libavformat.so.58()(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Processing Dependency: libavcodec.so.58()(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 --> Running transaction check ---> Package ffmpeg-xpra.x86_64 0:4.1.1-1.el7_6 will be installed ---> Package libvpx-xpra.x86_64 0:1.8.0-1.el7_6 will be installed ---> Package python2-xxhash.x86_64 0:1.3.0-1.el7_6 will be installed ---> Package xpra.x86_64 0:1.0.13-1.r21370.el7_6 will be installed --> Processing Dependency: libvpx.so.5()(64bit) for package: xpra-1.0.13-1.r21370.el7_6.x86_64 ---> Package xpra-common.noarch 0:1.0.13-1.r21370.el7_6 will be installed --> Finished Dependency Resolution Error: Package: xpra-1.0.13-1.r21370.el7_6.x86_64 (winswitch) Requires: libvpx.so.5()(64bit) Available: libvpx-xpra-1.7.0-1.el7_5.x86_64 (winswitch) libvpx.so.5()(64bit) Available: libvpx-xpra-1.7.0-1.el7_6.x86_64 (winswitch) libvpx.so.5()(64bit) Installing: libvpx-xpra-1.8.0-1.el7_6.x86_64 (winswitch) ~libvpx.so.6()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest What can I do? Best regards Wolfram