From antoine at nagafix.co.uk  Tue Nov  1 10:33:53 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Tue, 1 Nov 2016 17:33:53 +0700
Subject: [winswitch] detecting an attempt by an app to open a window
In-Reply-To: <1058164867.1321515.1477930364097@mail.yahoo.com>
References: <1531410526.2179985.1476217710791.ref@mail.yahoo.com>
 <1531410526.2179985.1476217710791@mail.yahoo.com>
 <1890c3e5-aa39-d286-61a7-b99ccf55adff@nagafix.co.uk>
 <1017135595.846463.1477689487838@mail.yahoo.com>
 <bd787fa2-2c46-87b5-7b23-2803d514503a@nagafix.co.uk>
 <1058164867.1321515.1477930364097@mail.yahoo.com>
Message-ID: <0fc5c71d-4bf2-9218-58ee-99df50bb1dad@nagafix.co.uk>

On 31/10/16 23:12, Mukul Agrawal wrote:
> Thanks Antoine.
> 
> Basically, I want to detect if user's app want to generate a graphical
> output and then I like to automatically connect user to the xpra html5
> client. I would like to be able to capture any window creation request
> whether client uses x11 API, openGL or anything else.
> At this point of time, I am not worried about video, sound, mouse or
> keyboard --- graphics window is the only thing that I care about.
The XCreateWindow is what you are looking for, application side.
The X11 server will emit a "CreateNotify" event for each new window.
You can find an example code that prints each CreateNotify event it sees
here:
http://xpra.org/trac/browser/xpra/trunk/src/tests/xpra/x11/bindings/listen_maprequests.py?rev=14372
(requires latest xpra trunk code to be installed)

Cheers
Antoine


>  
> Regards, Mukul ( https://sites.google.com/site/mukulagrawal )
> 
> 
> On Friday, October 28, 2016 10:01 PM, Antoine Martin
> <antoine at nagafix.co.uk> wrote:
> 
> 
> On 29/10/16 04:18, Mukul Agrawal wrote:
>> Following is probably not a xpra specific question rather generic x11
>> question, but I would appreciate if you have any pointers regarding this.
>>
>> I start variety of command-line applications on a headless remote host.
>> I have an xpra server running on this host and I make all applications
>> to send their "potential" graphical outputs to the xpra display. Not all
>> applications will generate graphical output.
>> In cases,  when application does try to open a graphical window on the
>> xpra display, I would like to take some follow-up action. How do I
>> detect that application is trying to send something to the display?
> There are many ways of detecting that applications try "to send
> something to the display", it really depends what "follow-up action" you
> want to trigger and how reliable you want this to be.
> 
> X11 applications will open a connection to the X11 server:
> https://tronche.com/gui/x/xlib/display/opening.html
> but that alone is not a guarantee that they will "show" something (they
> may just interact with the clipboard, keyboard or whatever).
> X11 applications that show windows will need to call XCreateWindow:
> https://linux.die.net/man/3/xcreatewindow
> So that's another way of detecting that they intend to show something
> (but then you have to check that the window is actually mapped, visible
> and displayed, etc)
> Both can be intercepted with LD_PRELOAD tricks.
> 
> Looking at it from the window manager's perspective (xpra, which
> connects to the X11 server as a client), we get notifications from the
> X11 server when any new window is created. That's the core of any window
> manager. Then you need to reconcile this window with the process that
> spawned it:
> http://unix.stackexchange.com/questions/5478/what-process-created-this-x11-window
> At that point, you usually also have many other window attributes you
> can use ("WM_CLASS", title, etc).
> 
> Cheers
> Antoine
> 
> 
> 
>> 
>> Regards,
>> Mukul
>> ( https://sites.google.com/site/mukulagrawal
> <https://sites.google.com/site/mukulagrawal>)
>>
>>
>>
>> On Tuesday, October 11, 2016 8:18 PM, Antoine Martin
>> <antoine at nagafix.co.uk <mailto:antoine at nagafix.co.uk>> wrote:
>>
>>
>> On 12/10/16 03:28, Mukul Agrawal wrote:
>>> On Ubuntu Xenial, xpra is using the fallback option of Xvfb.
>>> I will like to somehow be able to use Xdummy.
>>> My specific use-case is on headless machines .... so I don't have any
>>> Xorg starting by default.
>>> Is there any workaround that can enable me to use Xdummy?
>> Possibly, the Xdummy wiki page gives some clues about some of the
>> permission changes that may be required (tested with Trusty):
>> http://xpra.org/trac/wiki/Xdummy#Ubuntu
>>
>>> Is this expected to be a long term problem or do you expect to have a
>>> solution in near term?
>> Until Ubuntu fixes their packages or provides a workaround, no.
>>
>>> I highly doubt Ubuntu will do anything about it, even in near future LTS
>>> releases.
>> You should be asking the Ubuntu developers.
>> They should know since they're the ones patching the upstream Xorg
>> packages. Debian does not have this issue either.
>>
>>> Alternatively, if I rollback to Trusty, do I need to follow the
>>> procedure mentioned in the link below?
>>> Or will newer releases of xpra take care of it automatically?
>> There is nothing we can do in our code: the broken Xorg packaging is
>> Ubuntu's, not ours.
>>
>>> [I never followed this procedure before on Trusty but I dont recall
>>> seeing Xdummy related warning before either.
>> Which warning?
>> I don't recall which one was the last version of Ubuntu that supported
>> running Xdummy, sorry.
>>
>> Cheers
>> Antoine
>>
>>>
>>> Xdummy ? Xpra <https://xpra.org/trac/wiki/Xdummy>
>>>
>>>   
>>>
>>>   
>>>
>>>
>>>    Xdummy ? Xpra
>>>
>>> xpra - screen for X
>>>   
>>>
>>> <https://xpra.org/trac/wiki/Xdummy>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>> Mukul ( https://sites.google.com/site/mukulagrawal
>> <https://sites.google.com/site/mukulagrawal>)
>>>
>>>
>>> On Friday, September 16, 2016 11:45 AM, Mukul Agrawal via shifter-users
>>> <shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>> wrote:
>>>
>>>
>>> Thanks for the clarifications.I simplified the setup (non-sudo user for
>>> proxy; same usernames on both machines) to be able to debug. But it
>>> still does not work.
>>> Multifile authentication on proxy succeeds. But seems like it not using
>>> correct ssh command line to connect to backened server.  Logs on the
>>> proxy are attached below. There are no logs on the backend xpra server.
>>> The sshd logs on the backend server says that the connection was closed
>>> by the proxy [preauth].
>>> 1. I now start proxy as non-sudo user1 on machine1 and attach it to
>>> non-priveldged tcp port1. Give it a display number disp1.
>>>
>>>  xpra proxy :disp1 --bind-tcp=0.0.0.0:port1
>>> --tcp-auth=multifile:filename=path-to-multifile -d auth
>>>
>>> Machine1 is running newer version of XPRA (xpra proxy version
> 1.0-r13637).
>>>
>>> multifile looks like following :-
>>> user1|pswd1|1000|1000|ssh:user1 at machine2 <mailto:user1 at machine2>
> <mailto:user1 at machine2 <mailto:user1 at machine2>>
>> <mailto:user1 at machine2 <mailto:user1 at machine2> <mailto:user1 at machine2
> <mailto:user1 at machine2>>>:disp2||
>>>
>>>
>>> 2. start an xpra server on machine2 under the user account with with
>>> same username user1. Give it a display number disp2.
>>>
>>> xpra start :disp2DISPLAY=:disp2 xeyes &
>>>
>>> Machine2 is using older version of XPRA (0.15.10 r11439). Not sure if
>>> this creates any problems.
>>>
>>> 3. Try attaching to backend server on machine2 from machine 1 using ssh
>>> transport and public key authentication.
>>> xpra attach ssh:user1 at machine2 <mailto:user1 at machine2>
> <mailto:user1 at machine2 <mailto:user1 at machine2>>
>> <mailto:user1 at machine2 <mailto:user1 at machine2> <mailto:user1 at machine2
> <mailto:user1 at machine2>>>:disp2
>>> This works fine. So seems like different versions are compatible.
>>> 4. Try attaching from xpra clent running on machine3 (win7 machine).
>>>
>>> xpra attach --password-file=pswd.txt tcp:user1 at machine1
> <mailto:user1 at machine1>
>> <mailto:user1 at machine1 <mailto:user1 at machine1>>
>>> <mailto:user1 at machine1 <mailto:user1 at machine1> <mailto:user1 at machine1
> <mailto:user1 at machine1>>>:port1
>>>
>>> OR
>>> xpra attach tcp:user1:pswd1 at machine1 <mailto:pswd1 at machine1>
> <mailto:pswd1 at machine1 <mailto:pswd1 at machine1>>
>> <mailto:pswd1 at machine1 <mailto:pswd1 at machine1> <mailto:pswd1 at machine1
> <mailto:pswd1 at machine1>>>:port1
>>>
>>>
>>> Proxy Logs :-
>>>
>>> 2016-09-16 11:03:55,160 New tcp connection received from
>>> IP3:1834^[[0m^[[36m2016-09-16 11:03:55,160 socktype=tcp,
>>> authclass=('multifile',
>>> <class'xpra.server.auth.multifile_auth.Authenticator'>, {'filename':
>>> 'path-to-multifile2.txt'}),encryption=, keyfile=^[[0m^[[36m2016-09-16
>>> 11:03:55,161 creating authenticator ('multifile',<class
>>> 'xpra.server.auth.multifile_auth.Authenticator'>, {'filename':
>>> 'path-to-multifile2.txt'})with username=user1^[[0m^[[36m2016-09-16
>>> 11:03:55,161 multifile=multi passwordfile^[[0m^[[36m2016-09-16
>>> 11:03:55,161 processing authentication withmulti password file,
>>> response=None, client_salt=, challenge_sent=False^[[0m^[[36m2016-09-16
>>> 11:03:55,161
>>>
>>
> challenge:('dc743d422f664331be64f48c22913d8144207dcab83c4ec2bdd6ed21a88a7567','hmac')^[[0m2016-09-16
>>> 11:03:55,161 Authentication required by multipassword file authenticator
>>> module^[[0m2016-09-16 11:03:55,162 sending challenge for 'user1' using
>>> hmac digest^[[0m^[[36m2016-09-16 11:03:55,271 processing authentication
>>> withmulti password file, response=864f4fff84caf265599ff84726295167,
>>>
>>
> client_salt=38643238663234613531386134353065386363383266363131346438393164356338383537383062303665363431396162633432363735643634643066346133,challenge_sent=True^[[0m^[[36m2016-09-16
>>> 11:03:55,271
>>> mtime(path-to-multifile2.txt)=1473994487.22^[[0m^[[36m2016-09-16
>>> 11:03:55,271 loaded 184 bytes from
>>> 'path-to-multifile2.txt'^[[0m^[[36m2016-09-16 11:03:55,272 line 1:
>>> ^[[36m2016-09-1611:03:55,272 found 7 fields^[[0m?. Something here
>>>
>>
> ?hex(salt)=5c07050c5556005307570e57000603545a06550c54520e5203065d090a555c04570c0a05005c5303520e565500545a530007500453530755570c5c5151015704,hash=864f4fff84caf265599ff84726295167^[[0m^[[36m2016-09-16
>>> 11:03:55,272 authentication challengepassed^[[0m^[[36m2016-09-16
>>> 11:03:55,272 start_proxy(Protocol(tcpsocket: internalIP1:port1<-
>>> IP3:1834), {..}, None) found sessions: (1000,1000, ['ssh:user1 at IP2
> <mailto:user1 at IP2>
>> <mailto:user1 at IP2 <mailto:user1 at IP2>>
>>> <mailto:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>>>:disp2'], {},
>> {})^[[0m^[[36m2016-09-16 11:03:55,273
>>> start_proxy:proxy-virtual-display=:disp1 (ignored), user specified
>>> display=None, founddisplays=['ssh:user1 at IP2 <mailto:user1 at IP2>
> <mailto:user1 at IP2 <mailto:user1 at IP2>>
>>> <mailto:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>>>:disp2']^[[0m2016-09-16
>> 11:03:55,499 proxy video
>>> encoders: x264^[[0m2016-09-16 11:03:55,499 new proxy instance
>>> started^[[0m2016-09-16 11:03:55,499 for client tcp socket:
>>> internalIP1:port1<- IP3:1834^[[0m2016-09-16 11:03:55,499 and server
>>> Pipe(ssh:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>> <mailto:user1 at IP2 <mailto:user1 at IP2>
>> <mailto:user1 at IP2 <mailto:user1 at IP2>>>:disp2)^[[0m2016-09-16 11:03:55,500
>>> proxy instance now also availableusing unix domain
>>> socket:^[[0m2016-09-16
>>> 11:03:55,500
>> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m^[[31m2016-09-16
>>> 11:03:55,503 Error: SSH connection to thexpra server
>>> failed^[[0m^[[31m2016-09-16 11:03:55,504  check your username, hostname,
>>> displaynumber, firewall, etc^[[0m^[[31m2016-09-16 11:03:55,504  for
>>> server: ssh:user1 at IP2 <mailto:user1 at IP2> <mailto:user1 at IP2
> <mailto:user1 at IP2>> <mailto:user1 at IP2 <mailto:user1 at IP2>
>> <mailto:user1 at IP2 <mailto:user1 at IP2>>>:disp2^[[0m^[[31m2016-09-16
>>> 11:03:55,504  the command line used was:^[[0m^[[31m2016-09-16
>>> 11:03:55,504  ssh -x -l user1 -T IP2 sh -c 'xprainitenv;~/.xpra/run-xpra
>>> _proxy :disp2 || $XDG_RUNTIME_DIR/xpra/run-xpra _proxy:disp2 || xpra
>>> _proxy :disp2'^[[0m2016-09-16 11:03:55,504 stop(server connection
>>> lost,Protocol(None))^[[0m2016-09-16 11:03:55,505 removing socket
>>> path-to-.xpra/ip-internal-IP1-proxy-11703^[[0m2016-09-16 11:03:55,505
>>> proxy instance 11703 stopped^[[0m
>>>
>>>
>>>
>>>
>>>
>>>  Regards, Mukul ( https://sites.google.com/site/mukulagrawal
>>> <https://sites.google.com/site/mukulagrawal>)
>>>
>>>    On Thursday, September 15, 2016 10:24 AM, Antoine Martin via
>>> shifter-users <shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>>> wrote:
>>>
>>>
>>> On 15/09/16 11:39, Mukul Agrawal via shifter-users wrote:
>>>> If I want xpra proxy on machine1 to connect to xpra server on machine2
>>> using ssh with public key authentication and no password, then how
>>> should I set it up?
>>> I have not tested this, but SSH connections from the proxy should be
>>> using the public key of the user running the proxy server process and
>>> not the key of the user you authenticate as. (which may not have a user
>>> account at all on the system running the proxy)
>>>
>>>> Public keys are already in default locations and xpra is able to
>>> attach directly from machine2 to machine 1 using standard format:  xpra
>>> attach ssh:username at machine1 <mailto:username at machine1>
> <mailto:username at machine1 <mailto:username at machine1>>
>> <mailto:username at machine1 <mailto:username at machine1>
> <mailto:username at machine1 <mailto:username at machine1>>>:display.
>>> I thought the server you wanted to connect to was "machine 2" and not
>>> the other way around?
>>>
>>>> But when I try to connect via proxy from client machine3, proxy is not
>>> being able to authenticate.
>>> Have you checked your ssh server logs for an answer?
>>>
>>>> It sends the challenge but then there is no log after that.
>>> Please share the log sample up to that point to help clarify things.
>>>
>>> Note: when using SSH connections, the server does not need to use
>>> another socket authentication module. That's usually just redundant.
>>>
>>>> I am using multifile like this :-
>>>> username|pswd|1000|1000|ssh:machine1:display||
>>>> and attach command from machine3 like this:-xpra attach
>>> tcp:username:pswd at machine2 <mailto:pswd at machine2>
> <mailto:pswd at machine2 <mailto:pswd at machine2>>
>> <mailto:pswd at machine2 <mailto:pswd at machine2> <mailto:pswd at machine2
> <mailto:pswd at machine2>>>:proxyPORT
>>>>
>>>> Are the usernames and passwords actually associated with login
>>> accounts on the target machine or their significance is only with
>>> respect to multifile resolution?
>>> It depends: if the proxy server runs as root, each proxied connection
>>> will run as the uid and gid you defined. (ie: 1000 above)
>>> But the connection to the backend server is made before changing uid, so
>>> the ssh key used will not be the one of the user specified in multifile.
>>>
>>> If you don't mind using SSH with passwords, you should be able to use
>>> something like this (untested):
>>> |username|pswd|1000|1000|ssh/username2:password2 at machine2
> <mailto:password2 at machine2>
>> <mailto:password2 at machine2 <mailto:password2 at machine2>>
>>> <mailto:password2 at machine2 <mailto:password2 at machine2>
> <mailto:password2 at machine2 <mailto:password2 at machine2>>>/display||
>>>
>>> We could also change the code to:
>>> * add support for ssh options to multifile, so you could specify the
>>> keyfile for each user
>>> * change the ordering so the connection to the backend server happens
>>> after changing uid and gid (but this would only work with the proxy
>>> running as root)
>>> Feel free to create tickets for this.
>>>
>>>> Can password be left blank for public key authentication?
>>> That doesn't make sense: the password in multifile is for authentication
>>> to the proxy, not to the backend server.
>>> Unless you're trying to connect via ssh to your proxy? (but why?)
>>>
>>> Cheers
>>> Antoine
>>>
>>>
>>>>
>>>> Thanks.
>>>>
>>>> _______________________________________________
>>>> shifter-users mailing list
>>>> shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto: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
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto: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
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>
>>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>
>> <mailto:shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>>>
>>
>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>>>
>>>
>>
>>
>>
> 
> 
> 



From sivmu at web.de  Thu Nov  3 02:45:42 2016
From: sivmu at web.de (sivmu)
Date: Thu, 3 Nov 2016 03:45:42 +0100
Subject: [winswitch] Problem on Polaris
Message-ID: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>

Hello everyone,

Using the new Polaris10 AMD RX480 GPU, I get several failures in the
logs and it takes at least 15 seconds to connect the client.

Tested on archlinux with version 0.17.6

Anyone an idea how to figure this one out?

Log extract:

cannot build the OpenCL program: clBuildProgram failed:
BUILD_PROGRAM_FAILURE -
Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
3.9.0)' on 'Clover' at 0x55f4fb28ea08>:
error: unknown target CPU 'polaris10'
error: unknown target CPU 'polaris10'
(options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
(source saved as /tmp/tmpAQzs_b.cl)
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/xpra/codecs/csc_opencl/colorspace_converter.py",
line 441, in bui
program.build()
File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 438,
in build
options_bytes=options_bytes, source=self._source)
File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 473,
in _build_and_catch_errors
raise err
RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE -
Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
3.9.0)' on 'Clover' at 0x55f4fb28
error: unknown target CPU 'polaris10'
error: unknown target CPU 'polaris10'
(options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
(source saved as /tmp/tmpAQzs_b.cl)
all warnings:
Warning: csc_opencl failed its self test
cannot build the OpenCL program: clBuildProgram failed:
BUILD_PROGRAM_FAILURE -
Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
3.9.0)' on 'Clover' at 0x55f4fb28
error: unknown target CPU 'polaris10'
error: unknown target CPU 'polaris10'
(options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
(source saved as /tmp/tmpAQzs_b.cl)


From antoine at nagafix.co.uk  Thu Nov  3 03:10:57 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Thu, 3 Nov 2016 10:10:57 +0700
Subject: [winswitch] Problem on Polaris
In-Reply-To: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
References: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
Message-ID: <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>

On 03/11/16 09:45, sivmu via shifter-users wrote:
> Hello everyone,
> 
> Using the new Polaris10 AMD RX480 GPU, I get several failures in the
> logs and it takes at least 15 seconds to connect the client.
> 
> Tested on archlinux with version 0.17.6
> 
> Anyone an idea how to figure this one out?
> 
> Log extract:
> 
> cannot build the OpenCL program: clBuildProgram failed:
> BUILD_PROGRAM_FAILURE -
> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
> 3.9.0)' on 'Clover' at 0x55f4fb28ea08>:
> error: unknown target CPU 'polaris10'
> error: unknown target CPU 'polaris10'
This looks like a bug in python-opencl.
Just disable the opencl csc converter, ie this should be enough:
--csc-modules=libyuv
You can verify which ones are active with:
xpra info | grep csc

Cheers
Antoine


> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
> (source saved as /tmp/tmpAQzs_b.cl)
> Traceback (most recent call last):
> File
> "/usr/lib/python2.7/site-packages/xpra/codecs/csc_opencl/colorspace_converter.py",
> line 441, in bui
> program.build()
> File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 438,
> in build
> options_bytes=options_bytes, source=self._source)
> File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 473,
> in _build_and_catch_errors
> raise err
> RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE -
> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
> 3.9.0)' on 'Clover' at 0x55f4fb28
> error: unknown target CPU 'polaris10'
> error: unknown target CPU 'polaris10'
> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
> (source saved as /tmp/tmpAQzs_b.cl)
> all warnings:
> Warning: csc_opencl failed its self test
> cannot build the OpenCL program: clBuildProgram failed:
> BUILD_PROGRAM_FAILURE -
> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
> 3.9.0)' on 'Clover' at 0x55f4fb28
> error: unknown target CPU 'polaris10'
> error: unknown target CPU 'polaris10'
> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
> (source saved as /tmp/tmpAQzs_b.cl)
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 



From sivmu at web.de  Thu Nov  3 23:58:53 2016
From: sivmu at web.de (sivmu)
Date: Fri, 4 Nov 2016 00:58:53 +0100
Subject: [winswitch] Problem on Polaris
In-Reply-To: <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>
References: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
 <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>
Message-ID: <8a26b7d2-4569-8399-e183-f9094ad23354@web.de>

changing csc-modules did not help.

the output of xpra info | grep csc after the changes:

client.encoding.csc_atoms=1
client.encoding.full_csc_modes.h265=('RGB',)
video.encoding.csc-module.cython=disabled
video.encoding.csc-module.opencl=not found
video.encoding.csc-module.swscale=disabled


still the same error message.
However after removing python2-pyopencl, the error message disapeared,
but the issue with the slow response still exists.

Please note, after removing the amd gpu and using the internal intel
gpu, xpra works fine and connects in less then a second.

So the issue is definitly related to the gpu.



Am 03.11.2016 um 04:10 schrieb Antoine Martin via shifter-users:
> On 03/11/16 09:45, sivmu via shifter-users wrote:
>> Hello everyone,
>>
>> Using the new Polaris10 AMD RX480 GPU, I get several failures in the
>> logs and it takes at least 15 seconds to connect the client.
>>
>> Tested on archlinux with version 0.17.6
>>
>> Anyone an idea how to figure this one out?
>>
>> Log extract:
>>
>> cannot build the OpenCL program: clBuildProgram failed:
>> BUILD_PROGRAM_FAILURE -
>> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
>> 3.9.0)' on 'Clover' at 0x55f4fb28ea08>:
>> error: unknown target CPU 'polaris10'
>> error: unknown target CPU 'polaris10'
> This looks like a bug in python-opencl.
> Just disable the opencl csc converter, ie this should be enough:
> --csc-modules=libyuv
> You can verify which ones are active with:
> xpra info | grep csc
> 
> Cheers
> Antoine
> 
> 
>> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
>> (source saved as /tmp/tmpAQzs_b.cl)
>> Traceback (most recent call last):
>> File
>> "/usr/lib/python2.7/site-packages/xpra/codecs/csc_opencl/colorspace_converter.py",
>> line 441, in bui
>> program.build()
>> File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 438,
>> in build
>> options_bytes=options_bytes, source=self._source)
>> File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 473,
>> in _build_and_catch_errors
>> raise err
>> RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE -
>> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
>> 3.9.0)' on 'Clover' at 0x55f4fb28
>> error: unknown target CPU 'polaris10'
>> error: unknown target CPU 'polaris10'
>> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
>> (source saved as /tmp/tmpAQzs_b.cl)
>> all warnings:
>> Warning: csc_opencl failed its self test
>> cannot build the OpenCL program: clBuildProgram failed:
>> BUILD_PROGRAM_FAILURE -
>> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
>> 3.9.0)' on 'Clover' at 0x55f4fb28
>> error: unknown target CPU 'polaris10'
>> error: unknown target CPU 'polaris10'
>> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
>> (source saved as /tmp/tmpAQzs_b.cl)
>> _______________________________________________
>> 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 Nov  4 02:16:29 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Fri, 4 Nov 2016 09:16:29 +0700
Subject: [winswitch] Problem on Polaris
In-Reply-To: <8a26b7d2-4569-8399-e183-f9094ad23354@web.de>
References: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
 <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>
 <8a26b7d2-4569-8399-e183-f9094ad23354@web.de>
Message-ID: <96864fb1-8e8f-deb5-98c5-bb4bf520de06@nagafix.co.uk>

On 04/11/16 06:58, sivmu via shifter-users wrote:
> changing csc-modules did not help.
> 
> the output of xpra info | grep csc after the changes:
> 
> client.encoding.csc_atoms=1
> client.encoding.full_csc_modes.h265=('RGB',)
> video.encoding.csc-module.cython=disabled
> video.encoding.csc-module.opencl=not found
> video.encoding.csc-module.swscale=disabled
> 
> 
> still the same error message.
> However after removing python2-pyopencl, the error message disapeared,
> but the issue with the slow response still exists.
> 
> Please note, after removing the amd gpu and using the internal intel
> gpu, xpra works fine and connects in less then a second.
> 
> So the issue is definitly related to the gpu.
In that case, try running with opengl disabled:
xpra attach --opengl=no ...

And if that helps, please post the bug report's opengl data.
Or just post the output from the gl_check.py tool so we can greylist
those GPUs until the drivers become more mature.

Cheers
Antoine


> Am 03.11.2016 um 04:10 schrieb Antoine Martin via shifter-users:
>> On 03/11/16 09:45, sivmu via shifter-users wrote:
>>> Hello everyone,
>>>
>>> Using the new Polaris10 AMD RX480 GPU, I get several failures in the
>>> logs and it takes at least 15 seconds to connect the client.
>>>
>>> Tested on archlinux with version 0.17.6
>>>
>>> Anyone an idea how to figure this one out?
>>>
>>> Log extract:
>>>
>>> cannot build the OpenCL program: clBuildProgram failed:
>>> BUILD_PROGRAM_FAILURE -
>>> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
>>> 3.9.0)' on 'Clover' at 0x55f4fb28ea08>:
>>> error: unknown target CPU 'polaris10'
>>> error: unknown target CPU 'polaris10'
>> This looks like a bug in python-opencl.
>> Just disable the opencl csc converter, ie this should be enough:
>> --csc-modules=libyuv
>> You can verify which ones are active with:
>> xpra info | grep csc
>>
>> Cheers
>> Antoine
>>
>>
>>> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
>>> (source saved as /tmp/tmpAQzs_b.cl)
>>> Traceback (most recent call last):
>>> File
>>> "/usr/lib/python2.7/site-packages/xpra/codecs/csc_opencl/colorspace_converter.py",
>>> line 441, in bui
>>> program.build()
>>> File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 438,
>>> in build
>>> options_bytes=options_bytes, source=self._source)
>>> File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 473,
>>> in _build_and_catch_errors
>>> raise err
>>> RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE -
>>> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
>>> 3.9.0)' on 'Clover' at 0x55f4fb28
>>> error: unknown target CPU 'polaris10'
>>> error: unknown target CPU 'polaris10'
>>> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
>>> (source saved as /tmp/tmpAQzs_b.cl)
>>> all warnings:
>>> Warning: csc_opencl failed its self test
>>> cannot build the OpenCL program: clBuildProgram failed:
>>> BUILD_PROGRAM_FAILURE -
>>> Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM
>>> 3.9.0)' on 'Clover' at 0x55f4fb28
>>> error: unknown target CPU 'polaris10'
>>> error: unknown target CPU 'polaris10'
>>> (options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
>>> (source saved as /tmp/tmpAQzs_b.cl)
>>> _______________________________________________
>>> 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 sivmu at web.de  Fri Nov  4 21:08:57 2016
From: sivmu at web.de (sivmu)
Date: Fri, 4 Nov 2016 22:08:57 +0100
Subject: [winswitch] Problem on Polaris
In-Reply-To: <96864fb1-8e8f-deb5-98c5-bb4bf520de06@nagafix.co.uk>
References: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
 <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>
 <8a26b7d2-4569-8399-e183-f9094ad23354@web.de>
 <96864fb1-8e8f-deb5-98c5-bb4bf520de06@nagafix.co.uk>
Message-ID: <b14e701a-03ae-d810-55d0-fa7c0c2b0514@web.de>



Am 04.11.2016 um 03:16 schrieb Antoine Martin via shifter-users:
> In that case, try running with opengl disabled:
> xpra attach --opengl=no ...
> 
> And if that helps, please post the bug report's opengl data.
> Or just post the output from the gl_check.py tool so we can greylist
> those GPUs until the drivers become more mature.
> 
> Cheers
> Antoine

That did not help either.
I also tried to turn off as many features of xpra as possible but
nothing changed, except fewer error messages about missing dependencies
like printing support.


From antoine at nagafix.co.uk  Sat Nov  5 04:55:09 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sat, 5 Nov 2016 11:55:09 +0700
Subject: [winswitch] Problem on Polaris
In-Reply-To: <b14e701a-03ae-d810-55d0-fa7c0c2b0514@web.de>
References: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
 <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>
 <8a26b7d2-4569-8399-e183-f9094ad23354@web.de>
 <96864fb1-8e8f-deb5-98c5-bb4bf520de06@nagafix.co.uk>
 <b14e701a-03ae-d810-55d0-fa7c0c2b0514@web.de>
Message-ID: <dee38625-57d2-3212-a09d-cffa1e103000@nagafix.co.uk>

On 05/11/16 04:08, sivmu via shifter-users wrote:
> 
> 
> Am 04.11.2016 um 03:16 schrieb Antoine Martin via shifter-users:
>> In that case, try running with opengl disabled:
>> xpra attach --opengl=no ...
>>
>> And if that helps, please post the bug report's opengl data.
>> Or just post the output from the gl_check.py tool so we can greylist
>> those GPUs until the drivers become more mature.
>>
>> Cheers
>> Antoine
> 
> That did not help either.
> I also tried to turn off as many features of xpra as possible but
> nothing changed, except fewer error messages about missing dependencies
> like printing support.
Please file a ticket and attach the output of both the client and server
running with "--debug all".
Hopefully we can see at which point it is getting stuck.

Cheers
Antoine


From xpra at tlinx.org  Fri Nov 11 16:29:19 2016
From: xpra at tlinx.org (L.A. Walsh)
Date: Fri, 11 Nov 2016 08:29:19 -0800
Subject: [winswitch] clueless new user w/prob(s?): xpra start - "start" -
 invalid mode+init error
Message-ID: <5825F1DF.6030809@tlinx.org>

I really don't know what I'm doing, or the benefit(s) of xpra/winshift over
a regular X session, but I'm having problems even "starting".

I'm trying to start a server, locally so I can try starting clients to
display on it, but it doesn't seem to like the 'start' flag. 

Currently, I use the X-server from cygwin running as ":0" to display
X-clients coming from an "almost headless" linux-server (who also
have DISPLAY set to my winbox (DISPLAY=athenae:0). 

By almost headless, I mean that the video HW  on the linux-box
is not good for doing much beyond displaying a text console, so
I don't even run an X server on the linux box.  I rely on the
Win7SP1x64 client for display -- mostly gvim instances and maybe
a machine-status prog like xosview.  Rarely, I bring up
other X-using progs on the server, like firefox -- but those
are rare usages since for things like that I use programs
running on the Windows box.

I have tried to forward sound a few times, but generally gave up
on that as being too complicated to setup or just not working so well.

I would *like* to have GLX working to allow running GLX using programs
on the linux box to display on my Windows box which has a decent
graphics card.

I usually disable security between linux and my Winbox as it
slows things down and is unneeded (really!).  The winbox isn't
on the outside net(internet), and uses the server to access outside
services. 

Anyway, how would something as basic as "start" not
work when I run it on the winbox? 

Exact error is "xpra initialization error: invalid mode 'start'".

Any idea why something so basic wouldn't work or give any useful
hint as to what was wrong?

Thanks!
-linda



From antoine at nagafix.co.uk  Sat Nov 12 07:29:10 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sat, 12 Nov 2016 14:29:10 +0700
Subject: [winswitch] clueless new user w/prob(s?): xpra start - "start"
 - invalid mode+init error
In-Reply-To: <5825F1DF.6030809@tlinx.org>
References: <5825F1DF.6030809@tlinx.org>
Message-ID: <4b5f3de8-9c9b-3225-30cb-60af134beb92@nagafix.co.uk>

On 11/11/16 23:29, L.A. Walsh via shifter-users wrote:
> I really don't know what I'm doing, or the benefit(s) of xpra/winshift over
> a regular X session,
For most people:
* it doesn't die if your connection does, you can re-attach
* it's faster
* sound, printing, etc..
That's all here:
http://xpra.org/trac/wiki/Enhancements

> but I'm having problems even "starting".
More details needed on what you're doing where.

> I'm trying to start a server, locally so I can try starting clients to
> display on it, but it doesn't seem to like the 'start' flag.
> Currently, I use the X-server from cygwin running as ":0" to display
> X-clients coming from an "almost headless" linux-server (who also
> have DISPLAY set to my winbox (DISPLAY=athenae:0).
> By almost headless, I mean that the video HW  on the linux-box
> is not good for doing much beyond displaying a text console, so
> I don't even run an X server on the linux box.  I rely on the
> Win7SP1x64 client for display -- mostly gvim instances and maybe
> a machine-status prog like xosview.  Rarely, I bring up
> other X-using progs on the server, like firefox -- but those
> are rare usages since for things like that I use programs
> running on the Windows box.
> 
> I have tried to forward sound a few times, but generally gave up
> on that as being too complicated to setup or just not working so well.
It should work out of the box on supported distributions (anything
recent should do).

> I would *like* to have GLX working to allow running GLX using programs
> on the linux box to display on my Windows box which has a decent
> graphics card.
Xdummy supports software OpenGL, so this should work out of the box too.
On distros that use the Xvfb fallback (mostly Ubuntu), you may want to
look here (TLDR: use VirtualGL):
http://xpra.org/trac/wiki/Usage/OpenGL

> I usually disable security between linux and my Winbox as it
> slows things down and is unneeded (really!).  The winbox isn't
> on the outside net(internet), and uses the server to access outside
> services.
I'm not sure what "security" you are talking about, but if you're
relying on the Linux box as your gateway I wouldn't disable all defences
just "because it is Linux".

> Anyway, how would something as basic as "start" not
> work when I run it on the winbox?
> Exact error is "xpra initialization error: invalid mode 'start'".
"start" is used to start a new seamless session, MS Windows does not
support *exporting* seamless sessions, only connecting to them.
Either run the "xpra start" on your Linux server and connect to it
later, or in one swoop:
xpra_cmd.exe start ssh:LINUXHOST --start=xterm

> Any idea why something so basic wouldn't work or give any useful
> hint as to what was wrong?
http://xpra.org/trac/wiki/Usage
There is also a man page with more details, which is also online:
http://xpra.org/manual.html

Any help in improving the manual or wiki to make this clearer is always
much appreciated.

Cheers
Antoine

> 
> Thanks!
> -linda
> 
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users



From tmesposito00 at gmail.com  Wed Nov 16 15:41:18 2016
From: tmesposito00 at gmail.com (Thomas Esposito)
Date: Wed, 16 Nov 2016 10:41:18 -0500
Subject: [winswitch] windows xpra client CPU usage
Message-ID: <CANUZkSXQ4C5sP1i+N0oY6kR4Uz_9SWm1hGMz-H7-2r8XAOMjrA@mail.gmail.com>

My Xpra-Launcher.exe process is ALWAYS using from 5% to 10% of my CPU
capacity, even when my X applications are TOTALLY idle (i.e. windows are
out of focus and/or no redrawing from X clients).

This is a HUGE increase in CPU usage (and heat generation) on my laptop
relative to when I'm just doing simple browsing and email. For example, if
i'm just browsing and reading/writing email, my total CPU usage stays under
1% to 2% and the laptop stays cool with the fan off. If I add the Xpra
client to this, even though I'm not interacting with the X application
windows and they are not redrawing, my laptop starts getting hot and the
fan turns on. Note this is only with a single X application window running.

In comparison, the TigerVNC viewer and x2go CPU usage is effectively 0% if
the windows are not updating.


From antoine at nagafix.co.uk  Thu Nov 17 02:27:16 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Thu, 17 Nov 2016 09:27:16 +0700
Subject: [winswitch] windows xpra client CPU usage
In-Reply-To: <CANUZkSXQ4C5sP1i+N0oY6kR4Uz_9SWm1hGMz-H7-2r8XAOMjrA@mail.gmail.com>
References: <CANUZkSXQ4C5sP1i+N0oY6kR4Uz_9SWm1hGMz-H7-2r8XAOMjrA@mail.gmail.com>
Message-ID: <0e6a9c9b-dbc2-10e2-c900-6507720549e3@nagafix.co.uk>

On 16/11/16 22:41, Thomas Esposito via shifter-users wrote:
> My Xpra-Launcher.exe process is ALWAYS using from 5% to 10% of my CPU
> capacity, even when my X applications are TOTALLY idle (i.e. windows are
> out of focus and/or no redrawing from X clients).
My guess is that sound is enabled, sound forwarding uses a stream and
will consume network and CPU even when no sound is being played.

> This is a HUGE increase in CPU usage (and heat generation) on my laptop
> relative to when I'm just doing simple browsing and email. For example, if
> i'm just browsing and reading/writing email, my total CPU usage stays under
> 1% to 2% and the laptop stays cool with the fan off. If I add the Xpra
> client to this, even though I'm not interacting with the X application
> windows and they are not redrawing, my laptop starts getting hot and the
> fan turns on. Note this is only with a single X application window running.
Without sound, there should not be any network or CPU usage unless the
application's window is refreshing.
(bar ping packets every few seconds, but those are tiny)

> In comparison, the TigerVNC viewer and x2go CPU usage is effectively 0% if
> the windows are not updating.
TigerVNC does not do sound, or printing, and many other things!

Cheers
Antoine


From tmesposito00 at gmail.com  Thu Nov 17 05:14:34 2016
From: tmesposito00 at gmail.com (Thomas Esposito)
Date: Thu, 17 Nov 2016 00:14:34 -0500
Subject: [winswitch] windows xpra client CPU usage
In-Reply-To: <0e6a9c9b-dbc2-10e2-c900-6507720549e3@nagafix.co.uk>
References: <CANUZkSXQ4C5sP1i+N0oY6kR4Uz_9SWm1hGMz-H7-2r8XAOMjrA@mail.gmail.com>
 <0e6a9c9b-dbc2-10e2-c900-6507720549e3@nagafix.co.uk>
Message-ID: <CANUZkSXJyOS9fgpK89Lw-rQr9hWhtZFa1Kd-SFEbJKr_X9aNLA@mail.gmail.com>

I'm pretty sure that I have audio disabled on the server side, but I'll
check again tomorrow. Do I have to do anything special to disable audio on
the client side?

On Nov 16, 2016 9:27 PM, "Antoine Martin via shifter-users" <
shifter-users at lists.devloop.org.uk> wrote:

> On 16/11/16 22:41, Thomas Esposito via shifter-users wrote:
> > My Xpra-Launcher.exe process is ALWAYS using from 5% to 10% of my CPU
> > capacity, even when my X applications are TOTALLY idle (i.e. windows are
> > out of focus and/or no redrawing from X clients).
> My guess is that sound is enabled, sound forwarding uses a stream and
> will consume network and CPU even when no sound is being played.
>
> > This is a HUGE increase in CPU usage (and heat generation) on my laptop
> > relative to when I'm just doing simple browsing and email. For example,
> if
> > i'm just browsing and reading/writing email, my total CPU usage stays
> under
> > 1% to 2% and the laptop stays cool with the fan off. If I add the Xpra
> > client to this, even though I'm not interacting with the X application
> > windows and they are not redrawing, my laptop starts getting hot and the
> > fan turns on. Note this is only with a single X application window
> running.
> Without sound, there should not be any network or CPU usage unless the
> application's window is refreshing.
> (bar ping packets every few seconds, but those are tiny)
>
> > In comparison, the TigerVNC viewer and x2go CPU usage is effectively 0%
> if
> > the windows are not updating.
> TigerVNC does not do sound, or printing, and many other things!
>
> Cheers
> Antoine
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>


From antoine at nagafix.co.uk  Thu Nov 17 05:21:21 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Thu, 17 Nov 2016 12:21:21 +0700
Subject: [winswitch] windows xpra client CPU usage
In-Reply-To: <CANUZkSXJyOS9fgpK89Lw-rQr9hWhtZFa1Kd-SFEbJKr_X9aNLA@mail.gmail.com>
References: <CANUZkSXQ4C5sP1i+N0oY6kR4Uz_9SWm1hGMz-H7-2r8XAOMjrA@mail.gmail.com>
 <0e6a9c9b-dbc2-10e2-c900-6507720549e3@nagafix.co.uk>
 <CANUZkSXJyOS9fgpK89Lw-rQr9hWhtZFa1Kd-SFEbJKr_X9aNLA@mail.gmail.com>
Message-ID: <6229f6ca-856b-4306-78a7-1edd56aacf24@nagafix.co.uk>

Please don't top post.

On 17/11/16 12:14, Thomas Esposito wrote:
> I'm pretty sure that I have audio disabled on the server side,
There are 3 possible values for the "speaker" option: on, off, disabled.
If you disable it server side, the client cannot enable it.

> but I'll check again tomorrow.
>
> Do I have to do anything special to disable audio
> on the client side?
There are many ways of doing this on the client side, you can add:
* "--speaker=off" to you command line, as a one-off.
* "speaker=off" to your connection file if you use one (for that host)
* "speaker=off" to your user settings (affects all connections)
* "speaker=off" to your global xpra settings (affects all users)
* turn it off using the system tray at runtime

Cheers
Antoine



> 
> 
> On Nov 16, 2016 9:27 PM, "Antoine Martin via shifter-users"
> <shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>> wrote:
> 
>     On 16/11/16 22:41, Thomas Esposito via shifter-users wrote:
>     > My Xpra-Launcher.exe process is ALWAYS using from 5% to 10% of my CPU
>     > capacity, even when my X applications are TOTALLY idle (i.e.
>     windows are
>     > out of focus and/or no redrawing from X clients).
>     My guess is that sound is enabled, sound forwarding uses a stream and
>     will consume network and CPU even when no sound is being played.
> 
>     > This is a HUGE increase in CPU usage (and heat generation) on my
>     laptop
>     > relative to when I'm just doing simple browsing and email. For
>     example, if
>     > i'm just browsing and reading/writing email, my total CPU usage
>     stays under
>     > 1% to 2% and the laptop stays cool with the fan off. If I add the Xpra
>     > client to this, even though I'm not interacting with the X application
>     > windows and they are not redrawing, my laptop starts getting hot
>     and the
>     > fan turns on. Note this is only with a single X application window
>     running.
>     Without sound, there should not be any network or CPU usage unless the
>     application's window is refreshing.
>     (bar ping packets every few seconds, but those are tiny)
> 
>     > In comparison, the TigerVNC viewer and x2go CPU usage is
>     effectively 0% if
>     > the windows are not updating.
>     TigerVNC does not do sound, or printing, and many other things!
> 
>     Cheers
>     Antoine
>     _______________________________________________
>     shifter-users mailing list
>     shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>
> 



From tmesposito00 at gmail.com  Thu Nov 17 15:47:54 2016
From: tmesposito00 at gmail.com (Thomas Esposito)
Date: Thu, 17 Nov 2016 10:47:54 -0500
Subject: [winswitch] windows xpra client CPU usage
In-Reply-To: <6229f6ca-856b-4306-78a7-1edd56aacf24@nagafix.co.uk>
References: <CANUZkSXQ4C5sP1i+N0oY6kR4Uz_9SWm1hGMz-H7-2r8XAOMjrA@mail.gmail.com>
 <0e6a9c9b-dbc2-10e2-c900-6507720549e3@nagafix.co.uk>
 <CANUZkSXJyOS9fgpK89Lw-rQr9hWhtZFa1Kd-SFEbJKr_X9aNLA@mail.gmail.com>
 <6229f6ca-856b-4306-78a7-1edd56aacf24@nagafix.co.uk>
Message-ID: <CANUZkSXjwiyBtSiU8zo_4+WcxrNJvLgMXMn3x+FREME+DQtkgA@mail.gmail.com>

On Thu, Nov 17, 2016 at 12:21 AM, Antoine Martin <antoine at nagafix.co.uk>
wrote:

> Please don't top post.
>
> On 17/11/16 12:14, Thomas Esposito wrote:
> > I'm pretty sure that I have audio disabled on the server side,
> There are 3 possible values for the "speaker" option: on, off, disabled.
> If you disable it server side, the client cannot enable it.
>
> > but I'll check again tomorrow.
> >
> > Do I have to do anything special to disable audio
> > on the client side?
> There are many ways of doing this on the client side, you can add:
> * "--speaker=off" to you command line, as a one-off.
> * "speaker=off" to your connection file if you use one (for that host)
> * "speaker=off" to your user settings (affects all connections)
> * "speaker=off" to your global xpra settings (affects all users)
> * turn it off using the system tray at runtime
>

Both speaker and microphone are set to disabled. Accordingly, they are both
"grayed out" on the client because they are disabled on the server.
Nevertheless, I still have a constant CPU usage of 5% to 7%. I don't know
if this matters, but since I have a reasonable high-bandwidth connection to
the server, I'm using zlib/lz4/lzo encoding which seems to result in
quicker response times.

Client version is beta 1.0 r14228, running on Windows 7.

Server is beta 1.0 r14232 running on RHEL 6.6.

FWIW, I observed the same behavior on 0.17.5.


> Cheers
> Antoine
>
>
>
> >
> >
> > On Nov 16, 2016 9:27 PM, "Antoine Martin via shifter-users"
> > <shifter-users at lists.devloop.org.uk
> > <mailto:shifter-users at lists.devloop.org.uk>> wrote:
> >
> >     On 16/11/16 22:41, Thomas Esposito via shifter-users wrote:
> >     > My Xpra-Launcher.exe process is ALWAYS using from 5% to 10% of my
> CPU
> >     > capacity, even when my X applications are TOTALLY idle (i.e.
> >     windows are
> >     > out of focus and/or no redrawing from X clients).
> >     My guess is that sound is enabled, sound forwarding uses a stream and
> >     will consume network and CPU even when no sound is being played.
> >
> >     > This is a HUGE increase in CPU usage (and heat generation) on my
> >     laptop
> >     > relative to when I'm just doing simple browsing and email. For
> >     example, if
> >     > i'm just browsing and reading/writing email, my total CPU usage
> >     stays under
> >     > 1% to 2% and the laptop stays cool with the fan off. If I add the
> Xpra
> >     > client to this, even though I'm not interacting with the X
> application
> >     > windows and they are not redrawing, my laptop starts getting hot
> >     and the
> >     > fan turns on. Note this is only with a single X application window
> >     running.
> >     Without sound, there should not be any network or CPU usage unless
> the
> >     application's window is refreshing.
> >     (bar ping packets every few seconds, but those are tiny)
> >
> >     > In comparison, the TigerVNC viewer and x2go CPU usage is
> >     effectively 0% if
> >     > the windows are not updating.
> >     TigerVNC does not do sound, or printing, and many other things!
> >
> >     Cheers
> >     Antoine
> >     _______________________________________________
> >     shifter-users mailing list
> >     shifter-users at lists.devloop.org.uk
> >     <mailto:shifter-users at lists.devloop.org.uk>
> >     http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> >     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>
> >
>
>


From antoine at nagafix.co.uk  Thu Nov 17 15:53:20 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Thu, 17 Nov 2016 22:53:20 +0700
Subject: [winswitch] windows xpra client CPU usage
In-Reply-To: <CANUZkSXjwiyBtSiU8zo_4+WcxrNJvLgMXMn3x+FREME+DQtkgA@mail.gmail.com>
References: <CANUZkSXQ4C5sP1i+N0oY6kR4Uz_9SWm1hGMz-H7-2r8XAOMjrA@mail.gmail.com>
 <0e6a9c9b-dbc2-10e2-c900-6507720549e3@nagafix.co.uk>
 <CANUZkSXJyOS9fgpK89Lw-rQr9hWhtZFa1Kd-SFEbJKr_X9aNLA@mail.gmail.com>
 <6229f6ca-856b-4306-78a7-1edd56aacf24@nagafix.co.uk>
 <CANUZkSXjwiyBtSiU8zo_4+WcxrNJvLgMXMn3x+FREME+DQtkgA@mail.gmail.com>
Message-ID: <e269248b-f6d9-bfa4-7350-84cddb3712d1@nagafix.co.uk>

On 17/11/16 22:47, Thomas Esposito wrote:
> 
> 
> On Thu, Nov 17, 2016 at 12:21 AM, Antoine Martin <antoine at nagafix.co.uk
> <mailto:antoine at nagafix.co.uk>> wrote:
> 
>     Please don't top post.
> 
>     On 17/11/16 12:14, Thomas Esposito wrote:
>     > I'm pretty sure that I have audio disabled on the server side,
>     There are 3 possible values for the "speaker" option: on, off, disabled.
>     If you disable it server side, the client cannot enable it.
> 
>     > but I'll check again tomorrow.
>     >
>     > Do I have to do anything special to disable audio
>     > on the client side?
>     There are many ways of doing this on the client side, you can add:
>     * "--speaker=off" to you command line, as a one-off.
>     * "speaker=off" to your connection file if you use one (for that host)
>     * "speaker=off" to your user settings (affects all connections)
>     * "speaker=off" to your global xpra settings (affects all users)
>     * turn it off using the system tray at runtime
> 
> 
> Both speaker and microphone are set to disabled. Accordingly, they are
> both "grayed out" on the client because they are disabled on the server.
> Nevertheless, I still have a constant CPU usage of 5% to 7%.
Then it may just be that the application does repaint its window(s), or
maybe something else is causing the traffic (ie: clipboard?)

You may want to run in debug mode to see what is happening:
xpra attach -d all ...
If it's not immediately obvious, please attach the log to a ticket.

>I don't
> know if this matters, but since I have a reasonable high-bandwidth
> connection to the server, I'm using zlib/lz4/lzo encoding which seems to
> result in quicker response times.
Yes, if you have enough bandwidth, that's what you want.

> Client version is beta 1.0 r14228, running on Windows 7.
> 
> Server is beta 1.0 r14232 running on RHEL 6.6.
> 
> FWIW, I observed the same behavior on 0.17.5.

Cheers
Antoine


From aashidham at gmail.com  Fri Nov 18 01:35:16 2016
From: aashidham at gmail.com (Aaditya Shidham)
Date: Thu, 17 Nov 2016 17:35:16 -0800
Subject: [winswitch] How data flows through Xpra server and proxy
Message-ID: <CAH_o3hxqdqee=5=eQqmki5SQ0uEsaA-5jvBuMpmJH4NEM=YnZw@mail.gmail.com>

Hello,

I have the following invocation of Xpra:

xpra start :5455 --bind-tcp=0.0.0.0:5555 --html=on --no-daemon

And then I can get graphical programs in an Xpra client to load through

DISPLAY=:5455 xeyes

I'm curious how data for the x11 packets go through the Xpra program. It
seems that Xvfb is what handles the xeyes by storing the display in memory.
How does this data then pass to the rest of Xpra? According to (
http://stackoverflow.com/questions/12050021/how-to-make-xvfb-display-visible),
I need to use -fbdir to access this virtual memory, but this isn't used
when Xvfb is invoked by Xpra.

Also where is the local Unix socket used? I can see where the local domain
Unix socket is set inside xpra/scripts/server.py, but I don't see where it
is ever used. It seems to be named partially after the :5455
(~/.xpra/ip-XXX-XX-XX-5455), but where are the two connected?


From antoine at nagafix.co.uk  Fri Nov 18 04:26:14 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Fri, 18 Nov 2016 11:26:14 +0700
Subject: [winswitch] How data flows through Xpra server and proxy
In-Reply-To: <CAH_o3hxqdqee=5=eQqmki5SQ0uEsaA-5jvBuMpmJH4NEM=YnZw@mail.gmail.com>
References: <CAH_o3hxqdqee=5=eQqmki5SQ0uEsaA-5jvBuMpmJH4NEM=YnZw@mail.gmail.com>
Message-ID: <0d459139-25cc-68d3-72c8-92aa46fedbe2@nagafix.co.uk>

On 18/11/16 08:35, Aaditya Shidham via shifter-users wrote:
> Hello,
> 
> I have the following invocation of Xpra:
> xpra start :5455 --bind-tcp=0.0.0.0:5555 --html=on --no-daemon
> And then I can get graphical programs in an Xpra client to load through
> DISPLAY=:5455 xeyes
Use this instead:
xpra (..) --start=xeyes
So the application won't be killed if your ssh / xterm dies.

> I'm curious how data for the x11 packets go through the Xpra program. It
> seems that Xvfb is what handles the xeyes by storing the display in memory.
> How does this data then pass to the rest of Xpra? According to (
> http://stackoverflow.com/questions/12050021/how-to-make-xvfb-display-visible),
> I need to use -fbdir to access this virtual memory, but this isn't used
> when Xvfb is invoked by Xpra.
xpra is just like any other X11 client application, it connects to the
X11 server using its unix domain sockets and will use shared memory
(XShm) if available (it almost always is).

This does not need "-fbdir" which is specific to Xvfb and serves a
different purpose.

> Also where is the local Unix socket used? I can see where the local domain
> Unix socket is set inside xpra/scripts/server.py, but I don't see where it
> is ever used. It seems to be named partially after the :5455
> (~/.xpra/ip-XXX-XX-XX-5455), but where are the two connected?
That's xpra's socket, which is used for xpra connections, not X11
connections.
You can find more details on where this is going here:
http://xpra.org/trac/ticket/1129#comment:23
http://xpra.org/trac/wiki/Network

Cheers
Antoine


From aashidham at gmail.com  Fri Nov 18 05:43:27 2016
From: aashidham at gmail.com (Aaditya Shidham)
Date: Thu, 17 Nov 2016 21:43:27 -0800
Subject: [winswitch] How data flows through Xpra server and proxy
In-Reply-To: <0d459139-25cc-68d3-72c8-92aa46fedbe2@nagafix.co.uk>
References: <CAH_o3hxqdqee=5=eQqmki5SQ0uEsaA-5jvBuMpmJH4NEM=YnZw@mail.gmail.com>
 <0d459139-25cc-68d3-72c8-92aa46fedbe2@nagafix.co.uk>
Message-ID: <CAH_o3hyMM7AaBiFshmD2FCMGLFgCxL8DYqDp_BiKTkLKDvQnCg@mail.gmail.com>

When you say, " It connects to the
X11 server using its unix domain sockets and will use shared memory
(XShm) if available (it almost always is)."

Where are these unix domain sockets stored usually in the filesystem and
where in the codebase is this socket created and where is the graphics data
sent / received?

Also where in the source code is the socket located at
~/.xpra/ip-XXX-XX-XX-5455 read from / written to?

On Thu, Nov 17, 2016 at 8:26 PM, Antoine Martin via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> On 18/11/16 08:35, Aaditya Shidham via shifter-users wrote:
> > Hello,
> >
> > I have the following invocation of Xpra:
> > xpra start :5455 --bind-tcp=0.0.0.0:5555 --html=on --no-daemon
> > And then I can get graphical programs in an Xpra client to load through
> > DISPLAY=:5455 xeyes
> Use this instead:
> xpra (..) --start=xeyes
> So the application won't be killed if your ssh / xterm dies.
>
> > I'm curious how data for the x11 packets go through the Xpra program. It
> > seems that Xvfb is what handles the xeyes by storing the display in
> memory.
> > How does this data then pass to the rest of Xpra? According to (
> > http://stackoverflow.com/questions/12050021/how-to-
> make-xvfb-display-visible),
> > I need to use -fbdir to access this virtual memory, but this isn't used
> > when Xvfb is invoked by Xpra.
> xpra is just like any other X11 client application, it connects to the
> X11 server using its unix domain sockets and will use shared memory
> (XShm) if available (it almost always is).
>
> This does not need "-fbdir" which is specific to Xvfb and serves a
> different purpose.
>
> > Also where is the local Unix socket used? I can see where the local
> domain
> > Unix socket is set inside xpra/scripts/server.py, but I don't see where
> it
> > is ever used. It seems to be named partially after the :5455
> > (~/.xpra/ip-XXX-XX-XX-5455), but where are the two connected?
> That's xpra's socket, which is used for xpra connections, not X11
> connections.
> You can find more details on where this is going here:
> http://xpra.org/trac/ticket/1129#comment:23
> http://xpra.org/trac/wiki/Network
>
> Cheers
> Antoine
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>


From antoine at nagafix.co.uk  Fri Nov 18 05:50:53 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Fri, 18 Nov 2016 12:50:53 +0700
Subject: [winswitch] How data flows through Xpra server and proxy
In-Reply-To: <CAH_o3hyMM7AaBiFshmD2FCMGLFgCxL8DYqDp_BiKTkLKDvQnCg@mail.gmail.com>
References: <CAH_o3hxqdqee=5=eQqmki5SQ0uEsaA-5jvBuMpmJH4NEM=YnZw@mail.gmail.com>
 <0d459139-25cc-68d3-72c8-92aa46fedbe2@nagafix.co.uk>
 <CAH_o3hyMM7AaBiFshmD2FCMGLFgCxL8DYqDp_BiKTkLKDvQnCg@mail.gmail.com>
Message-ID: <170e6b7f-c746-fdf5-6258-33bc612b274b@nagafix.co.uk>

Please do not top-post.

On 18/11/16 12:43, Aaditya Shidham via shifter-users wrote:
> When you say, " It connects to the
> X11 server using its unix domain sockets and will use shared memory
> (XShm) if available (it almost always is)."
> 
> Where are these unix domain sockets stored usually in the filesystem and
/tmp/.X11-unix/

> where in the codebase is this socket created and where is the graphics data
> sent / received?
This code lives in the X11 libraries:
https://tronche.com/gui/x/xlib/display/opening.html

> Also where in the source code is the socket located at
> ~/.xpra/ip-XXX-XX-XX-5455 read from / written to?
I'm not sure what you're asking, the code that interacts with the
sockets is in various places, ie:
http://xpra.org/trac/browser/xpra/trunk/src/xpra/platform/dotxpra.py
http://xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/main.py
http://xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/server.py

The actual socket path definitions are per-platform, here's the stub:
http://xpra.org/trac/browser/xpra/trunk/src/xpra/platform/paths.py

If you tell us what you're trying to do, we can give you more specific
pointers.

Cheers
Antoine


> 
> On Thu, Nov 17, 2016 at 8:26 PM, Antoine Martin via shifter-users <
> shifter-users at lists.devloop.org.uk> wrote:
> 
>> On 18/11/16 08:35, Aaditya Shidham via shifter-users wrote:
>>> Hello,
>>>
>>> I have the following invocation of Xpra:
>>> xpra start :5455 --bind-tcp=0.0.0.0:5555 --html=on --no-daemon
>>> And then I can get graphical programs in an Xpra client to load through
>>> DISPLAY=:5455 xeyes
>> Use this instead:
>> xpra (..) --start=xeyes
>> So the application won't be killed if your ssh / xterm dies.
>>
>>> I'm curious how data for the x11 packets go through the Xpra program. It
>>> seems that Xvfb is what handles the xeyes by storing the display in
>> memory.
>>> How does this data then pass to the rest of Xpra? According to (
>>> http://stackoverflow.com/questions/12050021/how-to-
>> make-xvfb-display-visible),
>>> I need to use -fbdir to access this virtual memory, but this isn't used
>>> when Xvfb is invoked by Xpra.
>> xpra is just like any other X11 client application, it connects to the
>> X11 server using its unix domain sockets and will use shared memory
>> (XShm) if available (it almost always is).
>>
>> This does not need "-fbdir" which is specific to Xvfb and serves a
>> different purpose.
>>
>>> Also where is the local Unix socket used? I can see where the local
>> domain
>>> Unix socket is set inside xpra/scripts/server.py, but I don't see where
>> it
>>> is ever used. It seems to be named partially after the :5455
>>> (~/.xpra/ip-XXX-XX-XX-5455), but where are the two connected?
>> That's xpra's socket, which is used for xpra connections, not X11
>> connections.
>> You can find more details on where this is going here:
>> http://xpra.org/trac/ticket/1129#comment:23
>> http://xpra.org/trac/wiki/Network
>>
>> 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 m at merlinnot.com  Mon Nov 21 10:41:11 2016
From: m at merlinnot.com (=?utf-8?Q?Natan_S=C4=85gol?=)
Date: Mon, 21 Nov 2016 11:41:11 +0100
Subject: [winswitch] H264 - cora web client
Message-ID: <D0F0E691-F06B-48A2-B2E4-D71A6F00FA25@merlinnot.com>

Hi,

I?m trying to enable h264 in one of my projects <https://github.com/merlinnot/dev/tree/feature/atom>. I guess it should work much better than jpeg. I?ve been trying for two days now and nothing helps:
- installing x264
- installing ffmpeg
- passing ?encodings, ?encoding, ?video-encoders
- passing ?encoding=h264 in the URL

xpra is a daemonised service, runs after bringing container to life (vagrant up / docker run). $DISPLAY variable is already set, only thing to do is run ?atom? command inside container (logging via docker exec or vagrant ssh) and application becomes visible at port 8000. 

 My second issue is keyboard layout, passing keyboard_layout=pl in the URL doesn?t help, I can?t insert language-specific characters.

Do you know how can I make it work?

regards,
Natan

From antoine at nagafix.co.uk  Mon Nov 21 10:52:47 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Mon, 21 Nov 2016 17:52:47 +0700
Subject: [winswitch] H264 - cora web client
In-Reply-To: <D0F0E691-F06B-48A2-B2E4-D71A6F00FA25@merlinnot.com>
References: <D0F0E691-F06B-48A2-B2E4-D71A6F00FA25@merlinnot.com>
Message-ID: <c6ce9228-48e1-4fee-aa61-3297f829d741@nagafix.co.uk>

On 21/11/16 17:41, Natan S?gol via shifter-users wrote:
> Hi,
> 
> I?m trying to enable h264 in one of my projects <https://github.com/merlinnot/dev/tree/feature/atom>. I guess it should work much better than jpeg. I?ve been trying for two days now and nothing helps:
> - installing x264
> - installing ffmpeg
> - passing ?encodings, ?encoding, ?video-encoders
> - passing ?encoding=h264 in the URL
H264 is currently disabled in the HTML5 client, the latest betas builds
re-enable it again, try using those instead.

> xpra is a daemonised service, runs after bringing container to life (vagrant up / docker run). $DISPLAY variable is already set,
FYI: client applications should be started with "xpra --start=THEAPP"
rather than by hand with DISPLAY= to ensure the whole environment is
correctly setup.

> only thing to do is run ?atom? command inside container (logging via docker exec or vagrant ssh) and application becomes visible at port 8000. 
I'm not sure if and how "atom" and docker are relevant to your question.

>  My second issue is keyboard layout, passing keyboard_layout=pl in the URL doesn?t help, I can?t insert language-specific characters.
Keyboard support is very tricky to get right, even more so with browsers
since we only get limited keyboard data.
For debugging, see:
http://xpra.org/trac/wiki/Keyboard

Cheers
Antoine

> Do you know how can I make it work?
> 
> regards,
> Natan



From tmesposito00 at gmail.com  Mon Nov 21 15:45:11 2016
From: tmesposito00 at gmail.com (Thomas Esposito)
Date: Mon, 21 Nov 2016 10:45:11 -0500
Subject: [winswitch] unix authentication for TCP sessions?
Message-ID: <CANUZkSVOzMgPYmOsEfO4ByRBN8PUB4ks-5-6_WJeEgxGW4SjuQ@mail.gmail.com>

First some background info...

I've been using Xpra at work. I have a RHEL 6.6 virtual machine, which I
believe uses LDAP for login authentication. I don't have root/admin
privileges, so in order to use Xpra, I have manually extracted the contents
of all of the required RPMs and modified my PYTHONPATH, PATH,
LD_LIBRARY_PATH, and MANPATH variables to point to where the RPMs are
extracted.

Since I obviously can't install anything to "/etc", I have all of the
config files in "${HOME}/.xpra". For the beta version of xpra, this means
that I can't install any of the files in "/etc/pam.d" (which is new to the
1.0 beta).

In order to get good performance on my corporate intranet, I need to use
raw TCP with a port in the range 5900 5909 (i.e the ports used by VNC),
because this is prioritized on the network vs. ssh, which has very
inconsistent network performance. I'd like to use LDAP authentication for
my TCP sessions, but I'm not sure how to do this. I've tried setting
"--tcp-auth=pam" on the xpra command line, but the Win32 launcher reports
"Connection lost" when I try to connect. I get the following output in the
server-side log file (edited to remove IP addresses and user name):

2016-11-21 10:29:00,367 New tcp connection received from x.x.x.x:x
2016-11-21 10:29:00,369 Authentication required by PAM authenticator module
2016-11-21 10:29:00,369  sending challenge for username '<username>' using
xor digest
2016-11-21 10:29:00,511 client has requested disconnection: invalid digest
2016-11-21 10:29:00,512 Disconnecting client x.x.x.x:x:
2016-11-21 10:29:00,512  client request

Any idea how to get this working, keeping in mind the fact that I can't do
a normal install (i.e. write to "/etc") on the server side?


From antoine at nagafix.co.uk  Mon Nov 21 15:53:00 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Mon, 21 Nov 2016 22:53:00 +0700
Subject: [winswitch] unix authentication for TCP sessions?
In-Reply-To: <CANUZkSVOzMgPYmOsEfO4ByRBN8PUB4ks-5-6_WJeEgxGW4SjuQ@mail.gmail.com>
References: <CANUZkSVOzMgPYmOsEfO4ByRBN8PUB4ks-5-6_WJeEgxGW4SjuQ@mail.gmail.com>
Message-ID: <322a6a76-43b9-da96-d888-21a1ee839d7d@nagafix.co.uk>

On 21/11/16 22:45, Thomas Esposito via shifter-users wrote:
> First some background info...
> 
> I've been using Xpra at work. I have a RHEL 6.6 virtual machine, which I
> believe uses LDAP for login authentication. I don't have root/admin
> privileges, so in order to use Xpra, I have manually extracted the contents
> of all of the required RPMs and modified my PYTHONPATH, PATH,
> LD_LIBRARY_PATH, and MANPATH variables to point to where the RPMs are
> extracted.
> 
> Since I obviously can't install anything to "/etc", I have all of the
> config files in "${HOME}/.xpra". For the beta version of xpra, this means
> that I can't install any of the files in "/etc/pam.d" (which is new to the
> 1.0 beta).
> 
> In order to get good performance on my corporate intranet, I need to use
> raw TCP with a port in the range 5900 5909 (i.e the ports used by VNC),
> because this is prioritized on the network vs. ssh, which has very
> inconsistent network performance. I'd like to use LDAP authentication for
> my TCP sessions, but I'm not sure how to do this. I've tried setting
> "--tcp-auth=pam" on the xpra command line, but the Win32 launcher reports
> "Connection lost" when I try to connect. I get the following output in the
> server-side log file (edited to remove IP addresses and user name):
> 
> 2016-11-21 10:29:00,367 New tcp connection received from x.x.x.x:x
> 2016-11-21 10:29:00,369 Authentication required by PAM authenticator module
> 2016-11-21 10:29:00,369  sending challenge for username '<username>' using
> xor digest
> 2016-11-21 10:29:00,511 client has requested disconnection: invalid digest
> 2016-11-21 10:29:00,512 Disconnecting client x.x.x.x:x:
> 2016-11-21 10:29:00,512  client request
The client and server will refuse to send unencrypted passwords over
TCP, unfortunately PAM requires the actual password rather than a hash -
unlike the other plugins which can happily use HMAC.

> Any idea how to get this working, keeping in mind the fact that I can't do
> a normal install (i.e. write to "/etc") on the server side?
If you must use PAM, use SSL or AES encryption. (see wiki for details)
If not, use a different authentication module.

Cheers
Antoine

PS: there is a magic environment variable which can be used to force
xpra to use unencrypted passwords over TCP, but I am not posting it here
as this is not a good solution.


From tmesposito00 at gmail.com  Mon Nov 21 16:22:44 2016
From: tmesposito00 at gmail.com (Thomas Esposito)
Date: Mon, 21 Nov 2016 11:22:44 -0500
Subject: [winswitch] unix authentication for TCP sessions?
In-Reply-To: <322a6a76-43b9-da96-d888-21a1ee839d7d@nagafix.co.uk>
References: <CANUZkSVOzMgPYmOsEfO4ByRBN8PUB4ks-5-6_WJeEgxGW4SjuQ@mail.gmail.com>
 <322a6a76-43b9-da96-d888-21a1ee839d7d@nagafix.co.uk>
Message-ID: <CANUZkSUiQAcWc+tWUqTvRDCBJaVMso186kCRxvsf4qRTUT2+ag@mail.gmail.com>

Ok, so it looks like I need an AES keyfile. I tried omitting
"--tcp-encryption-keyfile" from the command line, but I get a "missing
encryption tokens" error in the log. How can I generate a keyfile? Also,
how do I launch the win32 client with this keyfile (there doesn't seem to
be a way to do this in the GUI).

On Mon, Nov 21, 2016 at 10:53 AM, Antoine Martin via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> On 21/11/16 22:45, Thomas Esposito via shifter-users wrote:
> > First some background info...
> >
> > I've been using Xpra at work. I have a RHEL 6.6 virtual machine, which I
> > believe uses LDAP for login authentication. I don't have root/admin
> > privileges, so in order to use Xpra, I have manually extracted the
> contents
> > of all of the required RPMs and modified my PYTHONPATH, PATH,
> > LD_LIBRARY_PATH, and MANPATH variables to point to where the RPMs are
> > extracted.
> >
> > Since I obviously can't install anything to "/etc", I have all of the
> > config files in "${HOME}/.xpra". For the beta version of xpra, this means
> > that I can't install any of the files in "/etc/pam.d" (which is new to
> the
> > 1.0 beta).
> >
> > In order to get good performance on my corporate intranet, I need to use
> > raw TCP with a port in the range 5900 5909 (i.e the ports used by VNC),
> > because this is prioritized on the network vs. ssh, which has very
> > inconsistent network performance. I'd like to use LDAP authentication for
> > my TCP sessions, but I'm not sure how to do this. I've tried setting
> > "--tcp-auth=pam" on the xpra command line, but the Win32 launcher reports
> > "Connection lost" when I try to connect. I get the following output in
> the
> > server-side log file (edited to remove IP addresses and user name):
> >
> > 2016-11-21 10:29:00,367 New tcp connection received from x.x.x.x:x
> > 2016-11-21 10:29:00,369 Authentication required by PAM authenticator
> module
> > 2016-11-21 10:29:00,369  sending challenge for username '<username>'
> using
> > xor digest
> > 2016-11-21 10:29:00,511 client has requested disconnection: invalid
> digest
> > 2016-11-21 10:29:00,512 Disconnecting client x.x.x.x:x:
> > 2016-11-21 10:29:00,512  client request
> The client and server will refuse to send unencrypted passwords over
> TCP, unfortunately PAM requires the actual password rather than a hash -
> unlike the other plugins which can happily use HMAC.
>
> > Any idea how to get this working, keeping in mind the fact that I can't
> do
> > a normal install (i.e. write to "/etc") on the server side?
> If you must use PAM, use SSL or AES encryption. (see wiki for details)
> If not, use a different authentication module.
>
> Cheers
> Antoine
>
> PS: there is a magic environment variable which can be used to force
> xpra to use unencrypted passwords over TCP, but I am not posting it here
> as this is not a good solution.
> _______________________________________________
> 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 Nov 21 16:30:20 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Mon, 21 Nov 2016 23:30:20 +0700
Subject: [winswitch] unix authentication for TCP sessions?
In-Reply-To: <CANUZkSUiQAcWc+tWUqTvRDCBJaVMso186kCRxvsf4qRTUT2+ag@mail.gmail.com>
References: <CANUZkSVOzMgPYmOsEfO4ByRBN8PUB4ks-5-6_WJeEgxGW4SjuQ@mail.gmail.com>
 <322a6a76-43b9-da96-d888-21a1ee839d7d@nagafix.co.uk>
 <CANUZkSUiQAcWc+tWUqTvRDCBJaVMso186kCRxvsf4qRTUT2+ag@mail.gmail.com>
Message-ID: <6272fad2-feda-683f-0e58-4f3c49f0aced@nagafix.co.uk>

On 21/11/16 23:22, Thomas Esposito wrote:
> Ok, so it looks like I need an AES keyfile. I tried omitting
> "--tcp-encryption-keyfile" from the command line, but I get a "missing
> encryption tokens" error in the log. How can I generate a keyfile? Also,
> how do I launch the win32 client with this keyfile (there doesn't seem
> to be a way to do this in the GUI).
Please don't top-post.

The AES key file is just binary data, of any length. Longer and more
random is better / stronger.
Unlike SSL which relies on a chain of trust, with AES you will need to
copy the same keyfile to both client and server.

The launcher GUI does not support setting the AES keyfile, but you can
specify it in the connection file it generates. (to create one just
click save, then you can just double click on that file)

IMO: it's probably easier to go with SSL if you're not too worried about
MITM attacks and trust the self signed certificate.

Cheers
Antoine


> 
> On Mon, Nov 21, 2016 at 10:53 AM, Antoine Martin via shifter-users
> <shifter-users at lists.devloop.org.uk
> <mailto:shifter-users at lists.devloop.org.uk>> wrote:
> 
>     On 21/11/16 22:45, Thomas Esposito via shifter-users wrote:
>     > First some background info...
>     >
>     > I've been using Xpra at work. I have a RHEL 6.6 virtual machine,
>     which I
>     > believe uses LDAP for login authentication. I don't have root/admin
>     > privileges, so in order to use Xpra, I have manually extracted the
>     contents
>     > of all of the required RPMs and modified my PYTHONPATH, PATH,
>     > LD_LIBRARY_PATH, and MANPATH variables to point to where the RPMs are
>     > extracted.
>     >
>     > Since I obviously can't install anything to "/etc", I have all of the
>     > config files in "${HOME}/.xpra". For the beta version of xpra,
>     this means
>     > that I can't install any of the files in "/etc/pam.d" (which is
>     new to the
>     > 1.0 beta).
>     >
>     > In order to get good performance on my corporate intranet, I need
>     to use
>     > raw TCP with a port in the range 5900 5909 (i.e the ports used by
>     VNC),
>     > because this is prioritized on the network vs. ssh, which has very
>     > inconsistent network performance. I'd like to use LDAP
>     authentication for
>     > my TCP sessions, but I'm not sure how to do this. I've tried setting
>     > "--tcp-auth=pam" on the xpra command line, but the Win32 launcher
>     reports
>     > "Connection lost" when I try to connect. I get the following
>     output in the
>     > server-side log file (edited to remove IP addresses and user name):
>     >
>     > 2016-11-21 10:29:00,367 New tcp connection received from x.x.x.x:x
>     > 2016-11-21 10:29:00,369 Authentication required by PAM
>     authenticator module
>     > 2016-11-21 10:29:00,369  sending challenge for username
>     '<username>' using
>     > xor digest
>     > 2016-11-21 10:29:00,511 client has requested disconnection:
>     invalid digest
>     > 2016-11-21 10:29:00,512 Disconnecting client x.x.x.x:x:
>     > 2016-11-21 10:29:00,512  client request
>     The client and server will refuse to send unencrypted passwords over
>     TCP, unfortunately PAM requires the actual password rather than a hash -
>     unlike the other plugins which can happily use HMAC.
> 
>     > Any idea how to get this working, keeping in mind the fact that I can't do
>     > a normal install (i.e. write to "/etc") on the server side?
>     If you must use PAM, use SSL or AES encryption. (see wiki for details)
>     If not, use a different authentication module.
> 
>     Cheers
>     Antoine
> 
>     PS: there is a magic environment variable which can be used to force
>     xpra to use unencrypted passwords over TCP, but I am not posting it here
>     as this is not a good solution.
>     _______________________________________________
>     shifter-users mailing list
>     shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     <http://lists.devloop.org.uk/mailman/listinfo/shifter-users>
> 
> 



From antoine at nagafix.co.uk  Sat Nov 26 13:02:52 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sat, 26 Nov 2016 20:02:52 +0700
Subject: [winswitch] [ANNOUNCE] Xpra 1.0-rc1
Message-ID: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk>

Hi,

The next LTS release is nearly ready.
We don't usually advertise release candidate builds, but this release is
going to be special. For more details see:
http://xpra.org/trac/wiki/News#a1.0ImportantFeatures

Unless major problems are found with these latest builds, the only thing
that will change for the final release is the new logo and icons which
are being worked on [1]. Downloads can be found here:
http://xpra.org/beta/

Cheers
Antoine

[1] Feedback welcome on the direction for the new icons:
http://xpra.org/trac/ticket/1342#comment:3


From achan011 at icloud.com  Sun Nov 27 10:34:49 2016
From: achan011 at icloud.com (Andreas Achatz)
Date: Sun, 27 Nov 2016 11:34:49 +0100
Subject: [winswitch] XPRA on SLES 11
Message-ID: <FF471D82-8D39-48F5-AC71-CDCCC5C87736@icloud.com>

Hey Folks,

at the moment I?m trying to get xpra running on a SLES 11 SP2 without any success. I tried different versions but always end up in dependency problems or non available packages for SLES. Does anyone get it  already running on this ?old? distribution. 

Cheers
Harry

From antoine at nagafix.co.uk  Sun Nov 27 11:40:58 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Sun, 27 Nov 2016 18:40:58 +0700
Subject: [winswitch] XPRA on SLES 11
In-Reply-To: <FF471D82-8D39-48F5-AC71-CDCCC5C87736@icloud.com>
References: <FF471D82-8D39-48F5-AC71-CDCCC5C87736@icloud.com>
Message-ID: <037714ed-33ab-80e4-accb-450813bfec86@nagafix.co.uk>

On 27/11/16 17:34, Andreas Achatz via shifter-users wrote:
> Hey Folks,
> 
> at the moment I?m trying to get xpra running on a SLES 11 SP2 without any success. I tried different versions but always end up in dependency problems or non available packages for SLES. Does anyone get it  already running on this ?old? distribution. 
If you actually include the exact dependency problems you are referring
to, someone might be able to point you in the right direction.
The other option, which may well be easier, is to build from source.

Cheers
Antoine

> 
> Cheers
> Harry
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
> 



From kc7noa at gmail.com  Mon Nov 28 07:02:35 2016
From: kc7noa at gmail.com (Michael Durkin)
Date: Sun, 27 Nov 2016 23:02:35 -0800
Subject: [winswitch] [ANNOUNCE] Xpra 1.0-rc1
In-Reply-To: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk>
References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk>
Message-ID: <CAC8M0EvBxb9W3-4=78xtMwzyj7gJ5ya=aUOxgeruXzcnjztK2A@mail.gmail.com>

i get an odd error ... one that i think should not happen -- i already have
cython installed ... but get errror from building it durring python
setup.py install of xpra v1

http://pastebin.com/DJrB3tMH

On Sat, Nov 26, 2016 at 5:02 AM, Antoine Martin via shifter-users <
shifter-users at lists.devloop.org.uk> wrote:

> Hi,
>
> The next LTS release is nearly ready.
> We don't usually advertise release candidate builds, but this release is
> going to be special. For more details see:
> http://xpra.org/trac/wiki/News#a1.0ImportantFeatures
>
> Unless major problems are found with these latest builds, the only thing
> that will change for the final release is the new logo and icons which
> are being worked on [1]. Downloads can be found here:
> http://xpra.org/beta/
>
> Cheers
> Antoine
>
> [1] Feedback welcome on the direction for the new icons:
> http://xpra.org/trac/ticket/1342#comment:3
> _______________________________________________
> 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 Nov 28 07:05:53 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Mon, 28 Nov 2016 14:05:53 +0700
Subject: [winswitch] [ANNOUNCE] Xpra 1.0-rc1
In-Reply-To: <CAC8M0EvBxb9W3-4=78xtMwzyj7gJ5ya=aUOxgeruXzcnjztK2A@mail.gmail.com>
References: <74aaec11-18b3-61b2-53f2-f15d86bd588d@nagafix.co.uk>
 <CAC8M0EvBxb9W3-4=78xtMwzyj7gJ5ya=aUOxgeruXzcnjztK2A@mail.gmail.com>
Message-ID: <1a73c2de-78d0-2610-2823-78fc9c74bed3@nagafix.co.uk>

On 28/11/16 14:02, Michael Durkin via shifter-users wrote:
> i get an odd error ... one that i think should not happen -- i already have
> cython installed ... but get errror from building it durring python
> setup.py install of xpra v1
> 
> http://pastebin.com/DJrB3tMH
Your version of Cython is too old.

For reference, here's the error message:
Cythonizing xpra/codecs/enc_x264/encoder.pyx
Error compiling Cython file:
------------------------------------------------------------
...
    cdef init_encoder(self, options_dict={}):
        cdef x264_param_t param
        cdef const char *preset
        preset = get_preset_names()[self.preset]
        self.tune = self.get_tune()
        x264_param_default_preset(&param, strtobytes(preset),
strtobytes(self.tune))
                                                   ^
------------------------------------------------------------
xpra/codecs/enc_x264/encoder.pyx:527:52: Obtaining 'char const *' from
temporary Python value

Cheers
Antoine




> 
> On Sat, Nov 26, 2016 at 5:02 AM, Antoine Martin via shifter-users <
> shifter-users at lists.devloop.org.uk> wrote:
> 
>> Hi,
>>
>> The next LTS release is nearly ready.
>> We don't usually advertise release candidate builds, but this release is
>> going to be special. For more details see:
>> http://xpra.org/trac/wiki/News#a1.0ImportantFeatures
>>
>> Unless major problems are found with these latest builds, the only thing
>> that will change for the final release is the new logo and icons which
>> are being worked on [1]. Downloads can be found here:
>> http://xpra.org/beta/
>>
>> Cheers
>> Antoine
>>
>> [1] Feedback welcome on the direction for the new icons:
>> http://xpra.org/trac/ticket/1342#comment:3
>> _______________________________________________
>> 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 sivmu at web.de  Tue Nov 29 10:35:07 2016
From: sivmu at web.de (sivmu)
Date: Tue, 29 Nov 2016 11:35:07 +0100
Subject: [winswitch] Problem on Polaris
In-Reply-To: <dee38625-57d2-3212-a09d-cffa1e103000@nagafix.co.uk>
References: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
 <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>
 <8a26b7d2-4569-8399-e183-f9094ad23354@web.de>
 <96864fb1-8e8f-deb5-98c5-bb4bf520de06@nagafix.co.uk>
 <b14e701a-03ae-d810-55d0-fa7c0c2b0514@web.de>
 <dee38625-57d2-3212-a09d-cffa1e103000@nagafix.co.uk>
Message-ID: <6ddd0809-bf30-6e94-2abc-97494631763e@web.de>


Am 05.11.2016 um 05:55 schrieb Antoine Martin via shifter-users:
> Please file a ticket and attach the output of both the client and server
> running with "--debug all".
> Hopefully we can see at which point it is getting stuck.
>
> Cheers
> Antoine

I tried to register for the bug tracker, but it seems there is something
broken. The image test to rule out bots, does not appear.

Regarding the issue I finally found the time to create the log files
requested. Since I cannot open a ticket at the moment I will just post
this here:

Used commands:

xpra --debug all start :7
DISPLAY=:7 xterm
xpra --debug all attach :7

Resulting logfiles:

https://paste.ee/r/If2rf
https://paste.ee/r/thw5g




From antoine at nagafix.co.uk  Tue Nov 29 10:44:46 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Tue, 29 Nov 2016 17:44:46 +0700
Subject: [winswitch] Problem on Polaris
In-Reply-To: <6ddd0809-bf30-6e94-2abc-97494631763e@web.de>
References: <9d3d23ef-419e-9869-f30b-4a3fc987960c@web.de>
 <15036765-5dc7-4aff-50ca-88758a227d1b@nagafix.co.uk>
 <8a26b7d2-4569-8399-e183-f9094ad23354@web.de>
 <96864fb1-8e8f-deb5-98c5-bb4bf520de06@nagafix.co.uk>
 <b14e701a-03ae-d810-55d0-fa7c0c2b0514@web.de>
 <dee38625-57d2-3212-a09d-cffa1e103000@nagafix.co.uk>
 <6ddd0809-bf30-6e94-2abc-97494631763e@web.de>
Message-ID: <dd837214-228e-d7ac-f99b-455de638e523@nagafix.co.uk>

On 29/11/16 17:35, sivmu via shifter-users wrote:
> 
> Am 05.11.2016 um 05:55 schrieb Antoine Martin via shifter-users:
>> Please file a ticket and attach the output of both the client and server
>> running with "--debug all".
>> Hopefully we can see at which point it is getting stuck.
>>
>> Cheers
>> Antoine
> 
> I tried to register for the bug tracker, but it seems there is something
> broken. The image test to rule out bots, does not appear.
Yes, sorry about that, we're waiting for trac to issue an overdue fix:
https://trac-hacks.org/ticket/11915#comment:28

> Regarding the issue I finally found the time to create the log files
> requested. Since I cannot open a ticket at the moment I will just post
> this here:
> 
> Used commands:
> 
> xpra --debug all start :7
> DISPLAY=:7 xterm
FYI: use this form instead:
xpra start --start=xterm

> xpra --debug all attach :7
> 
> Resulting logfiles:
> 
> https://paste.ee/r/If2rf
> https://paste.ee/r/thw5g
I don't see a client log file, which would be the most interesting one.
(only server log and xorg log in those links)

Cheers
Antoine


From kc7noa at gmail.com  Tue Nov 29 18:25:37 2016
From: kc7noa at gmail.com (Michael Durkin)
Date: Tue, 29 Nov 2016 10:25:37 -0800
Subject: [winswitch] error -- doubt its xpra
Message-ID: <CAC8M0EtRb7QDK6M=SJuv1+fSPz0K0kAV_37DPte0gs7zVymDZA@mail.gmail.com>

im getting an error of sorts and im not sure how to deal with it ,,,

http://pastebin.com/A2NAug19

/usr/bin/ld.bfd.real: /usr/local/lib/libavutil.a(log.o): relocation
R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making
a shared object; recompile with -fPIC
/usr/local/lib/libavutil.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1


From antoine at nagafix.co.uk  Tue Nov 29 18:52:21 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Wed, 30 Nov 2016 01:52:21 +0700
Subject: [winswitch] error -- doubt its xpra
In-Reply-To: <CAC8M0EtRb7QDK6M=SJuv1+fSPz0K0kAV_37DPte0gs7zVymDZA@mail.gmail.com>
References: <CAC8M0EtRb7QDK6M=SJuv1+fSPz0K0kAV_37DPte0gs7zVymDZA@mail.gmail.com>
Message-ID: <be833097-9d36-367e-134d-ba8b9d0e5ac9@nagafix.co.uk>

On 30/11/16 01:25, Michael Durkin via shifter-users wrote:
> im getting an error of sorts and im not sure how to deal with it ,,,
> 
> http://pastebin.com/A2NAug19
> 
> /usr/bin/ld.bfd.real: /usr/local/lib/libavutil.a(log.o): relocation
> R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making
> a shared object; recompile with -fPIC
> /usr/local/lib/libavutil.a: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> error: command 'arm-linux-gnueabihf-gcc' failed with exit status 1
Hmm, yet another strange build problem on arm. I'm not sure why you have
a static library in /usr/local...
And I'm not going to recommend that you try to fix it because it's very
likely that the libav version is going to be too old anyway.
So the best course of action is probably to just build with:
./setup.py build --without-dev_avcodec2 --without-csc_swscale
And see where that gets you.
Hopefully you won't have to turn off too many things to get a working build.

Cheers
Antoine


From roundsparrow at gmail.com  Tue Nov 29 19:41:35 2016
From: roundsparrow at gmail.com (Stephen RoundSparrow)
Date: Tue, 29 Nov 2016 14:41:35 -0500
Subject: [winswitch] xpra v0.17.6 multiple Ubuntu 16.x systems,
 cursor in shadow mode
Message-ID: <CAA3T=y5nGV2r9G21OqDGgW-BpPt8CibHBiDGYi1gMXEnDtWTXg@mail.gmail.com>

Hello. Congrats on the pending 1.0 LTS release. The feature list looks
great.

In shadow mode I've been unable to get the cursor to work. Resizing
cursors, edit cursors, etc just don't appear and it is always an arrow on
the client system.

I have an Ubuntu 16.04 client that I updated from xpra v0.15.8 to the
latest xpra v0.17.6 off the ppa. One host is Ubuntu 16.10 with it's xpra
v0.17.4 and another is Ubuntu 16.04 with it's xpra v0.15.8 version.  I've
tried adding --cursors=yes to client and it shows enabled on the Info
screen but neither host system will pass cursor changes to the client.

Is cursor mirroring in shadow mode unsupported or some other thing to try?

Thank you.


From antoine at nagafix.co.uk  Wed Nov 30 03:02:29 2016
From: antoine at nagafix.co.uk (Antoine Martin)
Date: Wed, 30 Nov 2016 10:02:29 +0700
Subject: [winswitch] xpra v0.17.6 multiple Ubuntu 16.x systems,
 cursor in shadow mode
In-Reply-To: <CAA3T=y5nGV2r9G21OqDGgW-BpPt8CibHBiDGYi1gMXEnDtWTXg@mail.gmail.com>
References: <CAA3T=y5nGV2r9G21OqDGgW-BpPt8CibHBiDGYi1gMXEnDtWTXg@mail.gmail.com>
Message-ID: <0b26208d-c555-264d-d66b-0fe63d00f487@nagafix.co.uk>

On 30/11/16 02:41, Stephen RoundSparrow via shifter-users wrote:
> Hello. Congrats on the pending 1.0 LTS release. The feature list looks
> great.
> 
> In shadow mode I've been unable to get the cursor to work. Resizing
> cursors, edit cursors, etc just don't appear and it is always an arrow on
> the client system.
> 
> I have an Ubuntu 16.04 client that I updated from xpra v0.15.8 to the
> latest xpra v0.17.6 off the ppa. One host is Ubuntu 16.10 with it's xpra
> v0.17.4 and another is Ubuntu 16.04 with it's xpra v0.15.8 version.  I've
> tried adding --cursors=yes to client and it shows enabled on the Info
> screen but neither host system will pass cursor changes to the client.
> 
> Is cursor mirroring in shadow mode unsupported or some other thing to try?
Not supported yet, sorry.

Cheers
Antoine