From totaam at xpra.org Tue Jan 4 11:31:28 2022 From: totaam at xpra.org (Antoine Martin) Date: Tue, 4 Jan 2022 18:31:28 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.3.1 - minor bugs Message-ID: Hi, This release fixes a small number of minor bugs. There is no urgency to update if you were not affected by them. The more detailed release notes can be found here: https://github.com/Xpra-org/xpra/releases/tag/v4.3.1 Downloads: https://github.com/Xpra-org/xpra/wiki/Download Cheers Antoine From luca.manganelli at comune.trento.it Mon Jan 10 07:19:44 2022 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Mon, 10 Jan 2022 08:19:44 +0100 Subject: [winswitch] Force SSH "normal" password authentication Message-ID: Hello, it's possible to instruct XPRA to connect via SSH normal password authentication (and not with the password of the authorization keys)? -- Comune di Trento? via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221 tel. +39 0461.884111 | www.comune.trento.it ? From antoine at nagafix.co.uk Mon Jan 10 12:31:55 2022 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 10 Jan 2022 19:31:55 +0700 Subject: [winswitch] Force SSH "normal" password authentication In-Reply-To: References: Message-ID: On 10/01/2022 14:19, Luca Manganelli via shifter-users wrote: > Hello, > > it's possible to instruct XPRA to connect via SSH normal password > authentication (and not with the password of the authorization keys)? > If I understand what you're asking correctly, this should do the trick (and really needs documenting): xpra attach --ssh=paramiko:auth=password Other possible options are "none", "agent" and "key". ie: --ssh=paramiko:auth=agent+key,stricthostkeychecking=no Add "-d ssh" for debugging. Cheers, Antoine From tmesposito00 at gmail.com Mon Jan 17 23:10:03 2022 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Mon, 17 Jan 2022 18:10:03 -0500 Subject: [winswitch] automatic scaling for hidpi (4k) inconsistent Message-ID: I recently upgraded from a 1080p laptop to a 4k laptop. I use Windows 10 for my client and have windows "Scale and Layout" set to 200% for my 4K screen and 100% for the others. When I have my Windows desktop expanded on multiple non-4k screens (i.e. 1440p), xpra windows automatically scale to 200% when they are on the 4k laptop screen and switch to 100% on the non-4k screens. This is with xpra's built-in display scaling set to "None". However, when I am using ONLY the 4k laptop screen by itself, xpra windows aren't scaled, even though the windows display scaling is set to 200%. I need to manually set the xpra display scaling to 200% for everything to be readable. From antoine at nagafix.co.uk Mon Jan 24 14:38:49 2022 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 24 Jan 2022 21:38:49 +0700 Subject: [winswitch] automatic scaling for hidpi (4k) inconsistent In-Reply-To: References: Message-ID: <03aba7bd-2ac8-80cb-a4d7-b83a3de3e0bf@nagafix.co.uk> On 18/01/2022 06:10, Thomas Esposito via shifter-users wrote: > I recently upgraded from a 1080p laptop to a 4k laptop. I use Windows 10 > for my client and have windows "Scale and Layout" set to 200% for my 4K > screen and 100% for the others. When I have my Windows desktop expanded on > multiple non-4k screens (i.e. 1440p), xpra windows automatically scale to > 200% when they are on the 4k laptop screen and switch to 100% on the non-4k > screens. AFAIK, Win10 is doing that. > This is with xpra's built-in display scaling set to "None". > However, when I am using ONLY the 4k laptop screen by itself, xpra windows > aren't scaled, even though the windows display scaling is set to 200%. I > need to manually set the xpra display scaling to 200% for everything to be > readable. I'm not sure that we can reliably do much better in this case. Operating systems have a habit of doing things behind the scenes and lying about the real physical screen's dimensions and DPI. What you're doing is upscaling the output by 200%, ideally what you would do instead is tell the server side to increase the DPI and hopefully the applications would then do whatever is needed to display properly (increase font size, whatever). In practice, this doesn't work very well, especially when the applications are started before the client connects and configures the virtual screen. Perhaps we should give the user the choice of not trying to synchronize the DPI, and upscale instead. Can you please create a new gihub issue for this? https://github.com/Xpra-org/xpra/issues/new/choose Cheers, Antoine From luca.manganelli at comune.trento.it Tue Jan 25 08:51:34 2022 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Tue, 25 Jan 2022 09:51:34 +0100 Subject: [winswitch] Xpra html5 - bottom area Message-ID: Hello, if there are buttons on the bottom area of HTML5 viewer, they are not clickable. I can see them but I cannot have any interaction with them -- Comune di Trento? via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221 tel. +39 0461.884111 | www.comune.trento.it ? From totaam at xpra.org Thu Jan 27 13:17:38 2022 From: totaam at xpra.org (Antoine Martin) Date: Thu, 27 Jan 2022 20:17:38 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.3.2 - minor bugs Message-ID: <37e46953-f197-b16b-1100-83cd2b3e6ee6@xpra.org> Hi, This release fixes a few minor bugs. There is no urgency to update if you were not affected by them. The more detailed release notes can be found here: https://github.com/Xpra-org/xpra/releases/tag/v4.3.2 The client websocket protocol fix allows http proxies (ie: apache) to be used as "single port multiplexing proxies" for the python client and not just html5 clients. The vaapi ffmpeg hardware encoder is disabled again because too many server crashes are being reported with it enabled. Downloads: https://github.com/Xpra-org/xpra/wiki/Download Cheers Antoine From antoine at nagafix.co.uk Thu Jan 27 13:22:58 2022 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 27 Jan 2022 20:22:58 +0700 Subject: [winswitch] Xpra html5 - bottom area In-Reply-To: References: Message-ID: <251352c2-6f20-b43e-2fe9-09247e99e97b@nagafix.co.uk> On 25/01/2022 15:51, Luca Manganelli via shifter-users wrote: > Hello, > > if there are buttons on the bottom area of HTML5 viewer, they are not > clickable. I can see them but I cannot have any interaction with them > Without knowing what distro and version you are using, or what size of screen triggers this problem, it's difficult to provide a definitive answer. My best guess is that you may be using a distribution that uses an unpatched Xdummy driver. There is a bug in the dummy driver which can cause the symptoms you describe. If that's the case, switch to Xvfb or start your server with a much bigger initial resolution, ie: `xpra start --resize-display=4k` If that doesn't help, please create an issue following: https://github.com/Xpra-org/xpra/wiki/Reporting-Bugs Cheers, Antoine From luca.manganelli at comune.trento.it Thu Jan 27 13:29:00 2022 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Thu, 27 Jan 2022 14:29:00 +0100 Subject: [winswitch] Xpra html5 - bottom area In-Reply-To: <251352c2-6f20-b43e-2fe9-09247e99e97b@nagafix.co.uk> References: <251352c2-6f20-b43e-2fe9-09247e99e97b@nagafix.co.uk> Message-ID: Il giorno gio 27 gen 2022 alle ore 14:23 Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> ha scritto: > Without knowing what distro and version you are using, or what size of > screen triggers this problem, it's difficult to provide a definitive answer. Sorry. I'm using Fedora 35 and XPRA v4.3.1-r0 Screen size: 1920x1080 > My best guess is that you may be using a distribution that uses an > unpatched Xdummy driver. There is a bug in the dummy driver which can > cause the symptoms you describe. > If that's the case, switch to Xvfb or start your server with a much > bigger initial resolution, ie: `xpra start --resize-display=4k` Great! Last command solved my issue. -- Comune di Trento? via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221 tel. +39 0461.884111 | www.comune.trento.it ?