From antoine at nagafix.co.uk Fri Nov 1 02:25:08 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 1 Nov 2019 09:25:08 +0700 Subject: [winswitch] Running XPRA with headless GPU in docker container displaying via HTML5 client In-Reply-To: <45db4213-2e53-2b08-d74a-3c4d7f3174a9@nagafix.co.uk> References: <45db4213-2e53-2b08-d74a-3c4d7f3174a9@nagafix.co.uk> Message-ID: (..) >> But it seems that for all examples I found an X-Server in the Docker host >> is used (like in the example above). > AFAIAA, that's currently unavoidable. https://github.com/VirtualGL/virtualgl/issues/10 Antoine From totaam at xpra.org Tue Nov 5 17:32:14 2019 From: totaam at xpra.org (Antoine Martin) Date: Wed, 6 Nov 2019 00:32:14 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.2: important fixes Message-ID: <950666df-4245-23d0-b55d-e811561daf56@xpra.org> Hi, This update fixes some serious bugs, in particular: * the OpenGL paint issues completely broke window rendering on some platforms. * the faac and faad2 codec updates fix a large number of bugs, some of which may be remotely exploitable. * clipboard issues * screen updates getting lost Updating is strongly recommended. Release notes: *? fix clipboard synchronization issue with MS Windows clients (properly this time) *? fix Pillow 6.x compatibility with MS Windows packaging *? fix null bytes in X11 error text (properly this time..) *? fix Python 3 servers wrongly re-sending the 'screen' attribute *? fix remote logging failures with some message formats *? fix lost screen updates *? fix GTK scaling causing window geometry issues *? fix HTML5 clipboard data sent from polling events *? fix CUDA device logging with multiple devices *? fix 32-bit build errors on xxhash *? fix RPM jpeg and libyuv dependencies *? fix OpenGL window not refreshing with Python 3 *? fix OpenGL context held for too long *? fix SSH connection errors when 'port' is specified in the ssh config *? fix faac and faad2 security issues in MS Windows and MacOS builds *? fix window size hints misapplied with GTK3 on MS Windows and Wayland *? disable OpenGL acceleration on old Intel chipsets *? disable OpenGL acceleration with GTK3 builds on MS Windows (for now, pending bug) *? show python interpreter version on about dialog *? re-instate ancient popup window workaround (was disabled by mistake) *? don't use av-synchronization for text and picture content types *? workaround Fedora packaging causing gratuitous conflicts The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From wssddc at wssddc.com Wed Nov 6 07:03:50 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Wed, 6 Nov 2019 02:03:50 -0500 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.2: important fixes In-Reply-To: <950666df-4245-23d0-b55d-e811561daf56@xpra.org> References: <950666df-4245-23d0-b55d-e811561daf56@xpra.org> Message-ID: I have a strange problem with 3.0.2: on Fedora 31 I've got an RDP (remote desktop) session in remmina displaying on Windows 7.? I can't send control characters to RDP.? If I run the RDP on-screen keyboard, Alt lights up if I hit that key, but control does not. Going back to 3.0.1 on the Windows side, it works.? The strange part is that control does work in the xterm used to launch remmina. From wolfram.humann at gmail.com Wed Nov 6 10:11:38 2019 From: wolfram.humann at gmail.com (Wolfram Humann) Date: Wed, 6 Nov 2019 11:11:38 +0100 Subject: [winswitch] 3.0.2-r24387 still not usable Message-ID: Just a quick note that for me Windows client 3.0.2-r24387 is still not usable. Window icons in the top left and top right corner are still missing. Some windows are clipped at the bottom so that buttons like Ok/Cancel are not accessible (I can send a screenshot if that helps). Some windows start "dancing" off the screen to the bottom after being moved (but they don't change size anymore). From antoine at devloop.org.uk Wed Nov 6 10:23:39 2019 From: antoine at devloop.org.uk (Antoine Martin) Date: Wed, 6 Nov 2019 17:23:39 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.2: important fixes In-Reply-To: References: <950666df-4245-23d0-b55d-e811561daf56@xpra.org> Message-ID: On 06/11/2019 14:03, Bob Babcock via shifter-users wrote: > I have a strange problem with 3.0.2: on Fedora 31 I've got an RDP > (remote desktop) session in remmina displaying on Windows 7.? I can't > send control characters to RDP.? If I run the RDP on-screen keyboard, > Alt lights up if I hit that key, but control does not. Going back to > 3.0.1 on the Windows side, it works.? The strange part is that control > does work in the xterm used to launch remmina. AltGr and Control are a bit messed up on MS Windows, we have workarounds especially for these keys. Maybe it is now interfering with something. Do you know of any other applications that shows this problem? I would rather try to reproduce with something simple, not something that requires a remote computer and a network connection. You can also try to launch the command "xpra keyboard-test" from within the xpra session to see what key events are being received. Cheers, Antoine From antoine at nagafix.co.uk Wed Nov 6 10:29:15 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 6 Nov 2019 17:29:15 +0700 Subject: [winswitch] 3.0.2-r24387 still not usable In-Reply-To: References: Message-ID: <1ba75928-315d-2f87-7923-6309dbf42a8a@nagafix.co.uk> On 06/11/2019 17:11, Wolfram Humann via shifter-users wrote: > Just a quick note that for me Windows client 3.0.2-r24387 is still not > usable. Window icons in the top left and top right corner are still > missing. Are you talking about window action buttons in the title bar? Like minimize, maximize, etc? > Some windows are clipped at the bottom so that buttons like > Ok/Cancel are not accessible (I can send a screenshot if that helps). Can you please create a ticket and attach it there? I am not seeing this with any of the applications I have tested with. > Some > windows start "dancing" off the screen to the bottom after being moved (but > they don't change size anymore). That sounds related to but different from: https://xpra.org/trac/ticket/2457 Do you have a specific application I can use to reproduce the problem? All those problems are likely related to the move to GTK3, which is really not a smooth process. You may have better luck with the legacy "Python2" builds also found in the download directory: https://xpra.org/dists/windows/ Cheers, Antoine From wssddc at wssddc.com Thu Nov 7 07:45:36 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Thu, 7 Nov 2019 02:45:36 -0500 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.2: important fixes In-Reply-To: References: <950666df-4245-23d0-b55d-e811561daf56@xpra.org> Message-ID: Antoine Martin via shifter-users wrote: > On 06/11/2019 14:03, Bob Babcock via shifter-users wrote: >> I have a strange problem with 3.0.2: on Fedora 31 I've got an RDP >> (remote desktop) session in remmina displaying on Windows 7.? I can't >> send control characters to RDP.? If I run the RDP on-screen keyboard, >> Alt lights up if I hit that key, but control does not. Going back to >> 3.0.1 on the Windows side, it works.? The strange part is that control >> does work in the xterm used to launch remmina. > AltGr and Control are a bit messed up on MS Windows, we have workarounds > especially for these keys. Maybe it is now interfering with something. > Do you know of any other applications that shows this problem? > I would rather try to reproduce with something simple, not something > that requires a remote computer and a network connection. > You can also try to launch the command "xpra keyboard-test" from within > the xpra session to see what key events are being received. Running keyboard-test I see right control up/down events, but nothing for left control.? Back in remote desktop, I got left control to sometimes work, but not? right control.? Keyboard-test doesn't see left control with 3.0.1 either. From antoine at nagafix.co.uk Thu Nov 7 16:21:06 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 7 Nov 2019 23:21:06 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.2: important fixes In-Reply-To: References: <950666df-4245-23d0-b55d-e811561daf56@xpra.org> Message-ID: <3d488bf1-aa01-10b7-1868-57891a100729@nagafix.co.uk> On 07/11/2019 14:45, Bob Babcock via shifter-users wrote: > Antoine Martin via shifter-users wrote: >> On 06/11/2019 14:03, Bob Babcock via shifter-users wrote: >>> I have a strange problem with 3.0.2: on Fedora 31 I've got an RDP >>> (remote desktop) session in remmina displaying on Windows 7.? I can't >>> send control characters to RDP.? If I run the RDP on-screen keyboard, >>> Alt lights up if I hit that key, but control does not. Going back to >>> 3.0.1 on the Windows side, it works.? The strange part is that control >>> does work in the xterm used to launch remmina. >> AltGr and Control are a bit messed up on MS Windows, we have workarounds >> especially for these keys. Maybe it is now interfering with something. >> Do you know of any other applications that shows this problem? >> I would rather try to reproduce with something simple, not something >> that requires a remote computer and a network connection. >> You can also try to launch the command "xpra keyboard-test" from within >> the xpra session to see what key events are being received. > > Running keyboard-test I see right control up/down events, but nothing > for left control.? Back in remote desktop, I got left control to > sometimes work, but not? right control.? Keyboard-test doesn't see left > control with 3.0.1 either. Would you mind creating a ticket, I just don't have time to look at this straight away. Thanks, Antoine From antoine at nagafix.co.uk Thu Nov 7 17:53:14 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 8 Nov 2019 00:53:14 +0700 Subject: [winswitch] 3.0.2-r24406 stable builds - was r24387 still not usable In-Reply-To: <1ba75928-315d-2f87-7923-6309dbf42a8a@nagafix.co.uk> References: <1ba75928-315d-2f87-7923-6309dbf42a8a@nagafix.co.uk> Message-ID: <467ccacc-65d1-db7c-c53c-ac4b02fa215d@nagafix.co.uk> > All those problems are likely related to the move to GTK3, which is > really not a smooth process. > You may have better luck with the legacy "Python2" builds also found in > the download directory: > https://xpra.org/dists/windows/ Thanks to the feedback and comments on the bug tracker, I believe both the window geometry and the OpenGL transparent-window bugs have been fixed. These were in fact caused by the same GTK3 bug, for which we now have a workaround. It was not spotted earlier because the Xpra window code was not changed, and it was a GTK3 library update that broke things just before the release.. AFAICT, this bug only affected MS Windows Python3 builds and also Python3 builds under Wayland (there is no workaround available there). I have just uploaded new stable 3.0.2 builds for MS Windows (r24406), as well as new 4.0 beta builds. For the gory details, see: https://xpra.org/trac/ticket/2475 https://xpra.org/trac/ticket/2457 https://xpra.org/trac/ticket/2466 Cheers, Antoine From wolfram.humann at gmail.com Fri Nov 8 11:31:59 2019 From: wolfram.humann at gmail.com (Wolfram Humann) Date: Fri, 8 Nov 2019 12:31:59 +0100 Subject: [winswitch] r24406 mostly very good! Message-ID: r24406 fixes basically all of my previous problems: no clipped or dancing or transparent windows, no missing buttons in the titlebar, copying in the windows client and pasting to RHEL Eclipse works. One small strangeness in Xpra-Python3-x86_64_4.0-r24406: The I-beam-shaped mouse-cursor in the Eclipse editor window is white and difficult to see. In all other versions I tried, including Xpra-Python3-x86_64_3.0.2-r24406, the cursor is black as expected. From ajs1 at cam.ac.uk Wed Nov 13 19:55:34 2019 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Wed, 13 Nov 2019 19:55:34 +0000 Subject: [winswitch] xpra: unwanted messages Message-ID: <1987c072-adc6-59a0-86e1-5eec80606da7@cam.ac.uk> Antoine, When I have an xpra connection between a local machine and a remote one, both running Ubuntu 18.04, I constantly receive messages like the ones below. They arrive many times an hour, sometimes several times a minute, and the message is always exactly the same and happens even in periods when the connection is live but inactive. Can these messages be suppressed? I suppose I could make xpra send everything to /dev/null, but then I would lose useful messages as well. Anthony 2019-11-13 17:14:48,083 sending updated screen size to server: 1920x1080 with 1 screens 2019-11-13 17:14:48,084 :0.0 (508x285 mm - DPI: 96x96) workarea: 1865x1053 at 55x27 2019-11-13 17:14:48,084 HDMI-1 (521x293 mm - DPI: 93x93) 2019-11-13 17:20:55,932 sending updated screen size to server: 1920x1080 with 1 screens 2019-11-13 17:20:55,933 :0.0 (508x285 mm - DPI: 96x96) workarea: 1865x1053 at 55x27 2019-11-13 17:20:55,933 HDMI-1 (521x293 mm - DPI: 93x93) 2019-11-13 17:55:17,043 sending updated screen size to server: 1920x1080 with 1 screens 2019-11-13 17:55:17,043 :0.0 (508x285 mm - DPI: 96x96) workarea: 1865x1053 at 55x27 2019-11-13 17:55:17,043 HDMI-1 (521x293 mm - DPI: 93x93) 2019-11-13 17:55:28,842 sending updated screen size to server: 1920x1080 with 1 screens 2019-11-13 17:55:28,842 :0.0 (508x285 mm - DPI: 96x96) workarea: 1865x1053 at 55x27 2019-11-13 17:55:28,843 HDMI-1 (521x293 mm - DPI: 93x93) 2019-11-13 17:55:30,244 sending updated screen size to server: 1920x1080 with 1 screens 2019-11-13 17:55:30,244 :0.0 (508x285 mm - DPI: 96x96) workarea: 1865x1053 at 55x27 2019-11-13 17:55:30,245 HDMI-1 (521x293 mm - DPI: 93x93) 2019-11-13 17:55:40,074 sending updated screen size to server: 1920x1080 with 1 screens 2019-11-13 17:55:40,075 :0.0 (508x285 mm - DPI: 96x96) workarea: 1865x1053 at 55x27 2019-11-13 17:55:40,075 HDMI-1 (521x293 mm - DPI: 93x93) From antoine at nagafix.co.uk Thu Nov 14 03:53:02 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 14 Nov 2019 10:53:02 +0700 Subject: [winswitch] xpra: unwanted messages In-Reply-To: <1987c072-adc6-59a0-86e1-5eec80606da7@cam.ac.uk> References: <1987c072-adc6-59a0-86e1-5eec80606da7@cam.ac.uk> Message-ID: On 14/11/2019 02:55, Anthony Stone via shifter-users wrote: > Antoine, > > When I have an xpra connection between a local machine and a remote one, > both running Ubuntu 18.04, I constantly receive messages like the ones > below. They arrive many times an hour, sometimes several times a minute, > and the message is always exactly the same and happens even in periods > when the connection is live but inactive. Something is changing your screen configuration and this is generating this event. If you can figure out what is doing that, we may be able to teach xpra to ignore it. Screen configuration changes are important, that's why they are always logged. > > Can these messages be suppressed? Not at present, no. > I suppose I could make xpra send > everything to /dev/null, but then I would lose useful messages as well. Right, there can always be useful messages there, best not to silence it all. Cheers, Antoine > > Anthony > > 2019-11-13 17:14:48,083 sending updated screen size to server: 1920x1080 > with 1 screens > 2019-11-13 17:14:48,084 :0.0 (508x285 mm - DPI: 96x96) workarea: > 1865x1053 at 55x27 > 2019-11-13 17:14:48,084 HDMI-1 (521x293 mm - DPI: 93x93) > 2019-11-13 17:20:55,932 sending updated screen size to server: 1920x1080 > with 1 screens > 2019-11-13 17:20:55,933 :0.0 (508x285 mm - DPI: 96x96) workarea: > 1865x1053 at 55x27 > 2019-11-13 17:20:55,933 HDMI-1 (521x293 mm - DPI: 93x93) > 2019-11-13 17:55:17,043 sending updated screen size to server: 1920x1080 > with 1 screens > 2019-11-13 17:55:17,043 :0.0 (508x285 mm - DPI: 96x96) workarea: > 1865x1053 at 55x27 > 2019-11-13 17:55:17,043 HDMI-1 (521x293 mm - DPI: 93x93) > 2019-11-13 17:55:28,842 sending updated screen size to server: 1920x1080 > with 1 screens > 2019-11-13 17:55:28,842 :0.0 (508x285 mm - DPI: 96x96) workarea: > 1865x1053 at 55x27 > 2019-11-13 17:55:28,843 HDMI-1 (521x293 mm - DPI: 93x93) > 2019-11-13 17:55:30,244 sending updated screen size to server: 1920x1080 > with 1 screens > 2019-11-13 17:55:30,244 :0.0 (508x285 mm - DPI: 96x96) workarea: > 1865x1053 at 55x27 > 2019-11-13 17:55:30,245 HDMI-1 (521x293 mm - DPI: 93x93) > 2019-11-13 17:55:40,074 sending updated screen size to server: 1920x1080 > with 1 screens > 2019-11-13 17:55:40,075 :0.0 (508x285 mm - DPI: 96x96) workarea: > 1865x1053 at 55x27 > 2019-11-13 17:55:40,075 HDMI-1 (521x293 mm - DPI: 93x93) > _______________________________________________ > 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 Nov 15 16:59:28 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 15 Nov 2019 23:59:28 +0700 Subject: [winswitch] xpra: unwanted messages In-Reply-To: <97cfcbe7-4705-218e-9857-fd737af625eb@cam.ac.uk> References: <1987c072-adc6-59a0-86e1-5eec80606da7@cam.ac.uk> <97cfcbe7-4705-218e-9857-fd737af625eb@cam.ac.uk> Message-ID: <6a6c18e0-bfa5-93c9-bd3d-2d3e9ae0bf3a@nagafix.co.uk> On 15/11/2019 20:09, Anthony Stone wrote: > I believe that the messages occur whenever Ubuntu 18.04 creates a new > workspace or deletes an empty one. Ubuntu 18.04 doesn't have a fixed > array of workspaces, as 16.04 did. It creates a new one whenever a > window is moved off the end of the current (linear) array of workspaces, > and deletes a workspace when the sole window on that workspace is > deleted or moved to a different workspace. xpra will keep track of workspaces and try to preserve the workspace each window is mapped on. > Can the screen configuration message be suppressed for this case? I move > windows between workspaces quite often, so I get a lot of these messages. You could try to get Ubuntu to use a fixed number of workspaces. This may prevent the screen reconfiguration message. Antoine PS: please keep the mailing list CCed. > > Anthony > > On 14/11/2019 03:53, Antoine Martin via shifter-users wrote: >> On 14/11/2019 02:55, Anthony Stone via shifter-users wrote: >>> Antoine, >>> >>> When I have an xpra connection between a local machine and a remote one, >>> both running Ubuntu 18.04, I constantly receive messages like the ones >>> below. They arrive many times an hour, sometimes several times a minute, >>> and the message is always exactly the same and happens even in periods >>> when the connection is live but inactive. >> Something is changing your screen configuration and this is generating >> this event. >> If you can figure out what is doing that, we may be able to teach xpra >> to ignore it. >> Screen configuration changes are important, that's why they are always >> logged. >> >>> >>> Can these messages be suppressed? >> Not at present, no. >>> I suppose I could make xpra send >>> everything to /dev/null, but then I would lose useful messages as well. >> Right, there can always be useful messages there, best not to silence it >> all. >> >> Cheers, >> Antoine >> >>> >>> Anthony >>> >>> 2019-11-13 17:14:48,083 sending updated screen size to server: 1920x1080 >>> with 1 screens >>> 2019-11-13 17:14:48,084 :0.0 (508x285 mm - DPI: 96x96) workarea: >>> 1865x1053 at 55x27 >>> 2019-11-13 17:14:48,084 HDMI-1 (521x293 mm - DPI: 93x93) >>> 2019-11-13 17:20:55,932 sending updated screen size to server: 1920x1080 >>> with 1 screens >>> 2019-11-13 17:20:55,933 :0.0 (508x285 mm - DPI: 96x96) workarea: >>> 1865x1053 at 55x27 >>> 2019-11-13 17:20:55,933 HDMI-1 (521x293 mm - DPI: 93x93) >>> 2019-11-13 17:55:17,043 sending updated screen size to server: 1920x1080 >>> with 1 screens >>> 2019-11-13 17:55:17,043 :0.0 (508x285 mm - DPI: 96x96) workarea: >>> 1865x1053 at 55x27 >>> 2019-11-13 17:55:17,043 HDMI-1 (521x293 mm - DPI: 93x93) >>> 2019-11-13 17:55:28,842 sending updated screen size to server: 1920x1080 >>> with 1 screens >>> 2019-11-13 17:55:28,842 :0.0 (508x285 mm - DPI: 96x96) workarea: >>> 1865x1053 at 55x27 >>> 2019-11-13 17:55:28,843 HDMI-1 (521x293 mm - DPI: 93x93) >>> 2019-11-13 17:55:30,244 sending updated screen size to server: 1920x1080 >>> with 1 screens >>> 2019-11-13 17:55:30,244 :0.0 (508x285 mm - DPI: 96x96) workarea: >>> 1865x1053 at 55x27 >>> 2019-11-13 17:55:30,245 HDMI-1 (521x293 mm - DPI: 93x93) >>> 2019-11-13 17:55:40,074 sending updated screen size to server: 1920x1080 >>> with 1 screens >>> 2019-11-13 17:55:40,075 :0.0 (508x285 mm - DPI: 96x96) workarea: >>> 1865x1053 at 55x27 >>> 2019-11-13 17:55:40,075 HDMI-1 (521x293 mm - DPI: 93x93) >>> _______________________________________________ >>> 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 wssddc at wssddc.com Wed Nov 27 04:20:16 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Tue, 26 Nov 2019 23:20:16 -0500 Subject: [winswitch] start-desktop with Fedora KDE Plasma Message-ID: <393db821-b395-80b2-a912-f8ed9c0ef01e@wssddc.com> [I sent this before with a messed up address, trying again] I've been trying out xpra start-desktop with Windows 7 or 10 viewing Fedora 31.? A few things I've had to figure out that don't seem well documented: To start KDE Plasma, the option is --start=startkde, not --start=plasma as I first guessed I must use the documented --start="xrandr..." option or the screen size is too large.? It doesn't default to 1920x1080. I got multiple messages "Error Authentication is required to create a color managed device", fixed by workaround I found at https://www.seei.biz/authentication-is-required-to-create-a-color-managed-device-in-xrdp/ I still get one message "System policy prevents control of network connections" but I can cancel or enter a password to get past this. The first problem I don't know how to fix is that when I close a desktop application, the screen usually doesn't refresh.? Konsole behaves this way.? I see this both at home with nVidia video on the Linux side and on a PowerEdge server at work with matrox video and no working GUI (which is why I'm looking at start-desktop). The second problem is that when I log off, I'm left with a black window which I can close, but the xpra server doesn't exit on the Linux side.? If I use --exit-with-children, the session doesn't even start.? Or maybe it starts but quits after xrandr? On the Linux end, I do not have the beta repository enabled, so the xpra version is v3.0.2-r24387. On the Windows end, I have 4.0.0.24461. From antoine at nagafix.co.uk Wed Nov 27 07:03:34 2019 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 27 Nov 2019 14:03:34 +0700 Subject: [winswitch] start-desktop with Fedora KDE Plasma In-Reply-To: <393db821-b395-80b2-a912-f8ed9c0ef01e@wssddc.com> References: <393db821-b395-80b2-a912-f8ed9c0ef01e@wssddc.com> Message-ID: On 27/11/2019 11:20, Bob Babcock via shifter-users wrote: > [I sent this before with a messed up address, trying again] > > I've been trying out xpra start-desktop with Windows 7 or 10 viewing > Fedora 31. A few things I've had to figure out that don't seem well > documented: > > To start KDE Plasma, the option is --start=startkde, not --start=plasma > as I first guessed It would be good to collect those commands somewhere on the wiki, as they do seem to change over time. FWIW: I have a 'startkde' in Fedora 31, but no 'plasma' command. > I must use the documented --start="xrandr..." option or the screen size > is too large.? It doesn't default to 1920x1080. The XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION is set by default to: 1280x1024 I get a resolution close to that on start-desktop, but this may also be the result of the resolution-challenged laptop I am using today. > I got multiple messages "Error Authentication is required to create a > color managed device", fixed by workaround I found at > https://www.seei.biz/authentication-is-required-to-create-a-color-managed-device-in-xrdp/ Thanks for the pointer. I have created a wiki page and added it there: https://xpra.org/trac/wiki/Colourspace Note: in newer versions it will be possible to disable colourspace synchronization, which may be easier than fiddling with polkit permissions. > I still get one message "System policy prevents control of network > connections" but I can cancel or enter a password to get past this. > > The first problem I don't know how to fix is that when I close a desktop > application, the screen usually doesn't refresh.? Konsole behaves this > way.? I see this both at home with nVidia video on the Linux side and on > a PowerEdge server at work with matrox video and no working GUI (which > is why I'm looking at start-desktop). Unless you use vglrun to accelerate your start-desktop session, the GPU will not be used. I cannot reproduce this problem, can you please file a ticket with mode details? (ie: the exact commands and a screenshot or two would really help) > The second problem is that when I log off, I'm left with a black window > which I can close, but the xpra server doesn't exit on the Linux side. > If I use --exit-with-children, the session doesn't even start.? Or maybe > it starts but quits after xrandr? The server log file should tell you what is happening here. Make sure the desktop session command is started with --start-child= xrandr should be started using --start= I've just tried it with --start-child=startkde --exit-with-children=yes and the session was correctly terminated when I logged out of KDE. Note that I did all this from the Linux laptop, I have not tried from the MS Windows client, which may cause the problem you are reporting. > On the Linux end, I do not have the beta repository enabled, so the xpra > version is v3.0.2-r24387. > On the Windows end, I have 4.0.0.24461. Both should work OK for what you're trying to do. Cheers, Antoine From wssddc at wssddc.com Wed Nov 27 08:11:24 2019 From: wssddc at wssddc.com (Bob Babcock) Date: Wed, 27 Nov 2019 03:11:24 -0500 Subject: [winswitch] start-desktop with Fedora KDE Plasma In-Reply-To: References: <393db821-b395-80b2-a912-f8ed9c0ef01e@wssddc.com> Message-ID: Antoine Martin via shifter-users wrote: > It would be good to collect those commands somewhere on the wiki, as they do > seem to change over time. > FWIW: I have a 'startkde' in Fedora 31, but no 'plasma' command. Plasma is what I see in the pulldown to select the window manager when I log on.? But I don't have a plasma command either. > The XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION is set by default to: > 1280x1024 Just tested.? If I set this on the Windows side, I don't have to use xrandr.? Google doesn't get any hits searching for XPRA_DEFAULT_DESKTOP_VFB_RESOLUTION. > I've just tried it with --start-child=startkde --exit-with-children=yes > and the session was correctly terminated when I logged out of KDE. That's what I was doing wrong.? I had --start=startkde, not --start-child.? Now the session starts and the server exits properly if I log off. So only the non-refreshing screen problem remains.? It's too late here to do any more.? I'll file a ticket tomorrow. Thanks for your help.