[winswitch] Xpra Xorg launch sequence: using a unix domain socket in /tmp/.X11-unix
Timothy Hobbs
timothy at hobbs.cz
Sun Aug 2 19:23:00 BST 2015
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
More information about the shifter-users
mailing list