From yonatan.zaken at gmail.com Sun May 9 08:56:41 2021 From: yonatan.zaken at gmail.com (yonatan zaken) Date: Sun, 9 May 2021 10:56:41 +0300 Subject: [winswitch] How to disable redirecting to log file Message-ID: Hi All, My platform: Linux Kubuntu 14 xpra version: xpra v1.0.12-r19800 I am trying to find a way to disable the redirecting of the xpra server output to the log file. The application that I run via. xpra start generates large amounts of data to stdout causing the ":1.log" file to be very large. This causes me trouble since the /run/user is left with no space sometimes. I tried adding the following flag to the xpra.conf file: remote-logging=no But i still see the applications output directed to the .log file. Any suggestions how to disable the redirecting of the applications stdout to the log file? *Cheers,* *Yonatan* From antoine at nagafix.co.uk Sun May 9 13:27:56 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 9 May 2021 19:27:56 +0700 Subject: [winswitch] How to disable redirecting to log file In-Reply-To: References: Message-ID: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> On 09/05/2021 14:56, yonatan zaken via shifter-users wrote: > Hi All, > My platform: Linux Kubuntu 14 > xpra version: xpra v1.0.12-r19800 > > I am trying to find a way to disable the redirecting of the xpra server > output to the log file. If you run your server with "--no-daemon" then the output will just go to stdout. You can then redirect that wherever you like: nohup xpra start --start=noisycommand --no-daemon >& /dev/null & > The application that I run via. xpra start generates large amounts of data > to stdout causing the ":1.log" file to be very large. This causes me > trouble since the /run/user is left with no space sometimes. So the problem is not caused by the xpra server but by your unspecified application. > I tried adding the following flag to the xpra.conf file: > remote-logging=no Remote logging has nothing to do with it. That's for sending the client's log messages to the server. (and in newer versions, also back the other way) > But i still see the applications output directed to the .log file. > > Any suggestions how to disable the redirecting of the applications stdout > to the log file? Why don't you just redirect the output of your noisy command? xpra start --start="bash -c 'therealcommand &> /dev/null'" You could also create a wrapper script to do the same thing: cat > /usr/bin/mycommand-wrapper << EOF #!/bin/bash mycommand $@ >& /dev/null EOF chmod +x /usr/bin/mycommand-wrapper Cheers, Antoine > > *Cheers,* > *Yonatan* > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From yonatan.zaken at gmail.com Sun May 9 17:01:12 2021 From: yonatan.zaken at gmail.com (yonatan zaken) Date: Sun, 9 May 2021 19:01:12 +0300 Subject: [winswitch] How to disable redirecting to log file In-Reply-To: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> References: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> Message-ID: Hi Antoine, Thanks for the response! I tried the following: > Why don't you just redirect the output of your noisy command? > xpra start --start="bash -c 'therealcommand &> /dev/null'" When trying to start a local session it works fine and stdout of the noisy command is redirected to /dev/null. But when trying to run the command on a remote machine I get the following error: Ambiguous output redirect. 2021-05-09 20:43:16,088 Error: SSH connection to the xpra server failed 2021-05-09 20:43:16,088 check your username, hostname, display number, firewall, etc 2021-05-09 20:43:16,088 for server: ssh:pci at 172.00.00.26 2021-05-09 20:43:16,088 the command line used was: 2021-05-09 20:43:16,088 ssh -x -l pci -T 172.19.31.26 sh -c 'xpra initenv;~/.xpra/run-xpra _proxy_start "--start-child=bash -c 'therealcommand >& /dev/null'" --exit-with-children --mmap-group || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy_start "--start-child=bash -c 'therealcommand >& /dev/null'" --exit-with-children --mmap-group || xpra _proxy_start "--start-child=bash -c 'therealcommand >& /dev/null'" --exit-with-children --mmap-group' Any idea how to overcome this ? *Cheers,* *Yonatan* On Sun, 9 May 2021 at 15:28, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 09/05/2021 14:56, yonatan zaken via shifter-users wrote: > > Hi All, > > My platform: Linux Kubuntu 14 > > xpra version: xpra v1.0.12-r19800 > > > > I am trying to find a way to disable the redirecting of the xpra server > > output to the log file. > If you run your server with "--no-daemon" then the output will just go > to stdout. You can then redirect that wherever you like: > nohup xpra start --start=noisycommand --no-daemon >& /dev/null & > > > The application that I run via. xpra start generates large amounts of > data > > to stdout causing the ":1.log" file to be very large. This causes me > > trouble since the /run/user is left with no space sometimes. > So the problem is not caused by the xpra server but by your unspecified > application. > > > I tried adding the following flag to the xpra.conf file: > > remote-logging=no > Remote logging has nothing to do with it. > That's for sending the client's log messages to the server. > (and in newer versions, also back the other way) > > > But i still see the applications output directed to the .log file. > > > > Any suggestions how to disable the redirecting of the applications stdout > > to the log file? > Why don't you just redirect the output of your noisy command? > xpra start --start="bash -c 'therealcommand &> /dev/null'" > > You could also create a wrapper script to do the same thing: > cat > /usr/bin/mycommand-wrapper << EOF > #!/bin/bash > mycommand $@ >& /dev/null > EOF > chmod +x /usr/bin/mycommand-wrapper > > Cheers, > Antoine > > > > > > *Cheers,* > > *Yonatan* > > _______________________________________________ > > 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 swine at pobox.com Mon May 10 01:50:22 2021 From: swine at pobox.com (Peter Swain) Date: Sun, 9 May 2021 17:50:22 -0700 Subject: [winswitch] How to disable redirecting to log file In-Reply-To: References: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> Message-ID: Yonatan, you've mixed two different notations here Use &>/dev/null or >&- 2>&- On Sun, May 9, 2021, 9:02 AM yonatan zaken via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > Hi Antoine, Thanks for the response! > > I tried the following: > > > Why don't you just redirect the output of your noisy command? > > xpra start --start="bash -c 'therealcommand &> /dev/null'" > > > When trying to start a local session it works fine and stdout of the noisy > command is redirected to /dev/null. > But when trying to run the command on a remote machine I get the following > error: > > Ambiguous output redirect. > 2021-05-09 20:43:16,088 Error: SSH connection to the xpra server failed > 2021-05-09 20:43:16,088 check your username, hostname, display number, > firewall, etc > 2021-05-09 20:43:16,088 for server: ssh:pci at 172.00.00.26 > 2021-05-09 20:43:16,088 the command line used was: > 2021-05-09 20:43:16,088 ssh -x -l pci -T 172.19.31.26 sh -c 'xpra > initenv;~/.xpra/run-xpra _proxy_start "--start-child=bash -c > 'therealcommand >& /dev/null'" --exit-with-children --mmap-group || > $XDG_RUNTIME_DIR/xpra/run-xpra _proxy_start "--start-child=bash -c > 'therealcommand >& /dev/null'" --exit-with-children --mmap-group || xpra > _proxy_start "--start-child=bash -c 'therealcommand >& /dev/null'" > --exit-with-children --mmap-group' > > Any idea how to overcome this ? > > *Cheers,* > *Yonatan* > > > > > On Sun, 9 May 2021 at 15:28, Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > > > On 09/05/2021 14:56, yonatan zaken via shifter-users wrote: > > > Hi All, > > > My platform: Linux Kubuntu 14 > > > xpra version: xpra v1.0.12-r19800 > > > > > > I am trying to find a way to disable the redirecting of the xpra server > > > output to the log file. > > If you run your server with "--no-daemon" then the output will just go > > to stdout. You can then redirect that wherever you like: > > nohup xpra start --start=noisycommand --no-daemon >& /dev/null & > > > > > The application that I run via. xpra start generates large amounts of > > data > > > to stdout causing the ":1.log" file to be very large. This causes me > > > trouble since the /run/user is left with no space sometimes. > > So the problem is not caused by the xpra server but by your unspecified > > application. > > > > > I tried adding the following flag to the xpra.conf file: > > > remote-logging=no > > Remote logging has nothing to do with it. > > That's for sending the client's log messages to the server. > > (and in newer versions, also back the other way) > > > > > But i still see the applications output directed to the .log file. > > > > > > Any suggestions how to disable the redirecting of the applications > stdout > > > to the log file? > > Why don't you just redirect the output of your noisy command? > > xpra start --start="bash -c 'therealcommand &> /dev/null'" > > > > You could also create a wrapper script to do the same thing: > > cat > /usr/bin/mycommand-wrapper << EOF > > #!/bin/bash > > mycommand $@ >& /dev/null > > EOF > > chmod +x /usr/bin/mycommand-wrapper > > > > Cheers, > > Antoine > > > > > > > > > > *Cheers,* > > > *Yonatan* > > > _______________________________________________ > > > 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 > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From yonatan.zaken at gmail.com Mon May 10 06:36:46 2021 From: yonatan.zaken at gmail.com (yonatan zaken) Date: Mon, 10 May 2021 08:36:46 +0300 Subject: [winswitch] How to disable redirecting to log file In-Reply-To: References: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> Message-ID: Hi Peter, thanks for the reply. I actually used this notation: >& For some reason I miss typed it in the quoted line. As I said, this works for me when running xpra start on a local machine but generated the error when using it on a remote machine. *Cheers,* *Yonatan* On Mon, 10 May 2021 at 03:50, Peter Swain wrote: > Yonatan, you've mixed two different notations here > > Use > &>/dev/null > or > >&- 2>&- > > On Sun, May 9, 2021, 9:02 AM yonatan zaken via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > >> Hi Antoine, Thanks for the response! >> >> I tried the following: >> >> > Why don't you just redirect the output of your noisy command? >> > xpra start --start="bash -c 'therealcommand &> /dev/null'" >> >> >> When trying to start a local session it works fine and stdout of the noisy >> command is redirected to /dev/null. >> But when trying to run the command on a remote machine I get the following >> error: >> >> Ambiguous output redirect. >> 2021-05-09 20:43:16,088 Error: SSH connection to the xpra server failed >> 2021-05-09 20:43:16,088 check your username, hostname, display number, >> firewall, etc >> 2021-05-09 20:43:16,088 for server: ssh:pci at 172.00.00.26 >> 2021-05-09 20:43:16,088 the command line used was: >> 2021-05-09 20:43:16,088 ssh -x -l pci -T 172.19.31.26 sh -c 'xpra >> initenv;~/.xpra/run-xpra _proxy_start "--start-child=bash -c >> 'therealcommand >& /dev/null'" --exit-with-children --mmap-group || >> $XDG_RUNTIME_DIR/xpra/run-xpra _proxy_start "--start-child=bash -c >> 'therealcommand >& /dev/null'" --exit-with-children --mmap-group || xpra >> _proxy_start "--start-child=bash -c 'therealcommand >& /dev/null'" >> --exit-with-children --mmap-group' >> >> Any idea how to overcome this ? >> >> *Cheers,* >> *Yonatan* >> >> >> >> >> On Sun, 9 May 2021 at 15:28, Antoine Martin via shifter-users < >> shifter-users at lists.devloop.org.uk> wrote: >> >> > On 09/05/2021 14:56, yonatan zaken via shifter-users wrote: >> > > Hi All, >> > > My platform: Linux Kubuntu 14 >> > > xpra version: xpra v1.0.12-r19800 >> > > >> > > I am trying to find a way to disable the redirecting of the xpra >> server >> > > output to the log file. >> > If you run your server with "--no-daemon" then the output will just go >> > to stdout. You can then redirect that wherever you like: >> > nohup xpra start --start=noisycommand --no-daemon >& /dev/null & >> > >> > > The application that I run via. xpra start generates large amounts of >> > data >> > > to stdout causing the ":1.log" file to be very large. This causes me >> > > trouble since the /run/user is left with no space sometimes. >> > So the problem is not caused by the xpra server but by your unspecified >> > application. >> > >> > > I tried adding the following flag to the xpra.conf file: >> > > remote-logging=no >> > Remote logging has nothing to do with it. >> > That's for sending the client's log messages to the server. >> > (and in newer versions, also back the other way) >> > >> > > But i still see the applications output directed to the .log file. >> > > >> > > Any suggestions how to disable the redirecting of the applications >> stdout >> > > to the log file? >> > Why don't you just redirect the output of your noisy command? >> > xpra start --start="bash -c 'therealcommand &> /dev/null'" >> > >> > You could also create a wrapper script to do the same thing: >> > cat > /usr/bin/mycommand-wrapper << EOF >> > #!/bin/bash >> > mycommand $@ >& /dev/null >> > EOF >> > chmod +x /usr/bin/mycommand-wrapper >> > >> > Cheers, >> > Antoine >> > >> > >> > > >> > > *Cheers,* >> > > *Yonatan* >> > > _______________________________________________ >> > > 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 >> > >> _______________________________________________ >> 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 Mon May 10 07:41:50 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 10 May 2021 13:41:50 +0700 Subject: [winswitch] How to disable redirecting to log file In-Reply-To: References: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> Message-ID: <5f357d40-9f37-64a3-be13-422d76d32bfd@nagafix.co.uk> On 10/05/2021 12:36, yonatan zaken wrote: > Hi Peter, thanks for the reply. > I actually used this notation: >& > For some reason I miss typed it in the quoted line. > > As I said, this works for me when running xpra start on a local machine > but generated the error when using it on a remote machine. That's because you're on an outdated 1.x version, it generates the ssh command line without proper quoting. Newer versions use the paramiko ssh backend by default which does not rely on escaping strings, and even the ssh backend has been re-worked to support nesting and quotes more correctly. If you have to stick with this outdated version, use the script approach I had suggested in my first reply. You can probably make this completely transparent by placing these wrapper scripts in /usr/local/bin with the same name as the real binary (just make sure to invoke the binary with its full path) and ensuring /usr/local/bin comes first in the $PATH. Cheers, Antoine > */ > /* > */Cheers,/* > */Yonatan/* > * > * > > > > On Mon, 10 May 2021 at 03:50, Peter Swain > wrote: > > Yonatan, you've mixed two different notations here > > Use > ? &>/dev/null > or > ? >&- 2>&- > > On Sun, May 9, 2021, 9:02 AM yonatan zaken via shifter-users > > wrote: > > Hi Antoine, Thanks for the response! > > I tried the following: > > > Why don't you just redirect the output of your noisy command? > > xpra start --start="bash -c 'therealcommand &> /dev/null'" > > > When trying to start a local session it works fine and stdout of > the noisy > command is redirected to /dev/null. > But when trying to run the command on a remote machine I get the > following > error: > > ?Ambiguous output redirect. > 2021-05-09 20:43:16,088 Error: SSH connection to the xpra server > failed > 2021-05-09 20:43:16,088? check your username, hostname, display > number, > firewall, etc > 2021-05-09 20:43:16,088? for server: ssh:pci at 172.00.00.26 > > 2021-05-09 20:43:16,088? the command line used was: > 2021-05-09 20:43:16,088? ssh -x -l pci -T 172.19.31.26 sh -c 'xpra > initenv;~/.xpra/run-xpra _proxy_start "--start-child=bash -c > 'therealcommand >& /dev/null'" --exit-with-children --mmap-group || > $XDG_RUNTIME_DIR/xpra/run-xpra _proxy_start "--start-child=bash -c > 'therealcommand >& /dev/null'" --exit-with-children --mmap-group > || xpra > _proxy_start "--start-child=bash -c 'therealcommand >& /dev/null'" > --exit-with-children --mmap-group' > > Any idea how to overcome this ? > > *Cheers,* > *Yonatan* > > > > > On Sun, 9 May 2021 at 15:28, Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk > > wrote: > > > On 09/05/2021 14:56, yonatan zaken via shifter-users wrote: > > > Hi All, > > > My platform: Linux Kubuntu 14 > > > xpra version: xpra v1.0.12-r19800 > > > > > > I am trying to find a way to disable the redirecting of the > xpra server > > > output to the log file. > > If you run your server with "--no-daemon" then the output will > just go > > to stdout. You can then redirect that wherever you like: > > nohup xpra start --start=noisycommand --no-daemon >& /dev/null & > > > > > The application that I run via. xpra start generates large > amounts of > > data > > > to stdout causing the ":1.log" file to be very large. This > causes me > > > trouble since the /run/user is left with no space sometimes. > > So the problem is not caused by the xpra server but by your > unspecified > > application. > > > > > I tried adding the following flag to the xpra.conf file: > > > remote-logging=no > > Remote logging has nothing to do with it. > > That's for sending the client's log messages to the server. > > (and in newer versions, also back the other way) > > > > > But i still see the applications output directed to the .log > file. > > > > > > Any suggestions how to disable the redirecting of the > applications stdout > > > to the log file? > > Why don't you just redirect the output of your noisy command? > > xpra start --start="bash -c 'therealcommand &> /dev/null'" > > > > You could also create a wrapper script to do the same thing: > > cat > /usr/bin/mycommand-wrapper << EOF > > #!/bin/bash > > mycommand $@ >& /dev/null > > EOF > > chmod +x /usr/bin/mycommand-wrapper > > > > Cheers, > > Antoine > > > > > > > > > > *Cheers,* > > > *Yonatan* > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > From me.xpra at cgf.cx Thu May 20 20:45:55 2021 From: me.xpra at cgf.cx (Christopher Faylor) Date: Thu, 20 May 2021 15:45:55 -0400 Subject: [winswitch] Get full session name from "xpra list-windows"? Message-ID: <20210520194555.GA14342@cgf.cx> Is there any way to get the non-truncated session name from the "xpra list-windows"? I wanted to use it to programatically to stop all displays opened with a given session but, since I'm using session names longer than 15 characters, they are truncated to 12 characters and "..". cgf From antoine at nagafix.co.uk Fri May 21 04:09:52 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 21 May 2021 10:09:52 +0700 Subject: [winswitch] Get full session name from "xpra list-windows"? In-Reply-To: <20210520194555.GA14342@cgf.cx> References: <20210520194555.GA14342@cgf.cx> Message-ID: On 21/05/2021 02:45, Christopher Faylor via shifter-users wrote: > Is there any way to get the non-truncated session name from the "xpra list-windows"? > I wanted to use it to programatically to stop all displays opened with a given session > but, since I'm using session names longer than 15 characters, they are truncated to > 12 characters and "..". Xpra 4.2 adds the "xpra list-sessions" subcommand which is much more suitable for what you are trying to do. It also includes "xpra clean-displays" and other subcommands aimed at making it easier to manage displays and sessions reliably. Cheers, Antoine > > cgf > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From me.xpra at cgf.cx Fri May 21 04:22:36 2021 From: me.xpra at cgf.cx (Christopher Faylor) Date: Thu, 20 May 2021 23:22:36 -0400 Subject: [winswitch] Get full session name from "xpra list-windows"? In-Reply-To: References: <20210520194555.GA14342@cgf.cx> Message-ID: <20210521032236.GA26020@cgf.cx> On Fri, May 21, 2021 at 10:09:52AM +0700, Antoine Martin via shifter-users wrote: >On 21/05/2021 02:45, Christopher Faylor via shifter-users wrote: >> Is there any way to get the non-truncated session name from the "xpra list-windows"? >> I wanted to use it to programatically to stop all displays opened with a given session >> but, since I'm using session names longer than 15 characters, they are truncated to >> 12 characters and "..". >Xpra 4.2 adds the "xpra list-sessions" subcommand which is much more >suitable for what you are trying to do. >It also includes "xpra clean-displays" and other subcommands aimed at >making it easier to manage displays and sessions reliably. Just downloaded it. list-sessions is perfect. Thanks. cgf From totaam at xpra.org Fri May 21 05:51:06 2021 From: totaam at xpra.org (Antoine Martin) Date: Fri, 21 May 2021 11:51:06 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.2 Message-ID: <4283854e-a852-1449-6a06-fe87124f1fce@xpra.org> Hi, This new release does not have many new features but it does include a large number of fixes. The most prominent new features are: * fast nvjpeg encoder (for nvidia GPUs only) ? this is particularly useful for getting a good framerate with the HTML5 client * using "pinentry" on Linux for password prompts and confirmation dialogs ? (this can be turned off with XPRA_PINENTRY=0, and for ssh with XPRA_SSH_PINENTRY=0) * subcommands for managing displays, sessions and cleaning up: ? 'recover', 'displays', 'list-sessions', 'clean-displays', 'clean-sockets' etc * user-friendly GUI for starting local and remote sessions The more detailed release notes can be found here: https://github.com/Xpra-org/xpra/releases/tag/v4.2 Downloads: https://github.com/Xpra-org/xpra/wiki/Download Cheers Antoine From totaam at xpra.org Fri May 21 06:41:45 2021 From: totaam at xpra.org (Antoine Martin) Date: Fri, 21 May 2021 12:41:45 +0700 Subject: [winswitch] [ANNOUNCE] Xpra HTML5 4.2 Message-ID: <2ee599e5-1116-d105-20b2-449daa2f011d@xpra.org> Hi, This new release of the HTML5 client coincides with the xpra 4.2 release in order to take advantage of some of the new features. In particular: * the connect dialog page is now more user friendly and offers lists to choose from when this feature is available from the server * it tells the xpra server to prefer the new fast nvjpeg encoder if present The more detailed release notes can be found here: https://github.com/Xpra-org/xpra-html5/releases/tag/v4.2 Cheers Antoine From terry at beam.ltd.uk Fri May 21 10:09:03 2021 From: terry at beam.ltd.uk (Terry Barnaby) Date: Fri, 21 May 2021 10:09:03 +0100 Subject: [winswitch] Fedora33 xpra h264 encoding support not working Message-ID: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> Hi, I am testing the usage of xpra between two Intel Fedora33 systems. It functions fine with default encoding (whatever is used) but I cannot enable h264 encoding to test with this. I have tried using the default Fedora RPM's "dnf install xpra xpra-codecs-freeworld xpra-html5 xpra-udev" as well as the https://github.com/Xpra-org/xpra RPM's. Both show the same issue. If I use "--encodings=h264" on a manually started server and client, the server messages have the error listed: "no common encodings found (server: rgb24, rgb32, grayscale, h264, auto vs client: h264, excluding: h264, vp8, vp9, h264+mp4, mpeg4+mp4, mpeg1, mpeg2, hevc)" So something is setting the "excluding:" part for some reason. I cannot find any information on why this would be. Any ideas on what may be happening ? Terry From antoine at nagafix.co.uk Fri May 21 13:10:39 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 21 May 2021 19:10:39 +0700 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> Message-ID: <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> On 21/05/2021 16:09, Terry Barnaby via shifter-users wrote: > Hi, > > I am testing the usage of xpra between two Intel Fedora33 systems. It > functions fine with default encoding (whatever is used) but I cannot > enable h264 encoding to test with this. > > I have tried using the default Fedora RPM's "dnf install xpra > xpra-codecs-freeworld xpra-html5 xpra-udev" as well as the > https://github.com/Xpra-org/xpra RPM's. Do not mix downstream packages like 'xpra-codecs-freeworld' and xpra's packages. And avoid downstream packages altogether: https://github.com/Xpra-org/xpra/wiki/Distribution-Packages > Both show the same issue. > > If I use "--encodings=h264" on a manually started server and client, the > server messages have the error listed: This is the wrong switch to use. You need more than one 'encodings' enabled to be able to run correctly. That said, with the xpra.org packages installed correctly, this doesn't cause the problems you report below. > "no common encodings found (server: rgb24, rgb32, grayscale, h264, auto > vs client: h264, excluding: h264, vp8, vp9, h264+mp4, mpeg4+mp4, mpeg1, > mpeg2, hevc)" > > So something is setting the "excluding:" part for some reason. I cannot > find any information on why this would be. > > Any ideas on what may be happening ? As per the documentation: https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Encodings.md *Do not* second guess the server engine by specifying encoding(s), as you will get it wrong and the behaviour is very likely to be sub-optimal. If you really want to use 'h264' and not the other video encoders, you can just use --video-encoders=x264,nvenc on the server side. Nothing else is needed, server side or client side. As I said, it's a bad idea but it does work and will use 'h264' whenever it is suitable - which if far from always being the case. ie: if the xpra server detects that the application in use is plain text (ie: a terminal) then it will still not use a video encoding like h264. Which is one of the reasons why you still need other encodings enabled. Cheers, Antoine > > Terry > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From terry at beam.ltd.uk Fri May 21 16:11:54 2021 From: terry at beam.ltd.uk (Terry Barnaby) Date: Fri, 21 May 2021 16:11:54 +0100 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> Message-ID: Many thanks for the reply, notes below. On 21/05/2021 13:10, Antoine Martin via shifter-users wrote: > On 21/05/2021 16:09, Terry Barnaby via shifter-users wrote: >> Hi, >> >> I am testing the usage of xpra between two Intel Fedora33 systems. It >> functions fine with default encoding (whatever is used) but I cannot >> enable h264 encoding to test with this. >> >> I have tried using the default Fedora RPM's "dnf install xpra >> xpra-codecs-freeworld xpra-html5 xpra-udev" as well as the >> https://github.com/Xpra-org/xpra RPM's. > Do not mix downstream packages like 'xpra-codecs-freeworld' and xpra's > packages. > > And avoid downstream packages altogether: > https://github.com/Xpra-org/xpra/wiki/Distribution-Packages Yes, I was not mixing xpra packages, just trying each set of xpra packages separately. I much prefer to use base system packages wherever possible. > >> Both show the same issue. >> >> If I use "--encodings=h264" on a manually started server and client, the >> server messages have the error listed: > This is the wrong switch to use. > You need more than one 'encodings' enabled to be able to run correctly. Not sure what you mean by this ? I am just experimenting to see what the capabilities/performance options are and so was trying to force full h264 encoding to try this out. I assume from what you say it is possible to define multiple encodings that xpra can choose from somehow ? > > That said, with the xpra.org packages installed correctly, this doesn't > cause the problems you report below. This was my fault. I had "--csc-modules=none" set on the server from previous tests. Sorry for the noise. > >> "no common encodings found (server: rgb24, rgb32, grayscale, h264, auto >> vs client: h264, excluding: h264, vp8, vp9, h264+mp4, mpeg4+mp4, mpeg1, >> mpeg2, hevc)" >> >> So something is setting the "excluding:" part for some reason. I cannot >> find any information on why this would be. >> >> Any ideas on what may be happening ? > As per the documentation: > https://github.com/Xpra-org/xpra/blob/master/docs/Usage/Encodings.md > *Do not* second guess the server engine by specifying encoding(s), as > you will get it wrong and the behaviour is very likely to be sub-optimal. > > If you really want to use 'h264' and not the other video encoders, you > can just use --video-encoders=x264,nvenc on the server side. Nothing > else is needed, server side or client side. > As I said, it's a bad idea but it does work and will use 'h264' whenever > it is suitable - which if far from always being the case. ie: if the > xpra server detects that the application in use is plain text (ie: a > terminal) then it will still not use a video encoding like h264. Which > is one of the reasons why you still need other encodings enabled. Yes, I understand that using a video stream for a static window is not a good idea. As I was saying I am just testing the capabilities to see what is possible. xpra now works with me when "--encodings=h264" is set. Generally the latancy/flickering is better than in auto. One thing that is interesting is the CPU usage on the server side. Using firefox as a test client and clicking on different web pages and waiting the server's CPU usage can be around 15% after than or sometimes 100% or 200% and then sticks at those values even though the page looks static after that. I assume that my xpra server here is using software h264 from those figures. Is there anyway to determine if xpra is using hardware h264 if I have managed to configure for that ? > > Cheers, > Antoine > > >> Terry >> >> _______________________________________________ >> 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 yonatan.zaken at gmail.com Tue May 25 20:32:10 2021 From: yonatan.zaken at gmail.com (yonatan zaken) Date: Tue, 25 May 2021 22:32:10 +0300 Subject: [winswitch] xpra v4.3-r40 initialization error: cannot find any live servers to connect to Message-ID: Hi All, Just installed the latest release. When running the following: xpra start --start=firefox; sleep 3; xpra attach This is the terminal output: ================================================== Entering daemon mode; any further errors will be reported to: /run/user/1000/xpra/S20128.log 2021-05-25 22:28:25,422 Warning: zlib is the only compressor enabled 2021-05-25 22:28:25,422 install and enable lz4 support for better performance 2021-05-25 22:28:25,422 Warning: 'rencode' packet encoder not found 2021-05-25 22:28:25,422 the other packet encoders are much slower 2021-05-25 22:28:25,422 Xpra GTK3 X11 client version 4.3-r40 64-bit 2021-05-25 22:28:25,518 running on Linux Ubuntu 18.04 bionic 2021-05-25 22:28:25,519 window manager is 'GNOME Shell' 2021-05-25 22:28:25,958 GStreamer version 1.14.5 for Python 3.6.9 64-bit 2021-05-25 22:28:26,035 created unix domain socket '/run/user/1000/xpra/clients/y10-20137' 2021-05-25 22:28:26,099 removing unix domain socket '/run/user/1000/xpra/clients/y10-20137' xpra initialization error: cannot find any live servers to connect to ================================================== And this is the log context: ================================================== failure on /tmp/.X11-unix/X19890: [Errno 2] No such file or directory: '/tmp/.X11-unix/X19890' 2021-05-25 22:25:26,531 cannot access python uinput module:^[[0m 2021-05-25 22:25:26,531 No module named 'uinput'^[[0m xpra initialization error: failed to execute xvfb command ['Xvfb-for-Xpra-S19890', '+extension', 'GLX', '+extension', 'Composite', '-screen', '0', '8192x4096x24+32', '-nolisten', 'tcp', '-noreset', '-auth' , '/run/user/1000/gdm/Xauthority', '-dpi', '96', '-displayfd', '6']: [Errno 2] No such file or directory: 'Xvfb': 'Xvfb' ================================================== Any idea how to solve this matter? *Cheers,* *Yonatan* From antoine at nagafix.co.uk Wed May 26 05:39:29 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 May 2021 11:39:29 +0700 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> Message-ID: <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> (..) > I much prefer to use base system packages wherever possible. Me too, normally. Unfortunately, it's just painful to use xpra with the system packages. >>> Both show the same issue. >>> >>> If I use "--encodings=h264" on a manually started server and client, the >>> server messages have the error listed: >> This is the wrong switch to use. >> You need more than one 'encodings' enabled to be able to run correctly. > > Not sure what you mean by this ? The xpra server needs more encodings enabled to be able to send screen updates. For example, it is not always possible to send screen updates using `h264". There are size constraints, rounding errors, etc. > I am just experimenting to see what the capabilities/performance options > are and so was trying to force full h264 encoding to try this out. Without knowing exactly what application you are testing with, I can't be certain, but forcing "h264" is almost always a bad idea. > I assume from what you say it is possible to define multiple encodings > that xpra can choose from somehow ? I have updated the manual to try to clarify : https://github.com/Xpra-org/xpra/commit/174056958a44d25d95bc5f8d659a5e916016620c --encodings vs --encoding (..) > xpra now works with me when "--encodings=h264" is set. Generally the > latancy/flickering is better than in auto. That's odd. Using "h264" alone will waste a lot of CPU and bandwidth. (assuming that it is actually used) The latency really depends on a large number of factors so I can't comment without knowing more. But there should be no flickering no matter which encoding is used. > One thing that is interesting > is the CPU usage on the server side. Using firefox as a test client and > clicking on different web pages and waiting the server's CPU usage can > be around 15% Do you have audio forwarding running? If there are no screen updates, the server CPU usage should be very close to zero. > after than or sometimes 100% or 200% and then sticks at > those values even though the page looks static after that. You can turn on "damage" and "compress" debugging on your server to see if it is receiving / sending screen updates: xpra start -d damage,compress * "damage" corresponds to application paint events * "compress" logs the type of picture compression used You can also see which encoding is used for each screen update using the colour coded client debug switch: xpra attach --no-mmap --env=XPRA_PAINT_BOX=1 The color codes are defined here: https://github.com/Xpra-org/xpra/blob/master/xpra/client/paint_colors.py > I assume that my xpra server here is using software h264 from those > figures. Assuming that it is actually using "h264" for all the screen updates - which is not guaranteed. > Is there anyway to determine if xpra is using hardware h264 if > I have managed to configure for that ? In theory, hardware acceleration should be used automatically if it is available. The only acceleration that is well tested is with NVENC. You can see which encoders are available on your system with: xpra encoding xpra video Again, just because hardware acceleration is available on your system does not mean that it should be used for every screen updates. In many cases, the server engine will prefer software encoding because it is more suitable. Cheers, Antoine > > >> >> Cheers, >> Antoine >> >> >>> Terry >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 Wed May 26 05:44:27 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 May 2021 11:44:27 +0700 Subject: [winswitch] xpra v4.3-r40 initialization error: cannot find any live servers to connect to In-Reply-To: References: Message-ID: On 26/05/2021 02:32, yonatan zaken via shifter-users wrote: > Hi All, > Just installed the latest release. > > When running the following: > xpra start --start=firefox; sleep 3; xpra attach > (..) > [Errno 2] No such file or directory: 'Xvfb': 'Xvfb' > ================================================== > > Any idea how to solve this matter? Yes. Your installation is clearly missing 'Xvfb'. You are also missing a number of other important packages like python3-lz4, python3-rencode and probably many others. These should have been pulled in automatically for you when you installed xpra. Cheers, Antoine > > *Cheers,* > *Yonatan* > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From terry at beam.ltd.uk Wed May 26 08:52:45 2021 From: terry at beam.ltd.uk (Terry Barnaby) Date: Wed, 26 May 2021 08:52:45 +0100 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> Message-ID: <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> Thanks for the reply and your work on xpra. I certainly looks a good remote desktop access system especially with the individual application support. On 26/05/2021 05:39, Antoine Martin via shifter-users wrote: > (..) >> I much prefer to use base system packages wherever possible. > Me too, normally. > Unfortunately, it's just painful to use xpra with the system packages. Is there any reason why the Fedora system packages should be so different ? I can see they wouldn't be so up-to-date but I would have thought the Fedora maintainer would take the upstream as close as possible. It would be a better user experience and probably less support if they were basically the same. > >>>> Both show the same issue. >>>> >>>> If I use "--encodings=h264" on a manually started server and client, the >>>> server messages have the error listed: >>> This is the wrong switch to use. >>> You need more than one 'encodings' enabled to be able to run correctly. >> Not sure what you mean by this ? > The xpra server needs more encodings enabled to be able to send screen > updates. > For example, it is not always possible to send screen updates using > `h264". There are size constraints, rounding errors, etc. > >> I am just experimenting to see what the capabilities/performance options >> are and so was trying to force full h264 encoding to try this out. > Without knowing exactly what application you are testing with, I can't > be certain, but forcing "h264" is almost always a bad idea. > >> I assume from what you say it is possible to define multiple encodings >> that xpra can choose from somehow ? > I have updated the manual to try to clarify : > https://github.com/Xpra-org/xpra/commit/174056958a44d25d95bc5f8d659a5e916016620c > > --encodings vs --encoding Ah, one thing that was missing is that you can set a list of allowed encodings like "--encodings=h264,rgb". I am, perhaps, using a difficult application to handle, Firefox. As that gives me the ability to experiment with widgets, images, videos etc easily. In the end am experimenting to see what is possible for remote access to a set of seismic data processing servers with GUI applications to show data in graphical form and interact with these. I am trying to see how near local application latency/quality is possible these days. > > (..) >> xpra now works with me when "--encodings=h264" is set. Generally the >> latancy/flickering is better than in auto. > That's odd. Using "h264" alone will waste a lot of CPU and bandwidth. > (assuming that it is actually used) > The latency really depends on a large number of factors so I can't > comment without knowing more. > But there should be no flickering no matter which encoding is used. In this case the flickering is during a screen update of Firefox. Click on a link and the screen updates but then various areas update again a few times (probably the images). With the h264 only encoding this was much less pronounced (maybe as a whole of screen update was used and perhaps there is a delay before this is sent after the application updates the window buffer). > >> One thing that is interesting >> is the CPU usage on the server side. Using firefox as a test client and >> clicking on different web pages and waiting the server's CPU usage can >> be around 15% > Do you have audio forwarding running? > If there are no screen updates, the server CPU usage should be very > close to zero. > >> after than or sometimes 100% or 200% and then sticks at >> those values even though the page looks static after that. > You can turn on "damage" and "compress" debugging on your server to see > if it is receiving / sending screen updates: > xpra start -d damage,compress > * "damage" corresponds to application paint events > * "compress" logs the type of picture compression used > > You can also see which encoding is used for each screen update using the > colour coded client debug switch: > xpra attach --no-mmap --env=XPRA_PAINT_BOX=1 > The color codes are defined here: > https://github.com/Xpra-org/xpra/blob/master/xpra/client/paint_colors.py Thanks for the information. I will play with those options next time I see this. I suspect it is the use of Firefox on a page with something being updated all of the time (although I didn't see anything) and with h264 lots of whole window screen updates are happening for small areas. > >> I assume that my xpra server here is using software h264 from those >> figures. > Assuming that it is actually using "h264" for all the screen updates - > which is not guaranteed. > >> Is there anyway to determine if xpra is using hardware h264 if >> I have managed to configure for that ? > In theory, hardware acceleration should be used automatically if it is > available. > The only acceleration that is well tested is with NVENC. > > You can see which encoders are available on your system with: > xpra encoding > xpra video > > Again, just because hardware acceleration is available on your system > does not mean that it should be used for every screen updates. > In many cases, the server engine will prefer software encoding because > it is more suitable. Ok on both systems there is the line "found 3 vaapi codecs: h264, hevc, mpeg2", so it looks like they are available. Is there anyway of forcing hardware encode (just for experimentation) ? Where I am coming from is to see how possible it is to have a low latency, good quality remote GUI program access these days for a scientific data processing server as mentioned above and was wondering how well using modern hardware h264/h265 encoding would work for this particular usage. As a background I have tried using gstreamer to simulate this usage between two machines connected using OpenVPN over a 30 MBits/s Internet connection. With this I could run 3 x 1024x768 at 30Hz h264 encoded video streams across the network with the following CPU usage: Server: 4 Cores, 4 HyperThreads, Intel(R) Xeon(R) CPU E3-1245 v5 @ 3.50GHz Client: 6 Cores, 0 HyperThreads, Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz 1 Application Host??? ??? Process??? ssh??? System ======================================= CPU Beam:??? 18%??? 1%??? 3% CPU Study??? 7.6%??? 4%??? 5% 3 Applications Host??? ??? Process??? ssh??? OveralSystem ======================================= CPU Beam:??? 3*18%??? 3*1%??? 9% CPU Study??? 3*7.6% ??? 3*4%??? 12% NetworkRate:??? 3.2 MByte/s So very low CPU usage and reasonable network bandwidth (default h264 encoder options used). Maybe naive, as I haven't looked into the issues in detail, but from this it seems it might be possible to simply send the whole application window at, say, 30 frames per second, stopping when there has been no activity for a time and continuing h264 encoding where it left off so using the h264 compression to handle the minor screen changes on its own (I know not the best for a GUI type update but simple and in hardware). I was hoping to simulate such a mode in xpra to see how well this might work. Terry From antoine at nagafix.co.uk Wed May 26 10:58:30 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 May 2021 16:58:30 +0700 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> Message-ID: <2ff31121-409d-1f76-bf24-19f309a4d762@nagafix.co.uk> On 26/05/2021 14:52, Terry Barnaby via shifter-users wrote: > Thanks for the reply and your work on xpra. I certainly looks a good > remote desktop access system especially with the individual application > support. > > On 26/05/2021 05:39, Antoine Martin via shifter-users wrote: >> (..) >>> I much prefer to use base system packages wherever possible. >> Me too, normally. >> Unfortunately, it's just painful to use xpra with the system packages. > > Is there any reason why the Fedora system packages should be so > different ? I can see they wouldn't be so up-to-date but I would have > thought the Fedora maintainer would take the upstream as close as > possible. It would be a better user experience and probably less support > if they were basically the same. Agreed. It's really disappointing that this is not the case. (..) >> >> --encodings vs --encoding > > Ah, one thing that was missing is that you can set a list of allowed > encodings like "--encodings=h264,rgb". > > I am, perhaps, using a difficult application to handle, Firefox. As that > gives me the ability to experiment with widgets, images, videos etc > easily. Yes, browsers are the most difficult type of application to handle as the same window, with the same metadata, can contain text or pictures or even video, often all of them at once. The ability to scroll up and down makes this even more difficult to handle. > In the end am experimenting to see what is possible for remote > access to a set of seismic data processing servers with GUI applications > to show data in graphical form and interact with these. I am trying to > see how near local application latency/quality is possible these days. Users of such applications usually have CPU and bandwidth to spare, and they achieve near local latency and quality. Xpra is quite popular for this type of application. You may want to add your application and / or specific windows to the mappings in: /etc/xpra/content-* >> (..) >>> xpra now works with me when "--encodings=h264" is set. Generally the >>> latancy/flickering is better than in auto. >> That's odd. Using "h264" alone will waste a lot of CPU and bandwidth. >> (assuming that it is actually used) >> The latency really depends on a large number of factors so I can't >> comment without knowing more. >> But there should be no flickering no matter which encoding is used. > > In this case the flickering is during a screen update of Firefox. Click > on a link and the screen updates but then various areas update again a > few times (probably the images). With the h264 only encoding this was > much less pronounced (maybe as a whole of screen update was used and > perhaps there is a delay before this is sent after the application > updates the window buffer). Right, that makes sense. (..) >>> Is there anyway to determine if xpra is using hardware h264 if >>> I have managed to configure for that ? >> In theory, hardware acceleration should be used automatically if it is >> available. >> The only acceleration that is well tested is with NVENC. >> >> You can see which encoders are available on your system with: >> xpra encoding >> xpra video >> >> Again, just because hardware acceleration is available on your system >> does not mean that it should be used for every screen updates. >> In many cases, the server engine will prefer software encoding because >> it is more suitable. > > Ok on both systems there is the line "found 3 vaapi codecs: h264, hevc, > mpeg2", so it looks like they are available. Is there anyway of forcing > hardware encode (just for experimentation) ? --video-encoders=ffmpeg Will only load the ffmpeg encoder, which is the one that does vaapi. (but that's not ideal - see below) This is a fairly generic API and I only have one active system that supports it, so I cannot guarantee that other cards / CPU will work well with it. NVENC is proprietary, but it works fairly consistently across a wide range of cards, and it is much faster too. Hardware encoders score higher than software encoders and will be used automatically unless the stream is brand new and instantiating a hardware encoder may take too long. > Where I am coming from is to see how possible it is to have a low > latency, good quality remote GUI program access these days for a > scientific data processing server as mentioned above and was wondering > how well using modern hardware h264/h265 encoding would work for this > particular usage. As a background I have tried using gstreamer to > simulate this usage between two machines connected using OpenVPN over a > 30 MBits/s Internet connection. With this I could run 3 x 1024x768 at 30Hz > h264 encoded video streams across the network with the following CPU usage: (..) 30Mbps should be enough for 4K30Hz. > > So very low CPU usage and reasonable network bandwidth (default h264 > encoder options used). Maybe naive, as I haven't looked into the issues > in detail, but from this it seems it might be possible to simply send > the whole application window at, say, 30 frames per second, stopping > when there has been no activity for a time and continuing h264 encoding > where it left off so using the h264 compression to handle the minor > screen changes on its own (I know not the best for a GUI type update but > simple and in hardware). I was hoping to simulate such a mode in xpra to > see how well this might work. The devil is in the details. You can also use hints to tell the xpra server to prefer video encoders. But: * it should not be used for all the popup windows, menus and tooltips that the application may use - those are small and short lived * it cannot be used for windows that use transparency - and some applications use transparency despite being completely opaque.. * lossy screen updates from video codecs trigger an automatic lossless refresh, which you can turn off if you wish: --auto-refresh-delay=0 * when there aren't many screen updates for a while, it may choose to use a lossless picture codec instead (which avoids the refresh) * hardware accelerated encoders take longer to initialize, so the server may start with a software encoder (x264) to prevent the screen updates from stuttering, or use jpeg until the video encoder is ready * if the server decides that the performance is inadequate, it may choose to subsample the data used as input to the encoder, or even downscale it etc.. Almost all of these characteristics can be tuned, but that's not normally needed. Cheers Antoine > > Terry > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From mike at cchtml.com Wed May 26 13:06:08 2021 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 26 May 2021 07:06:08 -0500 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> Message-ID: On 5/26/21 2:52 AM, Terry Barnaby via shifter-users wrote: > Is there any reason why the Fedora system packages should be so different ? I can > see they wouldn't be so up-to-date but I would have thought the Fedora maintainer > would take the upstream as close as possible. It would be a better user experience > and probably less support if they were basically the same. Most video codecs are patented. H.264* and HEVC still have active patents that require licensing. Fedora does not ship software that is encumbered by patents that requires licensing. Xpra relies on ffmpeg and ffmpeg cannot be shipped in Fedora so the Fedora repositories ship a version of Xpra with all of the patent encumbered features disabled. RPMFusion is a third-party repository that lives outside the USA where Fedora is based. You could have Xpra shipped in RPMFusion and have all of Xpra's features turned on and available. It's entirely possible for Antoine to ship his packages there instead of his own repository. Regards, Michael * OpenH.264 is shipped in Fedora, but it has limited format support and it is a plugin for Firefox. From antoine at nagafix.co.uk Wed May 26 13:43:00 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 May 2021 19:43:00 +0700 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> Message-ID: <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> On 26/05/2021 19:06, Michael Cronenworth via shifter-users wrote: > On 5/26/21 2:52 AM, Terry Barnaby via shifter-users wrote: >> Is there any reason why the Fedora system packages should be so >> different ? I can see they wouldn't be so up-to-date but I would have >> thought the Fedora maintainer would take the upstream as close as >> possible. It would be a better user experience and probably less >> support if they were basically the same. > > Most video codecs are patented. H.264* and HEVC still have active > patents that require licensing. Fedora does not ship software that is > encumbered by patents that requires licensing. Xpra relies on ffmpeg and For the sake of completeness, this is not 100% accurate: ffmpeg can be built under the GPL license and without the nonfree codecs. xpra's ffmpeg encoder which we are discussing in this thread can be enabled without those. Whether that's practical or not is another question. > ffmpeg cannot be shipped in Fedora so the Fedora repositories ship a > version of Xpra with all of the patent encumbered features disabled.> > RPMFusion is a third-party repository that lives outside the USA where > Fedora is based. You could have Xpra shipped in RPMFusion and have all > of Xpra's features turned on and available. It's entirely possible for > Antoine to ship his packages there instead of his own repository. There's a lot more to this than just the patented codec issue: https://github.com/Xpra-org/xpra/wiki/Distribution-Packages Cheers, Antoine > > Regards, > Michael > > > * OpenH.264 is shipped in Fedora, but it has limited format support and > it is a plugin for Firefox. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From mike at cchtml.com Wed May 26 13:56:35 2021 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 26 May 2021 07:56:35 -0500 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> Message-ID: <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> On 5/26/21 7:43 AM, Antoine Martin via shifter-users wrote: > For the sake of completeness, this is not 100% accurate: ffmpeg can be > built under the GPL license and without the nonfree codecs. > xpra's ffmpeg encoder which we are discussing in this thread can be > enabled without those. > Whether that's practical or not is another question. You're being extremely pedantic. Let's back up. Sure, it can. Will anyone package and ship it in Fedora that way? No. Besides the enormous effort to strip out the patented code the handful of codecs that would remain wouldn't make it useful. Disabling the codecs at build time is not enough if we want to be pedantic. > There's a lot more to this than just the patented codec issue: > https://github.com/Xpra-org/xpra/wiki/Distribution-Packages I think you missed my point. I was not saying "package the Fedora version into RPMFusion" -- I was saying take your (xpra.org) packages and ship them in RPMFusion. From terry at beam.ltd.uk Wed May 26 14:17:50 2021 From: terry at beam.ltd.uk (Terry Barnaby) Date: Wed, 26 May 2021 14:17:50 +0100 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> Message-ID: <24c980d1-b037-8797-8749-09cdc3444209@beam.ltd.uk> On 26/05/2021 13:56, Michael Cronenworth via shifter-users wrote: > On 5/26/21 7:43 AM, Antoine Martin via shifter-users wrote: >> For the sake of completeness, this is not 100% accurate: ffmpeg can be >> built under the GPL license and without the nonfree codecs. >> xpra's ffmpeg encoder which we are discussing in this thread can be >> enabled without those. >> Whether that's practical or not is another question. > > You're being extremely pedantic. Let's back up. > > Sure, it can. Will anyone package and ship it in Fedora that way? No. > Besides the enormous effort to strip out the patented code the handful > of codecs that would remain wouldn't make it useful. Disabling the > codecs at build time is not enough if we want to be pedantic. > >> There's a lot more to this than just the patented codec issue: >> https://github.com/Xpra-org/xpra/wiki/Distribution-Packages > > I think you missed my point. I was not saying "package the Fedora > version into RPMFusion" -- I was saying take your (xpra.org) packages > and ship them in RPMFusion. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users As a slight aside to this. My "dnf install xpra" from the Fedora33 repositories + rpmfusion + fedora-cisco-openh264 repositories does in fact have h264 and h265 support. So I presume the Fedora33 standard ffmpeg is being extended to support h264 by "plugin" h264 packages from those external repos. I'm not sure it supports hardware vaapi h264/h265 though. Actually I see that the Fedora33 xpra is using xpra-codecs-freeworld from rpmfusion. I presume with those hardware codecs the license is with the hardware ? xpra encoding codecs and csc modules found: * csc_cython?????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/csc_cython/colorspace_converter.cpython-39-x86_64-linux-gnu.so * csc_libyuv?????????? : * csc_swscale????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/csc_swscale/colorspace_converter.cpython-39-x86_64-linux-gnu.so * dec_avcodec2???????? : /usr/lib64/python3.9/site-packages/xpra/codecs/dec_avcodec2/decoder.cpython-39-x86_64-linux-gnu.so * dec_jpeg???????????? : * dec_pillow?????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/pillow/decoder.py * dec_vpx????????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/vpx/decoder.cpython-39-x86_64-linux-gnu.so * dec_webp???????????? : * enc_ffmpeg?????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/enc_ffmpeg/encoder.cpython-39-x86_64-linux-gnu.so * enc_jpeg???????????? : * enc_pillow?????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/pillow/encoder.py * enc_vpx????????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/vpx/encoder.cpython-39-x86_64-linux-gnu.so * enc_webp???????????? : * enc_x264???????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/enc_x264/encoder.cpython-39-x86_64-linux-gnu.so * enc_x265???????????? : /usr/lib64/python3.9/site-packages/xpra/codecs/enc_x265/encoder.cpython-39-x86_64-linux-gnu.so * nvenc??????????????? : codecs versions: * avcodec2??????????????????????? : 58.91.100 * cython????????????????????????? : 4.1 * ffmpeg????????????????????????? : 58.91.100 * numpy?????????????????????????? : 1.19.4 * pillow????????????????????????? : 7.2.0 * swscale???????????????????????? : 5.7.100 * vpx???????????????????????????? : 1.9.0 * x264??????????????????????????? : 160 * x265??????????????????????????? : 3.4 Terry From antoine at nagafix.co.uk Wed May 26 14:24:48 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 May 2021 20:24:48 +0700 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> Message-ID: On 26/05/2021 19:56, Michael Cronenworth via shifter-users wrote: > On 5/26/21 7:43 AM, Antoine Martin via shifter-users wrote: >> For the sake of completeness, this is not 100% accurate: ffmpeg can be >> built under the GPL license and without the nonfree codecs. >> xpra's ffmpeg encoder which we are discussing in this thread can be >> enabled without those. >> Whether that's practical or not is another question. > > You're being extremely pedantic. I would prefer "accurate". But we're really digressing here. > Let's back up.> > Sure, it can. Will anyone package and ship it in Fedora that way? No. > Besides the enormous effort to strip out the patented code I don't think it is as hard as you think: don't use --enable-nonfree and do enable --enable-gpl > the handful > of codecs that would remain wouldn't make it useful. It would be useful enough for xpra, in the context of what we're discussing in this thread. (I haven't checked - I assume that the libva code is GPL) > Disabling the > codecs at build time is not enough if we want to be pedantic. Let's digress a bit more then: why not? >> There's a lot more to this than just the patented codec issue: >> https://github.com/Xpra-org/xpra/wiki/Distribution-Packages > > I think you missed my point. I was not saying "package the Fedora > version into RPMFusion" -- I was saying take your (xpra.org) packages > and ship them in RPMFusion. Ah. I'm not sure what the process would be here. Worth looking into I guess. Cheers, Antoine From mike at cchtml.com Wed May 26 14:29:58 2021 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 26 May 2021 08:29:58 -0500 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> Message-ID: <3214009f-fb12-9f77-b57c-8fc03500c7a0@cchtml.com> On 5/26/21 8:24 AM, Antoine Martin via shifter-users wrote: >> Disabling the >> codecs at build time is not enough if we want to be pedantic. > Let's digress a bit more then: why not? > As someone who has worked with patented software and seen what Fedora Legal (a.k.a. Red Hat Legal) requires for publishing software in Fedora repositories I feel I am accurately representing what is required. You cannot ship the *source code* or binaries of patented software in Fedora. From mike at cchtml.com Wed May 26 14:30:12 2021 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 26 May 2021 08:30:12 -0500 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <24c980d1-b037-8797-8749-09cdc3444209@beam.ltd.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> <24c980d1-b037-8797-8749-09cdc3444209@beam.ltd.uk> Message-ID: On 5/26/21 8:17 AM, Terry Barnaby via shifter-users wrote: > As a slight aside to this. My "dnf install xpra" from the Fedora33 repositories + > rpmfusion + fedora-cisco-openh264 repositories does in fact have h264 and h265 > support. So I presume the Fedora33 standard ffmpeg is being extended to support > h264 by "plugin" h264 packages from those external repos. I'm not sure it supports > hardware vaapi h264/h265 though. > No. FFMpeg does not support plugins. Installing 'xpra' will only install the Fedora package. Fedora packages cannot require an external package such as from RPMFusion (xpra-codecs-freeworld). You installed this yourself. > Actually I see that the Fedora33 xpra is using xpra-codecs-freeworld from rpmfusion. Correct. It is possible to ship packages in RPMFusion that could either replace or extend software that requires patent encumbered software. The 'xpra-codecs-freeworld' package allows linking with ffmpeg and extending xpra support. Anyone could correct Fedora packaging to match upstream's (Antoine's) standards. Fedora is not a closed ecosystem. Many upstream maintainers publish their own packages directly in Fedora. > I presume with those hardware codecs the license is with the hardware ? No. From antoine at nagafix.co.uk Wed May 26 14:30:37 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 May 2021 20:30:37 +0700 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <24c980d1-b037-8797-8749-09cdc3444209@beam.ltd.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> <24c980d1-b037-8797-8749-09cdc3444209@beam.ltd.uk> Message-ID: <685477ce-45d5-5d3d-656b-f8f6d4389f2a@nagafix.co.uk> > As a slight aside to this. My "dnf install xpra" from the Fedora33 > repositories + rpmfusion + fedora-cisco-openh264 repositories does in > fact have h264 and h265 support. So I presume the Fedora33 standard > ffmpeg is being extended to support h264 by "plugin" h264 packages from > those external repos. I'm not sure it supports hardware vaapi h264/h265 > though. > > Actually I see that the Fedora33 xpra is using xpra-codecs-freeworld > from rpmfusion. > > I presume with those hardware codecs the license is with the hardware ? IANAL but I believe you are correct. > xpra encoding > codecs and csc modules found: (..) * no libyuv csc * no webp and jpeg decoders or encoders * x265 is force enabled This is just a terrible set of compilation options and a perfect example of why downstream packages should be avoided. Cheers, Antoine > Terry > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From terry at beam.ltd.uk Wed May 26 14:44:04 2021 From: terry at beam.ltd.uk (Terry Barnaby) Date: Wed, 26 May 2021 14:44:04 +0100 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> <24c980d1-b037-8797-8749-09cdc3444209@beam.ltd.uk> Message-ID: <5bc35bbd-aeac-d40e-db91-e25e14ff7418@beam.ltd.uk> On 26/05/2021 14:30, Michael Cronenworth via shifter-users wrote: > On 5/26/21 8:17 AM, Terry Barnaby via shifter-users wrote: >> As a slight aside to this. My "dnf install xpra" from the Fedora33 >> repositories + rpmfusion + fedora-cisco-openh264 repositories does in >> fact have h264 and h265 support. So I presume the Fedora33 standard >> ffmpeg is being extended to support h264 by "plugin" h264 packages >> from those external repos. I'm not sure it supports hardware vaapi >> h264/h265 though. >> > > No. FFMpeg does not support plugins. > > Installing 'xpra' will only install the Fedora package. Fedora > packages cannot require an external package such as from RPMFusion > (xpra-codecs-freeworld). You installed this yourself. > >> Actually I see that the Fedora33 xpra is using xpra-codecs-freeworld >> from rpmfusion. > > Correct. It is possible to ship packages in RPMFusion that could > either replace or extend software that requires patent encumbered > software. The 'xpra-codecs-freeworld' package allows linking with > ffmpeg and extending xpra support. Anyone could correct Fedora > packaging to match upstream's (Antoine's) standards. Fedora is not a > closed ecosystem. Many upstream maintainers publish their own packages > directly in Fedora. > >> I presume with those hardware codecs the license is with the hardware ? > > No. Are you sure that hardware based H264/HEVC encoder/decoder usage license is not covered by the manufacturer/supplier of the hardware codecs ? From mike at cchtml.com Wed May 26 14:57:59 2021 From: mike at cchtml.com (Michael Cronenworth) Date: Wed, 26 May 2021 08:57:59 -0500 Subject: [winswitch] Fedora33 xpra h264 encoding support not working In-Reply-To: <5bc35bbd-aeac-d40e-db91-e25e14ff7418@beam.ltd.uk> References: <1eba35ac-77bf-b398-8dd4-18ba4fa9b2ff@beam.ltd.uk> <1edf46a5-fa77-4a10-978f-63075cf566ad@nagafix.co.uk> <010e7b7f-2bd0-033c-1f7b-b0c349c32f4f@nagafix.co.uk> <560a481c-4906-cee0-157d-3251155b7ecf@beam.ltd.uk> <47ecbee9-b703-b39c-4279-6ce4c4b4fa0b@nagafix.co.uk> <68e8b4af-82f4-2bb4-43b8-c383ead34a64@cchtml.com> <24c980d1-b037-8797-8749-09cdc3444209@beam.ltd.uk> <5bc35bbd-aeac-d40e-db91-e25e14ff7418@beam.ltd.uk> Message-ID: <0857123f-d9da-b9c3-28fa-91b86c5fc890@cchtml.com> On 5/26/21 8:44 AM, Terry Barnaby via shifter-users wrote: > Are you sure that hardware based H264/HEVC encoder/decoder usage license is not > covered by the manufacturer/supplier of the hardware codecs ? Sorry, I was reading your message as "does my hardware allow me to freely use codecs" so please ignore my answer. From yonatan.zaken at gmail.com Fri May 28 13:02:37 2021 From: yonatan.zaken at gmail.com (yonatan zaken) Date: Fri, 28 May 2021 15:02:37 +0300 Subject: [winswitch] How to disable redirecting to log file In-Reply-To: <5f357d40-9f37-64a3-be13-422d76d32bfd@nagafix.co.uk> References: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> <5f357d40-9f37-64a3-be13-422d76d32bfd@nagafix.co.uk> Message-ID: Thank Antoine, I will try this. Last question on this matter, is there any way to disable gnerating the :#.log files under /run/user/500/xpra/... ? *Cheers,* *Yonatan* On Mon, 10 May 2021 at 09:41, Antoine Martin wrote: > On 10/05/2021 12:36, yonatan zaken wrote: > > Hi Peter, thanks for the reply. > > I actually used this notation: >& > > For some reason I miss typed it in the quoted line. > > > > As I said, this works for me when running xpra start on a local machine > > but generated the error when using it on a remote machine. > That's because you're on an outdated 1.x version, it generates the ssh > command line without proper quoting. > Newer versions use the paramiko ssh backend by default which does not > rely on escaping strings, and even the ssh backend has been re-worked to > support nesting and quotes more correctly. > > If you have to stick with this outdated version, use the script approach > I had suggested in my first reply. > You can probably make this completely transparent by placing these > wrapper scripts in /usr/local/bin with the same name as the real binary > (just make sure to invoke the binary with its full path) and ensuring > /usr/local/bin comes first in the $PATH. > > Cheers, > Antoine > > > > */ > > /* > > */Cheers,/* > > */Yonatan/* > > * > > * > > > > > > > > On Mon, 10 May 2021 at 03:50, Peter Swain > > wrote: > > > > Yonatan, you've mixed two different notations here > > > > Use > > &>/dev/null > > or > > >&- 2>&- > > > > On Sun, May 9, 2021, 9:02 AM yonatan zaken via shifter-users > > > > wrote: > > > > Hi Antoine, Thanks for the response! > > > > I tried the following: > > > > > Why don't you just redirect the output of your noisy command? > > > xpra start --start="bash -c 'therealcommand &> /dev/null'" > > > > > > When trying to start a local session it works fine and stdout of > > the noisy > > command is redirected to /dev/null. > > But when trying to run the command on a remote machine I get the > > following > > error: > > > > Ambiguous output redirect. > > 2021-05-09 20:43:16,088 Error: SSH connection to the xpra server > > failed > > 2021-05-09 20:43:16,088 check your username, hostname, display > > number, > > firewall, etc > > 2021-05-09 20:43:16,088 for server: ssh:pci at 172.00.00.26 > > > > 2021-05-09 20:43:16,088 the command line used was: > > 2021-05-09 20:43:16,088 ssh -x -l pci -T 172.19.31.26 sh -c > 'xpra > > initenv;~/.xpra/run-xpra _proxy_start "--start-child=bash -c > > 'therealcommand >& /dev/null'" --exit-with-children --mmap-group > || > > $XDG_RUNTIME_DIR/xpra/run-xpra _proxy_start "--start-child=bash > -c > > 'therealcommand >& /dev/null'" --exit-with-children --mmap-group > > || xpra > > _proxy_start "--start-child=bash -c 'therealcommand >& > /dev/null'" > > --exit-with-children --mmap-group' > > > > Any idea how to overcome this ? > > > > *Cheers,* > > *Yonatan* > > > > > > > > > > On Sun, 9 May 2021 at 15:28, Antoine Martin via shifter-users < > > shifter-users at lists.devloop.org.uk > > > wrote: > > > > > On 09/05/2021 14:56, yonatan zaken via shifter-users wrote: > > > > Hi All, > > > > My platform: Linux Kubuntu 14 > > > > xpra version: xpra v1.0.12-r19800 > > > > > > > > I am trying to find a way to disable the redirecting of the > > xpra server > > > > output to the log file. > > > If you run your server with "--no-daemon" then the output will > > just go > > > to stdout. You can then redirect that wherever you like: > > > nohup xpra start --start=noisycommand --no-daemon >& /dev/null > & > > > > > > > The application that I run via. xpra start generates large > > amounts of > > > data > > > > to stdout causing the ":1.log" file to be very large. This > > causes me > > > > trouble since the /run/user is left with no space sometimes. > > > So the problem is not caused by the xpra server but by your > > unspecified > > > application. > > > > > > > I tried adding the following flag to the xpra.conf file: > > > > remote-logging=no > > > Remote logging has nothing to do with it. > > > That's for sending the client's log messages to the server. > > > (and in newer versions, also back the other way) > > > > > > > But i still see the applications output directed to the .log > > file. > > > > > > > > Any suggestions how to disable the redirecting of the > > applications stdout > > > > to the log file? > > > Why don't you just redirect the output of your noisy command? > > > xpra start --start="bash -c 'therealcommand &> /dev/null'" > > > > > > You could also create a wrapper script to do the same thing: > > > cat > /usr/bin/mycommand-wrapper << EOF > > > #!/bin/bash > > > mycommand $@ >& /dev/null > > > EOF > > > chmod +x /usr/bin/mycommand-wrapper > > > > > > Cheers, > > > Antoine > > > > > > > > > > > > > > *Cheers,* > > > > *Yonatan* > > > > _______________________________________________ > > > > 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 > > > > > > > _______________________________________________ > > 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 May 28 14:50:57 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 28 May 2021 20:50:57 +0700 Subject: [winswitch] How to disable redirecting to log file In-Reply-To: References: <8016ac2d-35d5-2c37-03ba-a5d280c7d534@nagafix.co.uk> <5f357d40-9f37-64a3-be13-422d76d32bfd@nagafix.co.uk> Message-ID: On 28/05/2021 19:02, yonatan zaken wrote: > Thank Antoine, I will try this. > Last question on this matter, is there any way to disable?gnerating the > :#.log files under /run/user/500/xpra/... ? You could do: "xpra start --log-file=/dev/null" The same thing could be used for the Xvfb log file. Cheers, Antoine > > */Cheers,/* > */Yonatan/* > * > * > > > > On Mon, 10 May 2021 at 09:41, Antoine Martin > wrote: > > On 10/05/2021 12:36, yonatan zaken wrote: > > Hi Peter, thanks for the reply. > > I actually used this notation: >& > > For some reason I miss typed it in the quoted line. > > > > As I said, this works for me when running xpra start on a local > machine > > but generated the error when using it on a remote machine. > That's because you're on an outdated 1.x version, it generates the ssh > command line without proper quoting. > Newer versions use the paramiko ssh backend by default which does not > rely on escaping strings, and even the ssh backend has been re-worked to > support nesting and quotes more correctly. > > If you have to stick with this outdated version, use the script approach > I had suggested in my first reply. > You can probably make this completely transparent by placing these > wrapper scripts in /usr/local/bin with the same name as the real binary > (just make sure to invoke the binary with its full path) and ensuring > /usr/local/bin comes first in the $PATH. > > Cheers, > Antoine > > > > */ > > /* > > */Cheers,/* > > */Yonatan/* > > * > > * > > > > > > > > On Mon, 10 May 2021 at 03:50, Peter Swain > > >> wrote: > > > >? ? ?Yonatan, you've mixed two different notations here > > > >? ? ?Use > >? ? ?? &>/dev/null > >? ? ?or > >? ? ?? >&- 2>&- > > > >? ? ?On Sun, May 9, 2021, 9:02 AM yonatan zaken via shifter-users > >? ? ? > >? ? ? >> wrote: > > > >? ? ? ? ?Hi Antoine, Thanks for the response! > > > >? ? ? ? ?I tried the following: > > > >? ? ? ? ?> Why don't you just redirect the output of your noisy > command? > >? ? ? ? ?> xpra start --start="bash -c 'therealcommand &> /dev/null'" > > > > > >? ? ? ? ?When trying to start a local session it works fine and > stdout of > >? ? ? ? ?the noisy > >? ? ? ? ?command is redirected to /dev/null. > >? ? ? ? ?But when trying to run the command on a remote machine I > get the > >? ? ? ? ?following > >? ? ? ? ?error: > > > >? ? ? ? ??Ambiguous output redirect. > >? ? ? ? ?2021-05-09 20:43:16,088 Error: SSH connection to the xpra > server > >? ? ? ? ?failed > >? ? ? ? ?2021-05-09 20:43:16,088? check your username, hostname, > display > >? ? ? ? ?number, > >? ? ? ? ?firewall, etc > >? ? ? ? ?2021-05-09 20:43:16,088? for server: ssh:pci at 172.00.00.26 > > >? ? ? ? ? > > >? ? ? ? ?2021-05-09 20:43:16,088? the command line used was: > >? ? ? ? ?2021-05-09 20:43:16,088? ssh -x -l pci -T 172.19.31.26 sh > -c 'xpra > >? ? ? ? ?initenv;~/.xpra/run-xpra _proxy_start "--start-child=bash -c > >? ? ? ? ?'therealcommand >& /dev/null'" --exit-with-children > --mmap-group || > >? ? ? ? ?$XDG_RUNTIME_DIR/xpra/run-xpra _proxy_start > "--start-child=bash -c > >? ? ? ? ?'therealcommand >& /dev/null'" --exit-with-children > --mmap-group > >? ? ? ? ?|| xpra > >? ? ? ? ?_proxy_start "--start-child=bash -c 'therealcommand >& > /dev/null'" > >? ? ? ? ?--exit-with-children --mmap-group' > > > >? ? ? ? ?Any idea how to overcome this ? > > > >? ? ? ? ?*Cheers,* > >? ? ? ? ?*Yonatan* > > > > > > > > > >? ? ? ? ?On Sun, 9 May 2021 at 15:28, Antoine Martin via > shifter-users < > >? ? ? ? ?shifter-users at lists.devloop.org.uk > > >? ? ? ? ? >> wrote: > > > >? ? ? ? ?> On 09/05/2021 14:56, yonatan zaken via shifter-users wrote: > >? ? ? ? ?> > Hi All, > >? ? ? ? ?> > My platform: Linux Kubuntu 14 > >? ? ? ? ?> > xpra version: xpra v1.0.12-r19800 > >? ? ? ? ?> > > >? ? ? ? ?> > I am trying to find a way to disable the redirecting > of the > >? ? ? ? ?xpra server > >? ? ? ? ?> > output to the log file. > >? ? ? ? ?> If you run your server with "--no-daemon" then the > output will > >? ? ? ? ?just go > >? ? ? ? ?> to stdout. You can then redirect that wherever you like: > >? ? ? ? ?> nohup xpra start --start=noisycommand --no-daemon >& > /dev/null & > >? ? ? ? ?> > >? ? ? ? ?> > The application that I run via. xpra start generates large > >? ? ? ? ?amounts of > >? ? ? ? ?> data > >? ? ? ? ?> > to stdout causing the ":1.log" file to be very large. This > >? ? ? ? ?causes me > >? ? ? ? ?> > trouble since the /run/user is left with no space > sometimes. > >? ? ? ? ?> So the problem is not caused by the xpra server but by your > >? ? ? ? ?unspecified > >? ? ? ? ?> application. > >? ? ? ? ?> > >? ? ? ? ?> > I tried adding the following flag to the xpra.conf file: > >? ? ? ? ?> > remote-logging=no > >? ? ? ? ?> Remote logging has nothing to do with it. > >? ? ? ? ?> That's for sending the client's log messages to the server. > >? ? ? ? ?> (and in newer versions, also back the other way) > >? ? ? ? ?> > >? ? ? ? ?> > But i still see the applications output directed to > the .log > >? ? ? ? ?file. > >? ? ? ? ?> > > >? ? ? ? ?> > Any suggestions how to disable the redirecting of the > >? ? ? ? ?applications stdout > >? ? ? ? ?> > to the log file? > >? ? ? ? ?> Why don't you just redirect the output of your noisy > command? > >? ? ? ? ?> xpra start --start="bash -c 'therealcommand &> /dev/null'" > >? ? ? ? ?> > >? ? ? ? ?> You could also create a wrapper script to do the same thing: > >? ? ? ? ?> cat > /usr/bin/mycommand-wrapper << EOF > >? ? ? ? ?> #!/bin/bash > >? ? ? ? ?> mycommand $@ >& /dev/null > >? ? ? ? ?> EOF > >? ? ? ? ?> chmod +x /usr/bin/mycommand-wrapper > >? ? ? ? ?> > >? ? ? ? ?> Cheers, > >? ? ? ? ?> Antoine > >? ? ? ? ?> > >? ? ? ? ?> > >? ? ? ? ?> > > >? ? ? ? ?> > *Cheers,* > >? ? ? ? ?> > *Yonatan* > >? ? ? ? ?> > _______________________________________________ > >? ? ? ? ?> > 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 > > >? ? ? ? > ? > > >? ? ? ? ?> > >? ? ? ? ?_______________________________________________ > >? ? ? ? ?shifter-users mailing list > >? ? ? ? ?shifter-users at lists.devloop.org.uk > > >? ? ? ? ? > > >? ? ? ? > ?https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > >? ? ? ? > ? > > > >