Xpra: Ticket #461: allow authenticated command line clients to control the server

we should be able to control:


Thu, 21 Nov 2013 15:26:50 GMT - Antoine Martin:

Good enough for a round of testing. This will be very useful for implementing more selective debugging (#411).


Undocumented features...:


Unless otherwise stated, all the commands given below should exit with no error code ("0"):

xpra ...
echo $?

Thu, 21 Nov 2013 15:28:08 GMT - Antoine Martin: owner changed

Wed, 04 Dec 2013 13:35:13 GMT - Antoine Martin:

r4855 adds "fadein" and "fadeout" sound control commands. ie:

xpra control :10 sound-output fadeout

r4860 adds support for an optional fadeout delay, the command becomes:

xpra control :10 sound-output fadeout 500

The delay is specified in milliseconds (in the example: 0.5 seconds)

Thu, 05 Dec 2013 02:49:06 GMT - alas:

Connecting with an osx client via command line, and trying to enter the commands listed within the same terminal shell I get no response. The commands type, but don't seem to be received/interpreted at all.

osx client 0.11.0-r4855; fedora19 server 0.11.0-r4840

2013-12-04 18:25:33,800 GL Extension GL_KHR_debug unavailable
2013-12-04 18:27:04,446 re-starting speaker because of overrun
2013-12-04 18:27:04,912 using audio codec: MPEG 1 Audio, Layer 3 (MP3)
xpra control :16 help
xpra control :10 help
xpra control :16 compression zlib
xpra control :10 compression zlib
xpra info } grep connection.compression=
xpra info | grep connection.compression=

I assume there's something painfully obvious that I'm missing?


Thu, 05 Dec 2013 03:29:14 GMT - Antoine Martin:

afarr: unless you're running an xpra server on osx display :10 or :16, xpra is simply failing to connect since you're not specifying a valid connection point. This should be obvious by removing the '| hero' from the command line.

Thu, 05 Dec 2013 20:35:23 GMT - alas:

I was running the xpra session on display :16 of the linux server, then connecting to it by means of the osx terminal ./xpra attach tcp:stuff:1202

Should I be specifying the port on the client side, rather than the server-side specified display? (I'll keep poking at it and see what I see in the meantime.)

Fri, 06 Dec 2013 01:17:34 GMT - Antoine Martin:

Please post the exact commands that you've used, the ones from comment:4 are confusing and look wrong.

Please also try another client OS (Fedora?), maybe OSX has problems.

Fri, 06 Dec 2013 01:52:25 GMT - alas:

I launched the xpra server on a just-yum-updated Fedora 19 vm with the command dbus-launch xpra --no-daemon --bind-tcp= --start-child=xterm --start-child=xterm start :16

I then launched the osx client through a terminal window with the command ./xpra attach tcp: --opengl=on in the instance mentioned in comment:4.

The client outputted its usual startup output... the last 3 lines of which I copied, hoping it would make it apparent exactly where I was trying to use the commands from.

In the terminal window, once I'd gotten that usual output, I tried to enter the commands that I copied & pasted in comment:4. I used xpra control :16 help to start because I'd specified display :16 on the server side (and hoped that it would thusly be interpreted by the session).

As you can see though, I got no response from the server.

We ran into some wrinkles with the windows client, but I'll try that and maybe a fedora soon.

Fri, 06 Dec 2013 13:00:59 GMT - Antoine Martin:

If you're typing those "xpra control" commands from within an xpra session (therefore running on the server already), then changing client OS and version will make no difference at all. BTW, saying "within the same terminal shell" is confusing: the OSX command line is a shell too.

I don't see how it is possible for "xpra control" not to print anything on screen, at least an error of some sort. It seems you may also have run "xpra info", and that always returns something. So something seems to be very wrong with your setup. Does the server even receive a new connection when you run those commands, or are those commands not doing anything at all?

Anyway, r4865 adds the ability to change window scaling on the fly too (which will also need testing), like so:

xpra control DISPLAY scaling WINDOW-ID scaling-value

Where WINDOW-ID can be found via "xpra info", or "*" can be used as wildcard. The scaling-value takes the same form as the hardcoded ones already documented here: wiki/CSC.

Here are some examples:

Tue, 10 Dec 2013 01:52:37 GMT - alas:

Testing with osx client 0.11.0-r4905 and fedora 19 server 0.11.0-r4904.

It looks like the suspend command xpra control :16 suspend stops the video playback, but the sound continues. The resume command xpra control :16 resume not only resumes the video, but brings it back in sync with the sound which had continued all along.

Compression changes, with your 0.11.0-r4903 osx client build, seem to work, but are not displayed by the Xpra session-info window, though xpra info :16 | grep 'compression' shows the compression to have changed.

The name function seems to work (though I was only able to determine that with recourse to an xpra info call).

The sound-output stop, start, fadeout, and fadein all seem to work beautifully.

It would be nice to see more verbosity in the xpra control :display help command... when it is a little more settled.

Tue, 10 Dec 2013 05:12:59 GMT - Antoine Martin: status changed; resolution set

suspend stops the video playback, but the sound continues

That's the idea, we have control commands for both. Mostly just a PoC at this point. Not sure how useful that is going to be.

Compression changes .. but are not displayed by the Xpra session-info window

That's because the client compression is not changed, only the server one. Remember that network packets flow in both directions, this affects sending only. (and although we could add protocol support for telling the client to follow suit - I don't think it is worth the complexity, as the client sends very little data compared to the server, so compression really doesn't matter much in this direction)

Note: where lz4 makes the most difference is when we send fairly large amounts of data and not already compressed with a picture encoding. That is:

It would be nice to see more verbosity in the xpra control :display help command

Yes, it would be...

Wed, 08 Jan 2014 04:54:06 GMT - Antoine Martin:

Further enhancements:

Use it like so:

xpra control :10 client show_session_info


xpra control :10 client show_session_info Statistics

Wed, 08 Jan 2014 05:46:45 GMT - Antoine Martin: status changed; resolution deleted

r5148 re-uses the same mechanism so we can now forward bencode/rencode and zlib/lz4 changes to the client:

xpra control :10 encoder bencode

Causes this on the client:

switching to bencode on server request

Which can be verified with:

xpra info | egrep "connection.encoder=|connection.compression="



This was handy for testing and finding an existing bug: this causes the connection to drop instantly:

xpra control :10 client show_session_info Statistics
xpra control :10 encoder bencode

with improved error handling and logging from r5149 + r5150, we see:

None value in 'hello' packet->[1]->value for key='window[1].property.scaling'
error in write format loop
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 394, in _write_format_thread_loop
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 405, in _add_packet_to_queue
    chunks, proto_flags = self.encode(packet)
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 576, in encode
    raise e
ValueError: cannot encode '[2, {'network.bencode': True, 'keyboard.keysym.Hangul': 130, 'window[...

We have an illegal None value in the window's scaling property, this is fixed in r5151 (should be backported too).

There are enough changes here to warrant more testing, especially with the bencoder enabled at both ends as this is the only encoder supported by html5 (#473) and java clients. Re-opening the bug.

Thu, 09 Jan 2014 00:39:01 GMT - Smo:

Tested these new functions

xpra control :13 client show_session_info
client control command 'show_session_info' forwarded
$ xpra control :13 client show_session_info Statistics
client control command 'show_session_info' forwarded
$ xpra control :13 client show_session_info Statistics
client control command 'show_session_info' forwarded
$ xpra control :13 encoder bencode
$ xpra info | egrep "connection.encoder=|connection.compression="

All worked with no issue

Thu, 09 Jan 2014 01:35:35 GMT - Antoine Martin: status changed; resolution set

Fri, 31 Jan 2014 04:19:01 GMT - Antoine Martin:

Note: some improvements in this area for 0.12:

Fri, 06 Jun 2014 07:37:44 GMT - Antoine Martin:

Important change in 0.14 (see r6664): the order of the arguments has changed so that all the commands use a similar structure, with the windows IDs at the end (if any). Here are some examples:


When specifying a list of windows, you can leave it empty to imply all the windows or specify * which has the advantage of being more explicit.

Wed, 16 Jul 2014 23:51:21 GMT - aradtech: priority, status changed; resolution deleted

I am unable to get the xpra control scaling command to work for me. I am using Server Linux Fedora 20 0.14.0 6898 2014-07-16

XPRA_SCALING=1 xpra start :100 --start-child=xterm --no-daemon --bind-tcp=

Windows Client Version 0.14.0 6896 2014-07-14

xpra attach tcp:clientip:10000

get a xterm start up firefox in it

then on the server I issue the following commands

[aradtech@localhost .xpra]$ xpra control :100 scaling 1:1 "*"
scaling set to None on window [1, 2, 14] for 1 clients
[aradtech@localhost .xpra]$ xpra control :100 scaling 2:3 "*"
scaling set to None on window [1, 2, 14] for 1 clients
[aradtech@localhost .xpra]$ xpra control :100 scaling 2:3 "*"
scaling set to None on window [1, 2, 14] for 1 clients
[aradtech@localhost .xpra]$ xpra control :100 scaling 1:3 "*"

as you can see it always says that scaling is set to none , no matter what scaling factor is set to.

I was also unable to figure out how to send that command from the client side to server side so perhaps some clarification on how to go from remote to server using tcp with the control command.

Also I am using x264 encoding.

Thu, 17 Jul 2014 08:31:22 GMT - Antoine Martin: owner, status changed


This has been broken for a very long time! (we need regression tests) r6899 fixes this (and will need to be backported).

As for sending from client to server, there are examples you can use:

Tue, 29 Jul 2014 10:46:31 GMT - Antoine Martin: priority changed

Can I close this?

Fri, 01 Aug 2014 13:11:52 GMT - Antoine Martin: status changed; resolution set

Sun, 04 Jan 2015 11:58:03 GMT - Antoine Martin:

Improvement to logging control in r8377: we only enable / disable logging on the loggers that match ALL the categories supplied. This makes it much more useful as it is now much more selective if needed. ie:

xpra control :10 debug enable x11 focus

Will not enable focus debugging on loggers that are not both x11' and focus.

Sat, 23 Jan 2021 04:56:15 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/461