From thomase00 at yahoo.com Sat Oct 1 05:28:20 2016 From: thomase00 at yahoo.com (Thomas Esposito) Date: Sat, 1 Oct 2016 00:28:20 -0400 Subject: [winswitch] can't connect with windows 7 client Message-ID: I'm running an xpra server on a redhat el6.6 remote redhat el 6.6 virtual machine. I don't have root permissions, so I did the following: 1.) Downloaded the following rpms to my home directory: Cython-0.24.1-1.el6_6.x86_64.rpm ffmpeg-xpra-3.1.3-1.el6_6.x86_64.rpm ffmpeg-xpra-devel-3.1.3-1.el6_6.x86_64.rpm gstreamer-plugins-ugly-0.10.18-4.el6.x86_64.rpm libfakeXinerama-0.1.0-3.el6.x86_64.rpm libvpx-xpra-1.6.0-1.el6_6.x86_64.rpm libvpx-xpra-devel-1.6.0-1.el6_6.x86_64.rpm libwebp-xpra-0.5.0-1.el6_6.x86_64.rpm libwebp-xpra-devel-0.5.0-1.el6_6.x86_64.rpm lz4-devel-r131-1.el6_6.x86_64.rpm lz4-r131-1.el6_6.x86_64.rpm lz4-static-r131-1.el6_6.x86_64.rpm PyOpenGL-3.1.1a1r1-1.el6.noarch.rpm PyOpenGL-accelerate-3.1.1a1r1-1.el6.x86_64.rpm PyOpenGL-Tk-3.1.1a1r1-1.el6.noarch.rpm python-crypto-2.6.1-2.el6.x86_64.rpm python-lz4-0.8.2-1.el6_6.x86_64.rpm python-netifaces-0.10.4-3.el6_6.x86_64.rpm python-pillow-3.2.0-1.el6_6.x86_64.rpm python-pillow-devel-3.2.0-1.el6_6.x86_64.rpm python-pillow-qt-3.2.0-1.el6_6.x86_64.rpm python-pillow-sane-2.6.1-1.el6.x86_64.rpm python-pillow-tk-3.2.0-1.el6_6.x86_64.rpm python-pycuda-2015.1-1.x86_64.rpm python-pyopengl-3.1.1a1-4.1xpra3.el6_6.x86_64.rpm python-pyopengl-tk-3.1.1a1-4.1xpra3.el6_6.noarch.rpm python-pytools-2015.1.2-1.el6.noarch.rpm python-rencode-1.0.5-1.el6_6.x86_64.rpm winswitch-0.12.22-1.x86_64.rpm x264-xpra-20160704-1.el6_6.x86_64.rpm x264-xpra-devel-20160704-1.el6_6.x86_64.rpm xorg-x11-drv-dummy-0.3.6-15.xpra6.el6.x86_64.rpm xpra-0.17.5-2.r13455.el6_6.x86_64.rpm xpra-common-0.17.5-2.r13455.el6_6.noarch.rpm xvidcore-1.3.4-1.el6_6.x86_64.rpm xvidcore-devel-1.3.4-1.el6_6.x86_64.rpm yasm-1.3.0-1.el6.x86_64.rpm yasm-devel-1.3.0-1.el6.x86_64.rpm 2.) For each rpm, I ran: rpm2cpio PACKAGE.rpm > PACKAGE.cpio cpio -idv < PACKAGE.cpio This unpacks the contents of all of the rpms as if my home directory were '/'. e.g. The path to the xpra executable is ${HOME}/usr/bin 3.) Set the following env variables: PYTHONPATH=$PYTHONPATH:${HOME}/usr/lib64/python2.6/site-packages PATH=$PATH:${HOME}/usr/bin LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${HOME}/usr/lib64:${HOME}/usr/lib64/gstreamer-0.10:/${HOME}/usr/lib64/xorg/modules/drivers:${HOME}/usr/lib64/xpra At this point, I can start an xpra session: xpra start :100 After setting DISPLAY=:100, I can start an xterm within the session. It is important to note that up to this point, I'm running everything on the RHEL6 server from within a VNC desktop session. 'xpra list' reports that the session is live. On my local Windows 7 machine, I have downloaded the xpra client. When I attempt to connect via ssh, after entering the correct login password, I immediately get a dialog box with the following error: Server unexpectedly closed network connection. If I run Xpra_cmd.exe from a command line terminal, I get the following output when attempting to connect: Xpra gtk2 client version 0.17.5-r13487 running on Microsoft Windows 7 GStreamer version 1.8 for Python 3.4 OpenGL_accelerate module loaded detected keyboard: layout=us desktop size is 1920x1080 with 1 screen: Default (508x285 mm - DPI: 96x96) workarea: 1920x1040 DISPLAY1 (677x381 mm - DPI: 72x72) failed to receive anything, not an xpra server? could also be the wrong username, password or port or maybe this server does not support 'unknown' compression or 'bencode' packet encoding? I know it's not the wrong username or password, because if either is incorrect, I don't even get that far. The part about 'unknown' compression is curious because I have H.264 encoding selected in the client. Back on my VNC desktop on the server, I can attach with: xpra attach :100 and the xpra client starts, connects, and the xterm appears on my VNC desktop. So the session DEFINITELY exists, and I am just having a problem connecting to the remote session from my local Windows machine. Here is the contents of the ${HOME}/.xpra/:100.log file after starting up the session: X.Org X Server 1.15.0 Release Date: 2013-12-27 X Protocol Version 11, Revision 0 Build Operating System: x86-027 2.6.18-400.1.1.el5 Current Operating System: Linux sjlvda1566 2.6.32-504.30.3.el6.x86_64 #1 SMP Thu Jul 9 15:20:47 EDT 2015 x86_64 Kernel command line: ro root=UUID=8230e56b-29bb-498d-861a-920ce03d479f rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=129M at 0M KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet Build Date: 06 February 2015 12:21:48AM Build ID: xorg-x11-server 1.15.0-26.el6_6 Current version of pixman: 0.32.4 Before reporting problems, check https://www.redhat.com/apps/support/ to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (++) Log file: "/home/thomase/.xpra/Xorg.:100.log", Time: Sat Oct 1 00:21:11 2016 (++) Using config file: "/home/thomase/.xpra/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" Initializing built-in extension Generic Event Extension Initializing built-in extension SHAPE Initializing built-in extension MIT-SHM Initializing built-in extension XInputExtension Initializing built-in extension XTEST Initializing built-in extension BIG-REQUESTS Initializing built-in extension SYNC Initializing built-in extension XKEYBOARD Initializing built-in extension XC-MISC Initializing built-in extension SECURITY Initializing built-in extension XINERAMA Initializing built-in extension XFIXES Initializing built-in extension RENDER Initializing built-in extension RANDR Initializing built-in extension COMPOSITE Initializing built-in extension DAMAGE Initializing built-in extension MIT-SCREEN-SAVER Initializing built-in extension DOUBLE-BUFFER Initializing built-in extension RECORD Initializing built-in extension DPMS Initializing built-in extension Present Initializing built-in extension X-Resource Initializing built-in extension XVideo Initializing built-in extension XVideo-MotionCompensation Initializing built-in extension SELinux Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX 2016-10-01 00:21:11,711 created unix domain socket: /home/thomase/.xpra/sjlvda1566-100 [0m /usr/lib/python2.6/site-packages/dbus/connection.py:242: DeprecationWarning: object.__init__() takes no parameters super(Connection, self).__init__(*args, **kwargs) [33m2016-10-01 00:21:12,120 Warning: using fallback encryption library pycrypto [0m [33m2016-10-01 00:21:12,121 python-cryptography is not available: No module named cryptography [0m [33m2016-10-01 00:21:13,250 Warning: webcam forwarding is disabled [0m [33m2016-10-01 00:21:13,250 the virtual video directory '/sys/devices/virtual/video4linux' was not found [0m [33m2016-10-01 00:21:13,250 make sure that the 'v4l2loopback' kernel module is installed and loaded [0m 2016-10-01 00:21:13,250 found 0 virtual video devices [0m 2016-10-01 00:21:13,283 pulseaudio server started with pid 23074 [0m E: pid.c: Daemon already running. 2016-10-01 00:21:13,842 GStreamer version 0.10 for Python 2.6 [0m 2016-10-01 00:21:13,895 D-Bus notification forwarding is available [0m 2016-10-01 00:21:13,925 xpra X11 version 0.17.5-r13455 [0m 2016-10-01 00:21:13,991 running with pid 23039 on Linux Red Hat Enterprise Linux Server 6.6 Santiago [0m 2016-10-01 00:21:13,991 on display :100 [0m 2016-10-01 00:21:14,010 xpra is ready. [0m [33m2016-10-01 00:21:16,134 Warning: lpinfo command failed and returned 1 [0m [33m2016-10-01 00:21:16,135 command used: '/usr/sbin/lpinfo --make-and-model Generic PDF Printer -m' [0m [33m2016-10-01 00:21:16,224 Warning: pulseaudio has terminated shortly after startup. [0m [33m2016-10-01 00:21:16,224 pulseaudio is limited to a single instance per user account, [0m [33m2016-10-01 00:21:16,224 and one may be running already for user 'thomase' [0m [33m2016-10-01 00:21:16,224 to avoid this warning, either fix the pulseaudio command line [0m [33m2016-10-01 00:21:16,224 or use the 'pulseaudio=no' option [0m Nothing gets added to this log file when I make the failed connection attempt from my Windows machine. Any ideas what might be the problem? From antoine at nagafix.co.uk Sat Oct 1 06:34:12 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 1 Oct 2016 12:34:12 +0700 Subject: [winswitch] can't connect with windows 7 client In-Reply-To: References: Message-ID: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> On 01/10/16 11:28, Thomas Esposito via shifter-users wrote: > I'm running an xpra server on a redhat el6.6 remote redhat el 6.6 virtual > machine. I don't have root permissions, so I did the following: > > 1.) Downloaded the following rpms to my home directory: (snip) > > 2.) For each rpm, I ran: > rpm2cpio PACKAGE.rpm > PACKAGE.cpio > cpio -idv < PACKAGE.cpio > > This unpacks the contents of all of the rpms as if my home directory were > '/'. > e.g. The path to the xpra executable is ${HOME}/usr/bin > > 3.) Set the following env variables: > PYTHONPATH=$PYTHONPATH:${HOME}/usr/lib64/python2.6/site-packages > PATH=$PATH:${HOME}/usr/bin > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${HOME}/usr/lib64:${HOME}/usr/lib64/gstreamer-0.10:/${HOME}/usr/lib64/xorg/modules/drivers:${HOME}/usr/lib64/xpra Does Xorg honour the module path for loading the dummy driver this way? (check for "dummy" warnings in your Xorg log file) > At this point, I can start an xpra session: > > xpra start :100 > > After setting DISPLAY=:100, I can start an xterm within the session. FYI: always prefer this form: xpra start :100 --start=xterm As this will set the environment correctly for the application launched. (and also detach it from the terminal you run from) > It is important to note that up to this point, I'm running everything on > the RHEL6 server from within a VNC desktop session. > > 'xpra list' reports that the session is live. > > On my local Windows 7 machine, I have downloaded the xpra client. When I > attempt to connect via ssh, after entering the correct login password, I > immediately get a dialog box with the following error: > > Server unexpectedly closed network connection. > > If I run Xpra_cmd.exe from a command line terminal, I get the following > output when attempting to connect: Please always provide the exact command line that you used (minus any passwords and IP addresses, etc), ie: Xpra_cmd attach ssh/username:password at host:22/100 > Xpra gtk2 client version 0.17.5-r13487 > running on Microsoft Windows 7 > GStreamer version 1.8 for Python 3.4 > OpenGL_accelerate module loaded > detected keyboard: layout=us > desktop size is 1920x1080 with 1 screen: > Default (508x285 mm - DPI: 96x96) workarea: 1920x1040 > DISPLAY1 (677x381 mm - DPI: 72x72) > failed to receive anything, not an xpra server? > could also be the wrong username, password or port > or maybe this server does not support 'unknown' compression or 'bencode' > packet encoding? > > I know it's not the wrong username or password, because if either is > incorrect, I don't even get that far. The part about 'unknown' compression > is curious because I have H.264 encoding selected in the client. That's the packet compression and encoding, not picture encoding. It means that no packets were exchanged with the server. > Back on my VNC desktop on the server, I can attach with: > > xpra attach :100 > > and the xpra client starts, connects, and the xterm appears on my VNC > desktop. > > So the session DEFINITELY exists, and I am just having a problem connecting > to the remote session from my local Windows machine. > > Here is the contents of the ${HOME}/.xpra/:100.log file after starting up > the session: (snip) > Nothing gets added to this log file when I make the failed connection > attempt from my Windows machine. > > Any ideas what might be the problem? The run-xpra script which is executed via ssh may not be able to correctly setup the environment and therefore fails to connect to your xpra server instance. Try running from your server: ~/.xpra/run-xpra list :100 or: ~/.xpra/run-xpra info :100 Also try to connect via ssh from Linux to rule out any problems with the client side. Cheers Antoine From tmesposito00 at gmail.com Sat Oct 1 14:40:14 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Sat, 1 Oct 2016 09:40:14 -0400 Subject: [winswitch] can't connect with windows 7 client In-Reply-To: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> References: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> Message-ID: On Sat, Oct 1, 2016 at 1:34 AM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 01/10/16 11:28, Thomas Esposito via shifter-users wrote: > > I'm running an xpra server on a redhat el6.6 remote redhat el 6.6 virtual > > machine. I don't have root permissions, so I did the following: > > > > 1.) Downloaded the following rpms to my home directory: > (snip) > > > > 2.) For each rpm, I ran: > > rpm2cpio PACKAGE.rpm > PACKAGE.cpio > > cpio -idv < PACKAGE.cpio > > > > This unpacks the contents of all of the rpms as if my home directory were > > '/'. > > e.g. The path to the xpra executable is ${HOME}/usr/bin > > > > 3.) Set the following env variables: > > PYTHONPATH=$PYTHONPATH:${HOME}/usr/lib64/python2.6/site-packages > > PATH=$PATH:${HOME}/usr/bin > > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${HOME}/usr/lib64:${HOME} > /usr/lib64/gstreamer-0.10:/${HOME}/usr/lib64/xorg/modules/ > drivers:${HOME}/usr/lib64/xpra > Does Xorg honour the module path for loading the dummy driver this way? > (check for "dummy" warnings in your Xorg log file) I don't see any concerning "dummy" warnings in the log, although it does appear to be loading dummy_drv.so from the normal /usr/lib64/xorg/modules/drivers install directory rather than from my home directory. The 2 versions of dummy_drv.so have different sizes. > > > At this point, I can start an xpra session: > > > > xpra start :100 > > > > After setting DISPLAY=:100, I can start an xterm within the session. > FYI: always prefer this form: > xpra start :100 --start=xterm > As this will set the environment correctly for the application launched. > (and also detach it from the terminal you run from) > > > It is important to note that up to this point, I'm running everything on > > the RHEL6 server from within a VNC desktop session. > > > > 'xpra list' reports that the session is live. > > > > On my local Windows 7 machine, I have downloaded the xpra client. When > IX > > attempt to connect via ssh, after entering the correct login password, I > > immediately get a dialog box with the following error: > > > > Server unexpectedly closed network connection. > > > > If I run Xpra_cmd.exe from a command line terminal, I get the following > > output when attempting to connect: > Please always provide the exact command line that you used (minus any > passwords and IP addresses, etc), ie: > Xpra_cmd attach ssh/username:password at host:22/100 > For the Windows client, I am literally just running that command (i.e. no args), and then starting up the session with the GUI. > > > Xpra gtk2 client version 0.17.5-r13487 > > running on Microsoft Windows 7 > > GStreamer version 1.8 for Python 3.4 > > OpenGL_accelerate module loaded > > detected keyboard: layout=us > > desktop size is 1920x1080 with 1 screen: > > Default (508x285 mm - DPI: 96x96) workarea: 1920x1040 > > DISPLAY1 (677x381 mm - DPI: 72x72) > > failed to receive anything, not an xpra server? > > could also be the wrong username, password or port > > or maybe this server does not support 'unknown' compression or > 'bencode' > > packet encoding? > > > > I know it's not the wrong username or password, because if either is > > incorrect, I don't even get that far. The part about 'unknown' > compression > > is curious because I have H.264 encoding selected in the client. > That's the packet compression and encoding, not picture encoding. > It means that no packets were exchanged with the server. > > > Back on my VNC desktop on the server, I can attach with: > > > > xpra attach :100 > > > > and the xpra client starts, connects, and the xterm appears on my VNC > > desktop. > > > > So the session DEFINITELY exists, and I am just having a problem > connecting > > to the remote session from my local Windows machine. > > > > Here is the contents of the ${HOME}/.xpra/:100.log file after starting up > > the session: > (snip) > > Nothing gets added to this log file when I make the failed connection > > attempt from my Windows machine. > > > > Any ideas what might be the problem? > The run-xpra script which is executed via ssh may not be able to > correctly setup the environment and therefore fails to connect to your > xpra server instance. Try running from your server: > ~/.xpra/run-xpra list :100 > or: > ~/.xpra/run-xpra info :100 > If I go to a different terminal on the same machine (i.e. where I started the server) WITHOUT the environment variables set up as I have described above, I can start a session, run an xterm on it, and attach to the session successfully as follows: ~/.xpra/run-xpra start :100 xterm -display :100 & ~/xpra/run-xpra attach :100 > Also try to connect via ssh from Linux to rule out any problems with the > client side. I CANNOT attach via ssh from another Linux machine. After successfully entering my ssh password, I get the following error message: 2016-10-01 09:33:37,037 The SSH process has terminated with exit code 255 2016-10-01 09:33:37,037 the command line used was: 2016-10-01 09:33:37,037 ssh -x -T *server_name* xpra initenv;~/.xpra/run-xpra _proxy :100 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100 || xpra _proxy :100 At this point, after seeing the 'xpra initenv' command here, I thought that I was on to something, so I added the PATH, PYTHONPATH, and LD_LIBRARY_PATH setup as described above to my ~/.bashrc. Unfortunately, after doing this, I still get the same error when attempting to connect from another Linux machine (and my Windows machine). > > Cheers > Antoine > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From tzahi.ml at gmail.com Sun Oct 2 08:11:15 2016 From: tzahi.ml at gmail.com (tzahi ml) Date: Sun, 2 Oct 2016 10:11:15 +0300 Subject: [winswitch] Html5 with H264 support Message-ID: Hi All, Is it possible to anticipate when html5 client with 264 support will be available? even as a beta? (I saw some attempts in the past and that it is disabled due to extreme unstableness). It seems like a game changer to me since the bandwidth required compared to NOVNC etc... would be a lot lower while not loosing responsiveness. I am using NOVNC on a heavy traffic network. Thanks! Tzahi. From antoine at nagafix.co.uk Sun Oct 2 08:20:19 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 2 Oct 2016 14:20:19 +0700 Subject: [winswitch] Html5 with H264 support In-Reply-To: References: Message-ID: Hi, On 02/10/16 14:11, tzahi ml via shifter-users wrote: > Hi All, > Is it possible to anticipate when html5 client with 264 support will be > available? even as a beta? (I saw some attempts in the past and that it is > disabled due to extreme unstableness). It seems like a game changer to me > since the bandwidth required compared to NOVNC etc... would be a lot lower > while not loosing responsiveness. I am using NOVNC on a heavy traffic > network. The updated HTML5 client is the only feature blocking the current release. The developer in charge of this effort is currently very busy but the new code should land real soon now. Alternatively, I could take a stab at fixing the existing code, but it would never be quite as efficient as the new client code. Either way, I will make an announcement once there is something available that people can test. Cheers Antoine > > Thanks! > > Tzahi. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Sun Oct 2 11:19:19 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 2 Oct 2016 17:19:19 +0700 Subject: [winswitch] can't connect with windows 7 client In-Reply-To: References: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> Message-ID: <3f87ddf1-2312-8850-c6cc-8eaa7dd3a28a@nagafix.co.uk> > > Server unexpectedly closed network connection. > > > > If I run Xpra_cmd.exe from a command line terminal, I get the following > > output when attempting to connect: > Please always provide the exact command line that you used (minus any > passwords and IP addresses, etc), ie: > Xpra_cmd attach ssh/username:password at host:22/100 > > For the Windows client, I am literally just running that command (i.e. > no args), and then starting up the session with the GUI. You should always try the command line version when reporting bugs, as it can be easily cut&pasted and it is much easier to spot obvious problems. (snip) > > Any ideas what might be the problem? > The run-xpra script which is executed via ssh may not be able to > correctly setup the environment and therefore fails to connect to your > xpra server instance. Try running from your server: > ~/.xpra/run-xpra list :100 > or: > ~/.xpra/run-xpra info :100 > > If I go to a different terminal on the same machine (i.e. where I > started the server) WITHOUT the environment variables set up as I have > described above, I can start a session, run an xterm on it, and attach > to the session successfully as follows: > > ~/.xpra/run-xpra start :100 > xterm -display :100 & > ~/xpra/run-xpra attach :100 > > > Also try to connect via ssh from Linux to rule out any problems with the > client side. > > I CANNOT attach via ssh from another Linux machine. After successfully > entering my ssh password, I get the following error message: > 2016-10-01 09:33:37,037 The SSH process has terminated with exit code 255 > 2016-10-01 09:33:37,037 the command line used was: > 2016-10-01 09:33:37,037 ssh -x -T */server_name/* xpra > initenv;~/.xpra/run-xpra _proxy :100 || $XDG_RUNTIME_DIR/xpra/run-xpra > _proxy :100 || xpra _proxy :100 Try running just this command from a Linux terminal: ssh -x -T $SERVERHOST ~/.xpra/run-xpra _proxy :100 Then press enter a few times, this should connect your terminal to the remote xpra server. The server will be confused by your keyboard input and print something like: disconnect: invalid packet header, character 0xa, not an xpra client?? Maybe your ssh shell commands are restricted, or it uses a non-standard shell which is incompatible with the proxy syntax we use. > At this point, after seeing the 'xpra initenv' command here, I thought > that I was on to something, so I added the PATH, PYTHONPATH, and > LD_LIBRARY_PATH setup as described above to my ~/.bashrc. Unfortunately, > after doing this, I still get the same error when attempting to connect > from another Linux machine (and my Windows machine). xpra initenv is there to setup one of the "run-xpra" scripts on the system if one is not present yet. You can override it using the environment variable XPRA_INITENV_COMMAND. ie to disable it: XPRA_INITENV_COMMAND="" xpra attach ssh ... Cheers Antoine From tmesposito00 at gmail.com Sun Oct 2 14:15:30 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Sun, 2 Oct 2016 09:15:30 -0400 Subject: [winswitch] can't connect with windows 7 client In-Reply-To: <3f87ddf1-2312-8850-c6cc-8eaa7dd3a28a@nagafix.co.uk> References: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> <3f87ddf1-2312-8850-c6cc-8eaa7dd3a28a@nagafix.co.uk> Message-ID: On Sun, Oct 2, 2016 at 6:19 AM, Antoine Martin wrote: > > > Server unexpectedly closed network connection. > > > > > > If I run Xpra_cmd.exe from a command line terminal, I get the > following > > > output when attempting to connect: > > Please always provide the exact command line that you used (minus any > > passwords and IP addresses, etc), ie: > > Xpra_cmd attach ssh/username:password at host:22/100 > > > > For the Windows client, I am literally just running that command (i.e. > > no args), and then starting up the session with the GUI. > You should always try the command line version when reporting bugs, as > it can be easily cut&pasted and it is much easier to spot obvious problems. > (snip) > > > Any ideas what might be the problem? > > The run-xpra script which is executed via ssh may not be able to > > correctly setup the environment and therefore fails to connect to > your > > xpra server instance. Try running from your server: > > ~/.xpra/run-xpra list :100 > > or: > > ~/.xpra/run-xpra info :100 > > > > If I go to a different terminal on the same machine (i.e. where I > > started the server) WITHOUT the environment variables set up as I have > > described above, I can start a session, run an xterm on it, and attach > > to the session successfully as follows: > > > > ~/.xpra/run-xpra start :100 > > xterm -display :100 & > > ~/xpra/run-xpra attach :100 > > > > > > Also try to connect via ssh from Linux to rule out any problems with > the > > client side. > > > > I CANNOT attach via ssh from another Linux machine. After successfully > > entering my ssh password, I get the following error message: > > 2016-10-01 09:33:37,037 The SSH process has terminated with exit code 255 > > 2016-10-01 09:33:37,037 the command line used was: > > 2016-10-01 09:33:37,037 ssh -x -T */server_name/* xpra > > initenv;~/.xpra/run-xpra _proxy :100 || $XDG_RUNTIME_DIR/xpra/run-xpra > > _proxy :100 || xpra _proxy :100 > Try running just this command from a Linux terminal: > ssh -x -T $SERVERHOST ~/.xpra/run-xpra _proxy :100 > Then press enter a few times, this should connect your terminal to the > remote xpra server. The server will be confused by your keyboard input > and print something like: > disconnect: invalid packet header, character 0xa, not an xpra client?? > > Maybe your ssh shell commands are restricted, or it uses a non-standard > shell which is incompatible with the proxy syntax we use. > Well, this is embarrassing, but the server is closing the ssh connection immediately after authentication, even for a regular login shell! It happens both when using PuTTY on my Winnow 7 machine and when ssh'ing from another Linux machine on the network. This is a VM that has been allocated to me for work, and according to the FAQ written by IT, ssh SHOULD be supported. I won't be able to get in touch with them until Monday, but assuming the problem is on my end (i.e. not due to the way the VM was provisioned/configured), what could possibly cause ssh to close connections immediately after authentication? > > > At this point, after seeing the 'xpra initenv' command here, I thought > > that I was on to something, so I added the PATH, PYTHONPATH, and > > LD_LIBRARY_PATH setup as described above to my ~/.bashrc. Unfortunately, > > after doing this, I still get the same error when attempting to connect > > from another Linux machine (and my Windows machine). > xpra initenv is there to setup one of the "run-xpra" scripts on the > system if one is not present yet. > You can override it using the environment variable XPRA_INITENV_COMMAND. > ie to disable it: > XPRA_INITENV_COMMAND="" xpra attach ssh ... > > Cheers > Antoine > From stroller at stellar.eclipse.co.uk Sun Oct 2 18:51:59 2016 From: stroller at stellar.eclipse.co.uk (Stroller) Date: Sun, 2 Oct 2016 18:51:59 +0100 Subject: [winswitch] can't connect with windows 7 client In-Reply-To: References: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> <3f87ddf1-2312-8850-c6cc-8eaa7dd3a28a@nagafix.co.uk> Message-ID: > On 2 Oct 2016, at 14:15, Thomas Esposito via shifter-users wrote: > > Well, this is embarrassing, but the server is closing the ssh connection > immediately after authentication, even for a regular login shell! ? > what could possibly cause ssh to close connections > immediately after authentication? Bad shell? The admins have set the user's shell to /bin/false because they don't want (or expect) you using this service? Stroll.r From tmesposito00 at gmail.com Sun Oct 2 19:11:49 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Sun, 2 Oct 2016 14:11:49 -0400 Subject: [winswitch] can't connect with windows 7 client In-Reply-To: References: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> <3f87ddf1-2312-8850-c6cc-8eaa7dd3a28a@nagafix.co.uk> Message-ID: Maybe, but like I said, everything I have read indicates that the intent is for us to have ssh access. On Oct 2, 2016 1:52 PM, "Stroller via shifter-users" < shifter-users at lists.devloop.org.uk> wrote: > > > On 2 Oct 2016, at 14:15, Thomas Esposito via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > > > > Well, this is embarrassing, but the server is closing the ssh connection > > immediately after authentication, even for a regular login shell! ? > > what could possibly cause ssh to close connections > > immediately after authentication? > > Bad shell? > > The admins have set the user's shell to /bin/false because they don't want > (or expect) you using this service? > > Stroll.r > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From tmesposito00 at gmail.com Mon Oct 3 19:54:49 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Mon, 3 Oct 2016 14:54:49 -0400 Subject: [winswitch] can't connect with windows 7 client In-Reply-To: References: <80da738c-bb81-6921-f5d0-9ed35fa5da94@nagafix.co.uk> <3f87ddf1-2312-8850-c6cc-8eaa7dd3a28a@nagafix.co.uk> Message-ID: I resolved my ssh connection issues, but thanks for the help. Now that I have this basically working, there are a few other issues I'd like to work through, but I'll start a new thread for those. On Sun, Oct 2, 2016 at 2:11 PM, Thomas Esposito wrote: > Maybe, but like I said, everything I have read indicates that the intent > is for us to have ssh access. > > On Oct 2, 2016 1:52 PM, "Stroller via shifter-users" < > shifter-users at lists.devloop.org.uk> wrote: > >> >> > On 2 Oct 2016, at 14:15, Thomas Esposito via shifter-users < >> shifter-users at lists.devloop.org.uk> wrote: >> > >> > Well, this is embarrassing, but the server is closing the ssh connection >> > immediately after authentication, even for a regular login shell! ? >> > what could possibly cause ssh to close connections >> > immediately after authentication? >> >> Bad shell? >> >> The admins have set the user's shell to /bin/false because they don't >> want (or expect) you using this service? >> >> Stroll.r >> >> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > From thomase00 at yahoo.com Mon Oct 3 20:07:39 2016 From: thomase00 at yahoo.com (Thomas Esposito) Date: Mon, 3 Oct 2016 15:07:39 -0400 Subject: [winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value Message-ID: The fonts rendered by Xorg are very small, and I suspect the reason is because the DPI is being set to an unreasonably low value (i.e. 42x28 now, but varies depending on the monitor setup). Rather than deal with the patched dummy driver, I'm assuming that I should be able to simply fix the X DPI to a reasonable value (i.e. 96x96), since that is what I'm accustomed to anyway, being a Windows user primarily. I know there are quasi-religious arguments about a fixed DPI of 96, particularly with all the high-res monitors available now, but I'd rather not get into that. Anyway, I've attempted to fix the Xorg DPI by using the '--dpi=96' switch on the xpra command line AND by uncommenting the 'dpi = 96' line from the default xpra.conf file included with the install (which I have copied to ~/.xpra/xpra.conf). In both cases, this does not seem to have any effect, and my fonts and DPI remain unreasonably small. What am I missing? Also interesting, although most likely unrelated, is the output I get when running 'xrdb -q': gnome.Xft/DPI: 98304 Xft.hinting: 1 Xft.antialias: 1 Xft.dpi: 96 Xft.rgba: none Xcursor.size: 21 Xft/DPI: 98304 Xft.hintstyle: hintmedium I know the DPI here is for client-side/fontconfig fonts and is unrelated to Xorg-rendered fonts, but I find the value of 98304 to be strange here. From thomase00 at yahoo.com Mon Oct 3 21:18:32 2016 From: thomase00 at yahoo.com (Thomas Esposito) Date: Mon, 3 Oct 2016 16:18:32 -0400 Subject: [winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value In-Reply-To: References: Message-ID: I'm not sure if this is related to my issue, but I have reason to doubt that the shared libraries that I extracted from the rpm files are actually being loaded. In a prior thread, I mentioned that since I don't have admin privileges, I manually extracted the following rpms https://www.xpra.org/dists/CentOS/6.6/x86_64/ : Cython-0.24.1-1.el6_6.x86_64.rpm PyOpenGL-3.1.1a1r1-1.el6.noarch.rpm PyOpenGL-Tk-3.1.1a1r1-1.el6.noarch.rpm PyOpenGL-accelerate-3.1.1a1r1-1.el6.x86_64.rpm ffmpeg-xpra-3.1.3-1.el6_6.x86_64.rpm ffmpeg-xpra-devel-3.1.3-1.el6_6.x86_64.rpm gstreamer-plugins-ugly-0.10.18-4.el6.x86_64.rpm libfakeXinerama-0.1.0-3.el6.x86_64.rpm libvpx-xpra-1.6.0-1.el6_6.x86_64.rpm libvpx-xpra-devel-1.6.0-1.el6_6.x86_64.rpm libwebp-xpra-0.5.0-1.el6_6.x86_64.rpm libwebp-xpra-devel-0.5.0-1.el6_6.x86_64.rpm lz4-devel-r131-1.el6_6.x86_64.rpm lz4-r131-1.el6_6.x86_64.rpm lz4-static-r131-1.el6_6.x86_64.rpm python-crypto-2.6.1-2.el6.x86_64.rpm python-lz4-0.8.2-1.el6_6.x86_64.rpm python-netifaces-0.10.4-3.el6_6.x86_64.rpm python-pillow-3.2.0-1.el6_6.x86_64.rpm python-pillow-devel-3.2.0-1.el6_6.x86_64.rpm python-pillow-qt-3.2.0-1.el6_6.x86_64.rpm python-pillow-sane-2.6.1-1.el6.x86_64.rpm python-pillow-tk-3.2.0-1.el6_6.x86_64.rpm python-pycuda-2015.1-1.x86_64.rpm python-pyopengl-3.1.1a1-4.1xpra3.el6_6.x86_64.rpm python-pyopengl-tk-3.1.1a1-4.1xpra3.el6_6.noarch.rpm python-pytools-2015.1.2-1.el6.noarch.rpm python-rencode-1.0.5-1.el6_6.x86_64.rpm winswitch-0.12.22-1.x86_64.rpm x264-xpra-20160704-1.el6_6.x86_64.rpm x264-xpra-devel-20160704-1.el6_6.x86_64.rpm xorg-x11-drv-dummy-0.3.6-15.xpra6.el6.x86_64.rpm xpra-0.17.5-2.r13455.el6_6.x86_64.rpm xpra-common-0.17.5-2.r13455.el6_6.noarch.rpm xvidcore-1.3.4-1.el6_6.x86_64.rpm xvidcore-devel-1.3.4-1.el6_6.x86_64.rpm yasm-1.3.0-1.el6.x86_64.rpm yasm-devel-1.3.0-1.el6.x86_64.rpm Specifically, I created a directory named on a shared disk (i.e. ) and extracted the files in each package in such a way that this directory was effectively the root directory. For example, the *.so files were extracted to '/usr/lib64' directory tree. I found all of the directories to which I had extracted *.so files and added those directories to LD_LIBRARY_PATH. When running certain X applications, I get the following error message, although the application appears to run fine: ERROR: ld.so: object '/projects/avenger_de1/thomase/xpra/usr/lib64/libfakeXinerama.so.1' from LD_PRELOAD cannot be preloaded: ignored. Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file (I'm using display :100) reports that it is loading the standard /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the patched driver in /usr/lib64/xorg/modules/drivers/dummy_drv.so.. How can I be sure that any of the libraries that I have downloaded are actually being loaded? On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito wrote: > The fonts rendered by Xorg are very small, and I suspect the reason is > because the DPI is being set to an unreasonably low value (i.e. 42x28 now, > but varies depending on the monitor setup). Rather than deal with the > patched dummy driver, I'm assuming that I should be able to simply fix the > X DPI to a reasonable value (i.e. 96x96), since that is what I'm accustomed > to anyway, being a Windows user primarily. I know there are quasi-religious > arguments about a fixed DPI of 96, particularly with all the high-res > monitors available now, but I'd rather not get into that. > > Anyway, I've attempted to fix the Xorg DPI by using the '--dpi=96' switch > on the xpra command line AND by uncommenting the 'dpi = 96' line from the > default xpra.conf file included with the install (which I have copied to > ~/.xpra/xpra.conf). In both cases, this does not seem to have any effect, > and my fonts and DPI remain unreasonably small. > > What am I missing? > > Also interesting, although most likely unrelated, is the output I get when > running 'xrdb -q': > > gnome.Xft/DPI: 98304 > Xft.hinting: 1 > Xft.antialias: 1 > Xft.dpi: 96 > Xft.rgba: none > Xcursor.size: 21 > Xft/DPI: 98304 > Xft.hintstyle: hintmedium > > I know the DPI here is for client-side/fontconfig fonts and is unrelated > to Xorg-rendered fonts, but I find the value of 98304 to be strange here. > From antoine at nagafix.co.uk Tue Oct 4 09:52:11 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 4 Oct 2016 15:52:11 +0700 Subject: [winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value In-Reply-To: References: Message-ID: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> On 04/10/16 03:18, Thomas Esposito via shifter-users wrote: > I'm not sure if this is related to my issue, Probably is. > but I have reason to doubt > that the shared libraries that I extracted from the rpm files are actually > being loaded. This may severely impact your experience: missing picture codecs, wrong DPI, etc.. > In a prior thread, I mentioned that since I don't have admin privileges, I > manually extracted the following rpms > https://www.xpra.org/dists/CentOS/6.6/x86_64/ : (snip) BTW, you don't need all of those RPMs installed, only the ones that are required for installing the main "xpra" package. See: rpm -qpR xpra*rpm > Specifically, I created a directory named on a shared disk > (i.e. ) and extracted the files in each package > in such a way that this directory was effectively the root directory. For > example, the *.so files were extracted to > '/usr/lib64' directory tree. > > I found all of the directories to which I had extracted *.so files and > added those directories to LD_LIBRARY_PATH. > > When running certain X applications, I get the following error message, > although the application appears to run fine: > > ERROR: ld.so: object > '/projects/avenger_de1/thomase/xpra/usr/lib64/libfakeXinerama.so.1' from > LD_PRELOAD cannot be preloaded: ignored. See: http://xpra.org/trac/wiki/FakeXinerama Things should work reasonably well without it. > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file (I'm using > display :100) reports that it is loading the standard > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the patched > driver in > /usr/lib64/xorg/modules/drivers/dummy_drv.so.. This will be the source of your DPI problems: you won't be using a patched dummy driver. > How can I be sure that any of the libraries that I have downloaded are > actually being loaded? That depends on how the application loads its shared objects. In the case of Xorg, this is probably a hard-coded path you can do nothing about. (and you probably won't be able to LD_PRELOAD it either) > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito wrote: > >> The fonts rendered by Xorg are very small, and I suspect the reason is >> because the DPI is being set to an unreasonably low value (i.e. 42x28 now, >> but varies depending on the monitor setup). Rather than deal with the >> patched dummy driver, I'm assuming that I should be able to simply fix the >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm accustomed >> to anyway, being a Windows user primarily. I know there are quasi-religious >> arguments about a fixed DPI of 96, particularly with all the high-res >> monitors available now, but I'd rather not get into that. The issue you're hitting is that the applications you use do not honour any of your DPI settings but they try to calculate their own "hardware DPI" based on the monitor dimensions and screen resolution. This never works well, which is why we have use a patched dummy driver to simulate the "correct" values. If you want to fix this without using the patched dummy driver, your only option is to edit your etc/xpra/xorg.conf and change the DisplaySize of the monitor to get the desired DPI value: https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI This will not adapt when you connect clients with different resolutions. You may also want to try to switch to Xvfb instead of Xdummy by changing the "xvfb=" line in your xpra config file. >> Anyway, I've attempted to fix the Xorg DPI by using the '--dpi=96' switch >> on the xpra command line AND by uncommenting the 'dpi = 96' line from the >> default xpra.conf file included with the install (which I have copied to >> ~/.xpra/xpra.conf). In both cases, this does not seem to have any effect, >> and my fonts and DPI remain unreasonably small. >> >> What am I missing? >> >> Also interesting, although most likely unrelated, It is related and very relevant, but sadly it is also ignored by many applications. >>is the output I get when >> running 'xrdb -q': >> >> gnome.Xft/DPI: 98304 >> Xft.hinting: 1 >> Xft.antialias: 1 >> Xft.dpi: 96 >> Xft.rgba: none >> Xcursor.size: 21 >> Xft/DPI: 98304 >> Xft.hintstyle: hintmedium >> >> I know the DPI here is for client-side/fontconfig fonts and is unrelated >> to Xorg-rendered fonts, but I find the value of 98304 to be strange here. That's the DPI value multiplied by 1024, see: https://wiki.debian.org/MonitorDPI Cheers Antoine >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From tmesposito00 at gmail.com Tue Oct 4 15:43:37 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Tue, 4 Oct 2016 10:43:37 -0400 Subject: [winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value In-Reply-To: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> Message-ID: On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 04/10/16 03:18, Thomas Esposito via shifter-users wrote: > > I'm not sure if this is related to my issue, > Probably is. > > > but I have reason to doubt > > that the shared libraries that I extracted from the rpm files are > actually > > being loaded. > This may severely impact your experience: missing picture codecs, wrong > DPI, etc.. > Actually, I think the one of the issues contributing to my DPI problem are that I can't seem to load the dummy_drv.so instead of the patched version from the rpm. I'm guessing that Xorg is using a hard-coded path to /usr/lib64/xorg/modules/drivers/, and using that without even looking at my LD_LIBRARY_PATH. I'm not sure there is any way around this without directly replacing the lib in /usr/lib64/xorg/modules/drivers. > > > In a prior thread, I mentioned that since I don't have admin privileges, > I > > manually extracted the following rpms > > https://www.xpra.org/dists/CentOS/6.6/x86_64/ : > (snip) > BTW, you don't need all of those RPMs installed, only the ones that are > required for installing the main "xpra" package. See: > rpm -qpR xpra*rpm > > > Specifically, I created a directory named on a shared disk > > (i.e. ) and extracted the files in each > package > > in such a way that this directory was effectively the root directory. For > > example, the *.so files were extracted to > > '/usr/lib64' directory tree. > > > > I found all of the directories to which I had extracted *.so files and > > added those directories to LD_LIBRARY_PATH. > > > > When running certain X applications, I get the following error message, > > although the application appears to run fine: > > > > ERROR: ld.so: object > > '/projects/avenger_de1/thomase/xpra/usr/lib64/libfakeXinerama.so.1' from > > LD_PRELOAD cannot be preloaded: ignored. > See: > http://xpra.org/trac/wiki/FakeXinerama > Things should work reasonably well without it. > > > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file (I'm > using > > display :100) reports that it is loading the standard > > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the patched > > driver in > > /usr/lib64/xorg/modules/ > drivers/dummy_drv.so.. > This will be the source of your DPI problems: you won't be using a > patched dummy driver. > > > How can I be sure that any of the libraries that I have downloaded are > > actually being loaded? > That depends on how the application loads its shared objects. > In the case of Xorg, this is probably a hard-coded path you can do > nothing about. (and you probably won't be able to LD_PRELOAD it either) > Nope, I can't seem to LD_PRELOAD your dummy_drv.so (I get ERRORs). > > > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito > wrote: > > > >> The fonts rendered by Xorg are very small, and I suspect the reason is > >> because the DPI is being set to an unreasonably low value (i.e. 42x28 > now, > >> but varies depending on the monitor setup). Rather than deal with the > >> patched dummy driver, I'm assuming that I should be able to simply fix > the > >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm > accustomed > >> to anyway, being a Windows user primarily. I know there are > quasi-religious > >> arguments about a fixed DPI of 96, particularly with all the high-res > >> monitors available now, but I'd rather not get into that. > The issue you're hitting is that the applications you use do not honour > any of your DPI settings but they try to calculate their own "hardware > DPI" based on the monitor dimensions and screen resolution. > This never works well, which is why we have use a patched dummy driver > to simulate the "correct" values. > I'm not sure about this explanation. For example, when I use TigerVNC, I can set the DPI directly on the vncserver command line with the '-dpi' switch. When I do this, the "resolution" reported by xdpyinfo matches the value that I set on the command line. More importantly, when running the very same X applications that I am having DPI problems with when using xpra, the Xvnc server fonts scale EXACTLY according the the reported "resolution" value (at least when application requests a DPI-scaled font). When using xpra (at least without the patched dummy_drv.so), the "--dpi" switch has absolutely NO effect on the "resolution" reported by xdpyinfo. Rather, it seems to ALWAYS be calculated based on the Modeline resolution and the DisplaySize (I think we agree on this). In particular, what doesn't make sense to me is the idea that individual X applications will be doing their OWN DPI calculation. According to my understanding, the X application simply asks the X server to render a font. It may asks for an unscaled font (e.g. RHEL6 xemacs seems to do this), which will always be rendered the same regardless of DPI, but otherwise it is up to the X server how to render it based on its own understanding of DPI. It seems that the issue is NOT that some X applications calculate their own DPI, but rather that the X server itself (when using the standard dummy_drv.so) effectively IGNORES the DPI switch that Xorg was started with and instead calculates it based on Modeline resolution and DisplaySize. I suppose that the end result is ultimately the same, and dummy_drv.so needs to be fixed in such a way that it respects the DPI. As you say, I imagine that if I was actually able to use the patched dummy_drv.so (it seems I can't though), I would see that the "resolution" reported by xdpyinfo is what I have requested and DPI-scaled fonts will look "right". Ultimately, I believe that the only input the individual X applications provide into the equation is effectively binary. That is, it either requests a scaled on un-scaled font. Also, I think it's confusing to refer to the X server DPI and Xft.dpi in the same context. These are associated with 2 TOTALLY different font rendering systems. Xft is for modern client-side (i.e. X application side) font rendering. This is totally independent of the X server DPI and it explains why I don't have any problems with the fonts in my gnome-terminal for example. All that being said, forgive me if I'm being presumptuous. ;-) I can certainly be convinced otherwise, but right now, something just isn't adding up regarding this explanation. > > If you want to fix this without using the patched dummy driver, your > only option is to edit your etc/xpra/xorg.conf and change the > DisplaySize of the monitor to get the desired DPI value: > https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI > This will not adapt when you connect clients with different resolutions. > > You may also want to try to switch to Xvfb instead of Xdummy by changing > the "xvfb=" line in your xpra config file. > > >> Anyway, I've attempted to fix the Xorg DPI by using the '--dpi=96' > switch > >> on the xpra command line AND by uncommenting the 'dpi = 96' line from > the > >> default xpra.conf file included with the install (which I have copied to > >> ~/.xpra/xpra.conf). In both cases, this does not seem to have any > effect, > >> and my fonts and DPI remain unreasonably small. > >> > >> What am I missing? > >> > >> Also interesting, although most likely unrelated, > It is related and very relevant, but sadly it is also ignored by many > applications. > > >>is the output I get when > >> running 'xrdb -q': > >> > >> gnome.Xft/DPI: 98304 > >> Xft.hinting: 1 > >> Xft.antialias: 1 > >> Xft.dpi: 96 > >> Xft.rgba: none > >> Xcursor.size: 21 > >> Xft/DPI: 98304 > >> Xft.hintstyle: hintmedium > >> > >> I know the DPI here is for client-side/fontconfig fonts and is unrelated > >> to Xorg-rendered fonts, but I find the value of 98304 to be strange > here. > That's the DPI value multiplied by 1024, see: > https://wiki.debian.org/MonitorDPI > > Cheers > Antoine > > > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Tue Oct 4 16:23:06 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 4 Oct 2016 22:23:06 +0700 Subject: [winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value In-Reply-To: References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> Message-ID: <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> On 04/10/16 21:43, Thomas Esposito wrote: > On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users > > wrote: > On 04/10/16 03:18, Thomas Esposito via shifter-users wrote: > > I'm not sure if this is related to my issue, > Probably is. > > > but I have reason to doubt > > that the shared libraries that I extracted from the rpm files are actually > > being loaded. > This may severely impact your experience: missing picture codecs, wrong > DPI, etc.. > > Actually, I think the one of the issues contributing to my DPI problem > are that I can't seem to load the dummy_drv.so instead of the patched > version from the rpm. I'm guessing that Xorg is using a hard-coded path > to /usr/lib64/xorg/modules/drivers/, and using that without even looking > at my LD_LIBRARY_PATH. I'm not sure there is any way around this without > directly replacing the lib in /usr/lib64/xorg/modules/drivers. Yes, like I said just below, use the patched dummy driver. In your case, you may need to build your own patched Xorg server from source to get it loaded. (snip) > > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file (I'm using > > display :100) reports that it is loading the standard > > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the patched > > driver in > > /usr/lib64/xorg/modules/drivers/dummy_drv.so.. > This will be the source of your DPI problems: you won't be using a > patched dummy driver. ^ See here. > > How can I be sure that any of the libraries that I have downloaded are > > actually being loaded? > That depends on how the application loads its shared objects. > In the case of Xorg, this is probably a hard-coded path you can do > nothing about. (and you probably won't be able to LD_PRELOAD it either) > > Nope, I can't seem to LD_PRELOAD your dummy_drv.so (I get ERRORs). > > > > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito > wrote: > > > >> The fonts rendered by Xorg are very small, and I suspect the reason is > >> because the DPI is being set to an unreasonably low value (i.e. 42x28 now, > >> but varies depending on the monitor setup). Rather than deal with the > >> patched dummy driver, I'm assuming that I should be able to simply fix the > >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm accustomed > >> to anyway, being a Windows user primarily. I know there are quasi-religious > >> arguments about a fixed DPI of 96, particularly with all the high-res > >> monitors available now, but I'd rather not get into that. > The issue you're hitting is that the applications you use do not honour > any of your DPI settings but they try to calculate their own "hardware > DPI" based on the monitor dimensions and screen resolution. > This never works well, which is why we have use a patched dummy driver > to simulate the "correct" values. > > I'm not sure about this explanation. OK. > For example, when I use TigerVNC, I > can set the DPI directly on the vncserver command line with the '-dpi' > switch. When I do this, the "resolution" reported by xdpyinfo matches > the value that I set on the command line. More importantly, when running > the very same X applications that I am having DPI problems with when > using xpra, the Xvnc server fonts scale EXACTLY according the the > reported "resolution" value (at least when application requests a > DPI-scaled font). When using xpra (at least without the patched > dummy_drv.so), the "--dpi" switch has absolutely NO effect on the > "resolution" reported by xdpyinfo. Rather, it seems to ALWAYS be > calculated based on the Modeline resolution and the DisplaySize (I think > we agree on this). In particular, what doesn't make sense to me is the > idea that individual X applications will be doing their OWN DPI > calculation. According to my understanding, the X application simply > asks the X server to render a font. Those days are long gone, "most" applications use toolkits nowadays and not X11 core rendering. > It may asks for an unscaled font > (e.g. RHEL6 xemacs seems to do this), which will always be rendered the > same regardless of DPI, but otherwise it is up to the X server how to > render it based on its own understanding of DPI. It seems that the issue > is NOT that some X applications calculate their own DPI, but rather that > the X server itself (when using the standard dummy_drv.so) effectively > IGNORES the DPI switch that Xorg was started with and instead calculates > it based on Modeline resolution and DisplaySize. Almost, but not quite: the dpi is not ignored, it is scaled. When the client connects, the dummy virtual screen is resized to match your client's resolution as best we can, and at that point the dummy screen does have a "fixed virtual size" of sorts. ie with trunk: when we change the default ~8K resolution down to 1080p... the original DPI value is divided by ~4. The patched dummy driver will not only keep the DPI constant when the screen is resized, it will also try to honour the value supplied by the client. (obviously, not all clients have the same DPI settings) > I suppose that the end > result is ultimately the same, and dummy_drv.so needs to be fixed in > such a way that it respects the DPI. As you say, I imagine that if I was > actually able to use the patched dummy_drv.so (it seems I can't though), > I would see that the "resolution" reported by xdpyinfo is what I have > requested and DPI-scaled fonts will look "right". Yes, that's why it's there. > Ultimately, I believe that the only input the individual X applications > provide into the equation is effectively binary. That is, it either > requests a scaled on un-scaled font. > Also, I think it's confusing to refer to the X server DPI and Xft.dpi in > the same context. These are associated with 2 TOTALLY different font > rendering systems. Xft is for modern client-side (i.e. X application > side) font rendering. This is totally independent of the X server DPI > and it explains why I don't have any problems with the fonts in my > gnome-terminal for example. As far as xpra is concerned, whether the forwarded applications will be using X11 rendering or client-side rendering is totally irrelevant: all options must be supported. So we synchronize all the DPI settings we can get our hands on in the hope that all applications will render using the correct settings. In some cases, this requires a patched dummy driver be achieved. > All that being said, forgive me if I'm being presumptuous. ;-) I can > certainly be convinced otherwise, but right now, something just isn't > adding up regarding this explanation. There should be enough information above, otherwise there is *a lot* more on the wiki and the DPI related tickets. Cheers Antoine > > > > If you want to fix this without using the patched dummy driver, your > only option is to edit your etc/xpra/xorg.conf and change the > DisplaySize of the monitor to get the desired DPI value: > https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI > > This will not adapt when you connect clients with different resolutions. > > You may also want to try to switch to Xvfb instead of Xdummy by changing > the "xvfb=" line in your xpra config file. > > >> Anyway, I've attempted to fix the Xorg DPI by using the '--dpi=96' switch > >> on the xpra command line AND by uncommenting the 'dpi = 96' line from the > >> default xpra.conf file included with the install (which I have copied to > >> ~/.xpra/xpra.conf). In both cases, this does not seem to have any effect, > >> and my fonts and DPI remain unreasonably small. > >> > >> What am I missing? > >> > >> Also interesting, although most likely unrelated, > It is related and very relevant, but sadly it is also ignored by many > applications. > > >>is the output I get when > >> running 'xrdb -q': > >> > >> gnome.Xft/DPI: 98304 > >> Xft.hinting: 1 > >> Xft.antialias: 1 > >> Xft.dpi: 96 > >> Xft.rgba: none > >> Xcursor.size: 21 > >> Xft/DPI: 98304 > >> Xft.hintstyle: hintmedium > >> > >> I know the DPI here is for client-side/fontconfig fonts and is unrelated > >> to Xorg-rendered fonts, but I find the value of 98304 to be strange here. > That's the DPI value multiplied by 1024, see: > https://wiki.debian.org/MonitorDPI > > Cheers > Antoine > > > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > From tmesposito00 at gmail.com Wed Oct 5 20:14:20 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Wed, 5 Oct 2016 15:14:20 -0400 Subject: [winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value In-Reply-To: <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> Message-ID: Adding the path to the usr/lib64/xorg/modules/drivers directory of my local install to the LD_LIBRARY_PATH was not enough to force Xorg to use the patched dummy driver. However, I discovered that I could add a "ModulePath" line to my xorg.conf in order to change the effective module search path. So, the DPI problem is solved. Thanks for the help! The next 2 issues on my list are: 1.) My terminal of choice has been gnome-terminal for a while. This is version 2.31.3 on RHEL6.6. The problem is that, when I maximize the window, the edge of the window appears to extend beyond the bottom edge of my monitor. As a result, the bottom row of text in the terminal is mostly cut off. When I maximize to an extended display in a dual-monitor setup, it is not quite as bad and I can see about the top 75% of the bottom row of text. I wonder if this has something to do with this particular X application being forced to relatively coarse-grained sizing increments (i.e. in units of text columns-rows), and then rounding up to the next size increment rather than down when the maximized window size doesn't exactly match one of these coarse-grained increments. 2.) This is a bigger issue. I'm finding that compared to TigerVNC, which is the officially-supported remote X solution in my office (and doesn't support per-application windows like xpra), is MUCH faster than xpra. I haven't ruled out some kind of network QOS prioritizing VNC traffic over ssh, but I wanted to ask what kind of performance I should be expecting relative to something like TigerVNC. We also have FreeNX working (but again, not with per-application windows), which supposedly uses ssh as well, but FreeNX performance is at least as good as TigerVNC, if not better. xpra is in a DISTANT 3rd place. On Tue, Oct 4, 2016 at 11:23 AM, Antoine Martin wrote: > On 04/10/16 21:43, Thomas Esposito wrote: > > On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users > > > > wrote: > > On 04/10/16 03:18, Thomas Esposito via shifter-users wrote: > > > I'm not sure if this is related to my issue, > > Probably is. > > > > > but I have reason to doubt > > > that the shared libraries that I extracted from the rpm files are > actually > > > being loaded. > > This may severely impact your experience: missing picture codecs, > wrong > > DPI, etc.. > > > > Actually, I think the one of the issues contributing to my DPI problem > > are that I can't seem to load the dummy_drv.so instead of the patched > > version from the rpm. I'm guessing that Xorg is using a hard-coded path > > to /usr/lib64/xorg/modules/drivers/, and using that without even looking > > at my LD_LIBRARY_PATH. I'm not sure there is any way around this without > > directly replacing the lib in /usr/lib64/xorg/modules/drivers. > Yes, like I said just below, use the patched dummy driver. > In your case, you may need to build your own patched Xorg server from > source to get it loaded. > > (snip) > > > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file > (I'm using > > > display :100) reports that it is loading the standard > > > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the > patched > > > driver in > > > /usr/lib64/xorg/modules/ > drivers/dummy_drv.so.. > > This will be the source of your DPI problems: you won't be using a > > patched dummy driver. > ^ See here. > > > > How can I be sure that any of the libraries that I have downloaded > are > > > actually being loaded? > > That depends on how the application loads its shared objects. > > In the case of Xorg, this is probably a hard-coded path you can do > > nothing about. (and you probably won't be able to LD_PRELOAD it > either) > > > > Nope, I can't seem to LD_PRELOAD your dummy_drv.so (I get ERRORs). > > > > > > > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito < > thomase00 at yahoo.com > wrote: > > > > > >> The fonts rendered by Xorg are very small, and I suspect the > reason is > > >> because the DPI is being set to an unreasonably low value (i.e. > 42x28 now, > > >> but varies depending on the monitor setup). Rather than deal with > the > > >> patched dummy driver, I'm assuming that I should be able to > simply fix the > > >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm > accustomed > > >> to anyway, being a Windows user primarily. I know there are > quasi-religious > > >> arguments about a fixed DPI of 96, particularly with all the > high-res > > >> monitors available now, but I'd rather not get into that. > > The issue you're hitting is that the applications you use do not > honour > > any of your DPI settings but they try to calculate their own > "hardware > > DPI" based on the monitor dimensions and screen resolution. > > This never works well, which is why we have use a patched dummy > driver > > to simulate the "correct" values. > > > > I'm not sure about this explanation. > OK. > > > For example, when I use TigerVNC, I > > can set the DPI directly on the vncserver command line with the '-dpi' > > switch. When I do this, the "resolution" reported by xdpyinfo matches > > the value that I set on the command line. More importantly, when running > > the very same X applications that I am having DPI problems with when > > using xpra, the Xvnc server fonts scale EXACTLY according the the > > reported "resolution" value (at least when application requests a > > DPI-scaled font). When using xpra (at least without the patched > > dummy_drv.so), the "--dpi" switch has absolutely NO effect on the > > "resolution" reported by xdpyinfo. Rather, it seems to ALWAYS be > > calculated based on the Modeline resolution and the DisplaySize (I think > > we agree on this). In particular, what doesn't make sense to me is the > > idea that individual X applications will be doing their OWN DPI > > calculation. According to my understanding, the X application simply > > asks the X server to render a font. > Those days are long gone, "most" applications use toolkits nowadays and > not X11 core rendering. > > > It may asks for an unscaled font > > (e.g. RHEL6 xemacs seems to do this), which will always be rendered the > > same regardless of DPI, but otherwise it is up to the X server how to > > render it based on its own understanding of DPI. It seems that the issue > > is NOT that some X applications calculate their own DPI, but rather that > > the X server itself (when using the standard dummy_drv.so) effectively > > IGNORES the DPI switch that Xorg was started with and instead calculates > > it based on Modeline resolution and DisplaySize. > Almost, but not quite: the dpi is not ignored, it is scaled. > When the client connects, the dummy virtual screen is resized to match > your client's resolution as best we can, and at that point the dummy > screen does have a "fixed virtual size" of sorts. > > ie with trunk: when we change the default ~8K resolution down to > 1080p... the original DPI value is divided by ~4. > > The patched dummy driver will not only keep the DPI constant when the > screen is resized, it will also try to honour the value supplied by the > client. (obviously, not all clients have the same DPI settings) > > > I suppose that the end > > result is ultimately the same, and dummy_drv.so needs to be fixed in > > such a way that it respects the DPI. As you say, I imagine that if I was > > actually able to use the patched dummy_drv.so (it seems I can't though), > > I would see that the "resolution" reported by xdpyinfo is what I have > > requested and DPI-scaled fonts will look "right". > Yes, that's why it's there. > > > Ultimately, I believe that the only input the individual X applications > > provide into the equation is effectively binary. That is, it either > > requests a scaled on un-scaled font. > > Also, I think it's confusing to refer to the X server DPI and Xft.dpi in > > the same context. These are associated with 2 TOTALLY different font > > rendering systems. Xft is for modern client-side (i.e. X application > > side) font rendering. This is totally independent of the X server DPI > > and it explains why I don't have any problems with the fonts in my > > gnome-terminal for example. > As far as xpra is concerned, whether the forwarded applications will be > using X11 rendering or client-side rendering is totally irrelevant: all > options must be supported. > > So we synchronize all the DPI settings we can get our hands on in the > hope that all applications will render using the correct settings. > In some cases, this requires a patched dummy driver be achieved. > > > All that being said, forgive me if I'm being presumptuous. ;-) I can > > certainly be convinced otherwise, but right now, something just isn't > > adding up regarding this explanation. > There should be enough information above, otherwise there is *a lot* > more on the wiki and the DPI related tickets. > > Cheers > Antoine > > > > > > > > > > If you want to fix this without using the patched dummy driver, your > > only option is to edit your etc/xpra/xorg.conf and change the > > DisplaySize of the monitor to get the desired DPI value: > > https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI > > > > This will not adapt when you connect clients with different > resolutions. > > > > You may also want to try to switch to Xvfb instead of Xdummy by > changing > > the "xvfb=" line in your xpra config file. > > > > >> Anyway, I've attempted to fix the Xorg DPI by using the > '--dpi=96' switch > > >> on the xpra command line AND by uncommenting the 'dpi = 96' line > from the > > >> default xpra.conf file included with the install (which I have > copied to > > >> ~/.xpra/xpra.conf). In both cases, this does not seem to have any > effect, > > >> and my fonts and DPI remain unreasonably small. > > >> > > >> What am I missing? > > >> > > >> Also interesting, although most likely unrelated, > > It is related and very relevant, but sadly it is also ignored by many > > applications. > > > > >>is the output I get when > > >> running 'xrdb -q': > > >> > > >> gnome.Xft/DPI: 98304 > > >> Xft.hinting: 1 > > >> Xft.antialias: 1 > > >> Xft.dpi: 96 > > >> Xft.rgba: none > > >> Xcursor.size: 21 > > >> Xft/DPI: 98304 > > >> Xft.hintstyle: hintmedium > > >> > > >> I know the DPI here is for client-side/fontconfig fonts and is > unrelated > > >> to Xorg-rendered fonts, but I find the value of 98304 to be > strange here. > > That's the DPI value multiplied by 1024, see: > > https://wiki.debian.org/MonitorDPI MonitorDPI> > > > > Cheers > > Antoine > > > > > > >> > > > _______________________________________________ > > > shifter-users mailing list > > > shifter-users at lists.devloop.org.uk > > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > > > From tmesposito00 at gmail.com Thu Oct 6 03:20:00 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Wed, 5 Oct 2016 22:20:00 -0400 Subject: [winswitch] neither --dpi switch or dpi setting in xpra.conf allows me to set the DPI to fixed value In-Reply-To: References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> Message-ID: Just to add a bit more info... I've tried x264, lz4, and png (32, 8, and gray scale) encodings and none of these approach the responsiveness and perceived performance of TigerVNC with Tight encoding. When I look at the stats and graphs under session info, I see lots of latency spikes, particularly under Damage latency, which spikes into several seconds. I've also tried this on a Microsoft Azure Ubuntu VM that I've been playing around with via a free trial account. The performance seems better (same encodings), but occasionally gets pretty bad. Maybe it's just intermittent network issues. I haven't been able to get VNC working on this VM... On Oct 5, 2016 3:14 PM, "Thomas Esposito" wrote: > Adding the path to the usr/lib64/xorg/modules/drivers directory of my > local install to the LD_LIBRARY_PATH was not enough to force Xorg to use > the patched dummy driver. However, I discovered that I could add a > "ModulePath" line to my xorg.conf in order to change the effective module > search path. > > So, the DPI problem is solved. Thanks for the help! > > The next 2 issues on my list are: > > 1.) My terminal of choice has been gnome-terminal for a while. This is > version 2.31.3 on RHEL6.6. The problem is that, when I maximize the window, > the edge of the window appears to extend beyond the bottom edge of my > monitor. As a result, the bottom row of text in the terminal is mostly cut > off. When I maximize to an extended display in a dual-monitor setup, it is > not quite as bad and I can see about the top 75% of the bottom row of text. > I wonder if this has something to do with this particular X application > being forced to relatively coarse-grained sizing increments (i.e. in units > of text columns-rows), and then rounding up to the next size increment > rather than down when the maximized window size doesn't exactly match one > of these coarse-grained increments. > > 2.) This is a bigger issue. I'm finding that compared to TigerVNC, which > is the officially-supported remote X solution in my office (and doesn't > support per-application windows like xpra), is MUCH faster than xpra. I > haven't ruled out some kind of network QOS prioritizing VNC traffic over > ssh, but I wanted to ask what kind of performance I should be expecting > relative to something like TigerVNC. We also have FreeNX working (but > again, not with per-application windows), which supposedly uses ssh as > well, but FreeNX performance is at least as good as TigerVNC, if not > better. xpra is in a DISTANT 3rd place. > > > > On Tue, Oct 4, 2016 at 11:23 AM, Antoine Martin > wrote: > >> On 04/10/16 21:43, Thomas Esposito wrote: >> > On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users >> > > > > wrote: >> > On 04/10/16 03:18, Thomas Esposito via shifter-users wrote: >> > > I'm not sure if this is related to my issue, >> > Probably is. >> > >> > > but I have reason to doubt >> > > that the shared libraries that I extracted from the rpm files are >> actually >> > > being loaded. >> > This may severely impact your experience: missing picture codecs, >> wrong >> > DPI, etc.. >> > >> > Actually, I think the one of the issues contributing to my DPI problem >> > are that I can't seem to load the dummy_drv.so instead of the patched >> > version from the rpm. I'm guessing that Xorg is using a hard-coded path >> > to /usr/lib64/xorg/modules/drivers/, and using that without even >> looking >> > at my LD_LIBRARY_PATH. I'm not sure there is any way around this without >> > directly replacing the lib in /usr/lib64/xorg/modules/drivers. >> Yes, like I said just below, use the patched dummy driver. >> In your case, you may need to build your own patched Xorg server from >> source to get it loaded. >> >> (snip) >> > > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file >> (I'm using >> > > display :100) reports that it is loading the standard >> > > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the >> patched >> > > driver in >> > > /usr/lib64/xorg/modules/drivers/ >> dummy_drv.so.. >> > This will be the source of your DPI problems: you won't be using a >> > patched dummy driver. >> ^ See here. >> >> > > How can I be sure that any of the libraries that I have >> downloaded are >> > > actually being loaded? >> > That depends on how the application loads its shared objects. >> > In the case of Xorg, this is probably a hard-coded path you can do >> > nothing about. (and you probably won't be able to LD_PRELOAD it >> either) >> > >> > Nope, I can't seem to LD_PRELOAD your dummy_drv.so (I get ERRORs). >> > >> > >> > > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito < >> thomase00 at yahoo.com > wrote: >> > > >> > >> The fonts rendered by Xorg are very small, and I suspect the >> reason is >> > >> because the DPI is being set to an unreasonably low value (i.e. >> 42x28 now, >> > >> but varies depending on the monitor setup). Rather than deal >> with the >> > >> patched dummy driver, I'm assuming that I should be able to >> simply fix the >> > >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm >> accustomed >> > >> to anyway, being a Windows user primarily. I know there are >> quasi-religious >> > >> arguments about a fixed DPI of 96, particularly with all the >> high-res >> > >> monitors available now, but I'd rather not get into that. >> > The issue you're hitting is that the applications you use do not >> honour >> > any of your DPI settings but they try to calculate their own >> "hardware >> > DPI" based on the monitor dimensions and screen resolution. >> > This never works well, which is why we have use a patched dummy >> driver >> > to simulate the "correct" values. >> > >> > I'm not sure about this explanation. >> OK. >> >> > For example, when I use TigerVNC, I >> > can set the DPI directly on the vncserver command line with the '-dpi' >> > switch. When I do this, the "resolution" reported by xdpyinfo matches >> > the value that I set on the command line. More importantly, when running >> > the very same X applications that I am having DPI problems with when >> > using xpra, the Xvnc server fonts scale EXACTLY according the the >> > reported "resolution" value (at least when application requests a >> > DPI-scaled font). When using xpra (at least without the patched >> > dummy_drv.so), the "--dpi" switch has absolutely NO effect on the >> > "resolution" reported by xdpyinfo. Rather, it seems to ALWAYS be >> > calculated based on the Modeline resolution and the DisplaySize (I think >> > we agree on this). In particular, what doesn't make sense to me is the >> > idea that individual X applications will be doing their OWN DPI >> > calculation. According to my understanding, the X application simply >> > asks the X server to render a font. >> Those days are long gone, "most" applications use toolkits nowadays and >> not X11 core rendering. >> >> > It may asks for an unscaled font >> > (e.g. RHEL6 xemacs seems to do this), which will always be rendered the >> > same regardless of DPI, but otherwise it is up to the X server how to >> > render it based on its own understanding of DPI. It seems that the issue >> > is NOT that some X applications calculate their own DPI, but rather that >> > the X server itself (when using the standard dummy_drv.so) effectively >> > IGNORES the DPI switch that Xorg was started with and instead calculates >> > it based on Modeline resolution and DisplaySize. >> Almost, but not quite: the dpi is not ignored, it is scaled. >> When the client connects, the dummy virtual screen is resized to match >> your client's resolution as best we can, and at that point the dummy >> screen does have a "fixed virtual size" of sorts. >> >> ie with trunk: when we change the default ~8K resolution down to >> 1080p... the original DPI value is divided by ~4. >> >> The patched dummy driver will not only keep the DPI constant when the >> screen is resized, it will also try to honour the value supplied by the >> client. (obviously, not all clients have the same DPI settings) >> >> > I suppose that the end >> > result is ultimately the same, and dummy_drv.so needs to be fixed in >> > such a way that it respects the DPI. As you say, I imagine that if I was >> > actually able to use the patched dummy_drv.so (it seems I can't though), >> > I would see that the "resolution" reported by xdpyinfo is what I have >> > requested and DPI-scaled fonts will look "right". >> Yes, that's why it's there. >> >> > Ultimately, I believe that the only input the individual X applications >> > provide into the equation is effectively binary. That is, it either >> > requests a scaled on un-scaled font. >> > Also, I think it's confusing to refer to the X server DPI and Xft.dpi in >> > the same context. These are associated with 2 TOTALLY different font >> > rendering systems. Xft is for modern client-side (i.e. X application >> > side) font rendering. This is totally independent of the X server DPI >> > and it explains why I don't have any problems with the fonts in my >> > gnome-terminal for example. >> As far as xpra is concerned, whether the forwarded applications will be >> using X11 rendering or client-side rendering is totally irrelevant: all >> options must be supported. >> >> So we synchronize all the DPI settings we can get our hands on in the >> hope that all applications will render using the correct settings. >> In some cases, this requires a patched dummy driver be achieved. >> >> > All that being said, forgive me if I'm being presumptuous. ;-) I can >> > certainly be convinced otherwise, but right now, something just isn't >> > adding up regarding this explanation. >> There should be enough information above, otherwise there is *a lot* >> more on the wiki and the DPI related tickets. >> >> Cheers >> Antoine >> >> >> > >> > >> > >> > If you want to fix this without using the patched dummy driver, your >> > only option is to edit your etc/xpra/xorg.conf and change the >> > DisplaySize of the monitor to get the desired DPI value: >> > https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI >> > >> > This will not adapt when you connect clients with different >> resolutions. >> > >> > You may also want to try to switch to Xvfb instead of Xdummy by >> changing >> > the "xvfb=" line in your xpra config file. >> > >> > >> Anyway, I've attempted to fix the Xorg DPI by using the >> '--dpi=96' switch >> > >> on the xpra command line AND by uncommenting the 'dpi = 96' line >> from the >> > >> default xpra.conf file included with the install (which I have >> copied to >> > >> ~/.xpra/xpra.conf). In both cases, this does not seem to have >> any effect, >> > >> and my fonts and DPI remain unreasonably small. >> > >> >> > >> What am I missing? >> > >> >> > >> Also interesting, although most likely unrelated, >> > It is related and very relevant, but sadly it is also ignored by >> many >> > applications. >> > >> > >>is the output I get when >> > >> running 'xrdb -q': >> > >> >> > >> gnome.Xft/DPI: 98304 >> > >> Xft.hinting: 1 >> > >> Xft.antialias: 1 >> > >> Xft.dpi: 96 >> > >> Xft.rgba: none >> > >> Xcursor.size: 21 >> > >> Xft/DPI: 98304 >> > >> Xft.hintstyle: hintmedium >> > >> >> > >> I know the DPI here is for client-side/fontconfig fonts and is >> unrelated >> > >> to Xorg-rendered fonts, but I find the value of 98304 to be >> strange here. >> > That's the DPI value multiplied by 1024, see: >> > https://wiki.debian.org/MonitorDPI > orDPI> >> > >> > Cheers >> > Antoine >> > >> > >> > >> >> > > _______________________________________________ >> > > shifter-users mailing list >> > > shifter-users at lists.devloop.org.uk >> > >> > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > >> > > >> > >> > _______________________________________________ >> > shifter-users mailing list >> > shifter-users at lists.devloop.org.uk >> > >> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > >> > >> > >> >> > From antoine at nagafix.co.uk Thu Oct 6 05:06:28 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 6 Oct 2016 11:06:28 +0700 Subject: [winswitch] high latency (was dpi switch..) In-Reply-To: References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> Message-ID: <00d5857e-f4d4-dc07-0db4-b7c08589ee4d@nagafix.co.uk> On 06/10/16 09:20, Thomas Esposito wrote: > Just to add a bit more info... > > I've tried x264, lz4, and png (32, 8, and gray scale) encodings and none > of these approach the responsiveness and perceived performance of > TigerVNC with Tight encoding. > > When I look at the stats and graphs under session info, I see lots of > latency spikes, particularly under Damage latency, which spikes into > several seconds. That would be a bug. Although xpra has been heavily optimized for fast networks, with relatively low latency and low packet loss, it should still adapt to more challenging network conditions. Others have reported this before but I've never seen it for myself directly, which makes it hard to fix. Could be the same as: http://xpra.org/trac/ticket/999 Please add your information there. > I've also tried this on a Microsoft Azure Ubuntu VM that I've been > playing around with via a free trial account. The performance seems > better (same encodings), but occasionally gets pretty bad. Maybe it's > just intermittent network issues. Sounds like it. Cheers Antoine > I haven't been able to get VNC working > on this VM... From antoine at nagafix.co.uk Thu Oct 6 05:11:00 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 6 Oct 2016 11:11:00 +0700 Subject: [winswitch] DPI, window resizing increments and performance (was dpi..) In-Reply-To: References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> Message-ID: On 06/10/16 02:14, Thomas Esposito wrote: > Adding the path to the usr/lib64/xorg/modules/drivers directory of my > local install to the LD_LIBRARY_PATH was not enough to force Xorg to use > the patched dummy driver. However, I discovered that I could add a > "ModulePath" line to my xorg.conf in order to change the effective > module search path. > > So, the DPI problem is solved. Thanks for the help! Ah, forgot about this option! > The next 2 issues on my list are: > > 1.) My terminal of choice has been gnome-terminal for a while. This is > version 2.31.3 on RHEL6.6. The problem is that, when I maximize the > window, the edge of the window appears to extend beyond the bottom edge > of my monitor. As a result, the bottom row of text in the terminal is > mostly cut off. When I maximize to an extended display in a dual-monitor > setup, it is not quite as bad and I can see about the top 75% of the > bottom row of text. I wonder if this has something to do with this > particular X application being forced to relatively coarse-grained > sizing increments (i.e. in units of text columns-rows), and then > rounding up to the next size increment rather than down when the > maximized window size doesn't exactly match one of these coarse-grained > increments. Sounds like: http://xpra.org/trac/ticket/1327 The size increments should be forwarded to the client. > 2.) This is a bigger issue. I'm finding that compared to TigerVNC, which > is the officially-supported remote X solution in my office (and doesn't > support per-application windows like xpra), is MUCH faster than xpra. I > haven't ruled out some kind of network QOS prioritizing VNC traffic over > ssh, but I wanted to ask what kind of performance I should be expecting > relative to something like TigerVNC. We also have FreeNX working (but > again, not with per-application windows), which supposedly uses ssh as > well, but FreeNX performance is at least as good as TigerVNC, if not > better. xpra is in a DISTANT 3rd place. See the other email, sounds like a bug. Cheers Antoine > > > > On Tue, Oct 4, 2016 at 11:23 AM, Antoine Martin > wrote: > > On 04/10/16 21:43, Thomas Esposito wrote: > > On Tue, Oct 4, 2016 at 4:52 AM, Antoine Martin via shifter-users > > > > >> wrote: > > On 04/10/16 03:18, Thomas Esposito via shifter-users wrote: > > > I'm not sure if this is related to my issue, > > Probably is. > > > > > but I have reason to doubt > > > that the shared libraries that I extracted from the rpm files are actually > > > being loaded. > > This may severely impact your experience: missing picture codecs, wrong > > DPI, etc.. > > > > Actually, I think the one of the issues contributing to my DPI problem > > are that I can't seem to load the dummy_drv.so instead of the patched > > version from the rpm. I'm guessing that Xorg is using a hard-coded path > > to /usr/lib64/xorg/modules/drivers/, and using that without even looking > > at my LD_LIBRARY_PATH. I'm not sure there is any way around this without > > directly replacing the lib in /usr/lib64/xorg/modules/drivers. > Yes, like I said just below, use the patched dummy driver. > In your case, you may need to build your own patched Xorg server from > source to get it loaded. > > (snip) > > > Also, despite my LD_LIBRARY_PATH setting, my Xorg.:100.log file (I'm using > > > display :100) reports that it is loading the standard > > > /usr/lib64/xorg/modules/drivers/dummy_drv.so, rather than the patched > > > driver in > > > /usr/lib64/xorg/modules/drivers/dummy_drv.so.. > > This will be the source of your DPI problems: you won't be using a > > patched dummy driver. > ^ See here. > > > > How can I be sure that any of the libraries that I have downloaded are > > > actually being loaded? > > That depends on how the application loads its shared objects. > > In the case of Xorg, this is probably a hard-coded path you can do > > nothing about. (and you probably won't be able to LD_PRELOAD it either) > > > > Nope, I can't seem to LD_PRELOAD your dummy_drv.so (I get ERRORs). > > > > > > > On Mon, Oct 3, 2016 at 3:07 PM, Thomas Esposito > >> wrote: > > > > > >> The fonts rendered by Xorg are very small, and I suspect the reason is > > >> because the DPI is being set to an unreasonably low value (i.e. 42x28 now, > > >> but varies depending on the monitor setup). Rather than deal with the > > >> patched dummy driver, I'm assuming that I should be able to simply fix the > > >> X DPI to a reasonable value (i.e. 96x96), since that is what I'm accustomed > > >> to anyway, being a Windows user primarily. I know there are quasi-religious > > >> arguments about a fixed DPI of 96, particularly with all the high-res > > >> monitors available now, but I'd rather not get into that. > > The issue you're hitting is that the applications you use do not honour > > any of your DPI settings but they try to calculate their own "hardware > > DPI" based on the monitor dimensions and screen resolution. > > This never works well, which is why we have use a patched dummy driver > > to simulate the "correct" values. > > > > I'm not sure about this explanation. > OK. > > > For example, when I use TigerVNC, I > > can set the DPI directly on the vncserver command line with the '-dpi' > > switch. When I do this, the "resolution" reported by xdpyinfo matches > > the value that I set on the command line. More importantly, when running > > the very same X applications that I am having DPI problems with when > > using xpra, the Xvnc server fonts scale EXACTLY according the the > > reported "resolution" value (at least when application requests a > > DPI-scaled font). When using xpra (at least without the patched > > dummy_drv.so), the "--dpi" switch has absolutely NO effect on the > > "resolution" reported by xdpyinfo. Rather, it seems to ALWAYS be > > calculated based on the Modeline resolution and the DisplaySize (I think > > we agree on this). In particular, what doesn't make sense to me is the > > idea that individual X applications will be doing their OWN DPI > > calculation. According to my understanding, the X application simply > > asks the X server to render a font. > Those days are long gone, "most" applications use toolkits nowadays and > not X11 core rendering. > > > It may asks for an unscaled font > > (e.g. RHEL6 xemacs seems to do this), which will always be rendered the > > same regardless of DPI, but otherwise it is up to the X server how to > > render it based on its own understanding of DPI. It seems that the issue > > is NOT that some X applications calculate their own DPI, but rather that > > the X server itself (when using the standard dummy_drv.so) effectively > > IGNORES the DPI switch that Xorg was started with and instead calculates > > it based on Modeline resolution and DisplaySize. > Almost, but not quite: the dpi is not ignored, it is scaled. > When the client connects, the dummy virtual screen is resized to match > your client's resolution as best we can, and at that point the dummy > screen does have a "fixed virtual size" of sorts. > > ie with trunk: when we change the default ~8K resolution down to > 1080p... the original DPI value is divided by ~4. > > The patched dummy driver will not only keep the DPI constant when the > screen is resized, it will also try to honour the value supplied by the > client. (obviously, not all clients have the same DPI settings) > > > I suppose that the end > > result is ultimately the same, and dummy_drv.so needs to be fixed in > > such a way that it respects the DPI. As you say, I imagine that if I was > > actually able to use the patched dummy_drv.so (it seems I can't though), > > I would see that the "resolution" reported by xdpyinfo is what I have > > requested and DPI-scaled fonts will look "right". > Yes, that's why it's there. > > > Ultimately, I believe that the only input the individual X applications > > provide into the equation is effectively binary. That is, it either > > requests a scaled on un-scaled font. > > Also, I think it's confusing to refer to the X server DPI and Xft.dpi in > > the same context. These are associated with 2 TOTALLY different font > > rendering systems. Xft is for modern client-side (i.e. X application > > side) font rendering. This is totally independent of the X server DPI > > and it explains why I don't have any problems with the fonts in my > > gnome-terminal for example. > As far as xpra is concerned, whether the forwarded applications will be > using X11 rendering or client-side rendering is totally irrelevant: all > options must be supported. > > So we synchronize all the DPI settings we can get our hands on in the > hope that all applications will render using the correct settings. > In some cases, this requires a patched dummy driver be achieved. > > > All that being said, forgive me if I'm being presumptuous. ;-) I can > > certainly be convinced otherwise, but right now, something just isn't > > adding up regarding this explanation. > There should be enough information above, otherwise there is *a lot* > more on the wiki and the DPI related tickets. > > Cheers > Antoine > > > > > > > > > > If you want to fix this without using the patched dummy > driver, your > > only option is to edit your etc/xpra/xorg.conf and change the > > DisplaySize of the monitor to get the desired DPI value: > > https://wiki.archlinux.org/index.php/xorg#Display_size_and_DPI > > > > > > > This will not adapt when you connect clients with different > resolutions. > > > > You may also want to try to switch to Xvfb instead of Xdummy > by changing > > the "xvfb=" line in your xpra config file. > > > > >> Anyway, I've attempted to fix the Xorg DPI by using the > '--dpi=96' switch > > >> on the xpra command line AND by uncommenting the 'dpi = 96' > line from the > > >> default xpra.conf file included with the install (which I > have copied to > > >> ~/.xpra/xpra.conf). In both cases, this does not seem to > have any effect, > > >> and my fonts and DPI remain unreasonably small. > > >> > > >> What am I missing? > > >> > > >> Also interesting, although most likely unrelated, > > It is related and very relevant, but sadly it is also ignored > by many > > applications. > > > > >>is the output I get when > > >> running 'xrdb -q': > > >> > > >> gnome.Xft/DPI: 98304 > > >> Xft.hinting: 1 > > >> Xft.antialias: 1 > > >> Xft.dpi: 96 > > >> Xft.rgba: none > > >> Xcursor.size: 21 > > >> Xft/DPI: 98304 > > >> Xft.hintstyle: hintmedium > > >> > > >> I know the DPI here is for client-side/fontconfig fonts and > is unrelated > > >> to Xorg-rendered fonts, but I find the value of 98304 to be > strange here. > > That's the DPI value multiplied by 1024, see: > > https://wiki.debian.org/MonitorDPI > > > > > > > Cheers > > Antoine > > > > > > >> > > > _______________________________________________ > > > shifter-users mailing list > > > shifter-users at lists.devloop.org.uk > > > > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > > > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > > > > > From tmesposito00 at gmail.com Fri Oct 7 05:05:45 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Fri, 7 Oct 2016 00:05:45 -0400 Subject: [winswitch] high latency (was dpi switch..) In-Reply-To: <00d5857e-f4d4-dc07-0db4-b7c08589ee4d@nagafix.co.uk> References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> <00d5857e-f4d4-dc07-0db4-b7c08589ee4d@nagafix.co.uk> Message-ID: As an experiment, I tried binding my xpra session to TCP port 5910, which is within the range typically used by VNC (also no encryption, which is fine because I'm on a private corporate intranet). The idea is to test out a theory that the network admins have prioritized VNC traffic (because there are a lot of people depending on remote VNC access) by classifying on the TCP port. It could be placebo, but it actually seems much better. I don't really see the latency spikes that I was seeing before, although I'd have to use it longer to be sure. It could also simply be that there is less network traffic at this time of day. IF my theory is true, and VNC traffic (identified by port) is being treated more favorably and consistently in the network, perhaps this is reducing the probability that I will encounter xpra bugs manifesting as catastrophic performance degradation triggered by changing network conditions. On Thu, Oct 6, 2016 at 12:06 AM, Antoine Martin wrote: > On 06/10/16 09:20, Thomas Esposito wrote: > > Just to add a bit more info... > > > > I've tried x264, lz4, and png (32, 8, and gray scale) encodings and none > > of these approach the responsiveness and perceived performance of > > TigerVNC with Tight encoding. > > > > When I look at the stats and graphs under session info, I see lots of > > latency spikes, particularly under Damage latency, which spikes into > > several seconds. > That would be a bug. Although xpra has been heavily optimized for fast > networks, with relatively low latency and low packet loss, it should > still adapt to more challenging network conditions. > > Others have reported this before but I've never seen it for myself > directly, which makes it hard to fix. Could be the same as: > http://xpra.org/trac/ticket/999 > Please add your information there. > > > I've also tried this on a Microsoft Azure Ubuntu VM that I've been > > playing around with via a free trial account. The performance seems > > better (same encodings), but occasionally gets pretty bad. Maybe it's > > just intermittent network issues. > Sounds like it. > > Cheers > Antoine > > > I haven't been able to get VNC working > > on this VM... > > From tmesposito00 at gmail.com Fri Oct 7 06:28:48 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Fri, 7 Oct 2016 01:28:48 -0400 Subject: [winswitch] high latency (was dpi switch..) In-Reply-To: References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> <00d5857e-f4d4-dc07-0db4-b7c08589ee4d@nagafix.co.uk> Message-ID: I've been thinking a bit more... Isn't the problem of avoiding the creation of a backlog of window updates that add to latency something that VNC has to solve as well? They seem to be doing a decent job of it. I found this interesting read... https://github.com/TigerVNC/tigervnc/wiki/Latency On Oct 7, 2016 12:05 AM, "Thomas Esposito" wrote: > As an experiment, I tried binding my xpra session to TCP port 5910, which > is within the range typically used by VNC (also no encryption, which is > fine because I'm on a private corporate intranet). The idea is to test out > a theory that the network admins have prioritized VNC traffic (because > there are a lot of people depending on remote VNC access) by classifying on > the TCP port. > > It could be placebo, but it actually seems much better. I don't really see > the latency spikes that I was seeing before, although I'd have to use it > longer to be sure. It could also simply be that there is less network > traffic at this time of day. IF my theory is true, and VNC traffic > (identified by port) is being treated more favorably and consistently in > the network, perhaps this is reducing the probability that I will encounter > xpra bugs manifesting as catastrophic performance degradation triggered by > changing network conditions. > > > On Thu, Oct 6, 2016 at 12:06 AM, Antoine Martin > wrote: > >> On 06/10/16 09:20, Thomas Esposito wrote: >> > Just to add a bit more info... >> > >> > I've tried x264, lz4, and png (32, 8, and gray scale) encodings and none >> > of these approach the responsiveness and perceived performance of >> > TigerVNC with Tight encoding. >> > >> > When I look at the stats and graphs under session info, I see lots of >> > latency spikes, particularly under Damage latency, which spikes into >> > several seconds. >> That would be a bug. Although xpra has been heavily optimized for fast >> networks, with relatively low latency and low packet loss, it should >> still adapt to more challenging network conditions. >> >> Others have reported this before but I've never seen it for myself >> directly, which makes it hard to fix. Could be the same as: >> http://xpra.org/trac/ticket/999 >> Please add your information there. >> >> > I've also tried this on a Microsoft Azure Ubuntu VM that I've been >> > playing around with via a free trial account. The performance seems >> > better (same encodings), but occasionally gets pretty bad. Maybe it's >> > just intermittent network issues. >> Sounds like it. >> >> Cheers >> Antoine >> >> > I haven't been able to get VNC working >> > on this VM... >> >> > From vfclists at gmail.com Sun Oct 9 15:36:03 2016 From: vfclists at gmail.com (vfclists .) Date: Sun, 9 Oct 2016 15:36:03 +0100 Subject: [winswitch] How do I use xpra as a substitute for a remote desktop like VNC or X2go? Message-ID: I have been getting some problems using the KDE Plasma 5 desktop on Debian Stretch/Sid using x2go and VNC on I want to try xpra instead. If I want to run an XFCE or Gnome session for instance, how do I start the xpra instance on the server? I have been able to get sessions going and I can run individual sessions in them, but how do I run desktops themselves? -- Frank Church ======================= http://devblog.brahmancreations.com From antoine at nagafix.co.uk Sun Oct 9 16:36:36 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 9 Oct 2016 22:36:36 +0700 Subject: [winswitch] How do I use xpra as a substitute for a remote desktop like VNC or X2go? In-Reply-To: References: Message-ID: <7e7b4f86-9b92-dbc3-c437-13d28f91a287@nagafix.co.uk> On 09/10/16 21:36, vfclists . via shifter-users wrote: > I have been getting some problems using the KDE Plasma 5 desktop on Debian > Stretch/Sid using x2go and VNC on I want to try xpra instead. > > If I want to run an XFCE or Gnome session for instance, how do I start the > xpra instance on the server? I have been able to get sessions going and I > can run individual sessions in them, but how do I run desktops themselves? > The best way is using the current pre-release (http://xpra.org/beta): xpra start-desktop ssh/$HOST --start-child=xterm --exit-with-children >From that xterm you can then launch the KDE session (whatever the launch command for that is - I do not know). Once that works, you can replace that command in the "start-child" command line argument. Cheers Antoine From antoine at nagafix.co.uk Sun Oct 9 16:53:41 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 9 Oct 2016 22:53:41 +0700 Subject: [winswitch] high latency (was dpi switch..) In-Reply-To: References: <90bc012a-1ea6-9840-8b6b-b7e390c02554@nagafix.co.uk> <7542cd2a-e259-7609-1d48-b7f0d5f04b7d@nagafix.co.uk> <00d5857e-f4d4-dc07-0db4-b7c08589ee4d@nagafix.co.uk> Message-ID: <175b0bba-a1db-9ebc-ba94-27ff1eac30f3@nagafix.co.uk> On 07/10/16 12:28, Thomas Esposito wrote: > I've been thinking a bit more... > > Isn't the problem of avoiding the creation of a backlog of window > updates that add to latency something that VNC has to solve as well? > They seem to be doing a decent job of it. They also have much fewer constraints: no individual windows (that come and go, each with its own rate of screen updates..), no video encodings, no sound, no sound synchronization (which delays video), etc.. > I found this interesting read... It is. > https://github.com/TigerVNC/tigervnc/wiki/Latency There's some very good points, it looks like we have already implemented most of these ideas in xpra: unsolicited updates, RTT (ping), per-client backlog accounting, flow-control.. As per the ticket link in my previous reply, I suspect that the flow control is being over-optimistic and overfills the network. The problem is that this works really well for fast LANs and so I don't want to start changing those heuristics without having some reproducible pathological test cases to fix. Adding latency and packet loss with tc doesn't seem to reproduce these problems so far. But if you can find a setup that does, we'll make sure to fix it! Cheers Antoine > > > On Oct 7, 2016 12:05 AM, "Thomas Esposito" > wrote: > > As an experiment, I tried binding my xpra session to TCP port 5910, > which is within the range typically used by VNC (also no encryption, > which is fine because I'm on a private corporate intranet). The idea > is to test out a theory that the network admins have prioritized VNC > traffic (because there are a lot of people depending on remote VNC > access) by classifying on the TCP port. > > It could be placebo, but it actually seems much better. I don't > really see the latency spikes that I was seeing before, although I'd > have to use it longer to be sure. It could also simply be that there > is less network traffic at this time of day. IF my theory is true, > and VNC traffic (identified by port) is being treated more favorably > and consistently in the network, perhaps this is reducing the > probability that I will encounter xpra bugs manifesting as > catastrophic performance degradation triggered by changing network > conditions. > > > On Thu, Oct 6, 2016 at 12:06 AM, Antoine Martin > > wrote: > > On 06/10/16 09:20, Thomas Esposito wrote: > > Just to add a bit more info... > > > > I've tried x264, lz4, and png (32, 8, and gray scale) > encodings and none > > of these approach the responsiveness and perceived performance of > > TigerVNC with Tight encoding. > > > > When I look at the stats and graphs under session info, I see > lots of > > latency spikes, particularly under Damage latency, which > spikes into > > several seconds. > That would be a bug. Although xpra has been heavily optimized > for fast > networks, with relatively low latency and low packet loss, it should > still adapt to more challenging network conditions. > > Others have reported this before but I've never seen it for myself > directly, which makes it hard to fix. Could be the same as: > http://xpra.org/trac/ticket/999 > Please add your information there. > > > I've also tried this on a Microsoft Azure Ubuntu VM that I've been > > playing around with via a free trial account. The performance > seems > > better (same encodings), but occasionally gets pretty bad. > Maybe it's > > just intermittent network issues. > Sounds like it. > > Cheers > Antoine > > > I haven't been able to get VNC working > > on this VM... > > From vfclists at gmail.com Tue Oct 11 08:09:36 2016 From: vfclists at gmail.com (vfclists .) Date: Tue, 11 Oct 2016 08:09:36 +0100 Subject: [winswitch] How do I use xpra as a substitute for a remote desktop like VNC or X2go? Message-ID: ------------------------------ > On 09/10/16 21:36, vfclists . via shifter-users wrote: >> I have been getting some problems using the KDE Plasma 5 desktop on Debian >> Stretch/Sid using x2go and VNC on I want to try xpra instead. >> >> If I want to run an XFCE or Gnome session for instance, how do I start the >> xpra instance on the server? I have been able to get sessions going and I >> can run individual sessions in them, but how do I run desktops themselves? >> > The best way is using the current pre-release (http://xpra.org/beta): > xpra start-desktop ssh/$HOST --start-child=xterm --exit-with-children > From that xterm you can then launch the KDE session (whatever the launch > command for that is - I do not know). Once that works, you can replace > that command in the "start-child" command line argument. > Cheers > Antoine In regard to your earlier response I prefer to stick to stable releases rather than use betas. Is it still possible in the current stable release? I don't mind it if is more difficult I am willing to give it a try and learn it more in depth -- Frank Church ======================= http://devblog.brahmancreations.com From antoine at nagafix.co.uk Tue Oct 11 12:33:01 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 11 Oct 2016 18:33:01 +0700 Subject: [winswitch] How do I use xpra as a substitute for a remote desktop like VNC or X2go? In-Reply-To: References: Message-ID: <0e3824f6-3de3-2ba0-751f-5d4e6c0c637e@nagafix.co.uk> On 11/10/16 14:09, vfclists . via shifter-users wrote: > ------------------------------ > >> On 09/10/16 21:36, vfclists . via shifter-users wrote: >>> I have been getting some problems using the KDE Plasma 5 desktop on Debian >>> Stretch/Sid using x2go and VNC on I want to try xpra instead. >>> >>> If I want to run an XFCE or Gnome session for instance, how do I start the >>> xpra instance on the server? I have been able to get sessions going and I >>> can run individual sessions in them, but how do I run desktops themselves? >>> >> The best way is using the current pre-release (http://xpra.org/beta): >> xpra start-desktop ssh/$HOST --start-child=xterm --exit-with-children > >> From that xterm you can then launch the KDE session (whatever the launch >> command for that is - I do not know). Once that works, you can replace >> that command in the "start-child" command line argument. > >> Cheers >> Antoine > > In regard to your earlier response I prefer to stick to stable releases > rather than use betas. Is it still possible in the current stable release? You may be able to use Xephyr or Xnest to get a VNC-like display, but this will not work very well at all in the stable branch. (bad performance, keyboard and many other bugs, etc). > I don't mind it if is more difficult I am willing to give it a try and > learn it more in depth In that case, I recommend the latest beta builds: the knowledge gained will be much more useful since the "start-desktop" solution will actually work well and it will be supported. Cheers Antoine From mukulagrawal78 at yahoo.com Tue Oct 11 21:28:30 2016 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Tue, 11 Oct 2016 20:28:30 +0000 (UTC) Subject: [winswitch] Xdummy on Ubuntu References: <1531410526.2179985.1476217710791.ref@mail.yahoo.com> Message-ID: <1531410526.2179985.1476217710791@mail.yahoo.com> On Ubuntu Xenial, xpra is using the fallback option of Xvfb. I will like to somehow be able to use Xdummy.My specific use-case is on headless machines .... so I don't have any Xorg starting by default. Is there any workaround that can enable me to use Xdummy?Is this expected to be a long term problem or do you expect to have a solution in near term? I highly doubt Ubuntu will do anything about it, even in near future LTS releases. Alternatively, if I rollback to Trusty, do I need to follow the procedure mentioned in the link below?Or will newer releases of xpra take care of it automatically? [I never followed this procedure before on Trusty but I dont recall seeing Xdummy related warning before either. Xdummy ? Xpra | | | | | | | | | | | Xdummy ? Xpra xpra - screen for X | | | | ?Regards, Mukul ( https://sites.google.com/site/mukulagrawal ) On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users wrote: Thanks for the clarifications.I simplified the setup (non-sudo user for proxy; same usernames on both machines) to be able to debug. But it still does not work. Multifile authentication on proxy succeeds. But seems like it not using correct ssh command line to connect to backened server.? Logs on the proxy are attached below. There are no logs on the backend xpra server. The sshd logs on the backend server says that the connection was closed by the proxy [preauth]. 1. I now start proxy as non-sudo user1 on machine1 and attach it to non-priveldged tcp port1. Give it a display number disp1. ?xpra proxy :disp1 --bind-tcp=0.0.0.0:port1 --tcp-auth=multifile:filename=path-to-multifile -d auth Machine1 is running newer version of XPRA (xpra proxy version 1.0-r13637). multifile looks like following :- user1|pswd1|1000|1000|ssh:user1 at machine2:disp2|| 2. start an xpra server on machine2 under the user account with with same username user1. Give it a display number disp2. xpra start :disp2DISPLAY=:disp2 xeyes & Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if this creates any problems. 3. Try attaching to backend server on machine2 from machine 1 using ssh transport and public key authentication. xpra attach ssh:user1 at machine2:disp2 This works fine. So seems like different versions are compatible. 4. Try attaching from xpra clent running on machine3 (win7 machine). xpra attach --password-file=pswd.txt tcp:user1 at machine1:port1 OR xpra attach tcp:user1:pswd1 at machine1:port1 Proxy Logs :- 2016-09-16 11:03:55,160 New tcp connection received from IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp, authclass=('multifile', , {'filename': 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16 11:03:55,161 creating authenticator ('multifile',, {'filename': 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16 11:03:55,161 processing authentication withmulti password file, response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16 11:03:55,161 challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16 11:03:55,161 Authentication required by multipassword file authenticator module^[[0m2016-09-16 11:03:55,162?sending challenge for 'user1' using hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication withmulti password file, response=864f4fff84caf265599ff84726295167, client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16 11:03:55,271 mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16 11:03:55,271 loaded 184 bytes from 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1: ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m?. Something here ?hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<- IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1 at IP2:disp2'], {}, {})^[[0m^[[36m2016-09-16 11:03:55,273 start_proxy:proxy-virtual-display=:disp1 (ignored), user specified display=None, founddisplays=['ssh:user1 at IP2:disp2']^[[0m2016-09-16 11:03:55,499 proxy video encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance started^[[0m2016-09-16 11:03:55,499?for client tcp socket: internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499?and server Pipe(ssh:user1 at IP2:disp2)^[[0m2016-09-16 11:03:55,500 proxy instance now also availableusing unix domain socket:^[[0m2016-09-16 11:03:55,500?path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16 11:03:55,503 Error: SSH connection to thexpra server failed^[[0m^[[31m2016-09-16 11:03:55,504? check your username, hostname, displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504? for server: ssh:user1 at IP2:disp2^[[0m^[[31m2016-09-16 11:03:55,504? the command line used was:^[[0m^[[31m2016-09-16 11:03:55,504? ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505 proxy instance 11703 stopped^[[0m ?Regards, Mukul ( https://sites.google.com/site/mukulagrawal ) ? ? On Thursday, September 15, 2016 10:24 AM, Antoine Martin via shifter-users wrote: On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote: > If I want xpra proxy on machine1 to connect to xpra server on machine2 using ssh with public key authentication and no password, then how should I set it up? I have not tested this, but SSH connections from the proxy should be using the public key of the user running the proxy server process and not the key of the user you authenticate as. (which may not have a user account at all on the system running the proxy) > Public keys are already in default locations and xpra is able to attach directly from machine2 to machine 1 using standard format:? xpra attach ssh:username at machine1:display. I thought the server you wanted to connect to was "machine 2" and not the other way around? > But when I try to connect via proxy from client machine3, proxy is not being able to authenticate. Have you checked your ssh server logs for an answer? > It sends the challenge but then there is no log after that. Please share the log sample up to that point to help clarify things. Note: when using SSH connections, the server does not need to use another socket authentication module. That's usually just redundant. > I am using multifile like this :- > username|pswd|1000|1000|ssh:machine1:display|| > and attach command from machine3 like this:-xpra attach tcp:username:pswd at machine2:proxyPORT > > Are the usernames and passwords actually associated with login accounts on the target machine or their significance is only with respect to multifile resolution? It depends: if the proxy server runs as root, each proxied connection will run as the uid and gid you defined. (ie: 1000 above) But the connection to the backend server is made before changing uid, so the ssh key used will not be the one of the user specified in multifile. If you don't mind using SSH with passwords, you should be able to use something like this (untested): |username|pswd|1000|1000|ssh/username2:password2 at machine2/display|| We could also change the code to: * add support for ssh options to multifile, so you could specify the keyfile for each user * change the ordering so the connection to the backend server happens after changing uid and gid (but this would only work with the proxy running as root) Feel free to create tickets for this. > Can password be left blank for public key authentication? That doesn't make sense: the password in multifile is for authentication to the proxy, not to the backend server. Unless you're trying to connect via ssh to your proxy? (but why?) Cheers Antoine > > Thanks. > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ shifter-users mailing list shifter-users at lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users ? _______________________________________________ shifter-users mailing list shifter-users at lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users From mukulagrawal78 at yahoo.com Wed Oct 12 00:53:18 2016 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Tue, 11 Oct 2016 23:53:18 +0000 (UTC) Subject: [winswitch] high latency (was dpi switch..) References: <1544087541.2260547.1476229998628.ref@mail.yahoo.com> Message-ID: <1544087541.2260547.1476229998628@mail.yahoo.com> This thread brings an interesting question to my mind :- If I am using the HTML5 client, therefore loosing the seamless-ness and all individual window benefits, then in that case is there any fundamental difference and/or benefit of using XPRA versus noVNC and vice-versa? Or should we expecting them to be same/similar, at least in principle? I run interactive graphical application across internet with reasonably fast typical household internet connections (e.g. I can stream Netflix on couple of devices simultaneously without any issues). XPRA python clients generally work very well but HTML5 client does not. noVNC also seems to do OK job.? ?Regards, Mukul ( https://sites.google.com/site/mukulagrawal ) On Sunday, October 9, 2016 8:53 AM, Antoine Martin via shifter-users wrote: On 07/10/16 12:28, Thomas Esposito wrote: > I've been thinking a bit more... > > Isn't the problem of avoiding the creation of a backlog of window > updates that add to latency something that VNC has to solve as well? > They seem to be doing a decent job of it. They also have much fewer constraints: no individual windows (that come and go, each with its own rate of screen updates..), no video encodings, no sound, no sound synchronization (which delays video), etc.. > I found this interesting read... It is. > https://github.com/TigerVNC/tigervnc/wiki/Latency There's some very good points, it looks like we have already implemented most of these ideas in xpra: unsolicited updates, RTT (ping), per-client backlog accounting, flow-control.. As per the ticket link in my previous reply, I suspect that the flow control is being over-optimistic and overfills the network. The problem is that this works really well for fast LANs and so I don't want to start changing those heuristics without having some reproducible pathological test cases to fix. Adding latency and packet loss with tc doesn't seem to reproduce these problems so far. But if you can find a setup that does, we'll make sure to fix it! Cheers Antoine > > > On Oct 7, 2016 12:05 AM, "Thomas Esposito" > wrote: > >? ? As an experiment, I tried binding my xpra session to TCP port 5910, >? ? which is within the range typically used by VNC (also no encryption, >? ? which is fine because I'm on a private corporate intranet). The idea >? ? is to test out a theory that the network admins have prioritized VNC >? ? traffic (because there are a lot of people depending on remote VNC >? ? access) by classifying on the TCP port. > >? ? It could be placebo, but it actually seems much better. I don't >? ? really see the latency spikes that I was seeing before, although I'd >? ? have to use it longer to be sure. It could also simply be that there >? ? is less network traffic at this time of day. IF my theory is true, >? ? and VNC traffic (identified by port) is being treated more favorably >? ? and consistently in the network, perhaps this is reducing the >? ? probability that I will encounter xpra bugs manifesting as >? ? catastrophic performance degradation triggered by changing network >? ? conditions. > > >? ? On Thu, Oct 6, 2016 at 12:06 AM, Antoine Martin >? ? > wrote: > >? ? ? ? On 06/10/16 09:20, Thomas Esposito wrote: >? ? ? ? > Just to add a bit more info... >? ? ? ? > >? ? ? ? > I've tried x264, lz4, and png (32, 8, and gray scale) >? ? ? ? encodings and none >? ? ? ? > of these approach the responsiveness and perceived performance of >? ? ? ? > TigerVNC with Tight encoding. >? ? ? ? > >? ? ? ? > When I look at the stats and graphs under session info, I see >? ? ? ? lots of >? ? ? ? > latency spikes, particularly under Damage latency, which >? ? ? ? spikes into >? ? ? ? > several seconds. >? ? ? ? That would be a bug. Although xpra has been heavily optimized >? ? ? ? for fast >? ? ? ? networks, with relatively low latency and low packet loss, it should >? ? ? ? still adapt to more challenging network conditions. > >? ? ? ? Others have reported this before but I've never seen it for myself >? ? ? ? directly, which makes it hard to fix. Could be the same as: >? ? ? ? http://xpra.org/trac/ticket/999 >? ? ? ? Please add your information there. > >? ? ? ? > I've also tried this on a Microsoft Azure Ubuntu VM that I've been >? ? ? ? > playing around with via a free trial account. The performance >? ? ? ? seems >? ? ? ? > better (same encodings), but occasionally gets pretty bad. >? ? ? ? Maybe it's >? ? ? ? > just intermittent network issues. >? ? ? ? Sounds like it. > >? ? ? ? Cheers >? ? ? ? Antoine > >? ? ? ? > I haven't been able to get VNC working >? ? ? ? > on this VM... > > _______________________________________________ shifter-users mailing list shifter-users at lists.devloop.org.uk http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed Oct 12 04:18:27 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 12 Oct 2016 10:18:27 +0700 Subject: [winswitch] Xdummy on Ubuntu In-Reply-To: <1531410526.2179985.1476217710791@mail.yahoo.com> References: <1531410526.2179985.1476217710791.ref@mail.yahoo.com> <1531410526.2179985.1476217710791@mail.yahoo.com> Message-ID: <1890c3e5-aa39-d286-61a7-b99ccf55adff@nagafix.co.uk> On 12/10/16 03:28, Mukul Agrawal wrote: > On Ubuntu Xenial, xpra is using the fallback option of Xvfb. > I will like to somehow be able to use Xdummy. > My specific use-case is on headless machines .... so I don't have any > Xorg starting by default. > Is there any workaround that can enable me to use Xdummy? Possibly, the Xdummy wiki page gives some clues about some of the permission changes that may be required (tested with Trusty): http://xpra.org/trac/wiki/Xdummy#Ubuntu > Is this expected to be a long term problem or do you expect to have a > solution in near term? Until Ubuntu fixes their packages or provides a workaround, no. > I highly doubt Ubuntu will do anything about it, even in near future LTS > releases. You should be asking the Ubuntu developers. They should know since they're the ones patching the upstream Xorg packages. Debian does not have this issue either. > Alternatively, if I rollback to Trusty, do I need to follow the > procedure mentioned in the link below? > Or will newer releases of xpra take care of it automatically? There is nothing we can do in our code: the broken Xorg packaging is Ubuntu's, not ours. > [I never followed this procedure before on Trusty but I dont recall > seeing Xdummy related warning before either. Which warning? I don't recall which one was the last version of Ubuntu that supported running Xdummy, sorry. Cheers Antoine > > Xdummy ? Xpra > > > > > > > Xdummy ? Xpra > > xpra - screen for X > > > > > > > > > > > Regards, > Mukul ( https://sites.google.com/site/mukulagrawal ) > > > On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users > wrote: > > > Thanks for the clarifications.I simplified the setup (non-sudo user for > proxy; same usernames on both machines) to be able to debug. But it > still does not work. > Multifile authentication on proxy succeeds. But seems like it not using > correct ssh command line to connect to backened server. Logs on the > proxy are attached below. There are no logs on the backend xpra server. > The sshd logs on the backend server says that the connection was closed > by the proxy [preauth]. > 1. I now start proxy as non-sudo user1 on machine1 and attach it to > non-priveldged tcp port1. Give it a display number disp1. > > xpra proxy :disp1 --bind-tcp=0.0.0.0:port1 > --tcp-auth=multifile:filename=path-to-multifile -d auth > > Machine1 is running newer version of XPRA (xpra proxy version 1.0-r13637). > > multifile looks like following :- > user1|pswd1|1000|1000|ssh:user1 at machine2 :disp2|| > > > 2. start an xpra server on machine2 under the user account with with > same username user1. Give it a display number disp2. > > xpra start :disp2DISPLAY=:disp2 xeyes & > > Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if > this creates any problems. > > 3. Try attaching to backend server on machine2 from machine 1 using ssh > transport and public key authentication. > xpra attach ssh:user1 at machine2 :disp2 > This works fine. So seems like different versions are compatible. > 4. Try attaching from xpra clent running on machine3 (win7 machine). > > xpra attach --password-file=pswd.txt tcp:user1 at machine1 > :port1 > > OR > xpra attach tcp:user1:pswd1 at machine1 :port1 > > > Proxy Logs :- > > 2016-09-16 11:03:55,160 New tcp connection received from > IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp, > authclass=('multifile', > , {'filename': > 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16 > 11:03:55,161 creating authenticator ('multifile', 'xpra.server.auth.multifile_auth.Authenticator'>, {'filename': > 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16 > 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16 > 11:03:55,161 processing authentication withmulti password file, > response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16 > 11:03:55,161 > challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16 > 11:03:55,161 Authentication required by multipassword file authenticator > module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using > hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication > withmulti password file, response=864f4fff84caf265599ff84726295167, > client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16 > 11:03:55,271 > mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16 > 11:03:55,271 loaded 184 bytes from > 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1: > ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m?. Something here > ?hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16 > 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16 > 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<- > IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1 at IP2 > :disp2'], {}, {})^[[0m^[[36m2016-09-16 11:03:55,273 > start_proxy:proxy-virtual-display=:disp1 (ignored), user specified > display=None, founddisplays=['ssh:user1 at IP2 > :disp2']^[[0m2016-09-16 11:03:55,499 proxy video > encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance > started^[[0m2016-09-16 11:03:55,499 for client tcp socket: > internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499 and server > Pipe(ssh:user1 at IP2 :disp2)^[[0m2016-09-16 11:03:55,500 > proxy instance now also availableusing unix domain > socket:^[[0m2016-09-16 > 11:03:55,500 path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16 > 11:03:55,503 Error: SSH connection to thexpra server > failed^[[0m^[[31m2016-09-16 11:03:55,504 check your username, hostname, > displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504 for > server: ssh:user1 at IP2 :disp2^[[0m^[[31m2016-09-16 > 11:03:55,504 the command line used was:^[[0m^[[31m2016-09-16 > 11:03:55,504 ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra > _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra > _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection > lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket > path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505 > proxy instance 11703 stopped^[[0m > > > > > > Regards, Mukul ( https://sites.google.com/site/mukulagrawal > ) > > On Thursday, September 15, 2016 10:24 AM, Antoine Martin via > shifter-users > wrote: > > > On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote: >> If I want xpra proxy on machine1 to connect to xpra server on machine2 > using ssh with public key authentication and no password, then how > should I set it up? > I have not tested this, but SSH connections from the proxy should be > using the public key of the user running the proxy server process and > not the key of the user you authenticate as. (which may not have a user > account at all on the system running the proxy) > >> Public keys are already in default locations and xpra is able to > attach directly from machine2 to machine 1 using standard format: xpra > attach ssh:username at machine1 :display. > I thought the server you wanted to connect to was "machine 2" and not > the other way around? > >> But when I try to connect via proxy from client machine3, proxy is not > being able to authenticate. > Have you checked your ssh server logs for an answer? > >> It sends the challenge but then there is no log after that. > Please share the log sample up to that point to help clarify things. > > Note: when using SSH connections, the server does not need to use > another socket authentication module. That's usually just redundant. > >> I am using multifile like this :- >> username|pswd|1000|1000|ssh:machine1:display|| >> and attach command from machine3 like this:-xpra attach > tcp:username:pswd at machine2 :proxyPORT >> >> Are the usernames and passwords actually associated with login > accounts on the target machine or their significance is only with > respect to multifile resolution? > It depends: if the proxy server runs as root, each proxied connection > will run as the uid and gid you defined. (ie: 1000 above) > But the connection to the backend server is made before changing uid, so > the ssh key used will not be the one of the user specified in multifile. > > If you don't mind using SSH with passwords, you should be able to use > something like this (untested): > |username|pswd|1000|1000|ssh/username2:password2 at machine2 > /display|| > > We could also change the code to: > * add support for ssh options to multifile, so you could specify the > keyfile for each user > * change the ordering so the connection to the backend server happens > after changing uid and gid (but this would only work with the proxy > running as root) > Feel free to create tickets for this. > >> Can password be left blank for public key authentication? > That doesn't make sense: the password in multifile is for authentication > to the proxy, not to the backend server. > Unless you're trying to connect via ssh to your proxy? (but why?) > > Cheers > Antoine > > >> >> Thanks. >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk > >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > From antoine at nagafix.co.uk Wed Oct 12 04:22:37 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 12 Oct 2016 10:22:37 +0700 Subject: [winswitch] high latency (was dpi switch..) In-Reply-To: <1544087541.2260547.1476229998628@mail.yahoo.com> References: <1544087541.2260547.1476229998628.ref@mail.yahoo.com> <1544087541.2260547.1476229998628@mail.yahoo.com> Message-ID: On 12/10/16 06:53, Mukul Agrawal wrote: > This thread brings an interesting question to my mind :- > > If I am using the HTML5 client, therefore loosing the seamless-ness and > all individual window benefits, then in that case is there any > fundamental difference and/or benefit of using XPRA versus noVNC and > vice-versa? Or should we expecting them to be same/similar, at least in > principle? It will be more similar because of the lack of a seamless mode, but with some added benefits: * sound support (being refactored) * video encoders - much faster (new client, in progress) * support for proxy servers, etc.. etc > I run interactive graphical application across internet with reasonably > fast typical household internet connections (e.g. I can stream Netflix > on couple of devices simultaneously without any issues). XPRA python > clients generally work very well but HTML5 client does not. noVNC also > seems to do OK job. The new HTML5 client code isn't ready yet, but I've been told it is as fast as the Python client :) Cheers Antoine > > > > Regards, > Mukul ( https://sites.google.com/site/mukulagrawal ) > > > On Sunday, October 9, 2016 8:53 AM, Antoine Martin via shifter-users > wrote: > > > On 07/10/16 12:28, Thomas Esposito wrote: >> I've been thinking a bit more... >> >> Isn't the problem of avoiding the creation of a backlog of window >> updates that add to latency something that VNC has to solve as well? >> They seem to be doing a decent job of it. > They also have much fewer constraints: no individual windows (that come > and go, each with its own rate of screen updates..), no video encodings, > no sound, no sound synchronization (which delays video), etc.. > >> I found this interesting read... > It is. > >> https://github.com/TigerVNC/tigervnc/wiki/Latency > There's some very good points, it looks like we have already implemented > most of these ideas in xpra: unsolicited updates, RTT (ping), per-client > backlog accounting, flow-control.. > > As per the ticket link in my previous reply, I suspect that the flow > control is being over-optimistic and overfills the network. > The problem is that this works really well for fast LANs and so I don't > want to start changing those heuristics without having some reproducible > pathological test cases to fix. Adding latency and packet loss with tc > doesn't seem to reproduce these problems so far. But if you can find a > setup that does, we'll make sure to fix it! > > Cheers > Antoine > > > >> >> >> On Oct 7, 2016 12:05 AM, "Thomas Esposito" >> >> wrote: >> >> As an experiment, I tried binding my xpra session to TCP port 5910, >> which is within the range typically used by VNC (also no encryption, >> which is fine because I'm on a private corporate intranet). The idea >> is to test out a theory that the network admins have prioritized VNC >> traffic (because there are a lot of people depending on remote VNC >> access) by classifying on the TCP port. >> >> It could be placebo, but it actually seems much better. I don't >> really see the latency spikes that I was seeing before, although I'd >> have to use it longer to be sure. It could also simply be that there >> is less network traffic at this time of day. IF my theory is true, >> and VNC traffic (identified by port) is being treated more favorably >> and consistently in the network, perhaps this is reducing the >> probability that I will encounter xpra bugs manifesting as >> catastrophic performance degradation triggered by changing network >> conditions. >> >> >> On Thu, Oct 6, 2016 at 12:06 AM, Antoine Martin >> > >> wrote: >> >> On 06/10/16 09:20, Thomas Esposito wrote: >> > Just to add a bit more info... >> > >> > I've tried x264, lz4, and png (32, 8, and gray scale) >> encodings and none >> > of these approach the responsiveness and perceived performance of >> > TigerVNC with Tight encoding. >> > >> > When I look at the stats and graphs under session info, I see >> lots of >> > latency spikes, particularly under Damage latency, which >> spikes into >> > several seconds. >> That would be a bug. Although xpra has been heavily optimized >> for fast >> networks, with relatively low latency and low packet loss, it > should >> still adapt to more challenging network conditions. >> >> Others have reported this before but I've never seen it for myself >> directly, which makes it hard to fix. Could be the same as: >> http://xpra.org/trac/ticket/999 > >> Please add your information there. >> >> > I've also tried this on a Microsoft Azure Ubuntu VM that I've > been >> > playing around with via a free trial account. The performance >> seems >> > better (same encodings), but occasionally gets pretty bad. >> Maybe it's >> > just intermittent network issues. >> Sounds like it. >> >> Cheers >> Antoine >> >> > I haven't been able to get VNC working >> > on this VM... >> >> > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > From tzahi.ml at gmail.com Thu Oct 13 13:09:03 2016 From: tzahi.ml at gmail.com (tzahi ml) Date: Thu, 13 Oct 2016 15:09:03 +0300 Subject: [winswitch] Off Topic: How to stream audio from a linux app to a browser Message-ID: Hi, Sorry for the off topic but I cannot seem to find and answer online. I am trying to figure out how to send real time audio from a linux program (pulseaudio?) to a web browser (web audio api?) without a plugin. I could not find guides or anything close. I tried shoutcast etc... but they are very laggy and defeats the point. Can someone point me in the right direction? (maybe from the html5 team) Thanks! From timothy at hobbs.cz Wed Oct 19 06:46:19 2016 From: timothy at hobbs.cz (Timothy Hobbs) Date: Wed, 19 Oct 2016 07:46:19 +0200 Subject: [winswitch] Off Topic: How to stream audio from a linux app to a browser In-Reply-To: References: Message-ID: <5beb0987-c6e0-80aa-de86-0d219b88fa1e@hobbs.cz> If you happen to use pulseaudio, then you could try adding a "stream" sink. I have not tested this, but here is an example: https://gist.github.com/djmaze/5234008 On 10/13/16 14:09, tzahi ml via shifter-users wrote: > Hi, > Sorry for the off topic but I cannot seem to find and answer online. > I am trying to figure out how to send real time audio from a linux program > (pulseaudio?) to a web browser (web audio api?) without a plugin. I could > not find guides or anything close. I tried shoutcast etc... but they are > very laggy and defeats the point. > > Can someone point me in the right direction? > (maybe from the html5 team) > > Thanks! > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From e.grammatico at gmail.com Wed Oct 19 15:38:11 2016 From: e.grammatico at gmail.com (Eric Grammatico) Date: Wed, 19 Oct 2016 14:38:11 +0000 Subject: [winswitch] Unable to print from the GTK2 client Message-ID: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> hi there, I tried to setup xpra with printing feature. Unfortunately, I met an error with the GTK2 client. The xpra server is running with CUPS, and the xpra client and the xapp (libreoffice) are running on remote hosts. The printers are shared as awaited, and visible from xapp host. No error, no message from the Xapp when printing, but xpra server and xpra client raise errors in their respective logs. the error stack from xpra server: parsed printer options: {'sha1': 'c3576dac636aa5936be2265728db719be87b74c9', 'printer': 'Xerox_Phaser_3250', 'options': {'time-at-processing': '1476885259', 'time-at-creation': '1476885259', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'job-uuid': 'urn:uuid:8969ba04-18ed-3bf4-5b5f-6d4619a262de'}, 'copies': '1', 'title': 'Untitled1'} 'Untitled1' sent to X11ServerSource(1 : Protocol(tcp socket: 172.19.0.2:10000 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xpra_attach.log URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xpra_start.log URL: From antoine at nagafix.co.uk Wed Oct 19 16:12:59 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 19 Oct 2016 22:12:59 +0700 Subject: [winswitch] Unable to print from the GTK2 client In-Reply-To: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> References: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> Message-ID: On 19/10/16 21:38, Eric Grammatico via shifter-users wrote: > hi there, > > I tried to setup xpra with printing feature. In theory, everything should be setup out of the box on supported distros like Fedora. > Unfortunately, I met an error with the GTK2 client. The xpra server is running with CUPS, and the xpra client and the xapp (libreoffice) are running on remote hosts. > > The printers are shared as awaited, and visible from xapp host. No error, no message from the Xapp when printing, but xpra server and xpra client raise errors in their respective logs. > > the error stack from xpra server: > parsed printer options: {'sha1': 'c3576dac636aa5936be2265728db719be87b74c9', 'printer': 'Xerox_Phaser_3250', 'options': {'time-at-processing': '1476885259', 'time-at-creation': '1476885259', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'job-uuid': 'urn:uuid:8969ba04-18ed-3bf4-5b5f-6d4619a262de'}, 'copies': '1', 'title': 'Untitled1'} > 'Untitled1' sent to X11ServerSource(1 : Protocol(tcp socket: 172.19.0.2:10000 That's odd. Printing with Fedora got tested quite thoroughly for the SELinux policy changes and I've never seen this problem before. Thanks for reporting it. I have just committed some improvements and posted some new beta builds, does that help? If not, please include the client's output with "--debug printing". Cheers Antoine From e.grammatico at gmail.com Wed Oct 19 16:27:13 2016 From: e.grammatico at gmail.com (Eric Grammatico) Date: Wed, 19 Oct 2016 15:27:13 +0000 Subject: [winswitch] Unable to print from the GTK2 client In-Reply-To: References: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> Message-ID: Thank you Antoine for your quick answer. I am running xpra-1.0-0.20161013r14149. XPRA server and Xapp are running on Centos 7.2 and XPRA client is running on Fedora. At this time of writing, no new beta available on Winswitch.org repository. Here are the logs from the client with -d printing option: $> xpra attach -d printing --opengl=no --encoding=h264 --username=eric tcp:localhost:10000 2016-10-19 17:18:01,982 Xpra gtk2 client version 1.0-r14149 64-bit 2016-10-19 17:18:01,982 running on Linux Fedora 24 Twenty Four 2016-10-19 17:18:01,983 Warning: failed to import opencv: 2016-10-19 17:18:01,983 No module named cv2 2016-10-19 17:18:01,983 webcam forwarding is disabled 2016-10-19 17:18:02,161 GStreamer version 1.8.3 for Python 2.7.12 64-bit 2016-10-19 17:18:02,594 keyboard settings: rules=evdev, model=pc101, layout=fr 2016-10-19 17:18:02,596 desktop size is 1680x1050 with 1 screen: 2016-10-19 17:18:02,596 :0.0 (444x277 mm - DPI: 96x96) workarea: 1680x1016 2016-10-19 17:18:02,596 monitor 1 (474x296 mm - DPI: 90x90) 2016-10-19 17:18:03,133 Xpra X11 server version 1.0-r14149 64-bit 2016-10-19 17:18:03,133 running on Linux CentOS Linux 7.2.1511 Core 2016-10-19 17:18:03,134 parse_printing_capabilities() client printing support=True 2016-10-19 17:18:03,134 parse_printing_capabilities() server printing support=True 2016-10-19 17:18:03,134 enabled remote logging 2016-10-19 17:18:03,136 Attached to tcp:localhost:10000 (press Control-C to detach) 2016-10-19 17:18:04,155 pycups settings: DEFAULT_CUPS_DBUS=1, CUPS_DBUS=1, POLLING_DELAY=60 2016-10-19 17:18:04,155 pycups settings: PRINTER_PREFIX=, ADD_LOCAL_PRINTERS=False 2016-10-19 17:18:04,155 pycups settings: FORWARDER_TMPDIR=/tmp 2016-10-19 17:18:04,156 pycups settings: SKIPPED_PRINTERS=['Cups-PDF'] 2016-10-19 17:18:04,156 DEFAULT_CUPS_OPTIONS={'fit-to-page': 'True'} 2016-10-19 17:18:04,156 init_printing= 2016-10-19 17:18:04,157 init_printing() printers_modified_callback=None 2016-10-19 17:18:04,157 init_dbus_listener() dbus_init=None 2016-10-19 17:18:04,158 system bus: 2016-10-19 17:18:04,160 system_bus.add_signal_receiver(..)=type='signal',path='/com/redhat/PrinterSpooler',interface='com.redhat.PrinterSpooler' 2016-10-19 17:18:04,161 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-19 17:18:04,162 do_send_printers() found printers={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}} 2016-10-19 17:18:04,162 do_send_printers() device-uri(Xerox_Phaser_3250)=usb://Xerox/Phaser%203250?serial=3969298510 2016-10-19 17:18:04,163 get_mimetype()=['application/pdf', 'application/postscript'] 2016-10-19 17:18:04,163 do_send_printers() device-uri(HP_HP_LaserJet_1200)=dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476 2016-10-19 17:18:04,164 get_mimetype()=['application/pdf', 'application/postscript'] 2016-10-19 17:18:04,164 do_send_printers() new printers: ['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] 2016-10-19 17:18:04,164 do_send_printers() printers=['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] 2016-10-19 17:18:04,165 do_send_printers() exported printers=Xerox_Phaser_3250, HP_HP_LaserJet_1200 2016-10-19 17:18:04,165 init_printing() enabled=True 2016-10-19 17:18:54,903 receiving file: ['2063309e720547981b7a1bdb85b93ff4306c5c78', 'application/pdf', True, True, 6842, '6842 bytes', {'copies': '1', 'sha1': 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}] 2016-10-19 17:18:54,904 sha1 digest: de8e3edbc97eb2746c0144f8534189655ccbeea4 - expected: de8e3edbc97eb2746c0144f8534189655ccbeea4 2016-10-19 17:18:54,904 downloaded 6842 bytes to application/pdf file for printing: 2016-10-19 17:18:54,905 '/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-1.pdf' 2016-10-19 17:18:54,905 sending 'Untitled1' to printer 'Xerox_Phaser_3250' 2016-10-19 17:18:54,905 safe print options({'copies': '1', 'sha1': 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) = {'PageSize': 'A4'} 2016-10-19 17:18:54,906 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-19 17:18:54,908 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-19 17:18:54,910 pycups.print_files('Xerox_Phaser_3250', ['/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-1.pdf'], 'Untitled1', {'copies': '1', 'sha1': 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) 2016-10-19 17:18:54,914 Unhandled error while processing a 'send-file' packet from peer using Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/client/client_base.py", line 871, in process_packet handler(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 278, in _process_send_file self.do_process_downloaded_file(filename, mimetype, printit, openit, filesize, options) File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 284, in do_process_downloaded_file self._print_file(filename, mimetype, options) File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 322, in _print_file job = print_files(printer, [filename], title, options) File "/usr/lib64/python2.7/site-packages/xpra/platform/pycups_printing.py", line 412, in print_files printpid = conn.printFiles(printer, filenames, title, actual_options) TypeError: Keys and values must be strings Thanks and regards, - _/) Eric Grammatico. 19 octobre 2016 17:13 "Antoine Martin via shifter-users" a ?crit: > On 19/10/16 21:38, Eric Grammatico via shifter-users wrote: > >> hi there, >> >> I tried to setup xpra with printing feature. > > In theory, everything should be setup out of the box on supported > distros like Fedora. > >> Unfortunately, I met an error with the GTK2 client. The xpra server is running with CUPS, and the >> xpra client and the xapp (libreoffice) are running on remote hosts. >> >> The printers are shared as awaited, and visible from xapp host. No error, no message from the Xapp >> when printing, but xpra server and xpra client raise errors in their respective logs. >> >> the error stack from xpra server: >> parsed printer options: {'sha1': 'c3576dac636aa5936be2265728db719be87b74c9', 'printer': >> 'Xerox_Phaser_3250', 'options': {'time-at-processing': '1476885259', 'time-at-creation': >> '1476885259', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'job-uuid': >> 'urn:uuid:8969ba04-18ed-3bf4-5b5f-6d4619a262de'}, 'copies': '1', 'title': 'Untitled1'} >> 'Untitled1' sent to X11ServerSource(1 : Protocol(tcp socket: 172.19.0.2:10000 > > That's odd. Printing with Fedora got tested quite thoroughly for the > SELinux policy changes and I've never seen this problem before. Thanks > for reporting it. > > I have just committed some improvements and posted some new beta builds, > does that help? > If not, please include the client's output with "--debug printing". > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed Oct 19 17:15:35 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 19 Oct 2016 23:15:35 +0700 Subject: [winswitch] Unable to print from the GTK2 client In-Reply-To: References: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> Message-ID: On 19/10/16 22:27, Eric Grammatico wrote: > Thank you Antoine for your quick answer. > > I am running xpra-1.0-0.20161013r14149. XPRA server and Xapp are running on Centos 7.2 and XPRA client is running on Fedora. At this time of writing, no new beta available on Winswitch.org repository. Ah, sorry, I thought the server was also on Fedora. CentOS 7.x didn't get tested quite as much as Fedora but it should also work out of the box. From your log, the print file does make it to the client so the server side is probably doing its job as expected. In any case, I've posted updated beta builds for both distros. Cheers Antoine > > Here are the logs from the client with -d printing option: > $> xpra attach -d printing --opengl=no --encoding=h264 --username=eric tcp:localhost:10000 > 2016-10-19 17:18:01,982 Xpra gtk2 client version 1.0-r14149 64-bit > 2016-10-19 17:18:01,982 running on Linux Fedora 24 Twenty Four > 2016-10-19 17:18:01,983 Warning: failed to import opencv: > 2016-10-19 17:18:01,983 No module named cv2 > 2016-10-19 17:18:01,983 webcam forwarding is disabled > 2016-10-19 17:18:02,161 GStreamer version 1.8.3 for Python 2.7.12 64-bit > 2016-10-19 17:18:02,594 keyboard settings: rules=evdev, model=pc101, layout=fr > 2016-10-19 17:18:02,596 desktop size is 1680x1050 with 1 screen: > 2016-10-19 17:18:02,596 :0.0 (444x277 mm - DPI: 96x96) workarea: 1680x1016 > 2016-10-19 17:18:02,596 monitor 1 (474x296 mm - DPI: 90x90) > 2016-10-19 17:18:03,133 Xpra X11 server version 1.0-r14149 64-bit > 2016-10-19 17:18:03,133 running on Linux CentOS Linux 7.2.1511 Core > 2016-10-19 17:18:03,134 parse_printing_capabilities() client printing support=True > 2016-10-19 17:18:03,134 parse_printing_capabilities() server printing support=True > 2016-10-19 17:18:03,134 enabled remote logging > 2016-10-19 17:18:03,136 Attached to tcp:localhost:10000 (press Control-C to detach) > > 2016-10-19 17:18:04,155 pycups settings: DEFAULT_CUPS_DBUS=1, CUPS_DBUS=1, POLLING_DELAY=60 > 2016-10-19 17:18:04,155 pycups settings: PRINTER_PREFIX=, ADD_LOCAL_PRINTERS=False > 2016-10-19 17:18:04,155 pycups settings: FORWARDER_TMPDIR=/tmp > 2016-10-19 17:18:04,156 pycups settings: SKIPPED_PRINTERS=['Cups-PDF'] > 2016-10-19 17:18:04,156 DEFAULT_CUPS_OPTIONS={'fit-to-page': 'True'} > 2016-10-19 17:18:04,156 init_printing= > 2016-10-19 17:18:04,157 init_printing() printers_modified_callback=None > 2016-10-19 17:18:04,157 init_dbus_listener() dbus_init=None > 2016-10-19 17:18:04,158 system bus: > 2016-10-19 17:18:04,160 system_bus.add_signal_receiver(..)=type='signal',path='/com/redhat/PrinterSpooler',interface='com.redhat.PrinterSpooler' > 2016-10-19 17:18:04,161 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} > 2016-10-19 17:18:04,162 do_send_printers() found printers={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}} > 2016-10-19 17:18:04,162 do_send_printers() device-uri(Xerox_Phaser_3250)=usb://Xerox/Phaser%203250?serial=3969298510 > 2016-10-19 17:18:04,163 get_mimetype()=['application/pdf', 'application/postscript'] > 2016-10-19 17:18:04,163 do_send_printers() device-uri(HP_HP_LaserJet_1200)=dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476 > 2016-10-19 17:18:04,164 get_mimetype()=['application/pdf', 'application/postscript'] > 2016-10-19 17:18:04,164 do_send_printers() new printers: ['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] > 2016-10-19 17:18:04,164 do_send_printers() printers=['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] > 2016-10-19 17:18:04,165 do_send_printers() exported printers=Xerox_Phaser_3250, HP_HP_LaserJet_1200 > 2016-10-19 17:18:04,165 init_printing() enabled=True > 2016-10-19 17:18:54,903 receiving file: ['2063309e720547981b7a1bdb85b93ff4306c5c78', 'application/pdf', True, True, 6842, '6842 bytes', {'copies': '1', 'sha1': 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}] > 2016-10-19 17:18:54,904 sha1 digest: de8e3edbc97eb2746c0144f8534189655ccbeea4 - expected: de8e3edbc97eb2746c0144f8534189655ccbeea4 > 2016-10-19 17:18:54,904 downloaded 6842 bytes to application/pdf file for printing: > 2016-10-19 17:18:54,905 '/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-1.pdf' > 2016-10-19 17:18:54,905 sending 'Untitled1' to printer 'Xerox_Phaser_3250' > 2016-10-19 17:18:54,905 safe print options({'copies': '1', 'sha1': 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) = {'PageSize': 'A4'} > 2016-10-19 17:18:54,906 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} > 2016-10-19 17:18:54,908 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} > 2016-10-19 17:18:54,910 pycups.print_files('Xerox_Phaser_3250', ['/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-1.pdf'], 'Untitled1', {'copies': '1', 'sha1': 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) > 2016-10-19 17:18:54,914 Unhandled error while processing a 'send-file' packet from peer using > Traceback (most recent call last): > File "/usr/lib64/python2.7/site-packages/xpra/client/client_base.py", line 871, in process_packet > handler(packet) > File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 278, in _process_send_file > self.do_process_downloaded_file(filename, mimetype, printit, openit, filesize, options) > File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 284, in do_process_downloaded_file > self._print_file(filename, mimetype, options) > File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 322, in _print_file > job = print_files(printer, [filename], title, options) > File "/usr/lib64/python2.7/site-packages/xpra/platform/pycups_printing.py", line 412, in print_files > printpid = conn.printFiles(printer, filenames, title, actual_options) > TypeError: Keys and values must be strings > > > > Thanks and regards, > - > _/) Eric Grammatico. > > > 19 octobre 2016 17:13 "Antoine Martin via shifter-users" a > ?crit: >> On 19/10/16 21:38, Eric Grammatico via shifter-users wrote: >> >>> hi there, >>> >>> I tried to setup xpra with printing feature. >> >> In theory, everything should be setup out of the box on supported >> distros like Fedora. >> >>> Unfortunately, I met an error with the GTK2 client. The xpra server is running with CUPS, and the >>> xpra client and the xapp (libreoffice) are running on remote hosts. >>> >>> The printers are shared as awaited, and visible from xapp host. No error, no message from the Xapp >>> when printing, but xpra server and xpra client raise errors in their respective logs. >>> >>> the error stack from xpra server: >>> parsed printer options: {'sha1': 'c3576dac636aa5936be2265728db719be87b74c9', 'printer': >>> 'Xerox_Phaser_3250', 'options': {'time-at-processing': '1476885259', 'time-at-creation': >>> '1476885259', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'job-uuid': >>> 'urn:uuid:8969ba04-18ed-3bf4-5b5f-6d4619a262de'}, 'copies': '1', 'title': 'Untitled1'} >>> 'Untitled1' sent to X11ServerSource(1 : Protocol(tcp socket: 172.19.0.2:10000 >> >> That's odd. Printing with Fedora got tested quite thoroughly for the >> SELinux policy changes and I've never seen this problem before. Thanks >> for reporting it. >> >> I have just committed some improvements and posted some new beta builds, >> does that help? >> If not, please include the client's output with "--debug printing". >> >> Cheers >> Antoine >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users From tzahi.ml at gmail.com Thu Oct 20 11:36:11 2016 From: tzahi.ml at gmail.com (tzahi ml) Date: Thu, 20 Oct 2016 13:36:11 +0300 Subject: [winswitch] Off Topic: How to stream audio from a linux app to a browser In-Reply-To: <5beb0987-c6e0-80aa-de86-0d219b88fa1e@hobbs.cz> References: <5beb0987-c6e0-80aa-de86-0d219b88fa1e@hobbs.cz> Message-ID: Tried that but there is a 3 sec delay (which is better than simply icecasting but still)... good to know though. Wish there was a way to get it to 1 sec. that would be totally acceptable. All these are transcoding the sound into mp3/ogg and this requires some kind of buffering which takes at least 3 sec. The only way i see is to send the data as is to the browser and play it. But, that sounds like scifi to me. Xpra html5 could encode the audio in the h264 stream when it will be available. Seems like the only way to get good results. On Wed, Oct 19, 2016 at 8:46 AM, Timothy Hobbs via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > If you happen to use pulseaudio, then you could try adding a "stream" > sink. I have not tested this, but here is an example: > > https://gist.github.com/djmaze/5234008 > > On 10/13/16 14:09, tzahi ml via shifter-users wrote: > > Hi, > > Sorry for the off topic but I cannot seem to find and answer online. > > I am trying to figure out how to send real time audio from a linux > program > > (pulseaudio?) to a web browser (web audio api?) without a plugin. I could > > not find guides or anything close. I tried shoutcast etc... but they are > > very laggy and defeats the point. > > > > Can someone point me in the right direction? > > (maybe from the html5 team) > > > > Thanks! > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Thu Oct 20 12:07:22 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 20 Oct 2016 18:07:22 +0700 Subject: [winswitch] Off Topic: How to stream audio from a linux app to a browser In-Reply-To: References: <5beb0987-c6e0-80aa-de86-0d219b88fa1e@hobbs.cz> Message-ID: On 20/10/16 17:36, tzahi ml via shifter-users wrote: > Tried that but there is a 3 sec delay (which is better than simply > icecasting but still)... good to know though. > Wish there was a way to get it to 1 sec. With xpra, you should be able to get less than 0.5 sec, network permitting. (and not with IE...) > that would be totally acceptable. > All these are transcoding the sound into mp3/ogg and this requires some > kind of buffering which takes at least 3 sec. Xpra can transcode to most of these formats in under 0.1s, other more efficient formats like opus and vorbis take even less time. > The only way i see is to send the data as is to the browser and play it. > But, that sounds like scifi to me. > Xpra html5 could encode the audio in the h264 stream when it will be > available. > Seems like the only way to get good results. WAV or MP3 can get decent results, the ultimate goal is to use AAC in an mpeg4 container. We're not going to mux it with the video because that's just too messy (there can be no video at times, etc...) I am working on the HTML5 client updates right now, just bear with me.. Cheers Antoine > > > On Wed, Oct 19, 2016 at 8:46 AM, Timothy Hobbs via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > >> If you happen to use pulseaudio, then you could try adding a "stream" >> sink. I have not tested this, but here is an example: >> >> https://gist.github.com/djmaze/5234008 >> >> On 10/13/16 14:09, tzahi ml via shifter-users wrote: >>> Hi, >>> Sorry for the off topic but I cannot seem to find and answer online. >>> I am trying to figure out how to send real time audio from a linux >> program >>> (pulseaudio?) to a web browser (web audio api?) without a plugin. I could >>> not find guides or anything close. I tried shoutcast etc... but they are >>> very laggy and defeats the point. >>> >>> Can someone point me in the right direction? >>> (maybe from the html5 team) >>> >>> Thanks! >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From e.grammatico at gmail.com Thu Oct 20 13:54:45 2016 From: e.grammatico at gmail.com (Eric Grammatico) Date: Thu, 20 Oct 2016 12:54:45 +0000 Subject: [winswitch] Unable to print from the GTK2 client In-Reply-To: References: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> Message-ID: <25d4054f92c5a9688613eed4a7deda26@webmail.grammatico.me> Hi Antoine, Thanks a lot for the new beta releases. Unfortunately, same error. Please find below logs from Client, as the file is uploaded to the client (I opened manually the pdf and able to read with Okular). thanks and best regards, Eric. $> xpra attach -d printing --opengl=no --encoding=h264 --username=eric tcp:localhost:10000 2016-10-20 14:44:41,156 Xpra gtk2 client version 1.0-r14149 64-bit 2016-10-20 14:44:41,156 running on Linux Fedora 24 Twenty Four 2016-10-20 14:44:41,157 Warning: failed to import opencv: 2016-10-20 14:44:41,157 No module named cv2 2016-10-20 14:44:41,157 webcam forwarding is disabled 2016-10-20 14:44:41,421 GStreamer version 1.8.3 for Python 2.7.12 64-bit 2016-10-20 14:44:42,006 keyboard settings: rules=evdev, model=pc101, layout=fr 2016-10-20 14:44:42,008 desktop size is 1680x1050 with 1 screen: 2016-10-20 14:44:42,008 :0.0 (444x277 mm - DPI: 96x96) workarea: 1680x1016 2016-10-20 14:44:42,008 monitor 1 (474x296 mm - DPI: 90x90) 2016-10-20 14:44:42,553 Xpra X11 server version 1.0-r14207 64-bit 2016-10-20 14:44:42,554 running on Linux CentOS Linux 7.2.1511 Core 2016-10-20 14:44:42,554 parse_printing_capabilities() client printing support=True 2016-10-20 14:44:42,554 parse_printing_capabilities() server printing support=True 2016-10-20 14:44:42,554 enabled remote logging 2016-10-20 14:44:42,560 Attached to tcp:localhost:10000 (press Control-C to detach) 2016-10-20 14:44:43,579 pycups settings: DEFAULT_CUPS_DBUS=1, CUPS_DBUS=1, POLLING_DELAY=60 2016-10-20 14:44:43,579 pycups settings: PRINTER_PREFIX=, ADD_LOCAL_PRINTERS=False 2016-10-20 14:44:43,579 pycups settings: FORWARDER_TMPDIR=/tmp 2016-10-20 14:44:43,580 pycups settings: SKIPPED_PRINTERS=['Cups-PDF'] 2016-10-20 14:44:43,580 DEFAULT_CUPS_OPTIONS={'fit-to-page': 'True'} 2016-10-20 14:44:43,581 init_printing= 2016-10-20 14:44:43,581 init_printing() printers_modified_callback=None 2016-10-20 14:44:43,581 init_dbus_listener() dbus_init=None 2016-10-20 14:44:43,582 system bus: 2016-10-20 14:44:43,582 system_bus.add_signal_receiver(..)=type='signal',path='/com/redhat/PrinterSpooler',interface='com.redhat.PrinterSpooler' 2016-10-20 14:44:43,585 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-20 14:44:43,586 do_send_printers() found printers={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}} 2016-10-20 14:44:43,586 do_send_printers() device-uri(Xerox_Phaser_3250)=usb://Xerox/Phaser%203250?serial=3969298510 2016-10-20 14:44:43,587 get_mimetype()=['application/pdf', 'application/postscript'] 2016-10-20 14:44:43,587 do_send_printers() device-uri(HP_HP_LaserJet_1200)=dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476 2016-10-20 14:44:43,587 get_mimetype()=['application/pdf', 'application/postscript'] 2016-10-20 14:44:43,587 do_send_printers() new printers: ['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] 2016-10-20 14:44:43,589 do_send_printers() printers=['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] 2016-10-20 14:44:43,589 do_send_printers() exported printers=Xerox_Phaser_3250, HP_HP_LaserJet_1200 2016-10-20 14:44:43,589 init_printing() enabled=True 2016-10-20 14:46:19,495 receiving file: ['2063309e720547981b7a1bdb85b93ff4306c5c78', 'application/pdf', True, True, 6904, '6904 bytes', {'copies': '1', 'sha1': '32a6a623c2a3385e701a7b43b714d09276d188e9', 'options': {'job-uuid': 'urn:uuid:95c115a4-dc75-380d-4fe2-2129ab262950', 'time-at-creation': '1476967579', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476967579'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}] 2016-10-20 14:46:19,501 sha1 digest: 32a6a623c2a3385e701a7b43b714d09276d188e9 - expected: 32a6a623c2a3385e701a7b43b714d09276d188e9 2016-10-20 14:46:19,502 downloaded 6904 bytes to application/pdf file for printing: 2016-10-20 14:46:19,504 '/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-2.pdf' 2016-10-20 14:46:19,505 sending 'Untitled1' to printer 'Xerox_Phaser_3250' 2016-10-20 14:46:19,505 safe print options({'copies': '1', 'sha1': '32a6a623c2a3385e701a7b43b714d09276d188e9', 'options': {'job-uuid': 'urn:uuid:95c115a4-dc75-380d-4fe2-2129ab262950', 'time-at-creation': '1476967579', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476967579'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) = {'PageSize': 'A4'} 2016-10-20 14:46:19,509 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-20 14:46:19,510 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-20 14:46:19,511 pycups.print_files('Xerox_Phaser_3250', ['/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-2.pdf'], 'Untitled1', {'copies': '1', 'sha1': '32a6a623c2a3385e701a7b43b714d09276d188e9', 'options': {'job-uuid': 'urn:uuid:95c115a4-dc75-380d-4fe2-2129ab262950', 'time-at-creation': '1476967579', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476967579'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) 2016-10-20 14:46:19,516 Unhandled error while processing a 'send-file' packet from peer using Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/client/client_base.py", line 871, in process_packet handler(packet) File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 278, in _process_send_file self.do_process_downloaded_file(filename, mimetype, printit, openit, filesize, options) File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 284, in do_process_downloaded_file self._print_file(filename, mimetype, options) File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 322, in _print_file job = print_files(printer, [filename], title, options) File "/usr/lib64/python2.7/site-packages/xpra/platform/pycups_printing.py", line 412, in print_files printpid = conn.printFiles(printer, filenames, title, actual_options) TypeError: Keys and values must be strings - _/) Eric Grammatico. 19 octobre 2016 18:15 "Antoine Martin" a ?crit: > On 19/10/16 22:27, Eric Grammatico wrote: > >> Thank you Antoine for your quick answer. >> >> I am running xpra-1.0-0.20161013r14149. XPRA server and Xapp are running on Centos 7.2 and XPRA >> client is running on Fedora. At this time of writing, no new beta available on Winswitch.org >> repository. > > Ah, sorry, I thought the server was also on Fedora. > > CentOS 7.x didn't get tested quite as much as Fedora but it should also > work out of the box. From your log, the print file does make it to the > client so the server side is probably doing its job as expected. > > In any case, I've posted updated beta builds for both distros. > > Cheers > Antoine > >> Here are the logs from the client with -d printing option: >> $> xpra attach -d printing --opengl=no --encoding=h264 --username=eric tcp:localhost:10000 >> 2016-10-19 17:18:01,982 Xpra gtk2 client version 1.0-r14149 64-bit >> 2016-10-19 17:18:01,982 running on Linux Fedora 24 Twenty Four >> 2016-10-19 17:18:01,983 Warning: failed to import opencv: >> 2016-10-19 17:18:01,983 No module named cv2 >> 2016-10-19 17:18:01,983 webcam forwarding is disabled >> 2016-10-19 17:18:02,161 GStreamer version 1.8.3 for Python 2.7.12 64-bit >> 2016-10-19 17:18:02,594 keyboard settings: rules=evdev, model=pc101, layout=fr >> 2016-10-19 17:18:02,596 desktop size is 1680x1050 with 1 screen: >> 2016-10-19 17:18:02,596 :0.0 (444x277 mm - DPI: 96x96) workarea: 1680x1016 >> 2016-10-19 17:18:02,596 monitor 1 (474x296 mm - DPI: 90x90) >> 2016-10-19 17:18:03,133 Xpra X11 server version 1.0-r14149 64-bit >> 2016-10-19 17:18:03,133 running on Linux CentOS Linux 7.2.1511 Core >> 2016-10-19 17:18:03,134 parse_printing_capabilities() client printing support=True >> 2016-10-19 17:18:03,134 parse_printing_capabilities() server printing support=True >> 2016-10-19 17:18:03,134 enabled remote logging >> 2016-10-19 17:18:03,136 Attached to tcp:localhost:10000 (press Control-C to detach) >> >> 2016-10-19 17:18:04,155 pycups settings: DEFAULT_CUPS_DBUS=1, CUPS_DBUS=1, POLLING_DELAY=60 >> 2016-10-19 17:18:04,155 pycups settings: PRINTER_PREFIX=, ADD_LOCAL_PRINTERS=False >> 2016-10-19 17:18:04,155 pycups settings: FORWARDER_TMPDIR=/tmp >> 2016-10-19 17:18:04,156 pycups settings: SKIPPED_PRINTERS=['Cups-PDF'] >> 2016-10-19 17:18:04,156 DEFAULT_CUPS_OPTIONS={'fit-to-page': 'True'} >> 2016-10-19 17:18:04,156 init_printing= >> 2016-10-19 17:18:04,157 init_printing() >> printers_modified_callback=None >> 2016-10-19 17:18:04,157 init_dbus_listener() dbus_init=None >> 2016-10-19 17:18:04,158 system bus: >> 2016-10-19 17:18:04,160 >> system_bus.add_signal_receiver(..)=type='signal',path='/com/redhat/PrinterSpooler',interface='com.re >> hat.PrinterSpooler' >> 2016-10-19 17:18:04,161 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': >> False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': >> 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', >> 'printer-state-reasons': [u'none'], 'printer-uri-supported': >> u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', >> 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': >> {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', >> 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', >> 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], >> 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, >> 'printer-location': u'', 'device-uri': >> u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f8 >> -c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': >> u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': >> u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': >> u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': >> u'cups-pdf:/'}} >> 2016-10-19 17:18:04,162 do_send_printers() found printers={u'Xerox_Phaser_3250': >> {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', >> 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', >> 'printer-state-reasons': [u'none'], 'printer-uri-supported': >> u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', >> 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': >> {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', >> 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', >> 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], >> 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, >> 'printer-location': u'', 'device-uri': >> u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f8 >> -c8e2-39ae-5864-b09c8b939476'}} >> 2016-10-19 17:18:04,162 do_send_printers() >> device-uri(Xerox_Phaser_3250)=usb://Xerox/Phaser%203250?serial=3969298510 >> 2016-10-19 17:18:04,163 get_mimetype()=['application/pdf', 'application/postscript'] >> 2016-10-19 17:18:04,163 do_send_printers() >> device-uri(HP_HP_LaserJet_1200)=dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ip >> ._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476 >> 2016-10-19 17:18:04,164 get_mimetype()=['application/pdf', 'application/postscript'] >> 2016-10-19 17:18:04,164 do_send_printers() new printers: ['Xerox_Phaser_3250', >> 'HP_HP_LaserJet_1200'] >> 2016-10-19 17:18:04,164 do_send_printers() printers=['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] >> 2016-10-19 17:18:04,165 do_send_printers() exported printers=Xerox_Phaser_3250, HP_HP_LaserJet_1200 >> 2016-10-19 17:18:04,165 init_printing() enabled=True >> 2016-10-19 17:18:54,903 receiving file: ['2063309e720547981b7a1bdb85b93ff4306c5c78', >> 'application/pdf', True, True, 6842, '6842 bytes', {'copies': '1', 'sha1': >> 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': >> 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', >> 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, >> 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}] >> 2016-10-19 17:18:54,904 sha1 digest: de8e3edbc97eb2746c0144f8534189655ccbeea4 - expected: >> de8e3edbc97eb2746c0144f8534189655ccbeea4 >> 2016-10-19 17:18:54,904 downloaded 6842 bytes to application/pdf file for printing: >> 2016-10-19 17:18:54,905 '/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-1.pdf' >> 2016-10-19 17:18:54,905 sending 'Untitled1' to printer 'Xerox_Phaser_3250' >> 2016-10-19 17:18:54,905 safe print options({'copies': '1', 'sha1': >> 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': >> 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', >> 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, >> 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) = {'PageSize': 'A4'} >> 2016-10-19 17:18:54,906 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': >> False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': >> 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', >> 'printer-state-reasons': [u'none'], 'printer-uri-supported': >> u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', >> 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': >> {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', >> 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', >> 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], >> 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, >> 'printer-location': u'', 'device-uri': >> u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f8 >> -c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': >> u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': >> u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': >> u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': >> u'cups-pdf:/'}} >> 2016-10-19 17:18:54,908 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': >> False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': >> 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', >> 'printer-state-reasons': [u'none'], 'printer-uri-supported': >> u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', >> 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': >> {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', >> 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', >> 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], >> 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, >> 'printer-location': u'', 'device-uri': >> u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f8 >> -c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': >> u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': >> u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': >> u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': >> u'cups-pdf:/'}} >> 2016-10-19 17:18:54,910 pycups.print_files('Xerox_Phaser_3250', >> ['/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-1.pdf'], 'Untitled1', {'copies': >> '1', 'sha1': 'de8e3edbc97eb2746c0144f8534189655ccbeea4', 'options': {'job-uuid': >> 'urn:uuid:d7d956d5-dc01-3bf7-652e-53fe088f73bd', 'time-at-creation': '1476890334', >> 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'time-at-processing': '1476890334'}, >> 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) >> 2016-10-19 17:18:54,914 Unhandled error while processing a 'send-file' packet from peer using >> >> Traceback (most recent call last): >> File "/usr/lib64/python2.7/site-packages/xpra/client/client_base.py", line 871, in process_packet >> handler(packet) >> File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 278, in >> _process_send_file >> self.do_process_downloaded_file(filename, mimetype, printit, openit, filesize, options) >> File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 284, in >> do_process_downloaded_file >> self._print_file(filename, mimetype, options) >> File "/usr/lib64/python2.7/site-packages/xpra/net/file_transfer.py", line 322, in _print_file >> job = print_files(printer, [filename], title, options) >> File "/usr/lib64/python2.7/site-packages/xpra/platform/pycups_printing.py", line 412, in >> print_files >> printpid = conn.printFiles(printer, filenames, title, actual_options) >> TypeError: Keys and values must be strings >> >> Thanks and regards, >> - >> _/) Eric Grammatico. >> >> 19 octobre 2016 17:13 "Antoine Martin via shifter-users" a >> ?crit: >>> On 19/10/16 21:38, Eric Grammatico via shifter-users wrote: >>> >>>> hi there, >>>> >>>> I tried to setup xpra with printing feature. >>> >>> In theory, everything should be setup out of the box on supported >>> distros like Fedora. >>> >>>> Unfortunately, I met an error with the GTK2 client. The xpra server is running with CUPS, and the >>>> xpra client and the xapp (libreoffice) are running on remote hosts. >>>> >>>> The printers are shared as awaited, and visible from xapp host. No error, no message from the Xapp >>>> when printing, but xpra server and xpra client raise errors in their respective logs. >>>> >>>> the error stack from xpra server: >>>> parsed printer options: {'sha1': 'c3576dac636aa5936be2265728db719be87b74c9', 'printer': >>>> 'Xerox_Phaser_3250', 'options': {'time-at-processing': '1476885259', 'time-at-creation': >>>> '1476885259', 'job-originating-host-name': '172.19.0.3', 'PageSize': 'A4', 'job-uuid': >>>> 'urn:uuid:8969ba04-18ed-3bf4-5b5f-6d4619a262de'}, 'copies': '1', 'title': 'Untitled1'} >>>> 'Untitled1' sent to X11ServerSource(1 : Protocol(tcp socket: 172.19.0.2:10000 >>> >>> That's odd. Printing with Fedora got tested quite thoroughly for the >>> SELinux policy changes and I've never seen this problem before. Thanks >>> for reporting it. >>> >>> I have just committed some improvements and posted some new beta builds, >>> does that help? >>> If not, please include the client's output with "--debug printing". >>> >>> Cheers >>> Antoine >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Thu Oct 20 15:07:36 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 20 Oct 2016 21:07:36 +0700 Subject: [winswitch] Unable to print from the GTK2 client In-Reply-To: <25d4054f92c5a9688613eed4a7deda26@webmail.grammatico.me> References: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> <25d4054f92c5a9688613eed4a7deda26@webmail.grammatico.me> Message-ID: On 20/10/16 19:54, Eric Grammatico wrote: > Hi Antoine, > > Thanks a lot for the new beta releases. > > Unfortunately, same error. Please find below logs from Client, as the file is uploaded to the client (I opened manually the pdf and able to read with Okular). Looks like the build you are using is still too old (1.0-r14149), the r14207 builds or later should have the fix you need to test with. Cheers Antoine > $> xpra attach -d printing --opengl=no --encoding=h264 --username=eric tcp:localhost:10000 > 2016-10-20 14:44:41,156 Xpra gtk2 client version 1.0-r14149 64-bit > 2016-10-20 14:44:41,156 running on Linux Fedora 24 Twenty Four (snip) From e.grammatico at gmail.com Thu Oct 20 15:29:25 2016 From: e.grammatico at gmail.com (Eric Grammatico) Date: Thu, 20 Oct 2016 14:29:25 +0000 Subject: [winswitch] Unable to print from the GTK2 client In-Reply-To: References: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> <25d4054f92c5a9688613eed4a7deda26@webmail.grammatico.me> Message-ID: <136d4d141cbdf015162faa930ea9ce26@webmail.grammatico.me> Sorry, my mistake... Failed again. Here are the logs: xpra attach -d printing --opengl=no --encoding=h264 --username=eric tcp:localhost:10000 2016-10-20 16:19:51,752 Xpra gtk2 client version 1.0-r14207 64-bit 2016-10-20 16:19:51,753 running on Linux Fedora 24 Twenty Four 2016-10-20 16:19:51,753 Warning: failed to import opencv: 2016-10-20 16:19:51,754 No module named cv2 2016-10-20 16:19:51,754 webcam forwarding is disabled 2016-10-20 16:19:51,934 GStreamer version 1.8.3 for Python 2.7.12 64-bit 2016-10-20 16:19:52,371 keyboard settings: rules=evdev, model=pc101, layout=fr 2016-10-20 16:19:52,372 desktop size is 1680x1050 with 1 screen: 2016-10-20 16:19:52,372 :0.0 (444x277 mm - DPI: 96x96) workarea: 1680x1016 2016-10-20 16:19:52,373 monitor 1 (474x296 mm - DPI: 90x90) 2016-10-20 16:19:52,891 Xpra X11 server version 1.0-r14207 64-bit 2016-10-20 16:19:52,892 running on Linux CentOS Linux 7.2.1511 Core 2016-10-20 16:19:52,892 parse_printing_capabilities() client printing support=True 2016-10-20 16:19:52,892 parse_printing_capabilities() server printing support=True 2016-10-20 16:19:52,893 enabled remote logging 2016-10-20 16:19:52,895 Attached to tcp:localhost:10000 (press Control-C to detach) 2016-10-20 16:19:53,914 pycups settings: DEFAULT_CUPS_DBUS=1, CUPS_DBUS=1, POLLING_DELAY=60 2016-10-20 16:19:53,914 pycups settings: PRINTER_PREFIX=, ADD_LOCAL_PRINTERS=False 2016-10-20 16:19:53,914 pycups settings: FORWARDER_TMPDIR=/tmp 2016-10-20 16:19:53,915 pycups settings: SKIPPED_PRINTERS=['Cups-PDF'] 2016-10-20 16:19:53,915 DEFAULT_CUPS_OPTIONS={'fit-to-page': 'True'} 2016-10-20 16:19:53,915 init_printing= 2016-10-20 16:19:53,916 init_printing() printers_modified_callback=None 2016-10-20 16:19:53,916 init_dbus_listener() dbus_init=None 2016-10-20 16:19:53,916 system bus: 2016-10-20 16:19:53,917 system_bus.add_signal_receiver(..)=type='signal',path='/com/redhat/PrinterSpooler',interface='com.redhat.PrinterSpooler' 2016-10-20 16:19:53,919 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-20 16:19:53,919 do_send_printers() found printers={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}} 2016-10-20 16:19:53,919 do_send_printers() device-uri(Xerox_Phaser_3250)=usb://Xerox/Phaser%203250?serial=3969298510 2016-10-20 16:19:53,919 get_mimetype()=['application/pdf', 'application/postscript'] 2016-10-20 16:19:53,920 do_send_printers() device-uri(HP_HP_LaserJet_1200)=dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476 2016-10-20 16:19:53,920 get_mimetype()=['application/pdf', 'application/postscript'] 2016-10-20 16:19:53,920 do_send_printers() new printers: ['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] 2016-10-20 16:19:53,921 do_send_printers() printers=['Xerox_Phaser_3250', 'HP_HP_LaserJet_1200'] 2016-10-20 16:19:53,921 do_send_printers() exported printers=Xerox_Phaser_3250, HP_HP_LaserJet_1200 2016-10-20 16:19:53,921 init_printing() enabled=True 2016-10-20 16:20:30,594 receiving file: ['2063309e720547981b7a1bdb85b93ff4306c5c78', 'application/pdf', True, True, 6099, '6099 bytes', {'copies': '1', 'sha1': '37ac67174f772c608d1517c0590a639428f39add', 'options': {'job-uuid': 'urn:uuid:7fa60444-cc4f-3f82-6e6e-cfb4f2636ca9', 'time-at-creation': '1476973230', 'job-originating-host-name': '172.19.0.1', 'PageSize': 'A4', 'time-at-processing': '1476973230'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}] 2016-10-20 16:20:30,594 sha1 digest: 37ac67174f772c608d1517c0590a639428f39add - expected: 37ac67174f772c608d1517c0590a639428f39add 2016-10-20 16:20:30,594 downloaded 6099 bytes to application/pdf file for printing: 2016-10-20 16:20:30,594 '/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-3.pdf' 2016-10-20 16:20:30,595 sending 'Untitled1' to printer 'Xerox_Phaser_3250' 2016-10-20 16:20:30,595 safe print options({'copies': '1', 'sha1': '37ac67174f772c608d1517c0590a639428f39add', 'options': {'job-uuid': 'urn:uuid:7fa60444-cc4f-3f82-6e6e-cfb4f2636ca9', 'time-at-creation': '1476973230', 'job-originating-host-name': '172.19.0.1', 'PageSize': 'A4', 'time-at-processing': '1476973230'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) = {'PageSize': 'A4'} 2016-10-20 16:20:30,598 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-20 16:20:30,600 pycups.get_all_printers()={u'Xerox_Phaser_3250': {'printer-is-shared': False, 'printer-info': u'Xerox Phaser 3250', 'printer-state-message': u'', 'printer-type': 10530836, 'printer-make-and-model': u'Xerox Phaser 3200MFP Foomatic/Postscript', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Xerox_Phaser_3250', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'usb://Xerox/Phaser%203250?serial=3969298510'}, u'HP_HP_LaserJet_1200': {'printer-is-shared': False, 'printer-info': u'HP HP LaserJet 1200', 'printer-state-message': u'', 'printer-type': 10522692, 'printer-make-and-model': u'HP LaserJet 1200 Postscript (recommended)', 'printer-state-reasons': [u'cups-ipp-conformance-failure-report', u'cups-ipp-missing-job-history'], 'printer-uri-supported': u'ipp://localhost/printers/HP_HP_LaserJet_1200', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'dnssd://Hewlett-Packard%20HP%20LaserJet%201200%20%40%20tadoussac._ipp._tcp.local/cups?uuid=5d554f88-c8e2-39ae-5864-b09c8b939476'}, u'Cups-PDF': {'printer-is-shared': True, 'printer-info': u'Cups-PDF', 'printer-state-message': u'', 'printer-type': 8450124, 'printer-make-and-model': u'Generic CUPS-PDF Printer', 'printer-state-reasons': [u'none'], 'printer-uri-supported': u'ipp://localhost/printers/Cups-PDF', 'printer-state': 3, 'printer-location': u'', 'device-uri': u'cups-pdf:/'}} 2016-10-20 16:20:30,600 pycups.print_files('Xerox_Phaser_3250', ['/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-3.pdf'], 'Untitled1', {'copies': '1', 'sha1': '37ac67174f772c608d1517c0590a639428f39add', 'options': {'job-uuid': 'urn:uuid:7fa60444-cc4f-3f82-6e6e-cfb4f2636ca9', 'time-at-creation': '1476973230', 'job-originating-host-name': '172.19.0.1', 'PageSize': 'A4', 'time-at-processing': '1476973230'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) 2016-10-20 16:20:30,602 Error: pycups printing on 'Xerox_Phaser_3250' failed for file 2016-10-20 16:20:30,603 /home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-3.pdf 2016-10-20 16:20:30,603 using cups server connection: 2016-10-20 16:20:30,603 printer options: 2016-10-20 16:20:30,603 sha1 : 37ac67174f772c608d1517c0590a639428f39add 2016-10-20 16:20:30,603 title : Untitled1 2016-10-20 16:20:30,603 fit-to-page : True 2016-10-20 16:20:30,604 copies : 1 2016-10-20 16:20:30,604 printer : Xerox_Phaser_3250 2016-10-20 16:20:30,604 options : {'job-uuid': 'urn:uuid:7fa60444-cc4f-3f82-6e6e-cfb4f2636ca9', 'time-at-creation': '1476973230', 'job-originating-host-name': '172.19.0.1', 'PageSize': 'A4', 'time-at-processing': '1476973230'} 2016-10-20 16:20:30,604 printing /home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-3.pdf, job=0 2016-10-20 16:20:30,607 printing failed and returned 0 - _/) Eric Grammatico. 20 octobre 2016 16:07 "Antoine Martin" a ?crit: > On 20/10/16 19:54, Eric Grammatico wrote: > >> Hi Antoine, >> >> Thanks a lot for the new beta releases. >> >> Unfortunately, same error. Please find below logs from Client, as the file is uploaded to the >> client (I opened manually the pdf and able to read with Okular). > > Looks like the build you are using is still too old (1.0-r14149), the > r14207 builds or later should have the fix you need to test with. > > Cheers > Antoine > >> $> xpra attach -d printing --opengl=no --encoding=h264 --username=eric tcp:localhost:10000 >> 2016-10-20 14:44:41,156 Xpra gtk2 client version 1.0-r14149 64-bit >> 2016-10-20 14:44:41,156 running on Linux Fedora 24 Twenty Four > > (snip) From antoine at nagafix.co.uk Thu Oct 20 16:47:17 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 20 Oct 2016 22:47:17 +0700 Subject: [winswitch] Unable to print from the GTK2 client In-Reply-To: <136d4d141cbdf015162faa930ea9ce26@webmail.grammatico.me> References: <1dbb276d1a07d450858c9711971e2fcb@webmail.grammatico.me> <25d4054f92c5a9688613eed4a7deda26@webmail.grammatico.me> <136d4d141cbdf015162faa930ea9ce26@webmail.grammatico.me> Message-ID: <7a696bd3-b37b-f319-5860-53d4c5c499fc@nagafix.co.uk> On 20/10/16 21:29, Eric Grammatico wrote: > Sorry, my mistake... > > Failed again. Here are the logs: (snip) > 2016-10-20 16:20:30,600 pycups.print_files('Xerox_Phaser_3250', ['/home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-3.pdf'], 'Untitled1', {'copies': '1', 'sha1': '37ac67174f772c608d1517c0590a639428f39add', 'options': {'job-uuid': 'urn:uuid:7fa60444-cc4f-3f82-6e6e-cfb4f2636ca9', 'time-at-creation': '1476973230', 'job-originating-host-name': '172.19.0.1', 'PageSize': 'A4', 'time-at-processing': '1476973230'}, 'printer': 'Xerox_Phaser_3250', 'title': 'Untitled1'}) > 2016-10-20 16:20:30,602 Error: pycups printing on 'Xerox_Phaser_3250' failed for file > 2016-10-20 16:20:30,603 /home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-3.pdf > 2016-10-20 16:20:30,603 using cups server connection: > 2016-10-20 16:20:30,603 printer options: > 2016-10-20 16:20:30,603 sha1 : 37ac67174f772c608d1517c0590a639428f39add > 2016-10-20 16:20:30,603 title : Untitled1 > 2016-10-20 16:20:30,603 fit-to-page : True > 2016-10-20 16:20:30,604 copies : 1 > 2016-10-20 16:20:30,604 printer : Xerox_Phaser_3250 > 2016-10-20 16:20:30,604 options : {'job-uuid': 'urn:uuid:7fa60444-cc4f-3f82-6e6e-cfb4f2636ca9', 'time-at-creation': '1476973230', 'job-originating-host-name': '172.19.0.1', 'PageSize': 'A4', 'time-at-processing': '1476973230'} > 2016-10-20 16:20:30,604 printing /home/eric/Downloads/2063309e720547981b7a1bdb85b93ff4306c5c78-3.pdf, job=0 > 2016-10-20 16:20:30,607 printing failed and returned 0 I've just tried it and it looks like some things have changed since this was last tested (not so long ago..), sorry about that: * the SELinux policy needs updating again, until then you may need to disable SELinux with "setenforce 0" * Some of the printer options we forwarded were rejected with the following error found in the cupsd log (use journalctl on Fedora): "Returning IPP client-error-attributes-or-values-not-supported for Create-Job (ipp://localhost:631/printers/iP2700-series) from localhost" So I've just fixed up the whitelisting code and the only safe bits we'll actually forward by default are: "Resolution" and "PageSize". (this can be changed) Hopefully this will not cause cups to reject your jobs anymore. Tested here without a printer since I don't have one at hand, but the jobs did get submitted to the virtual offline printer. New beta Fedora 24 builds posted. (r14232) Cheers Antoine From tzahi.ml at gmail.com Sat Oct 22 21:45:40 2016 From: tzahi.ml at gmail.com (tzahi ml) Date: Sat, 22 Oct 2016 23:45:40 +0300 Subject: [winswitch] Off Topic: How to stream audio from a linux app to a browser In-Reply-To: References: <5beb0987-c6e0-80aa-de86-0d219b88fa1e@hobbs.cz> Message-ID: I can tell you that I tried to stream ogg and when the browser accessed that stream it first buffered 2 secs. When there was a bandwidth stress the browser(chrome) automatically increased the buffer size to cope. The problem is that it doesn't go down and stayed 9 sec latency until you reconnect to the stream. I.e using the mechanism of the browser is not very good. On Oct 20, 2016 2:07 PM, "Antoine Martin via shifter-users" < shifter-users at lists.devloop.org.uk> wrote: > On 20/10/16 17:36, tzahi ml via shifter-users wrote: > > Tried that but there is a 3 sec delay (which is better than simply > > icecasting but still)... good to know though. > > Wish there was a way to get it to 1 sec. > With xpra, you should be able to get less than 0.5 sec, network > permitting. (and not with IE...) > > > that would be totally acceptable. > > All these are transcoding the sound into mp3/ogg and this requires some > > kind of buffering which takes at least 3 sec. > Xpra can transcode to most of these formats in under 0.1s, other more > efficient formats like opus and vorbis take even less time. > > > The only way i see is to send the data as is to the browser and play it. > > But, that sounds like scifi to me. > > Xpra html5 could encode the audio in the h264 stream when it will be > > available. > > Seems like the only way to get good results. > WAV or MP3 can get decent results, the ultimate goal is to use AAC in an > mpeg4 container. We're not going to mux it with the video because that's > just too messy (there can be no video at times, etc...) > > I am working on the HTML5 client updates right now, just bear with me.. > > Cheers > Antoine > > > > > > > On Wed, Oct 19, 2016 at 8:46 AM, Timothy Hobbs via shifter-users < > > shifter-users at lists.devloop.org.uk> wrote: > > > >> If you happen to use pulseaudio, then you could try adding a "stream" > >> sink. I have not tested this, but here is an example: > >> > >> https://gist.github.com/djmaze/5234008 > >> > >> On 10/13/16 14:09, tzahi ml via shifter-users wrote: > >>> Hi, > >>> Sorry for the off topic but I cannot seem to find and answer online. > >>> I am trying to figure out how to send real time audio from a linux > >> program > >>> (pulseaudio?) to a web browser (web audio api?) without a plugin. I > could > >>> not find guides or anything close. I tried shoutcast etc... but they > are > >>> very laggy and defeats the point. > >>> > >>> Can someone point me in the right direction? > >>> (maybe from the html5 team) > >>> > >>> Thanks! > >>> _______________________________________________ > >>> shifter-users mailing list > >>> shifter-users at lists.devloop.org.uk > >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > >> > >> _______________________________________________ > >> shifter-users mailing list > >> shifter-users at lists.devloop.org.uk > >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Fri Oct 28 16:46:25 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 28 Oct 2016 22:46:25 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 0.17.6 (many fixes) Message-ID: Hi, This update contains a very large number of fixes, including a critical fix for the NVENC encoder when used with Nvidia's Pascal GPUs: this prevents hard system lockups (local DoS bug in their drivers). Other notable fixes: some printing issues, many fixes for OSX and the proxy server, build fixes. Updating is recommended. Release notes: * fix server-side av-sync queue level accounting * fix system lockups with Nvidia Pascal GPUs * fix osx log directory lookup for shadow servers * fix win32 system authentication for shadow servers * fix pycups errors with non string options * fix for GTK3: force X11 backend * fix yaml missing version * fix missing lzo with OSX builds * fix OSX bug report tool command * fix OSX build stripping * fix clang builds (ignore warning from cython generated code) * fix build failures when nvcc is on the PATH * fix race condition in authentication handling (mostly harmless) * fix logging error in fakexinerama error handler * fix desktop scaling reset (was rounding) * fix file transfer via control channel command * fix handling of fatal errors when there are no socket directories * fix pulseaudio process tagging * fix proxy server when running on Python 2.6 and older glib versions * fix proxy packet re-compression, server type exported * fix minor debug logging error, avoid a spurious refresh warning * fix read-only mode command line parsing and tray menu errors * fix video encoding failures when video automatic scaling changes * fix hidden launcher bug on OSX with connection files * fix non-X11 servers image corruption * fix MS Windows and OSX build compatibility with OpenSSL 1.1 * fix video region detection dbus API * fix compilation with older versions of Cython * fix avoid crash with older versions of python-netifaces * fix stuck sound processes, use force exit if needed * fix disabled video region flag not honoured * fix stuck key modifiers when window loses focus * fix proxy hello data format * fix proxy authentication errors, add missing xpra info * fix display not honoured when connecting to a proxy * fix proxy failures with a single display detected more than once * fix proxy IO thread timeouts * fix authentication salt and hash handling (size and sanity checks) * fix some system authentication modules The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine From mukulagrawal78 at yahoo.com Fri Oct 28 22:18:07 2016 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Fri, 28 Oct 2016 21:18:07 +0000 (UTC) Subject: [winswitch] detecting an attempt by an app to open a window In-Reply-To: <1890c3e5-aa39-d286-61a7-b99ccf55adff@nagafix.co.uk> References: <1531410526.2179985.1476217710791.ref@mail.yahoo.com> <1531410526.2179985.1476217710791@mail.yahoo.com> <1890c3e5-aa39-d286-61a7-b99ccf55adff@nagafix.co.uk> Message-ID: <1017135595.846463.1477689487838@mail.yahoo.com> Following is probably not a xpra specific question rather generic x11 question, but I would appreciate if you have any pointers regarding this. I start variety of command-line applications on a headless remote host. I have an xpra server running on this host and I make all applications to send their "potential" graphical outputs to the xpra display. Not all applications will generate graphical output.In cases,? when application does try to open a graphical window on the xpra display, I would like to take some follow-up action. How do I detect that application is trying to send something to the display? ?Regards, Mukul ( https://sites.google.com/site/mukulagrawal ) On Tuesday, October 11, 2016 8:18 PM, Antoine Martin wrote: On 12/10/16 03:28, Mukul Agrawal wrote: > On Ubuntu Xenial, xpra is using the fallback option of Xvfb. > I will like to somehow be able to use Xdummy. > My specific use-case is on headless machines .... so I don't have any > Xorg starting by default. > Is there any workaround that can enable me to use Xdummy? Possibly, the Xdummy wiki page gives some clues about some of the permission changes that may be required (tested with Trusty): http://xpra.org/trac/wiki/Xdummy#Ubuntu > Is this expected to be a long term problem or do you expect to have a > solution in near term? Until Ubuntu fixes their packages or provides a workaround, no. > I highly doubt Ubuntu will do anything about it, even in near future LTS > releases. You should be asking the Ubuntu developers. They should know since they're the ones patching the upstream Xorg packages. Debian does not have this issue either. > Alternatively, if I rollback to Trusty, do I need to follow the > procedure mentioned in the link below? > Or will newer releases of xpra take care of it automatically? There is nothing we can do in our code: the broken Xorg packaging is Ubuntu's, not ours. > [I never followed this procedure before on Trusty but I dont recall > seeing Xdummy related warning before either. Which warning? I don't recall which one was the last version of Ubuntu that supported running Xdummy, sorry. Cheers Antoine > > Xdummy ? Xpra > > ??? > > ??? > > >? ? Xdummy ? Xpra > > xpra - screen for X > ??? > > > > > > > > >? > Regards, > Mukul ( https://sites.google.com/site/mukulagrawal ) > > > On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users > wrote: > > > Thanks for the clarifications.I simplified the setup (non-sudo user for > proxy; same usernames on both machines) to be able to debug. But it > still does not work. > Multifile authentication on proxy succeeds. But seems like it not using > correct ssh command line to connect to backened server.? Logs on the > proxy are attached below. There are no logs on the backend xpra server. > The sshd logs on the backend server says that the connection was closed > by the proxy [preauth]. > 1. I now start proxy as non-sudo user1 on machine1 and attach it to > non-priveldged tcp port1. Give it a display number disp1. > >? xpra proxy :disp1 --bind-tcp=0.0.0.0:port1 > --tcp-auth=multifile:filename=path-to-multifile -d auth > > Machine1 is running newer version of XPRA (xpra proxy version 1.0-r13637). > > multifile looks like following :- > user1|pswd1|1000|1000|ssh:user1 at machine2 :disp2|| > > > 2. start an xpra server on machine2 under the user account with with > same username user1. Give it a display number disp2. > > xpra start :disp2DISPLAY=:disp2 xeyes & > > Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if > this creates any problems. > > 3. Try attaching to backend server on machine2 from machine 1 using ssh > transport and public key authentication. > xpra attach ssh:user1 at machine2 :disp2 > This works fine. So seems like different versions are compatible. > 4. Try attaching from xpra clent running on machine3 (win7 machine). > > xpra attach --password-file=pswd.txt tcp:user1 at machine1 > :port1 > > OR > xpra attach tcp:user1:pswd1 at machine1 :port1 > > > Proxy Logs :- > > 2016-09-16 11:03:55,160 New tcp connection received from > IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp, > authclass=('multifile', > , {'filename': > 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16 > 11:03:55,161 creating authenticator ('multifile', 'xpra.server.auth.multifile_auth.Authenticator'>, {'filename': > 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16 > 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16 > 11:03:55,161 processing authentication withmulti password file, > response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16 > 11:03:55,161 > challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16 > 11:03:55,161 Authentication required by multipassword file authenticator > module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using > hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication > withmulti password file, response=864f4fff84caf265599ff84726295167, > client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16 > 11:03:55,271 > mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16 > 11:03:55,271 loaded 184 bytes from > 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1: > ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m?. Something here > ?hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16 > 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16 > 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<- > IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1 at IP2 > :disp2'], {}, {})^[[0m^[[36m2016-09-16 11:03:55,273 > start_proxy:proxy-virtual-display=:disp1 (ignored), user specified > display=None, founddisplays=['ssh:user1 at IP2 > :disp2']^[[0m2016-09-16 11:03:55,499 proxy video > encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance > started^[[0m2016-09-16 11:03:55,499 for client tcp socket: > internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499 and server > Pipe(ssh:user1 at IP2 :disp2)^[[0m2016-09-16 11:03:55,500 > proxy instance now also availableusing unix domain > socket:^[[0m2016-09-16 > 11:03:55,500 path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16 > 11:03:55,503 Error: SSH connection to thexpra server > failed^[[0m^[[31m2016-09-16 11:03:55,504? check your username, hostname, > displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504? for > server: ssh:user1 at IP2 :disp2^[[0m^[[31m2016-09-16 > 11:03:55,504? the command line used was:^[[0m^[[31m2016-09-16 > 11:03:55,504? ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra > _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra > _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection > lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket > path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505 > proxy instance 11703 stopped^[[0m > > > > > >? Regards, Mukul ( https://sites.google.com/site/mukulagrawal > ) > >? ? On Thursday, September 15, 2016 10:24 AM, Antoine Martin via > shifter-users > wrote: > > > On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote: >> If I want xpra proxy on machine1 to connect to xpra server on machine2 > using ssh with public key authentication and no password, then how > should I set it up? > I have not tested this, but SSH connections from the proxy should be > using the public key of the user running the proxy server process and > not the key of the user you authenticate as. (which may not have a user > account at all on the system running the proxy) > >> Public keys are already in default locations and xpra is able to > attach directly from machine2 to machine 1 using standard format:? xpra > attach ssh:username at machine1 :display. > I thought the server you wanted to connect to was "machine 2" and not > the other way around? > >> But when I try to connect via proxy from client machine3, proxy is not > being able to authenticate. > Have you checked your ssh server logs for an answer? > >> It sends the challenge but then there is no log after that. > Please share the log sample up to that point to help clarify things. > > Note: when using SSH connections, the server does not need to use > another socket authentication module. That's usually just redundant. > >> I am using multifile like this :- >> username|pswd|1000|1000|ssh:machine1:display|| >> and attach command from machine3 like this:-xpra attach > tcp:username:pswd at machine2 :proxyPORT >> >> Are the usernames and passwords actually associated with login > accounts on the target machine or their significance is only with > respect to multifile resolution? > It depends: if the proxy server runs as root, each proxied connection > will run as the uid and gid you defined. (ie: 1000 above) > But the connection to the backend server is made before changing uid, so > the ssh key used will not be the one of the user specified in multifile. > > If you don't mind using SSH with passwords, you should be able to use > something like this (untested): > |username|pswd|1000|1000|ssh/username2:password2 at machine2 > /display|| > > We could also change the code to: > * add support for ssh options to multifile, so you could specify the > keyfile for each user > * change the ordering so the connection to the backend server happens > after changing uid and gid (but this would only work with the proxy > running as root) > Feel free to create tickets for this. > >> Can password be left blank for public key authentication? > That doesn't make sense: the password in multifile is for authentication > to the proxy, not to the backend server. > Unless you're trying to connect via ssh to your proxy? (but why?) > > Cheers > Antoine > > >> >> Thanks. >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk > >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > >? > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > From antoine at nagafix.co.uk Sat Oct 29 06:01:39 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 29 Oct 2016 12:01:39 +0700 Subject: [winswitch] detecting an attempt by an app to open a window In-Reply-To: <1017135595.846463.1477689487838@mail.yahoo.com> References: <1531410526.2179985.1476217710791.ref@mail.yahoo.com> <1531410526.2179985.1476217710791@mail.yahoo.com> <1890c3e5-aa39-d286-61a7-b99ccf55adff@nagafix.co.uk> <1017135595.846463.1477689487838@mail.yahoo.com> Message-ID: On 29/10/16 04:18, Mukul Agrawal wrote: > Following is probably not a xpra specific question rather generic x11 > question, but I would appreciate if you have any pointers regarding this. > > I start variety of command-line applications on a headless remote host. > I have an xpra server running on this host and I make all applications > to send their "potential" graphical outputs to the xpra display. Not all > applications will generate graphical output. > In cases, when application does try to open a graphical window on the > xpra display, I would like to take some follow-up action. How do I > detect that application is trying to send something to the display? There are many ways of detecting that applications try "to send something to the display", it really depends what "follow-up action" you want to trigger and how reliable you want this to be. X11 applications will open a connection to the X11 server: https://tronche.com/gui/x/xlib/display/opening.html but that alone is not a guarantee that they will "show" something (they may just interact with the clipboard, keyboard or whatever). X11 applications that show windows will need to call XCreateWindow: https://linux.die.net/man/3/xcreatewindow So that's another way of detecting that they intend to show something (but then you have to check that the window is actually mapped, visible and displayed, etc) Both can be intercepted with LD_PRELOAD tricks. Looking at it from the window manager's perspective (xpra, which connects to the X11 server as a client), we get notifications from the X11 server when any new window is created. That's the core of any window manager. Then you need to reconcile this window with the process that spawned it: http://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window At that point, you usually also have many other window attributes you can use ("WM_CLASS", title, etc). Cheers Antoine > > Regards, > Mukul > ( https://sites.google.com/site/mukulagrawal ) > > > > On Tuesday, October 11, 2016 8:18 PM, Antoine Martin > wrote: > > > On 12/10/16 03:28, Mukul Agrawal wrote: >> On Ubuntu Xenial, xpra is using the fallback option of Xvfb. >> I will like to somehow be able to use Xdummy. >> My specific use-case is on headless machines .... so I don't have any >> Xorg starting by default. >> Is there any workaround that can enable me to use Xdummy? > Possibly, the Xdummy wiki page gives some clues about some of the > permission changes that may be required (tested with Trusty): > http://xpra.org/trac/wiki/Xdummy#Ubuntu > >> Is this expected to be a long term problem or do you expect to have a >> solution in near term? > Until Ubuntu fixes their packages or provides a workaround, no. > >> I highly doubt Ubuntu will do anything about it, even in near future LTS >> releases. > You should be asking the Ubuntu developers. > They should know since they're the ones patching the upstream Xorg > packages. Debian does not have this issue either. > >> Alternatively, if I rollback to Trusty, do I need to follow the >> procedure mentioned in the link below? >> Or will newer releases of xpra take care of it automatically? > There is nothing we can do in our code: the broken Xorg packaging is > Ubuntu's, not ours. > >> [I never followed this procedure before on Trusty but I dont recall >> seeing Xdummy related warning before either. > Which warning? > I don't recall which one was the last version of Ubuntu that supported > running Xdummy, sorry. > > Cheers > Antoine > >> >> Xdummy ? Xpra >> >> >> >> >> >> >> Xdummy ? Xpra >> >> xpra - screen for X >> >> >> >> >> >> >> >> >> >> >> Regards, >> Mukul ( https://sites.google.com/site/mukulagrawal > ) >> >> >> On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users >> > wrote: >> >> >> Thanks for the clarifications.I simplified the setup (non-sudo user for >> proxy; same usernames on both machines) to be able to debug. But it >> still does not work. >> Multifile authentication on proxy succeeds. But seems like it not using >> correct ssh command line to connect to backened server. Logs on the >> proxy are attached below. There are no logs on the backend xpra server. >> The sshd logs on the backend server says that the connection was closed >> by the proxy [preauth]. >> 1. I now start proxy as non-sudo user1 on machine1 and attach it to >> non-priveldged tcp port1. Give it a display number disp1. >> >> xpra proxy :disp1 --bind-tcp=0.0.0.0:port1 >> --tcp-auth=multifile:filename=path-to-multifile -d auth >> >> Machine1 is running newer version of XPRA (xpra proxy version 1.0-r13637). >> >> multifile looks like following :- >> user1|pswd1|1000|1000|ssh:user1 at machine2 > >:disp2|| >> >> >> 2. start an xpra server on machine2 under the user account with with >> same username user1. Give it a display number disp2. >> >> xpra start :disp2DISPLAY=:disp2 xeyes & >> >> Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if >> this creates any problems. >> >> 3. Try attaching to backend server on machine2 from machine 1 using ssh >> transport and public key authentication. >> xpra attach ssh:user1 at machine2 > >:disp2 >> This works fine. So seems like different versions are compatible. >> 4. Try attaching from xpra clent running on machine3 (win7 machine). >> >> xpra attach --password-file=pswd.txt tcp:user1 at machine1 > >> >:port1 >> >> OR >> xpra attach tcp:user1:pswd1 at machine1 > >:port1 >> >> >> Proxy Logs :- >> >> 2016-09-16 11:03:55,160 New tcp connection received from >> IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp, >> authclass=('multifile', >> , {'filename': >> 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16 >> 11:03:55,161 creating authenticator ('multifile',> 'xpra.server.auth.multifile_auth.Authenticator'>, {'filename': >> 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16 >> 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16 >> 11:03:55,161 processing authentication withmulti password file, >> response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16 >> 11:03:55,161 >> > challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16 >> 11:03:55,161 Authentication required by multipassword file authenticator >> module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using >> hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication >> withmulti password file, response=864f4fff84caf265599ff84726295167, >> > client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16 >> 11:03:55,271 >> mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16 >> 11:03:55,271 loaded 184 bytes from >> 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1: >> ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m?. Something here >> > ?hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16 >> 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16 >> 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<- >> IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1 at IP2 > >> >:disp2'], {}, > {})^[[0m^[[36m2016-09-16 11:03:55,273 >> start_proxy:proxy-virtual-display=:disp1 (ignored), user specified >> display=None, founddisplays=['ssh:user1 at IP2 >> >:disp2']^[[0m2016-09-16 > 11:03:55,499 proxy video >> encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance >> started^[[0m2016-09-16 11:03:55,499 for client tcp socket: >> internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499 and server >> Pipe(ssh:user1 at IP2 >:disp2)^[[0m2016-09-16 11:03:55,500 >> proxy instance now also availableusing unix domain >> socket:^[[0m2016-09-16 >> 11:03:55,500 > path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16 >> 11:03:55,503 Error: SSH connection to thexpra server >> failed^[[0m^[[31m2016-09-16 11:03:55,504 check your username, hostname, >> displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504 for >> server: ssh:user1 at IP2 >:disp2^[[0m^[[31m2016-09-16 >> 11:03:55,504 the command line used was:^[[0m^[[31m2016-09-16 >> 11:03:55,504 ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra >> _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra >> _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection >> lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket >> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505 >> proxy instance 11703 stopped^[[0m >> >> >> >> >> >> Regards, Mukul ( https://sites.google.com/site/mukulagrawal >> ) >> >> On Thursday, September 15, 2016 10:24 AM, Antoine Martin via >> shifter-users >> >> wrote: >> >> >> On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote: >>> If I want xpra proxy on machine1 to connect to xpra server on machine2 >> using ssh with public key authentication and no password, then how >> should I set it up? >> I have not tested this, but SSH connections from the proxy should be >> using the public key of the user running the proxy server process and >> not the key of the user you authenticate as. (which may not have a user >> account at all on the system running the proxy) >> >>> Public keys are already in default locations and xpra is able to >> attach directly from machine2 to machine 1 using standard format: xpra >> attach ssh:username at machine1 > >:display. >> I thought the server you wanted to connect to was "machine 2" and not >> the other way around? >> >>> But when I try to connect via proxy from client machine3, proxy is not >> being able to authenticate. >> Have you checked your ssh server logs for an answer? >> >>> It sends the challenge but then there is no log after that. >> Please share the log sample up to that point to help clarify things. >> >> Note: when using SSH connections, the server does not need to use >> another socket authentication module. That's usually just redundant. >> >>> I am using multifile like this :- >>> username|pswd|1000|1000|ssh:machine1:display|| >>> and attach command from machine3 like this:-xpra attach >> tcp:username:pswd at machine2 > >:proxyPORT >>> >>> Are the usernames and passwords actually associated with login >> accounts on the target machine or their significance is only with >> respect to multifile resolution? >> It depends: if the proxy server runs as root, each proxied connection >> will run as the uid and gid you defined. (ie: 1000 above) >> But the connection to the backend server is made before changing uid, so >> the ssh key used will not be the one of the user specified in multifile. >> >> If you don't mind using SSH with passwords, you should be able to use >> something like this (untested): >> |username|pswd|1000|1000|ssh/username2:password2 at machine2 > >> >/display|| >> >> We could also change the code to: >> * add support for ssh options to multifile, so you could specify the >> keyfile for each user >> * change the ordering so the connection to the backend server happens >> after changing uid and gid (but this would only work with the proxy >> running as root) >> Feel free to create tickets for this. >> >>> Can password be left blank for public key authentication? >> That doesn't make sense: the password in multifile is for authentication >> to the proxy, not to the backend server. >> Unless you're trying to connect via ssh to your proxy? (but why?) >> >> Cheers >> Antoine >> >> >>> >>> Thanks. >>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk > >> > >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk > >> > >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> >> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk > >> > > >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> >> > > > From tmesposito00 at gmail.com Sat Oct 29 20:52:06 2016 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Sat, 29 Oct 2016 15:52:06 -0400 Subject: [winswitch] how to turn off scaling? Message-ID: I have set 'desktop-scaling' to off in my xpra.conf file, but nevertheless, whenever I connect my client (running on Windows 7), my application windows are scaled to 125% or 150%. Is this a bug, or have I misunderstood what the 'desktop-scaling' setting does in xpra.conf? I have tried this both with 0.17.5 and the 1.0 beta. From antoine at nagafix.co.uk Sun Oct 30 03:16:15 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 30 Oct 2016 10:16:15 +0700 Subject: [winswitch] how to turn off scaling? In-Reply-To: References: Message-ID: On 30/10/16 02:52, Thomas Esposito via shifter-users wrote: > I have set 'desktop-scaling' to off in my xpra.conf file, Which xpra.conf? desktop-scaling is a client-side option.. > but nevertheless, > whenever I connect my client (running on Windows 7), my application windows > are scaled to 125% or 150%. Desktop scaling will show up in the "xpra_cmd.exe" output. Please post it here. > Is this a bug, or have I misunderstood what the 'desktop-scaling' setting > does in xpra.conf? Could be, but I've never seen it not being honoured. > I have tried this both with 0.17.5 and the 1.0 beta. Cheers Antoine From mukulagrawal78 at yahoo.com Mon Oct 31 16:12:44 2016 From: mukulagrawal78 at yahoo.com (Mukul Agrawal) Date: Mon, 31 Oct 2016 16:12:44 +0000 (UTC) Subject: [winswitch] detecting an attempt by an app to open a window In-Reply-To: References: <1531410526.2179985.1476217710791.ref@mail.yahoo.com> <1531410526.2179985.1476217710791@mail.yahoo.com> <1890c3e5-aa39-d286-61a7-b99ccf55adff@nagafix.co.uk> <1017135595.846463.1477689487838@mail.yahoo.com> Message-ID: <1058164867.1321515.1477930364097@mail.yahoo.com> Thanks Antoine. Basically, I want to detect if user's app want to generate a graphical output and then I like to automatically connect user to the xpra html5 client. I would like to be able to capture any window creation request whether client uses x11 API, openGL or anything else.At this point of time, I am not worried about video, sound, mouse or keyboard --- graphics window is the only thing that I care about. ?Regards, Mukul ( https://sites.google.com/site/mukulagrawal ) On Friday, October 28, 2016 10:01 PM, Antoine Martin wrote: On 29/10/16 04:18, Mukul Agrawal wrote: > Following is probably not a xpra specific question rather generic x11 > question, but I would appreciate if you have any pointers regarding this. > > I start variety of command-line applications on a headless remote host. > I have an xpra server running on this host and I make all applications > to send their "potential" graphical outputs to the xpra display. Not all > applications will generate graphical output. > In cases,? when application does try to open a graphical window on the > xpra display, I would like to take some follow-up action. How do I > detect that application is trying to send something to the display? There are many ways of detecting that applications try "to send something to the display", it really depends what "follow-up action" you want to trigger and how reliable you want this to be. X11 applications will open a connection to the X11 server: https://tronche.com/gui/x/xlib/display/opening.html but that alone is not a guarantee that they will "show" something (they may just interact with the clipboard, keyboard or whatever). X11 applications that show windows will need to call XCreateWindow: https://linux.die.net/man/3/xcreatewindow So that's another way of detecting that they intend to show something (but then you have to check that the window is actually mapped, visible and displayed, etc) Both can be intercepted with LD_PRELOAD tricks. Looking at it from the window manager's perspective (xpra, which connects to the X11 server as a client), we get notifications from the X11 server when any new window is created. That's the core of any window manager. Then you need to reconcile this window with the process that spawned it: http://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window At that point, you usually also have many other window attributes you can use ("WM_CLASS", title, etc). Cheers Antoine >? > Regards, > Mukul > ( https://sites.google.com/site/mukulagrawal ) > > > > On Tuesday, October 11, 2016 8:18 PM, Antoine Martin > wrote: > > > On 12/10/16 03:28, Mukul Agrawal wrote: >> On Ubuntu Xenial, xpra is using the fallback option of Xvfb. >> I will like to somehow be able to use Xdummy. >> My specific use-case is on headless machines .... so I don't have any >> Xorg starting by default. >> Is there any workaround that can enable me to use Xdummy? > Possibly, the Xdummy wiki page gives some clues about some of the > permission changes that may be required (tested with Trusty): > http://xpra.org/trac/wiki/Xdummy#Ubuntu > >> Is this expected to be a long term problem or do you expect to have a >> solution in near term? > Until Ubuntu fixes their packages or provides a workaround, no. > >> I highly doubt Ubuntu will do anything about it, even in near future LTS >> releases. > You should be asking the Ubuntu developers. > They should know since they're the ones patching the upstream Xorg > packages. Debian does not have this issue either. > >> Alternatively, if I rollback to Trusty, do I need to follow the >> procedure mentioned in the link below? >> Or will newer releases of xpra take care of it automatically? > There is nothing we can do in our code: the broken Xorg packaging is > Ubuntu's, not ours. > >> [I never followed this procedure before on Trusty but I dont recall >> seeing Xdummy related warning before either. > Which warning? > I don't recall which one was the last version of Ubuntu that supported > running Xdummy, sorry. > > Cheers > Antoine > >> >> Xdummy ? Xpra >> >>? ? >> >>? ? >> >> >>? ? Xdummy ? Xpra >> >> xpra - screen for X >>? ? >> >> >> >> >> >> >> >> >> >> Regards, >> Mukul ( https://sites.google.com/site/mukulagrawal > ) >> >> >> On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users >> > wrote: >> >> >> Thanks for the clarifications.I simplified the setup (non-sudo user for >> proxy; same usernames on both machines) to be able to debug. But it >> still does not work. >> Multifile authentication on proxy succeeds. But seems like it not using >> correct ssh command line to connect to backened server.? Logs on the >> proxy are attached below. There are no logs on the backend xpra server. >> The sshd logs on the backend server says that the connection was closed >> by the proxy [preauth]. >> 1. I now start proxy as non-sudo user1 on machine1 and attach it to >> non-priveldged tcp port1. Give it a display number disp1. >> >>? xpra proxy :disp1 --bind-tcp=0.0.0.0:port1 >> --tcp-auth=multifile:filename=path-to-multifile -d auth >> >> Machine1 is running newer version of XPRA (xpra proxy version 1.0-r13637). >> >> multifile looks like following :- >> user1|pswd1|1000|1000|ssh:user1 at machine2 > >:disp2|| >> >> >> 2. start an xpra server on machine2 under the user account with with >> same username user1. Give it a display number disp2. >> >> xpra start :disp2DISPLAY=:disp2 xeyes & >> >> Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if >> this creates any problems. >> >> 3. Try attaching to backend server on machine2 from machine 1 using ssh >> transport and public key authentication. >> xpra attach ssh:user1 at machine2 > >:disp2 >> This works fine. So seems like different versions are compatible. >> 4. Try attaching from xpra clent running on machine3 (win7 machine). >> >> xpra attach --password-file=pswd.txt tcp:user1 at machine1 > >> >:port1 >> >> OR >> xpra attach tcp:user1:pswd1 at machine1 > >:port1 >> >> >> Proxy Logs :- >> >> 2016-09-16 11:03:55,160 New tcp connection received from >> IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp, >> authclass=('multifile', >> , {'filename': >> 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16 >> 11:03:55,161 creating authenticator ('multifile',> 'xpra.server.auth.multifile_auth.Authenticator'>, {'filename': >> 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16 >> 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16 >> 11:03:55,161 processing authentication withmulti password file, >> response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16 >> 11:03:55,161 >> > challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16 >> 11:03:55,161 Authentication required by multipassword file authenticator >> module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using >> hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication >> withmulti password file, response=864f4fff84caf265599ff84726295167, >> > client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16 >> 11:03:55,271 >> mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16 >> 11:03:55,271 loaded 184 bytes from >> 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1: >> ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m?. Something here >> > ?hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16 >> 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16 >> 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<- >> IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1 at IP2 > >> >:disp2'], {}, > {})^[[0m^[[36m2016-09-16 11:03:55,273 >> start_proxy:proxy-virtual-display=:disp1 (ignored), user specified >> display=None, founddisplays=['ssh:user1 at IP2 >> >:disp2']^[[0m2016-09-16 > 11:03:55,499 proxy video >> encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance >> started^[[0m2016-09-16 11:03:55,499 for client tcp socket: >> internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499 and server >> Pipe(ssh:user1 at IP2 >:disp2)^[[0m2016-09-16 11:03:55,500 >> proxy instance now also availableusing unix domain >> socket:^[[0m2016-09-16 >> 11:03:55,500 > path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16 >> 11:03:55,503 Error: SSH connection to thexpra server >> failed^[[0m^[[31m2016-09-16 11:03:55,504? check your username, hostname, >> displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504? for >> server: ssh:user1 at IP2 >:disp2^[[0m^[[31m2016-09-16 >> 11:03:55,504? the command line used was:^[[0m^[[31m2016-09-16 >> 11:03:55,504? ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra >> _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra >> _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection >> lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket >> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505 >> proxy instance 11703 stopped^[[0m >> >> >> >> >> >>? Regards, Mukul ( https://sites.google.com/site/mukulagrawal >> ) >> >>? ? On Thursday, September 15, 2016 10:24 AM, Antoine Martin via >> shifter-users >> >> wrote: >> >> >> On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote: >>> If I want xpra proxy on machine1 to connect to xpra server on machine2 >> using ssh with public key authentication and no password, then how >> should I set it up? >> I have not tested this, but SSH connections from the proxy should be >> using the public key of the user running the proxy server process and >> not the key of the user you authenticate as. (which may not have a user >> account at all on the system running the proxy) >> >>> Public keys are already in default locations and xpra is able to >> attach directly from machine2 to machine 1 using standard format:? xpra >> attach ssh:username at machine1 > >:display. >> I thought the server you wanted to connect to was "machine 2" and not >> the other way around? >> >>> But when I try to connect via proxy from client machine3, proxy is not >> being able to authenticate. >> Have you checked your ssh server logs for an answer? >> >>> It sends the challenge but then there is no log after that. >> Please share the log sample up to that point to help clarify things. >> >> Note: when using SSH connections, the server does not need to use >> another socket authentication module. That's usually just redundant. >> >>> I am using multifile like this :- >>> username|pswd|1000|1000|ssh:machine1:display|| >>> and attach command from machine3 like this:-xpra attach >> tcp:username:pswd at machine2 > >:proxyPORT >>> >>> Are the usernames and passwords actually associated with login >> accounts on the target machine or their significance is only with >> respect to multifile resolution? >> It depends: if the proxy server runs as root, each proxied connection >> will run as the uid and gid you defined. (ie: 1000 above) >> But the connection to the backend server is made before changing uid, so >> the ssh key used will not be the one of the user specified in multifile. >> >> If you don't mind using SSH with passwords, you should be able to use >> something like this (untested): >> |username|pswd|1000|1000|ssh/username2:password2 at machine2 > >> >/display|| >> >> We could also change the code to: >> * add support for ssh options to multifile, so you could specify the >> keyfile for each user >> * change the ordering so the connection to the backend server happens >> after changing uid and gid (but this would only work with the proxy >> running as root) >> Feel free to create tickets for this. >> >>> Can password be left blank for public key authentication? >> That doesn't make sense: the password in multifile is for authentication >> to the proxy, not to the backend server. >> Unless you're trying to connect via ssh to your proxy? (but why?) >> >> Cheers >> Antoine >> >> >>> >>> Thanks. >>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk > >> > >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk > >> > >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> >> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk > >> > > >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> >> > > >