From timothy at hobbs.cz Sun Aug 2 00:50:04 2015 From: timothy at hobbs.cz (Timothy Hobbs) Date: Sun, 2 Aug 2015 01:50:04 +0200 Subject: [winswitch] Xpra Xorg launch sequence: using a unix domain socket in /tmp/.X11-unix In-Reply-To: References: <20150718200824.GC15275@timothy-debian-hp> <20150719081657.GA23770@timothy-debian-hp> Message-ID: <20150801235004.GD20039@timothy-debian-hp> Hey, I have finished implementing basic XPRA support in subuser. I haven't worked on getting mmap working yet, but I will do so shortly. I am currently planning the release of subuser 0.3 which will add XPRA support. You can read my draft press release here: http://subuser.org/news/0.3.html I have run into one problem, which is that when I launch the xpra server in a container the DPI isn't set correctly or something. Take a look at this screen shot of the Arduino IDE for example: http://timothy.hobbs.cz/arduino.png You see the size of the text in the menu? Obviously I am going to have to transfer DPI info to xpra from the host. How should I go about doing that? Thank you, Timothy Hobbs On Mon, Jul 20, 2015 at 09:46:44AM +0700, Antoine Martin wrote: > I think the wiki could do with some improvements with regards to running > xpra with containers (feel free to edit), until then: > * make sure mmap is enabled (and you can even use a trimmed down build > without any video codecs, which is much safer) > * disable compression > The performance should be very close to native, if not then something is > not setup right. > > Cheers > Antoine > It appears that I have fixed my imediate problem. I was sharing > /tmp/.X11-unix using docker volumes, and I needed to run chmod 1777 > /tmp/.X11-unix on it to get the permissions the way Xorg wants them :) > > Tim > > On Sat, Jul 18, 2015 at 10:08:25PM +0200, Timothy Hobbs wrote: > > Dear list, > > > > I am the creator of subuser.org. Subuser is a free open source software > project (LGPL3) which aims to allow a person to run desktop applications > inside Docker containers. Subuser has several aims. One is to make it > easier to publish desktop applications on linux by improving portability. > Another is to make the desktop more secure by containing those desktop > applications within their respective containers. > > > > Right now, the seccond goal is not met. Desktop applications communicate > with the host's X11 server by sharing the /tmp/.X11-unix folder with it. > This works well, but is completely insecure. I have been waiting for > wayland to come out in order to provide a secure solution. However, spurred > on by the success of OZ, written by subgraph.com I have begun to reconsider > xpra as an intermediate option. > > > > As I want to maintain portability and ease of creating subuser Docker > images, I do not wish to install the xpra server in each Docker image which > contains a desktop application. In order to maintain this sepparation of > requirements, I have come up with the following architecture involving 3 > containers: > > > > ------------- ------------- > > |desktop app| <--/tmp/.X11-unix--> |xpra server| Untrusted > > ------------- ------------- > > ^ > > | ~/.xpra > > v > > ------------- ------------- > > | host | <--/tmp/.X11-unix--> |xpra client| Trusted > > ------------- ------------- > > > > This allows me to run 3 containers. > > > > 1) contains the untrusted desktop application > > 2) contains an untrusted xpra server > > 3) contains a trusted xpra client > > > > I can use an up-to-date version of xpra, as I do not need to have xpra > installed on the host. > > > > The only problem, is that when I run > > > > $ xpra start :100 --start-child=xterm > > > > I don't end up with a unix domain socket in the xpra server's > /tmp/.X11-unix directory. This is despite the fact that I have -nolisten > tcp set in xpra.conf: > > > > xvfb=Xorg -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR > +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config > /etc/xpra/xorg.conf > > > > I am confused as to why this is happening, and how I can get a unix > domain socket to work with. I cannot use a UDP socket due to the > difficulties of sharing UDP sockets between containers. > > > > I have been testing this settup on xpra version 0.14.10 > > > > Thank you in advance for your help, > > > > Timothy Hobbs > > _______________________________________________ > > 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 Sun Aug 2 18:17:29 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 3 Aug 2015 00:17:29 +0700 Subject: [winswitch] awesome project, newbie questions In-Reply-To: References: <55BB6360.6020007@nagafix.co.uk> Message-ID: <55BE50A9.2030903@nagafix.co.uk> On 01/08/15 01:57, Barry Smoke wrote: > General statement, I'm trying to get detailed general overview about how winswitch works internally, and why the limitations exist on windows. > > See below: > >> I stumbled across this project while looking deeper into nomachine nx, and comparable remote protocols. >> I spent an afternoon learning about the winswitch gui, and connecting windows pc's together remotely. >> the client obviously has full support for the various remote connection protocols, vnc, nx, xpra, rdp, and various others. >> there seems to be no way to force a different protocol to be used for windows connections, although the note on the website indicates a licensing issue, not the technology is at fault. >>> I think you are referring to this page: >>> https://winswitch.org/documentation/protocols/rdp.html >>> Every version of windows is capable of running as a RDP server, but Microsoft charges you more for the privilege. > Yes, correct. The statement: > "Window Switch can only use RDP to connect to a Microsoft Windows machine and forward the desktop to the client's display. > Although there are other features and other servers, these are not supported at present. > (Mostly due to unnecessary licensing restrictions which have nothing to do with the technology)" > That leads the reader to think that technically, it might be a possibility to enable the functionality, maybe even use a version detection routine to figure out the licensing issue on a per server basis, right? We already do exactly that: http://winswitch.org/trac/browser/trunk/winswitch/virt/rdp_common_util.py >> how difficult would it be to enable a selection of the protocol to use for client to client connections on windows, for use as an internal remote assistance utility? >>> I'm not sure what you are asking. >> Does the client software act as a server, as I figured out a default port of 32123 is used for connections. >>> Usually, the applet starts a local server so that you can also access session on that machine. >>> This can be disabled. >>> The port you refer to is the winswitch port. >> Or, would nx server software, and xpra server software have to be run, to connect the session to? >>> I don't understand the question, sorry! >> Is there a design doc, or diagram showing the internal workflow? I did download the source, but haven't dug through too deep yet. >>> I'm afraid there isn't, only the code and the documentation on the website: >>> https://winswitch.org/documentation/ > I'll compile the above into one question. Since the issue of only using rdp is a licensing issue, the questions above are meant to determine the design of winswitch, and routing of sessions. > Is it possible to enable windows to windows xpra, or nx sessions as is, or would xpra server, or nx server need to be ported to windows? Xpra already runs as a shadow server on Windows but this is not exposed through the winswitch gui yet. There are plans to take this further in Xpra: * to allow hardware encoding to speed things up: http://xpra.org/trac/ticket/558 * speed up pixel capture: http://xpra.org/trac/ticket/389 * seamless mode: http://xpra.org/trac/ticket/897 I don't think you will ever see an open source NX server on Windows (but will gladly be proven wrong), the NX code dates back to monolithic X11 servers! Cheers Antoine > > > Cheers > Antoine >> Thanks, >> Barry Smoke >> >> _______________________________________________ >> 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 Sun Aug 2 18:32:17 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 3 Aug 2015 00:32:17 +0700 Subject: [winswitch] Xpra Xorg launch sequence: using a unix domain socket in /tmp/.X11-unix In-Reply-To: <20150801235004.GD20039@timothy-debian-hp> References: <20150718200824.GC15275@timothy-debian-hp> <20150719081657.GA23770@timothy-debian-hp> <20150801235004.GD20039@timothy-debian-hp> Message-ID: <55BE5421.90008@nagafix.co.uk> On 02/08/15 06:50, Timothy Hobbs wrote: > Hey, > > I have finished implementing basic XPRA support in subuser. I haven't worked on getting mmap working yet, but I will do so shortly. I am currently planning the release of subuser 0.3 which will add XPRA support. You can read my draft press release here: http://subuser.org/news/0.3.html > > I have run into one problem, which is that when I launch the xpra server in a container the DPI isn't set correctly or something. Take a look at this screen shot of the Arduino IDE for example: http://timothy.hobbs.cz/arduino.png This is a known problem with the vfb servers, newer versions of xpra give you a more helpful warning when you connect a client: *** DPI set to 23 x 28 (wanted 96 x 96) you may experience scaling problems, such as huge or small fonts, etc to fix this issue, try the dpi switch, or use a patched Xdummy driver *** Long story short: the X11 server assumes that the physical display has a fixed size (which sounds like a fair assumption to make) and that when you change the resolution, the DPI should change since the number of pixels change. In our case, there is no physical screen, only a virtual one, and so we want the DPI to remain constant (or better, use the one we request) and have the "phyiscal size" adjusted instead. * using the "--dpi=96" switch works in most cases, but not for applications which calculate their own DPI value by querying the X11 server for the physical screen size. * using the patched dummy driver works better, but overrides a system package... Hopefully a better solution will land in Xorg soon, also allowing us to define custom resolutions for the virtual display rather than trying to find a match in the limited pre-defined list: http://xpra.org/trac/ticket/56#comment:12 Then there's also the "Xft.dpi" display property (and the gnome variant..) which we synchronize alrady, but which is blissfully ignored by too many applications. > You see the size of the text in the menu? Obviously I am going to have to transfer DPI info to xpra from the host. How should I go about doing that? We already do that automatically, see the "wanted 96x96" in the log sample above, this should match your client's settings. Cheers Antoine > > Thank you, > Timothy Hobbs > > On Mon, Jul 20, 2015 at 09:46:44AM +0700, Antoine Martin wrote: >> I think the wiki could do with some improvements with regards to running >> xpra with containers (feel free to edit), until then: >> * make sure mmap is enabled (and you can even use a trimmed down build >> without any video codecs, which is much safer) >> * disable compression >> The performance should be very close to native, if not then something is >> not setup right. >> >> Cheers >> Antoine >> It appears that I have fixed my imediate problem. I was sharing >> /tmp/.X11-unix using docker volumes, and I needed to run chmod 1777 >> /tmp/.X11-unix on it to get the permissions the way Xorg wants them :) >> >> Tim >> >> On Sat, Jul 18, 2015 at 10:08:25PM +0200, Timothy Hobbs wrote: >>> Dear list, >>> >>> I am the creator of subuser.org. Subuser is a free open source software >> project (LGPL3) which aims to allow a person to run desktop applications >> inside Docker containers. Subuser has several aims. One is to make it >> easier to publish desktop applications on linux by improving portability. >> Another is to make the desktop more secure by containing those desktop >> applications within their respective containers. >>> Right now, the seccond goal is not met. Desktop applications communicate >> with the host's X11 server by sharing the /tmp/.X11-unix folder with it. >> This works well, but is completely insecure. I have been waiting for >> wayland to come out in order to provide a secure solution. However, spurred >> on by the success of OZ, written by subgraph.com I have begun to reconsider >> xpra as an intermediate option. >>> As I want to maintain portability and ease of creating subuser Docker >> images, I do not wish to install the xpra server in each Docker image which >> contains a desktop application. In order to maintain this sepparation of >> requirements, I have come up with the following architecture involving 3 >> containers: >>> ------------- ------------- >>> |desktop app| <--/tmp/.X11-unix--> |xpra server| Untrusted >>> ------------- ------------- >>> ^ >>> | ~/.xpra >>> v >>> ------------- ------------- >>> | host | <--/tmp/.X11-unix--> |xpra client| Trusted >>> ------------- ------------- >>> >>> This allows me to run 3 containers. >>> >>> 1) contains the untrusted desktop application >>> 2) contains an untrusted xpra server >>> 3) contains a trusted xpra client >>> >>> I can use an up-to-date version of xpra, as I do not need to have xpra >> installed on the host. >>> The only problem, is that when I run >>> >>> $ xpra start :100 --start-child=xterm >>> >>> I don't end up with a unix domain socket in the xpra server's >> /tmp/.X11-unix directory. This is despite the fact that I have -nolisten >> tcp set in xpra.conf: >>> xvfb=Xorg -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR >> +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config >> /etc/xpra/xorg.conf >>> I am confused as to why this is happening, and how I can get a unix >> domain socket to work with. I cannot use a UDP socket due to the >> difficulties of sharing UDP sockets between containers. >>> I have been testing this settup on xpra version 0.14.10 >>> >>> Thank you in advance for your help, >>> >>> Timothy Hobbs >>> _______________________________________________ >>> 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 timothy at hobbs.cz Sun Aug 2 19:23:00 2015 From: timothy at hobbs.cz (Timothy Hobbs) Date: Sun, 2 Aug 2015 20:23:00 +0200 Subject: [winswitch] Xpra Xorg launch sequence: using a unix domain socket in /tmp/.X11-unix In-Reply-To: <55BE5421.90008@nagafix.co.uk> References: <20150718200824.GC15275@timothy-debian-hp> <20150719081657.GA23770@timothy-debian-hp> <20150801235004.GD20039@timothy-debian-hp> <55BE5421.90008@nagafix.co.uk> Message-ID: <20150802182300.GA25361@timothy-debian-hp> Thank you for your detailed reply, Currently, I only have this problem with the Arduino IDE, all other applications tested work. XPRA 0.14.10 which is the version which ships with Debian Jessie claims that the `--dpi` setting is set to 96 by default: --dpi=DPI The 'dots per inch' value that client applications should try to honour (default: 96) I presume that this means that my only option now would be to try to ship a patched version of Xorg. For now, I am not going to do that, because this will complicate container building. Currently subuser builds all containers itself, and shipping a non-standard version of Xorg would mean that every user of subuser would have to wait for subuser to build Xorg at install time. Not exactly a happy option. In the future, maybe I'll do more in the way of providing support for pre-built containers and this fix can be applied. Or better yet, perhaps by that time the patch will have landed in Xorg's master. Thank you for your help and thanks for the great product! Timothy On Mon, Aug 03, 2015 at 12:32:17AM +0700, Antoine Martin wrote: > On 02/08/15 06:50, Timothy Hobbs wrote: > > Hey, > > > > I have finished implementing basic XPRA support in subuser. I haven't worked on getting mmap working yet, but I will do so shortly. I am currently planning the release of subuser 0.3 which will add XPRA support. You can read my draft press release here: http://subuser.org/news/0.3.html > > > > I have run into one problem, which is that when I launch the xpra server in a container the DPI isn't set correctly or something. Take a look at this screen shot of the Arduino IDE for example: http://timothy.hobbs.cz/arduino.png > This is a known problem with the vfb servers, newer versions of xpra > give you a more helpful warning when you connect a client: > *** > DPI set to 23 x 28 (wanted 96 x 96) > you may experience scaling problems, such as huge or small fonts, etc > to fix this issue, try the dpi switch, or use a patched Xdummy driver > *** > > Long story short: the X11 server assumes that the physical display has a > fixed size (which sounds like a fair assumption to make) and that when > you change the resolution, the DPI should change since the number of > pixels change. > In our case, there is no physical screen, only a virtual one, and so we > want the DPI to remain constant (or better, use the one we request) and > have the "phyiscal size" adjusted instead. > * using the "--dpi=96" switch works in most cases, but not for > applications which calculate their own DPI value by querying the X11 > server for the physical screen size. > * using the patched dummy driver works better, but overrides a system > package... > Hopefully a better solution will land in Xorg soon, also allowing us to > define custom resolutions for the virtual display rather than trying to > find a match in the limited pre-defined list: > http://xpra.org/trac/ticket/56#comment:12 > > Then there's also the "Xft.dpi" display property (and the gnome > variant..) which we synchronize alrady, but which is blissfully ignored > by too many applications. > > You see the size of the text in the menu? Obviously I am going to have to transfer DPI info to xpra from the host. How should I go about doing that? > We already do that automatically, see the "wanted 96x96" in the log > sample above, this should match your client's settings. > > Cheers > Antoine > > > > Thank you, > > Timothy Hobbs > > > > On Mon, Jul 20, 2015 at 09:46:44AM +0700, Antoine Martin wrote: > >> I think the wiki could do with some improvements with regards to running > >> xpra with containers (feel free to edit), until then: > >> * make sure mmap is enabled (and you can even use a trimmed down build > >> without any video codecs, which is much safer) > >> * disable compression > >> The performance should be very close to native, if not then something is > >> not setup right. > >> > >> Cheers > >> Antoine > >> It appears that I have fixed my imediate problem. I was sharing > >> /tmp/.X11-unix using docker volumes, and I needed to run chmod 1777 > >> /tmp/.X11-unix on it to get the permissions the way Xorg wants them :) > >> > >> Tim > >> > >> On Sat, Jul 18, 2015 at 10:08:25PM +0200, Timothy Hobbs wrote: > >>> Dear list, > >>> > >>> I am the creator of subuser.org. Subuser is a free open source software > >> project (LGPL3) which aims to allow a person to run desktop applications > >> inside Docker containers. Subuser has several aims. One is to make it > >> easier to publish desktop applications on linux by improving portability. > >> Another is to make the desktop more secure by containing those desktop > >> applications within their respective containers. > >>> Right now, the seccond goal is not met. Desktop applications communicate > >> with the host's X11 server by sharing the /tmp/.X11-unix folder with it. > >> This works well, but is completely insecure. I have been waiting for > >> wayland to come out in order to provide a secure solution. However, spurred > >> on by the success of OZ, written by subgraph.com I have begun to reconsider > >> xpra as an intermediate option. > >>> As I want to maintain portability and ease of creating subuser Docker > >> images, I do not wish to install the xpra server in each Docker image which > >> contains a desktop application. In order to maintain this sepparation of > >> requirements, I have come up with the following architecture involving 3 > >> containers: > >>> ------------- ------------- > >>> |desktop app| <--/tmp/.X11-unix--> |xpra server| Untrusted > >>> ------------- ------------- > >>> ^ > >>> | ~/.xpra > >>> v > >>> ------------- ------------- > >>> | host | <--/tmp/.X11-unix--> |xpra client| Trusted > >>> ------------- ------------- > >>> > >>> This allows me to run 3 containers. > >>> > >>> 1) contains the untrusted desktop application > >>> 2) contains an untrusted xpra server > >>> 3) contains a trusted xpra client > >>> > >>> I can use an up-to-date version of xpra, as I do not need to have xpra > >> installed on the host. > >>> The only problem, is that when I run > >>> > >>> $ xpra start :100 --start-child=xterm > >>> > >>> I don't end up with a unix domain socket in the xpra server's > >> /tmp/.X11-unix directory. This is despite the fact that I have -nolisten > >> tcp set in xpra.conf: > >>> xvfb=Xorg -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR > >> +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config > >> /etc/xpra/xorg.conf > >>> I am confused as to why this is happening, and how I can get a unix > >> domain socket to work with. I cannot use a UDP socket due to the > >> difficulties of sharing UDP sockets between containers. > >>> I have been testing this settup on xpra version 0.14.10 > >>> > >>> Thank you in advance for your help, > >>> > >>> Timothy Hobbs > >>> _______________________________________________ > >>> 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 Mon Aug 3 06:25:22 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 3 Aug 2015 12:25:22 +0700 Subject: [winswitch] Xpra Xorg launch sequence: using a unix domain socket in /tmp/.X11-unix In-Reply-To: <20150802182300.GA25361@timothy-debian-hp> References: <20150718200824.GC15275@timothy-debian-hp> <20150719081657.GA23770@timothy-debian-hp> <20150801235004.GD20039@timothy-debian-hp> <55BE5421.90008@nagafix.co.uk> <20150802182300.GA25361@timothy-debian-hp> Message-ID: <55BEFB42.7000209@nagafix.co.uk> On 03/08/15 01:23, Timothy Hobbs wrote: > Thank you for your detailed reply, > > Currently, I only have this problem with the Arduino IDE, all other applications tested work. XPRA 0.14.10 which is the version which ships with Debian Jessie claims that the `--dpi` setting is set to 96 by default: If you want to provide a stable experience to your users, I would strongly advise against using an unsupported version like 0.14.10, see here for details: http://xpra.org/trac/wiki/Packaging > --dpi=DPI The 'dots per inch' value that client applications > should try to honour (default: 96) One more thing I forgot: there's also the dpi switch to Xorg, which we set and overlaps with some of what I have said. > I presume that this means that my only option now would be to try to ship a patched version of Xorg. For now, I am not going to do that, because this will complicate container building. Currently subuser builds all containers itself, and shipping a non-standard version of Xorg would mean that every user of subuser would have to wait for subuser to build Xorg at install time. Not exactly a happy option. In the future, maybe I'll do more in the way of providing support for pre-built containers and this fix can be applied. Or better yet, perhaps by that time the patch will have landed in Xorg's master. Don't hold your breath. Even if it got merged today, it would take a long time before this ships in distros. Cheers Antoine > > Thank you for your help and thanks for the great product! > > Timothy > > On Mon, Aug 03, 2015 at 12:32:17AM +0700, Antoine Martin wrote: >> On 02/08/15 06:50, Timothy Hobbs wrote: >>> Hey, >>> >>> I have finished implementing basic XPRA support in subuser. I haven't worked on getting mmap working yet, but I will do so shortly. I am currently planning the release of subuser 0.3 which will add XPRA support. You can read my draft press release here: http://subuser.org/news/0.3.html >>> >>> I have run into one problem, which is that when I launch the xpra server in a container the DPI isn't set correctly or something. Take a look at this screen shot of the Arduino IDE for example: http://timothy.hobbs.cz/arduino.png >> This is a known problem with the vfb servers, newer versions of xpra >> give you a more helpful warning when you connect a client: >> *** >> DPI set to 23 x 28 (wanted 96 x 96) >> you may experience scaling problems, such as huge or small fonts, etc >> to fix this issue, try the dpi switch, or use a patched Xdummy driver >> *** >> >> Long story short: the X11 server assumes that the physical display has a >> fixed size (which sounds like a fair assumption to make) and that when >> you change the resolution, the DPI should change since the number of >> pixels change. >> In our case, there is no physical screen, only a virtual one, and so we >> want the DPI to remain constant (or better, use the one we request) and >> have the "phyiscal size" adjusted instead. >> * using the "--dpi=96" switch works in most cases, but not for >> applications which calculate their own DPI value by querying the X11 >> server for the physical screen size. >> * using the patched dummy driver works better, but overrides a system >> package... >> Hopefully a better solution will land in Xorg soon, also allowing us to >> define custom resolutions for the virtual display rather than trying to >> find a match in the limited pre-defined list: >> http://xpra.org/trac/ticket/56#comment:12 >> >> Then there's also the "Xft.dpi" display property (and the gnome >> variant..) which we synchronize alrady, but which is blissfully ignored >> by too many applications. >>> You see the size of the text in the menu? Obviously I am going to have to transfer DPI info to xpra from the host. How should I go about doing that? >> We already do that automatically, see the "wanted 96x96" in the log >> sample above, this should match your client's settings. >> >> Cheers >> Antoine >>> Thank you, >>> Timothy Hobbs >>> >>> On Mon, Jul 20, 2015 at 09:46:44AM +0700, Antoine Martin wrote: >>>> I think the wiki could do with some improvements with regards to running >>>> xpra with containers (feel free to edit), until then: >>>> * make sure mmap is enabled (and you can even use a trimmed down build >>>> without any video codecs, which is much safer) >>>> * disable compression >>>> The performance should be very close to native, if not then something is >>>> not setup right. >>>> >>>> Cheers >>>> Antoine >>>> It appears that I have fixed my imediate problem. I was sharing >>>> /tmp/.X11-unix using docker volumes, and I needed to run chmod 1777 >>>> /tmp/.X11-unix on it to get the permissions the way Xorg wants them :) >>>> >>>> Tim >>>> >>>> On Sat, Jul 18, 2015 at 10:08:25PM +0200, Timothy Hobbs wrote: >>>>> Dear list, >>>>> >>>>> I am the creator of subuser.org. Subuser is a free open source software >>>> project (LGPL3) which aims to allow a person to run desktop applications >>>> inside Docker containers. Subuser has several aims. One is to make it >>>> easier to publish desktop applications on linux by improving portability. >>>> Another is to make the desktop more secure by containing those desktop >>>> applications within their respective containers. >>>>> Right now, the seccond goal is not met. Desktop applications communicate >>>> with the host's X11 server by sharing the /tmp/.X11-unix folder with it. >>>> This works well, but is completely insecure. I have been waiting for >>>> wayland to come out in order to provide a secure solution. However, spurred >>>> on by the success of OZ, written by subgraph.com I have begun to reconsider >>>> xpra as an intermediate option. >>>>> As I want to maintain portability and ease of creating subuser Docker >>>> images, I do not wish to install the xpra server in each Docker image which >>>> contains a desktop application. In order to maintain this sepparation of >>>> requirements, I have come up with the following architecture involving 3 >>>> containers: >>>>> ------------- ------------- >>>>> |desktop app| <--/tmp/.X11-unix--> |xpra server| Untrusted >>>>> ------------- ------------- >>>>> ^ >>>>> | ~/.xpra >>>>> v >>>>> ------------- ------------- >>>>> | host | <--/tmp/.X11-unix--> |xpra client| Trusted >>>>> ------------- ------------- >>>>> >>>>> This allows me to run 3 containers. >>>>> >>>>> 1) contains the untrusted desktop application >>>>> 2) contains an untrusted xpra server >>>>> 3) contains a trusted xpra client >>>>> >>>>> I can use an up-to-date version of xpra, as I do not need to have xpra >>>> installed on the host. >>>>> The only problem, is that when I run >>>>> >>>>> $ xpra start :100 --start-child=xterm >>>>> >>>>> I don't end up with a unix domain socket in the xpra server's >>>> /tmp/.X11-unix directory. This is despite the fact that I have -nolisten >>>> tcp set in xpra.conf: >>>>> xvfb=Xorg -dpi 96 -noreset -nolisten tcp +extension GLX +extension RANDR >>>> +extension RENDER -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -config >>>> /etc/xpra/xorg.conf >>>>> I am confused as to why this is happening, and how I can get a unix >>>> domain socket to work with. I cannot use a UDP socket due to the >>>> difficulties of sharing UDP sockets between containers. >>>>> I have been testing this settup on xpra version 0.14.10 >>>>> >>>>> Thank you in advance for your help, >>>>> >>>>> Timothy Hobbs >>>>> _______________________________________________ >>>>> 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 Mon Aug 3 06:36:26 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 3 Aug 2015 12:36:26 +0700 Subject: [winswitch] [ANNOUNCE] [LTS] xpra 0.14.28 (many important fixes) Message-ID: <55BEFDDA.9050600@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This update fixes a very large number of bugs, some of which are important. Updating is strongly recommended. A fair proportion of these bug fixes are platform or packaging related, or they only trigger under specific settings. We will try to cover more platforms during testing in the future. In particular, testing printing, OpenGL and NVENC on actual systems running Debian or Ubuntu, since many errors did not manifest themselves when running virtualized. 0.14.28 release notes: * fix delta compression errors * fix application deadlocks on exit * fix invalid X11 atom * fix csc Cython red and blue colours swapped on little endian systems * fix byteswapping fallback code * fix unhandled failure code from libav * fix cleanup error on MS Windows, preventing process termination * fix OpenGL paint early errors * fix pulseaudio device count reported * fix timer warnings in GTK2 notifier (mostly used on OSX) * fix Xorg path detection for Fedora 22 onwards * fix invalid list of output colorspaces with x264 * fix bug report tool window so it can be used more than once * fix bug report tool log file error with Vista onwards * fix bug report screenshots on MS Windows with multiple screens * fix shadow mode on MS Windows with multiple screens * fix OpenCL platform selection override * fix Python3 Pillow encoding level (must be an integer) * fix capture of subprocesses return code * fix Xvfb dependencies for Ubuntu * fix client error if built without webp support * updated dependency list for Debian and Ubuntu distros * safer x264 API initialization call * safer lz4 version checking code * don't require a nonsensical display name on OSX and win32 * workaround invalid "help" options in config files * ensure any client decoding errors cause a window refresh * more helpful dpi warning * remove unused remnants of nvenc * more reliable and clean shutdown of connections and threads * skip sending invalid packet to client for the "name" control command * MS Windows build environment cleanup 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEUEARECAAYFAlW+/dcACgkQGK2zHPGK1rvhygCVEpRIkKc8uwFu16hXLHUNDGIT PwCeJIvIIDNZ6hy/szMiepLlj1UvN1Y= =bnCh -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Mon Aug 3 06:41:37 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 3 Aug 2015 12:41:37 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.15.4 (many important fixes) Message-ID: <55BEFF11.2010400@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Just like the 0.14.28 preceding it, this update fixes a large number of bugs, some of which are important. Updating is strongly recommended. Since many of the fixes are the same as 0.14.28, I will only include the fixes which are specific to 0.15.4, you can find the full list here: http://xpra.org/trac/browser/xpra/tags/v0.15.x/src/NEWS?rev=10209 * fix VP8 and VP9 performance when speed command line option is used * fix NVENC on cards with over 4GB of RAM * fix sound communication errors not causing subprocess termination * fix OpenCL csc module with Python3 * fix ldconfig warning on Debian and Ubuntu * fix warnings with X11 desktop environments without virtual desktops * fix use of deprecated ffmpeg enum names * include the CUDA pre-compiled kernels on Debian / Ubuntu (NVENC) * packaging fixes for printing on Debian / Ubuntu * don't require a nonsensical display name on OSX and win32 * safer OpenGL platform checks (prevents crashes with wine) * safer NVENC API call * MS Windows build environment cleanup * Fedora: update PyOpenGL package dependency 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlW+/xEACgkQGK2zHPGK1rsJpACfQvr+6lTCOSJQTU6gq+vY5hEi /5UAn1RUEw7ffYs1y18boaZ3H8O+MbT/ =kvkv -----END PGP SIGNATURE----- From fhenryco at yahoo.fr Thu Aug 13 14:48:57 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Thu, 13 Aug 2015 13:48:57 +0000 (UTC) Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes) In-Reply-To: <55A53D9D.3020204@nagafix.co.uk> References: <55A53D9D.3020204@nagafix.co.uk> Message-ID: <1256596133.4174210.1439473737278.JavaMail.yahoo@mail.yahoo.com> Hello, I'm not sure sending to the correct mailing list...My first question is: does xpra and winswitch work to provide a ?remote desktop of a virtual machine?In my case it's a kubuntu VM (virtualbox in another linux host system) and i successfully installed xpra and winswitch both server and client side which is also an ubuntu 14.04 remote system (it's just for testing purpose). ?i just apt-get installed the xpra and winswitch versions available in ubuntu , is that all right or should i really?follow the instructions here to add the repositories? : ?Window Switch - Debian Repository | ? | | ? | | ? | ? | ? | ? | ? | | Window Switch - Debian RepositoryWindow Switch Debian and Ubuntu Downloads: instructions for downloading and installing window switch on you Debian or Ubuntu operating system using our repository | | | | Afficher sur wins... | Aper?u par Yahoo | | | | ? | thanks in advance Fred Le Mardi 14 juillet 2015 18h49, Antoine Martin a ?crit : On 14/07/15 20:53, Douglas Doole wrote: > Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The DEBs have just landed now. Thanks for the reminder! Antoine > > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin > wrote: > > Hi, > > This update fixes a fair number of minor issues, none of which are > really critical, but updating is recommended nonetheless. > > There is also one "new" feature, which is unusual for a stable update, > that's because the feature is both very unlikely to interfere with > anything (10 lines of code) and very useful for running in containers. > You can now connect to a socket directly by name, ie: > xpra attach socket:/path/to/hostname-$DISPLAY > > > 0.15.3 release notes: > * fix invalid X11 atom > * fix unhandled failure code from libav > * fix default socket permissions when config file is missing > * fix error handling for missing cuda kernels > * fix OpenGL paint early errors > * fix "print" control command with multiple clients > * skip sending invalid packet to client for the "name" control command > * more helpful dpi warning > * support connecting to named unix domain sockets > * OpenGL option can force enable despite platform checks > * replace unsafe deprecated API call in HTML5 client > * more reliable and clean shutdown of connections and threads > * log internal system failures as errors > > 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 >? ? _______________________________________________ >? ? 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 fhenryco at yahoo.fr Thu Aug 13 15:36:46 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Thu, 13 Aug 2015 14:36:46 +0000 (UTC) Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes) In-Reply-To: <1256596133.4174210.1439473737278.JavaMail.yahoo@mail.yahoo.com> References: <1256596133.4174210.1439473737278.JavaMail.yahoo@mail.yahoo.com> Message-ID: <311901651.4244301.1439476607069.JavaMail.yahoo@mail.yahoo.com> OK, thanks, ?so i have to wait for the upgrade... ?so far, my two winswitches on two distant ubuntus dont see each other as these should through mdns (without any need for configuration) as far as i have understood . But may be this is because virtualbox VMs are designed to communicate only through RDP or VNC on the appropriate port (i opened 5010 on my firewall and could connect to it using rdesktop) , this is the naive question i was asking to myself...any comment on that ? Fred Le Jeudi 13 ao?t 2015 15h49, Fr?d?ric Henry-Couannier a ?crit : Hello, I'm not sure sending to the correct mailing list...My first question is: does xpra and winswitch work to provide a ?remote desktop of a virtual machine?In my case it's a kubuntu VM (virtualbox in another linux host system) and i successfully installed xpra and winswitch both server and client side which is also an ubuntu 14.04 remote system (it's just for testing purpose). ?i just apt-get installed the xpra and winswitch versions available in ubuntu , is that all right or should i really?follow the instructions here to add the repositories? : ?Window Switch - Debian Repository | ? | | ? |? | ? | ? | ? | ? | ? | | Window Switch - Debian RepositoryWindow Switch Debian and Ubuntu Downloads: instructions for downloading and installing window switch on you Debian or Ubuntu operating system using our repository | |? | | Afficher sur wins... | Aper?u par Yahoo | |? | | ? | thanks in advance Fred ? ? Le Mardi 14 juillet 2015 18h49, Antoine Martin a ?crit : ? On 14/07/15 20:53, Douglas Doole wrote: > Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The DEBs have just landed now. Thanks for the reminder! Antoine > > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin > wrote: > > Hi, > > This update fixes a fair number of minor issues, none of which are > really critical, but updating is recommended nonetheless. > > There is also one "new" feature, which is unusual for a stable update, > that's because the feature is both very unlikely to interfere with > anything (10 lines of code) and very useful for running in containers. > You can now connect to a socket directly by name, ie: > xpra attach socket:/path/to/hostname-$DISPLAY > > > 0.15.3 release notes: > * fix invalid X11 atom > * fix unhandled failure code from libav > * fix default socket permissions when config file is missing > * fix error handling for missing cuda kernels > * fix OpenGL paint early errors > * fix "print" control command with multiple clients > * skip sending invalid packet to client for the "name" control command > * more helpful dpi warning > * support connecting to named unix domain sockets > * OpenGL option can force enable despite platform checks > * replace unsafe deprecated API call in HTML5 client > * more reliable and clean shutdown of connections and threads > * log internal system failures as errors > > 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 >? ? _______________________________________________ >? ? 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 fhenryco at yahoo.fr Fri Aug 14 09:54:36 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Fri, 14 Aug 2015 08:54:36 +0000 (UTC) Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes) In-Reply-To: <311901651.4244301.1439476607069.JavaMail.yahoo@mail.yahoo.com> References: <311901651.4244301.1439476607069.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1809344330.4621534.1439542477018.JavaMail.yahoo@mail.yahoo.com> Eventually i managed to get the video remotely from my virtualbox ubuntu but using xpra commands (not windows switch GUI) but couldnt get any remote sound yet (though sound is audible on the server ) ... i got lost in?Sound ? Xpra | ? | | ? | | ? | ? | ? | ? | ? | | Sound ? Xpraxpra - screen for X | | | | Afficher sur ww... | Aper?u par Yahoo | | | | ? | Le Jeudi 13 ao?t 2015 16h36, Fr?d?ric Henry-Couannier a ?crit : OK, thanks, ?so i have to wait for the upgrade... ?so far, my two winswitches on two distant ubuntus dont see each other as these should through mdns (without any need for configuration) as far as i have understood . But may be this is because virtualbox VMs are designed to communicate only through RDP or VNC on the appropriate port (i opened 5010 on my firewall and could connect to it using rdesktop) , this is the naive question i was asking to myself...any comment on that ? Fred Le Jeudi 13 ao?t 2015 15h49, Fr?d?ric Henry-Couannier a ?crit : Hello, I'm not sure sending to the correct mailing list...My first question is: does xpra and winswitch work to provide a ?remote desktop of a virtual machine?In my case it's a kubuntu VM (virtualbox in another linux host system) and i successfully installed xpra and winswitch both server and client side which is also an ubuntu 14.04 remote system (it's just for testing purpose). ?i just apt-get installed the xpra and winswitch versions available in ubuntu , is that all right or should i really?follow the instructions here to add the repositories? : ?Window Switch - Debian Repository | ? | | ? |? | ? | ? | ? | ? | ? | | Window Switch - Debian RepositoryWindow Switch Debian and Ubuntu Downloads: instructions for downloading and installing window switch on you Debian or Ubuntu operating system using our repository | |? | | Afficher sur wins... | Aper?u par Yahoo | |? | | ? | thanks in advance Fred ? ? Le Mardi 14 juillet 2015 18h49, Antoine Martin a ?crit : ? On 14/07/15 20:53, Douglas Doole wrote: > Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The DEBs have just landed now. Thanks for the reminder! Antoine > > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin > wrote: > > Hi, > > This update fixes a fair number of minor issues, none of which are > really critical, but updating is recommended nonetheless. > > There is also one "new" feature, which is unusual for a stable update, > that's because the feature is both very unlikely to interfere with > anything (10 lines of code) and very useful for running in containers. > You can now connect to a socket directly by name, ie: > xpra attach socket:/path/to/hostname-$DISPLAY > > > 0.15.3 release notes: > * fix invalid X11 atom > * fix unhandled failure code from libav > * fix default socket permissions when config file is missing > * fix error handling for missing cuda kernels > * fix OpenGL paint early errors > * fix "print" control command with multiple clients > * skip sending invalid packet to client for the "name" control command > * more helpful dpi warning > * support connecting to named unix domain sockets > * OpenGL option can force enable despite platform checks > * replace unsafe deprecated API call in HTML5 client > * more reliable and clean shutdown of connections and threads > * log internal system failures as errors > > 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 >? ? _______________________________________________ >? ? 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 Aug 14 12:50:41 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 14 Aug 2015 18:50:41 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes) In-Reply-To: <1256596133.4174210.1439473737278.JavaMail.yahoo@mail.yahoo.com> References: <55A53D9D.3020204@nagafix.co.uk> <1256596133.4174210.1439473737278.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55CDD611.9010906@nagafix.co.uk> On 13/08/15 20:48, Fr?d?ric Henry-Couannier wrote: > Hello, > > I'm not sure sending to the correct mailing list... > My first question is: does xpra and winswitch work to provide a > remote desktop of a virtual machine? > In my case it's a kubuntu VM (virtualbox in another linux host system) > and i successfully installed xpra and winswitch both server and client > side which is also an ubuntu 14.04 remote system (it's just for > testing purpose). Some distributions like Ubuntu ship outdated versions for which there is no support here or elsewhere, for details see: http://xpra.org/trac/wiki/Packaging > > i just apt-get installed the xpra and winswitch versions available in > ubuntu , is that all right or should i really > follow the instructions here to add the repositories? : These repositories are supported here. Cheers Antoine > > Window Switch - Debian Repository > > > > > image > > > > > > > > > > > > Window Switch - Debian Repository > > > Window Switch Debian and Ubuntu Downloads: instructions for > downloading and installing window switch on you Debian or Ubuntu > operating system using our repository > > Afficher sur wins... > > > Aper?u par Yahoo > > > > > thanks in advance > > Fred > > > > Le Mardi 14 juillet 2015 18h49, Antoine Martin > a ?crit : > > > On 14/07/15 20:53, Douglas Doole wrote: > > Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The > DEBs have just landed now. > Thanks for the reminder! > > Antoine > > > > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin > > >> wrote: > > > Hi, > > > > This update fixes a fair number of minor issues, none of which are > > really critical, but updating is recommended nonetheless. > > > > There is also one "new" feature, which is unusual for a stable update, > > that's because the feature is both very unlikely to interfere with > > anything (10 lines of code) and very useful for running in containers. > > You can now connect to a socket directly by name, ie: > > xpra attach socket:/path/to/hostname-$DISPLAY > > > > > > 0.15.3 release notes: > > * fix invalid X11 atom > > * fix unhandled failure code from libav > > * fix default socket permissions when config file is missing > > * fix error handling for missing cuda kernels > > * fix OpenGL paint early errors > > * fix "print" control command with multiple clients > > * skip sending invalid packet to client for the "name" control command > > * more helpful dpi warning > > * support connecting to named unix domain sockets > > * OpenGL option can force enable despite platform checks > > * replace unsafe deprecated API call in HTML5 client > > * more reliable and clean shutdown of connections and threads > > * log internal system failures as errors > > > > 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 > > _______________________________________________ > > 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 Aug 14 12:52:36 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 14 Aug 2015 18:52:36 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes) In-Reply-To: <311901651.4244301.1439476607069.JavaMail.yahoo@mail.yahoo.com> References: <1256596133.4174210.1439473737278.JavaMail.yahoo@mail.yahoo.com> <311901651.4244301.1439476607069.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55CDD684.3070900@nagafix.co.uk> On 13/08/15 21:36, Fr?d?ric Henry-Couannier wrote: > OK, thanks, so i have to wait for the upgrade... so far, my two > winswitches on two distant ubuntus dont see each other as these should > through mdns (without any need for configuration) as far as i have > understood . But may be this is because virtualbox VMs are designed to > communicate only through RDP or VNC on the appropriate port (i opened > 5010 on my firewall and could connect to it using rdesktop) , this is > the naive question i was asking to myself...any comment on that ? Whether you run xpra or winswitch on bare metal or in a virtual machine should not make any difference. That said, if you want to use mdns then you must configure your VM to allow such traffic through (ie: use bridge networking with VirtualBox) Cheers Antoine > > Fred > > > > Le Jeudi 13 ao?t 2015 15h49, Fr?d?ric Henry-Couannier > a ?crit : > > > Hello, > I'm not sure sending to the correct mailing list...My first question > is: does xpra and winswitch work to provide a remote desktop of a > virtual machine?In my case it's a kubuntu VM (virtualbox in another > linux host system) and i successfully installed xpra and winswitch > both server and client side which is also an ubuntu 14.04 remote > system (it's just for testing purpose). > i just apt-get installed the xpra and winswitch versions available in > ubuntu , is that all right or should i really follow the instructions > here to add the repositories? : > Window Switch - Debian Repository > | | > | | | | | | | | > | Window Switch - Debian RepositoryWindow Switch Debian and Ubuntu > Downloads: instructions for downloading and installing window switch > on you Debian or Ubuntu operating system using our repository | > | | > | Afficher sur wins... | Aper?u par Yahoo | > | | > | | > > > thanks in advance > Fred > > > Le Mardi 14 juillet 2015 18h49, Antoine Martin > > a ?crit : > > > On 14/07/15 20:53, Douglas Doole wrote: > > Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The > DEBs have just landed now. > Thanks for the reminder! > > Antoine > > > > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin > > >> wrote: > > > Hi, > > > > This update fixes a fair number of minor issues, none of which are > > really critical, but updating is recommended nonetheless. > > > > There is also one "new" feature, which is unusual for a stable update, > > that's because the feature is both very unlikely to interfere with > > anything (10 lines of code) and very useful for running in containers. > > You can now connect to a socket directly by name, ie: > > xpra attach socket:/path/to/hostname-$DISPLAY > > > > > > 0.15.3 release notes: > > * fix invalid X11 atom > > * fix unhandled failure code from libav > > * fix default socket permissions when config file is missing > > * fix error handling for missing cuda kernels > > * fix OpenGL paint early errors > > * fix "print" control command with multiple clients > > * skip sending invalid packet to client for the "name" control command > > * more helpful dpi warning > > * support connecting to named unix domain sockets > > * OpenGL option can force enable despite platform checks > > * replace unsafe deprecated API call in HTML5 client > > * more reliable and clean shutdown of connections and threads > > * log internal system failures as errors > > > > 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 > > _______________________________________________ > > 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 fhenryco at yahoo.fr Sat Aug 15 13:26:24 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Sat, 15 Aug 2015 12:26:24 +0000 (UTC) Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes) In-Reply-To: <55CDD684.3070900@nagafix.co.uk> References: <55CDD684.3070900@nagafix.co.uk> Message-ID: <100571517.5241413.1439641584711.JavaMail.yahoo@mail.yahoo.com> Thanks and congratulation to the team for their work, ?clearly better performances than rdesktop on a LAN, ?i guess some sound stuttering in 720p is due to my limitation in bandwidth (100 Mb/s) and would disapear with a Gbit/s link ... i'v just noticed there is also a version for raspberry pi ... gonna test it ?;-) Le Vendredi 14 ao?t 2015 13h52, Antoine Martin a ?crit : On 13/08/15 21:36, Fr?d?ric Henry-Couannier wrote: OK, thanks, ?so i have to wait for the upgrade... ?so far, my two winswitches on two distant ubuntus dont see each other as these should through mdns (without any need for configuration) as far as i have understood . But may be this is because virtualbox VMs are designed to communicate only through RDP or VNC on the appropriate port (i opened 5010 on my firewall and could connect to it using rdesktop) , this is the naive question i was asking to myself...any comment on that ? Whether you run xpra or winswitch on bare metal or in a virtual machine should not make any difference. That said, if you want to use mdns then you must configure your VM to allow such traffic through (ie: use bridge networking with VirtualBox) Cheers Antoine Fred Le Jeudi 13 ao?t 2015 15h49, Fr?d?ric Henry-Couannier a ?crit : Hello, I'm not sure sending to the correct mailing list...My first question is: does xpra and winswitch work to provide a ?remote desktop of a virtual machine?In my case it's a kubuntu VM (virtualbox in another linux host system) and i successfully installed xpra and winswitch both server and client side which is also an ubuntu 14.04 remote system (it's just for testing purpose). ?i just apt-get installed the xpra and winswitch versions available in ubuntu , is that all right or should i really?follow the instructions here to add the repositories? : ?Window Switch - Debian Repository | ? | | ? |? | ? | ? | ? | ? | ? | | Window Switch - Debian RepositoryWindow Switch Debian and Ubuntu Downloads: instructions for downloading and installing window switch on you Debian or Ubuntu operating system using our repository | |? | | Afficher sur wins... | Aper?u par Yahoo | |? | | ? | thanks in advance Fred ? ? Le Mardi 14 juillet 2015 18h49, Antoine Martin a ?crit : ? On 14/07/15 20:53, Douglas Doole wrote: > Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The DEBs have just landed now. Thanks for the reminder! Antoine > > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin > wrote: > > Hi, > > This update fixes a fair number of minor issues, none of which are > really critical, but updating is recommended nonetheless. > > There is also one "new" feature, which is unusual for a stable update, > that's because the feature is both very unlikely to interfere with > anything (10 lines of code) and very useful for running in containers. > You can now connect to a socket directly by name, ie: > xpra attach socket:/path/to/hostname-$DISPLAY > > > 0.15.3 release notes: > * fix invalid X11 atom > * fix unhandled failure code from libav > * fix default socket permissions when config file is missing > * fix error handling for missing cuda kernels > * fix OpenGL paint early errors > * fix "print" control command with multiple clients > * skip sending invalid packet to client for the "name" control command > * more helpful dpi warning > * support connecting to named unix domain sockets > * OpenGL option can force enable despite platform checks > * replace unsafe deprecated API call in HTML5 client > * more reliable and clean shutdown of connections and threads > * log internal system failures as errors > > 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 >? ? _______________________________________________ >? ? 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 fhenryco at yahoo.fr Sun Aug 16 09:45:11 2015 From: fhenryco at yahoo.fr (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Henry-Couannier?=) Date: Sun, 16 Aug 2015 08:45:11 +0000 (UTC) Subject: [winswitch] [ANNOUNCE] xpra 0.15.3 (minor fixes) In-Reply-To: <100571517.5241413.1439641584711.JavaMail.yahoo@mail.yahoo.com> References: <100571517.5241413.1439641584711.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1673128358.5474664.1439714711027.JavaMail.yahoo@mail.yahoo.com> My LAN generated collisions and was on 100Mb/s, This is now fixed. now youtube perfect in 1080p with sound !! fantastic, congratulations again Le Samedi 15 ao?t 2015 14h26, Fr?d?ric Henry-Couannier a ?crit : Thanks and congratulation to the team for their work, ?clearly better performances than rdesktop on a LAN, ?i guess some sound stuttering in 720p is due to my limitation in bandwidth (100 Mb/s) and would disapear with a Gbit/s link ... i'v just noticed there is also a version for raspberry pi ... gonna test it ?;-) ? ? Le Vendredi 14 ao?t 2015 13h52, Antoine Martin a ?crit : ? ? On 13/08/15 21:36, Fr?d?ric Henry-Couannier wrote: ? ? OK, thanks, ?so i have to wait for the upgrade... ?so far, my two winswitches on two distant ubuntus dont see each other as these should through mdns (without any need for configuration) as far as? i have understood . But may be this is because virtualbox VMs are designed to communicate only through RDP or VNC on the appropriate port (i opened 5010 on my firewall and could connect to it using rdesktop) , this is the naive question i was asking to myself...any comment on that ?? Whether you run xpra or winswitch on bare metal or in a virtual machine should not make any difference. That said, if you want to use mdns then you must configure your VM to allow such traffic through (ie: use bridge networking with VirtualBox) Cheers Antoine ? ? Fred ? ? ? Le Jeudi 13 ao?t 2015 15h49, Fr?d?ric Henry-Couannier a ?crit : ? Hello, I'm not sure sending to the correct mailing list...My first question is: does xpra and winswitch work to provide a ?remote desktop of a virtual machine?In my case it's a kubuntu VM (virtualbox in another linux host system) and i successfully installed xpra and winswitch both server and client side which is also an ubuntu 14.04 remote system (it's just for testing purpose). ?i just apt-get installed the xpra and winswitch versions available in ubuntu , is that all right or should i really?follow the instructions here to add the repositories? : ?Window Switch - Debian Repository | ? | | ? |? | ? | ? | ? | ? | ? | | Window Switch - Debian RepositoryWindow Switch Debian and Ubuntu Downloads: instructions for downloading and installing window switch on you Debian or Ubuntu operating system using our repository | |? | | Afficher sur wins... | Aper?u par Yahoo | |? | | ? | thanks in advance Fred ? ? Le Mardi 14 juillet 2015 18h49, Antoine Martin a ?crit : ? On 14/07/15 20:53, Douglas Doole wrote: > Any idea why this hasn't been pushed out for Ubuntu 14.04 yet? The DEBs have just landed now. Thanks for the reminder! Antoine > > On Sun, Jul 12, 2015 at 11:33 AM Antoine Martin > wrote: > > Hi, > > This update fixes a fair number of minor issues, none of which are > really critical, but updating is recommended nonetheless. > > There is also one "new" feature, which is unusual for a stable update, > that's because the feature is both very unlikely to interfere with > anything (10 lines of code) and very useful for running in containers. > You can now connect to a socket directly by name, ie: > xpra attach socket:/path/to/hostname-$DISPLAY > > > 0.15.3 release notes: > * fix invalid X11 atom > * fix unhandled failure code from libav > * fix default socket permissions when config file is missing > * fix error handling for missing cuda kernels > * fix OpenGL paint early errors > * fix "print" control command with multiple clients > * skip sending invalid packet to client for the "name" control command > * more helpful dpi warning > * support connecting to named unix domain sockets > * OpenGL option can force enable despite platform checks > * replace unsafe deprecated API call in HTML5 client > * more reliable and clean shutdown of connections and threads > * log internal system failures as errors > > 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 >? ? _______________________________________________ >? ? 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 frtrack-winswitch at yahoo.com Tue Aug 18 08:35:35 2015 From: frtrack-winswitch at yahoo.com (Fabian Ritzmann) Date: Tue, 18 Aug 2015 07:35:35 +0000 (UTC) Subject: [winswitch] Cannot verify email address in Trac Message-ID: <1290460518.6582997.1439883335092.JavaMail.yahoo@mail.yahoo.com> Hi, I tried to create a Trac account here and it asked me to verify my email address. I haven't received any verification emails however (and yes, I checked my spam folder). I tried to resend the email a few times through but that didn't help. The email address is working fine otherwise and I am using it for this mailing list. Fabian From frtrack-winswitch at yahoo.com Tue Aug 18 08:49:10 2015 From: frtrack-winswitch at yahoo.com (Fabian Ritzmann) Date: Tue, 18 Aug 2015 07:49:10 +0000 (UTC) Subject: [winswitch] Issue 270: Winswitch unable to connect over ssh from MS Windows to server running openssh 6.7 Message-ID: <292509328.6581415.1439884150487.JavaMail.yahoo@mail.yahoo.com> Hi, Since I am Trac-impaired (see my previous email to this mailing list), I am sending my comments via email. I was trying to connect from a MacBook with Winswitch 0.12.21-r5329 to an Arch Linux server running OpenSSH 7.0p1. The SSH server is refusing the connection with this error message: sshd[20761]: fatal: Unable to negotiate with 10.128.133.54: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth] This looks like the same issue that this Windows user reported in with OpenSSH 6.7. The suggested work-around in the issue is to reenable the DH SHA1 key exchange, which I don't consider an option because it compromises security and exposes the host to the Logjam attack. I would hope that this issue gets more traction because it is an issue with any secure installation of OpenSSH and not specific to the Windows Winswitch client. Fabian From antoine at nagafix.co.uk Tue Aug 18 09:38:41 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 18 Aug 2015 15:38:41 +0700 Subject: [winswitch] Issue 270: Winswitch unable to connect over ssh from MS Windows to server running openssh 6.7 In-Reply-To: <292509328.6581415.1439884150487.JavaMail.yahoo@mail.yahoo.com> References: <292509328.6581415.1439884150487.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55D2EF11.7070309@nagafix.co.uk> On 18/08/15 14:49, Fabian Ritzmann wrote: > Hi, > > Since I am Trac-impaired (see my previous email to this mailing list), I am sending my comments via email. I was trying to connect from a MacBook with Winswitch 0.12.21-r5329 to an Arch Linux server running OpenSSH 7.0p1. The SSH server is refusing the connection with this error message: > > sshd[20761]: fatal: Unable to negotiate with 10.128.133.54: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth] > > This looks like the same issue that this Windows user reported in with OpenSSH 6.7. The suggested work-around in the issue is to reenable the DH SHA1 key exchange, which I don't consider an option because it compromises security and exposes the host to the Logjam attack. > > I would hope that this issue gets more traction because it is an issue with any secure installation of OpenSSH and not specific to the Windows Winswitch client. Until this issue is fixed in Twisted conch (the SSH layer), there is absolutely nothing we can do about it. Here's the more recent upstream ticket: http://twistedmatrix.com/trac/ticket/7717 Cheers Antoine > > Fabian > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From frtrack-winswitch at yahoo.com Tue Aug 18 10:46:08 2015 From: frtrack-winswitch at yahoo.com (Fabian Ritzmann) Date: Tue, 18 Aug 2015 09:46:08 +0000 (UTC) Subject: [winswitch] Issue 270: Winswitch unable to connect over ssh from MS Windows to server running openssh 6.7 In-Reply-To: <55D2EF11.7070309@nagafix.co.uk> References: <55D2EF11.7070309@nagafix.co.uk> Message-ID: <764417360.6657150.1439891168173.JavaMail.yahoo@mail.yahoo.com> Antoine Martin schrieb am 11:38 Dienstag, 18.August 2015: >On 18/08/15 14:49, Fabian Ritzmann wrote: >> Hi, >> >> Since I am Trac-impaired (see my previous email to this mailing list), I am sending my comments via email. I was trying to connect from a MacBook with Winswitch 0.12.21-r5329 to an Arch Linux >server running OpenSSH 7.0p1. The SSH server is refusing the connection with this error message: >> >> sshd[20761]: fatal: Unable to negotiate with 10.128.133.54: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 [preauth] >> >> This looks like the same issue that this Windows user reported in with OpenSSH 6.7. The suggested work-around in the issue is to reenable the DH SHA1 >key exchange, which I don't consider an option because it compromises security and exposes the host to the Logjam attack. >> >> I would hope that this issue gets more traction because it is an issue with any secure installation of OpenSSH and not specific to the Windows Winswitch client. >Until this issue is fixed in Twisted conch (the SSH layer), there is >absolutely nothing we can do about it. >Here's the more recent upstream ticket: >http://twistedmatrix.com/trac/ticket/7717 Thanks. Considering the age of that issue I better don't hold my breath. I guess I'll try creating a SSH tunnel manually and then connect the client to localhost. Fabian From johnss1221 at gmail.com Fri Aug 21 09:07:53 2015 From: johnss1221 at gmail.com (John Smith) Date: Fri, 21 Aug 2015 15:07:53 +0700 Subject: [winswitch] [xpra 0.15.4-1] Bugs in Firefox, Chrome and some questions Message-ID: Hi, I'm running xpra 0.15.4-1(r10209) for both server(Trusty) and client( Win 7 64bit). Recently using xpra, I found some bugs: 1. Firefox bug: + From server: start xpra with cmd: xpra start :100 --start-child=firefox --bind-tcp=0.0.0.0:10000 + From client: attach xpra with cmd: xpra attach tcp:IP:10000 + Now the Firefox window is opened and focused. The maximize button from titlebar is disabled. + Then if we make the Firefox window lost focus and refocus => The maximize button is enabled now. 2. Chrome bug: + Ticket: http://xpra.org/trac/ticket/771 + I think this bug is reappeared at the current version. And I remembered that xpra version 0.14.x could make the Chrome window resize by repaint a new titlebar. So, can we have an option to repaint or not the Chrome window titlebar? Thanks :) From antoine at nagafix.co.uk Fri Aug 21 10:49:05 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 21 Aug 2015 16:49:05 +0700 Subject: [winswitch] [xpra 0.15.4-1] Bugs in Firefox, Chrome and some questions In-Reply-To: References: Message-ID: <55D6F411.2010608@nagafix.co.uk> On 21/08/15 15:07, John Smith wrote: > Hi, > > I'm running xpra 0.15.4-1(r10209) for both server(Trusty) and client( Win 7 > 64bit). > Recently using xpra, I found some bugs: > 1. Firefox bug: > + From server: start xpra with cmd: xpra start :100 --start-child=firefox > --bind-tcp=0.0.0.0:10000 > + From client: attach xpra with cmd: xpra attach tcp:IP:10000 > + Now the Firefox window is opened and focused. The maximize button from > titlebar is disabled. > + Then if we make the Firefox window lost focus and refocus => The > maximize button is enabled now. Can you please file a ticket for this one? > 2. Chrome bug: > + Ticket: http://xpra.org/trac/ticket/771 > + I think this bug is reappeared at the current version. > And I remembered that xpra version 0.14.x could make the Chrome window > resize by repaint a new titlebar. So, can we have an option to repaint or > not the Chrome window titlebar? I'm not sure I understand: this ticket is about covering the taskbar when maximizing. If that's this problem has re-appeared then this ticket needs to be re-opened. Cheers Antoine > Thanks :) > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From johnss1221 at gmail.com Fri Aug 21 11:12:27 2015 From: johnss1221 at gmail.com (John Smith) Date: Fri, 21 Aug 2015 17:12:27 +0700 Subject: [winswitch] [xpra 0.15.4-1] Bugs in Firefox, Chrome and some questions In-Reply-To: <55D6F411.2010608@nagafix.co.uk> References: <55D6F411.2010608@nagafix.co.uk> Message-ID: Hi, > > > I'm running xpra 0.15.4-1(r10209) for both server(Trusty) and client( > Win 7 > > 64bit). > > Recently using xpra, I found some bugs: > > 1. Firefox bug: > > + From server: start xpra with cmd: xpra start :100 > --start-child=firefox > > --bind-tcp=0.0.0.0:10000 > > + From client: attach xpra with cmd: xpra attach tcp:IP:10000 > > + Now the Firefox window is opened and focused. The maximize button > from > > titlebar is disabled. > > + Then if we make the Firefox window lost focus and refocus => The > > maximize button is enabled now. > Can you please file a ticket for this one? > I will :) > > 2. Chrome bug: > > + Ticket: http://xpra.org/trac/ticket/771 > > + I think this bug is reappeared at the current version. > > And I remembered that xpra version 0.14.x could make the Chrome window > > resize by repaint a new titlebar. So, can we have an option to repaint or > > not the Chrome window titlebar? > I'm not sure I understand: this ticket is about covering the taskbar > when maximizing. > If that's this problem has re-appeared then this ticket needs to be > re-opened. > I have 2 problems about Chrome. First problem is about covering the taskbar when maximizing, and yes, this problem has re-appeared. And the second, I mentioned about xpra version 0.14.x ( I chose 0.14.13). If running xpra version 0.14.x, I can resize the Chrome window. Because xpra server repaint ( or add, or something like that ) a title bar at the top of the Chrome window. This title bar is already added to the Chrome window. It just removed after file this ticket . Sorry about my English. > > 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 > From johnss1221 at gmail.com Fri Aug 21 11:23:51 2015 From: johnss1221 at gmail.com (John Smith) Date: Fri, 21 Aug 2015 17:23:51 +0700 Subject: [winswitch] [xpra 0.15.4-1] Bugs in Firefox, Chrome and some questions In-Reply-To: References: <55D6F411.2010608@nagafix.co.uk> Message-ID: > >> > I'm running xpra 0.15.4-1(r10209) for both server(Trusty) and client( >> Win 7 >> > 64bit). >> > Recently using xpra, I found some bugs: >> > 1. Firefox bug: >> > + From server: start xpra with cmd: xpra start :100 >> --start-child=firefox >> > --bind-tcp=0.0.0.0:10000 >> > + From client: attach xpra with cmd: xpra attach tcp:IP:10000 >> > + Now the Firefox window is opened and focused. The maximize button >> from >> > titlebar is disabled. >> > + Then if we make the Firefox window lost focus and refocus => The >> > maximize button is enabled now. >> Can you please file a ticket for this one? > > I've just filed this ticket From johnss1221 at gmail.com Mon Aug 24 01:57:14 2015 From: johnss1221 at gmail.com (John Smith) Date: Mon, 24 Aug 2015 07:57:14 +0700 Subject: [winswitch] [xpra 0.15.4-1] Bugs in Firefox, Chrome and some questions In-Reply-To: References: <55D6F411.2010608@nagafix.co.uk> Message-ID: > > > 2. Chrome bug: >> > + Ticket: http://xpra.org/trac/ticket/771 >> > + I think this bug is reappeared at the current version. >> > And I remembered that xpra version 0.14.x could make the Chrome window >> > resize by repaint a new titlebar. So, can we have an option to repaint >> or >> > not the Chrome window titlebar? >> I'm not sure I understand: this ticket is about covering the taskbar >> when maximizing. >> If that's this problem has re-appeared then this ticket needs to be >> re-opened. >> > I have 2 problems about Chrome. First problem is about covering the > taskbar when maximizing, and yes, this problem has re-appeared. > And the second, I mentioned about xpra version 0.14.x ( I chose 0.14.13). > If running xpra version 0.14.x, I can resize the Chrome window. Because > xpra server repaint ( or add, or something like that ) a title bar at the > top of the Chrome window. This title bar is already added to the Chrome > window. It just removed after file this ticket > . > Sorry about my English. > Do you have any idea about an option ( or an argument) to add/remove a title bar of Chrome ? From thejunk.b at gmail.com Wed Aug 26 16:17:30 2015 From: thejunk.b at gmail.com (Randy) Date: Wed, 26 Aug 2015 11:17:30 -0400 Subject: [winswitch] new kde system tray Message-ID: <42375314.dWZa9FefDt@bumblebee> I reciently had kde 4.15.04.3-1 pushed to my machines in Debian Testing (Stretch) among other issues, like the lib's not being pushed at the same time, winswitch does not dock in the system tray. In fact after launching it, and it does connect to the other instances ok, it never shows up anywhere. "Bummer" So it is quite useless. On a side note, I keep my taskbar docked on the left side of the screen because my laptop has more relestate in width than height. Historaclly when I would click on the winswitch icon on the left the dropdown menu would appear on the very right side of the screen. Somewhat anoying. Could that be fixed when you get the system tray fixed again? Thanks -- If it ain't broke tweek it From thejunk.b at gmail.com Wed Aug 26 16:24:27 2015 From: thejunk.b at gmail.com (Randy) Date: Wed, 26 Aug 2015 11:24:27 -0400 Subject: [winswitch] new kde system tray In-Reply-To: <42375314.dWZa9FefDt@bumblebee> References: <42375314.dWZa9FefDt@bumblebee> Message-ID: <160071623.PB3ulQhk9T@bumblebee> On Wednesday, August 26, 2015 11:17:30 AM you wrote: > I reciently had kde 4.15.04.3-1 pushed to my machines in Debian Testing > (Stretch) among other issues, like the lib's not being pushed at the same > time, winswitch does not dock in the system tray. In fact after launching > it, and it does connect to the other instances ok, it never shows up > anywhere. "Bummer" So it is quite useless. > > On a side note, I keep my taskbar docked on the left side of the screen > because my laptop has more relestate in width than height. Historaclly > when I would click on the winswitch icon on the left the dropdown menu > would appear on the very right side of the screen. Somewhat anoying. > Could that be fixed when you get the system tray fixed again? > > Thanks Oh, I forgot, everthing is installed from deb http://winswitch.org/ jessie main winswitch 0.1221+dfsg-1 xpra 0.15.4-1 -- If it ain't broke tweek it From antoine at nagafix.co.uk Thu Aug 27 07:06:28 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 27 Aug 2015 13:06:28 +0700 Subject: [winswitch] new kde system tray In-Reply-To: <42375314.dWZa9FefDt@bumblebee> References: <42375314.dWZa9FefDt@bumblebee> Message-ID: <55DEA8E4.30907@nagafix.co.uk> On 26/08/15 22:17, Randy wrote: > I reciently had kde 4.15.04.3-1 pushed to my machines in Debian Testing > (Stretch) among other issues, like the lib's not being pushed at the same > time, winswitch does not dock in the system tray. In fact after launching > it, and it does connect to the other instances ok, it never shows up > anywhere. "Bummer" So it is quite useless. For situations like this one (gnome shell and others), you can try the windowed menu alternative: winswitch_applet --window-notray It's not very pretty, but it works. I am afraid I don't have KDE 4.15 installed anywhere, so don't hold your breath for a fix. > On a side note, I keep my taskbar docked on the left side of the screen > because my laptop has more relestate in width than height. Historaclly > when I would click on the winswitch icon on the left the dropdown menu > would appear on the very right side of the screen. Somewhat anoying. > Could that be fixed when you get the system tray fixed again? The code for the system tray used on Linux is found here: http://winswitch.org/trac/browser/trunk/winswitch/ui/statusicon_tray.py And the BaseTray superclass function is in here: http://winswitch.org/trac/browser/trunk/winswitch/ui/tray_util.py#L185 We use the regular gtk.status_icon_position_menu function - aren't other applications affected by this problem? Cheers Antoine > Thanks From thejunk.b at gmail.com Thu Aug 27 12:26:31 2015 From: thejunk.b at gmail.com (Randy) Date: Thu, 27 Aug 2015 07:26:31 -0400 Subject: [winswitch] new kde system tray In-Reply-To: <55DEA8E4.30907@nagafix.co.uk> References: <42375314.dWZa9FefDt@bumblebee> <55DEA8E4.30907@nagafix.co.uk> Message-ID: <5024432.mbOptjqJN3@bumblebee> On Thursday, August 27, 2015 01:06:28 PM Antoine Martin wrote: > On 26/08/15 22:17, Randy wrote: > > I reciently had kde 4.15.04.3-1 pushed to my machines in Debian Testing > > (Stretch) among other issues, like the lib's not being pushed at the same > > time, winswitch does not dock in the system tray. In fact after launching > > it, and it does connect to the other instances ok, it never shows up > > anywhere. "Bummer" So it is quite useless. > > For situations like this one (gnome shell and others), you can try the > windowed menu alternative: > winswitch_applet --window-notray > It's not very pretty, but it works. > Thanks, that makes it useable again. The hplip toolbox also does not doc to the tray as it should on my laptop which has been keep on testing since Wheezy. I have a netbook that also runs testing since Jessie and it is having this same issue since the push. I also have a "new to me" desktop with a fresh install of testing (stretch) which is affected. It has never had less that 4.15 on it. > > I am afraid I don't have KDE 4.15 installed anywhere, so don't hold your > breath for a fix. > > > On a side note, I keep my taskbar docked on the left side of the screen > > > > because my laptop has more relestate in width than height. Historaclly > > when I would click on the winswitch icon on the left the dropdown menu > > would appear on the very right side of the screen. Somewhat anoying. > > Could that be fixed when you get the system tray fixed again? > > The code for the system tray used on Linux is found here: > http://winswitch.org/trac/browser/trunk/winswitch/ui/statusicon_tray.py > And the BaseTray superclass function is in here: > http://winswitch.org/trac/browser/trunk/winswitch/ui/tray_util.py#L185 > We use the regular gtk.status_icon_position_menu function - aren't other > applications affected by this problem? > I don't recall any other application that this happens to, but it may and I am just not aware of it. Not that it should matter but, if I recall correctly I first docked my taskbar on the left but didn't like is so moved it to the right, clear back on wheezy. With the work around above the issue went away because the popup stays where the app window is. I have a second older laptop that also runs testing although kde does not work on it, so it is running lxde, don't know version but it is patched regularly so whatever is in testing is what it will have. Although the system tray applet works as it should, when it is clicked on the popup shows up on the upper right of the screen when the taskbar is docked on the left side of the screen. I also have noted that if I left click the mouse button has to be held down for the popup to stay on the screen, but if I right click it stays in place. I am more than happy to try to debug. My best programming is grade school level bash, so I may not be much of any help with finding the issue by reading the code but I will look through it when I get a chance. > Cheers > Antoine > > > Thanks > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users -- If it ain't broke tweek it From basd1 at fastbk.com Thu Aug 27 17:05:17 2015 From: basd1 at fastbk.com (basd) Date: Thu, 27 Aug 2015 09:05:17 -0700 Subject: [winswitch] new kde system tray In-Reply-To: <55DEA8E4.30907@nagafix.co.uk> References: <42375314.dWZa9FefDt@bumblebee> <55DEA8E4.30907@nagafix.co.uk> Message-ID: <55DF353D.3090901@fastbk.com> This is not specifically a KDE problem. I think it is a change in the freedesktop.org tray specification. For instance, cairo-dock also has the "new" tray system and you can also add the "classic" one. There are several work arounds I have used: 1. add the KDE 3.5 kicker panel to a different screen edge from the plasma one. 2. run cairo dock and add the classic tray. 3. run the standalone tray, I think it is "ktray". There is actually more than one standalone tray that will run on KDE, if you do the search. On 08/26/2015 11:06 PM, Antoine Martin wrote: > I am afraid I don't have KDE 4.15 installed anywhere, so don't hold your > breath for a fix. From thejunk.b at gmail.com Thu Aug 27 22:55:39 2015 From: thejunk.b at gmail.com (Randy) Date: Thu, 27 Aug 2015 17:55:39 -0400 Subject: [winswitch] new kde system tray In-Reply-To: <55DF353D.3090901@fastbk.com> References: <42375314.dWZa9FefDt@bumblebee> <55DEA8E4.30907@nagafix.co.uk> <55DF353D.3090901@fastbk.com> Message-ID: <2764645.QfVgWzFxd0@bumblebee> On Thursday, August 27, 2015 09:05:17 AM basd wrote: > This is not specifically a KDE problem. I think it is a change in the > freedesktop.org tray specification. For instance, cairo-dock also has the > "new" tray system and you can also add the "classic" one. > > There are several work arounds I have used: > > 1. add the KDE 3.5 kicker panel to a different screen edge from the plasma > one. 2. run cairo dock and add the classic tray. > 3. run the standalone tray, I think it is "ktray". There is actually more > than one standalone tray that will run on KDE, if you do the search. > > On 08/26/2015 11:06 PM, Antoine Martin wrote: > > I am afraid I don't have KDE 4.15 installed anywhere, so don't hold your > > breath for a fix. > Not really interested in chewing up more screen realestate by adding more taskbars all over the place just to have access to this app, which I don't use all that much. I can add some information though. I have tried both "alltray", and "kdock", both of which are suppose to take any app and push it to the system tray. Neither one works with the new kde tray. They both make the app window dissapear though. Thanks. -- If it ain't broke tweek it From basd1 at fastbk.com Sat Aug 29 19:04:19 2015 From: basd1 at fastbk.com (basd) Date: Sat, 29 Aug 2015 11:04:19 -0700 Subject: [winswitch] new kde system tray In-Reply-To: <2764645.QfVgWzFxd0@bumblebee> References: <42375314.dWZa9FefDt@bumblebee> <55DEA8E4.30907@nagafix.co.uk> <55DF353D.3090901@fastbk.com> <2764645.QfVgWzFxd0@bumblebee> Message-ID: <55E1F423.9040409@fastbk.com> Understood. But ... none of the alternative solutions I mentioned needs to take up significant real estate: Cairo-Dock -- auto hides on any screen edge. ktray -- small floating window just sufficient to hold the winswitch icon. kde3 kicker -- (a) has manual "hide" buttons, so it can be off-screen except when needed. (b) another option is to make it really short, just the length of the tray (and remove all other widgets), then re-size the plasma panel leaving enough space and put the kicker bar next to the plasma panel. On 08/27/2015 02:55 PM, Randy wrote: > Not really interested in chewing up more screen realestate by adding more > taskbars all over the place just to have access to this app, which I don't use > all that much. From antoine at nagafix.co.uk Mon Aug 31 03:17:07 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 31 Aug 2015 09:17:07 +0700 Subject: [winswitch] [ANNOUNCE] [LTS] xpra 0.14.29 (many fixes) Message-ID: <55E3B923.5020702@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This update fixes many bugs, but none of these issues should be considered critical. Unless you were encountering errors with encryption or with the Cython CSC fallback module (for those that do not have the ffmpeg libraries installed), there is no urgency to update. Release notes: * fix encryption not enabled when pycrypto is missing: error out * fix encryption information leak, free network packets after use * fix authentication plugins * fix latency with many sound codecs: vorbis, flac, opus, speex * fix some subcommands when encryption is enabled * fix spurious errors on closed connections * fix incorrect colours using CSC Cython fallback module * fix size limits on Cython fallback module * fix some invalid Xorg dummy modelines * fix errors in packet layer accounting * fix regression in python-lz4 version guessing code * fix RPM packaging: prefer our private libraries to the system ones * fix pactl output parsing * ship a default configuration file on OSX * show maximum OpenGL texture size in diagnostics and bug reports 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXjuSEACgkQGK2zHPGK1rsUJQCfQgb0dPr/0DxQTugqJ042bj5M +WIAmwaiXPwQFTUf2BNyVioTwB9+mlza =ne6w -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Mon Aug 31 03:23:57 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 31 Aug 2015 09:23:57 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.15.5 (many fixes) Message-ID: <55E3BABD.9000706@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Just like the 0.14.29 updates that precedes it, this update fixes many bugs, but none of these issues should be considered critical. There are also beta 0.16.0 packages available, fixing many more issues still. Release notes: * fix encryption not enabled when pycrypto is missing: error out * fix encryption information leak, free network packets after use * fix authentication plugins * fix latency with many sound codecs: vorbis, flac, opus, speex * fix the desktop naming code (worked by accident) * fix OpenGL errors with windows too big for the driver * fix some subcommands when encryption is enabled * fix spurious errors on closed connections * fix incorrect colours using CSC Cython fallback module * fix size limits on Cython fallback module * fix some invalid Xorg dummy modelines * fix aspect ratio not honoured and associated warnings * fix printing file compression * fix errors in packet layer accounting * fix regression in python-lz4 version guessing code * fix RPM packaging: prefer our private libraries to the system ones * fix pactl output parsing * fix error on Posix desktop environments without virtual desktops * fix unlikely connection closing errors * fix value overflows when unpremultiplying alpha channel * ship a default configuration file on OSX * try not to downscale windows from shadow servers * add vpx-xpra to the RPM dependency list so we get VPX 1.9 support * make it possible to generate the EXE installer without running it * allow the user to remove some atoms from _NET_SUPPORTED * show maximum OpenGL texture size in diagnostics and bug reports * minor python3 fixes 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlXjur0ACgkQGK2zHPGK1rskoACfQOKT2RtNCmXas5gAgtXxYfnX PigAn1k6EfFbyNCqAOTyjKGg6Yq5i3CK =klX2 -----END PGP SIGNATURE----- From thejunk.b at gmail.com Mon Aug 31 12:23:06 2015 From: thejunk.b at gmail.com (Randy) Date: Mon, 31 Aug 2015 07:23:06 -0400 Subject: [winswitch] gpg error Message-ID: <5322077.B5CKLRomjr@bumblebee> The checksums on the packages in the Debian Stretch repos are bad W: GPG error: http://winswitch.org stretch Release: The following signatures were invalid: -- If it ain't broke tweek it From thejunk.b at gmail.com Mon Aug 31 12:26:18 2015 From: thejunk.b at gmail.com (Randy) Date: Mon, 31 Aug 2015 07:26:18 -0400 Subject: [winswitch] gpg error In-Reply-To: <5322077.B5CKLRomjr@bumblebee> References: <5322077.B5CKLRomjr@bumblebee> Message-ID: <1562519.tBXoKVBuYo@bumblebee> Interesting that this only seems to affect one of my machines, an older laptap On Monday, August 31, 2015 07:23:06 AM you wrote: > The checksums on the packages in the Debian > Stretch repos are bad > > W: GPG error: http://winswitch.org stretch > Release: The following signatures were invalid: -- If it ain't broke tweek it