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
>>>>> [email protected]
>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>> _______________________________________________
>>>> shifter-users mailing list
>>>> [email protected]
>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>> _______________________________________________
>>> shifter-users mailing list
>>> [email protected]
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>
>> _______________________________________________
>> shifter-users mailing list
>> [email protected]
>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users


_______________________________________________
shifter-users mailing list
[email protected]
http://lists.devloop.org.uk/mailman/listinfo/shifter-users

Reply via email to