#461 closed enhancement (worksforme)
allow authenticated command line clients to control the server
Reported by: | Antoine Martin | Owned by: | aradtech |
---|---|---|---|
Priority: | critical | Milestone: | 0.11 |
Component: | server | Version: | |
Keywords: | Cc: |
Description
we should be able to control:
- sound (stop, start)
- change current encoding
- compression (switch to lz4 or zlib)
- debugging
- suspend/resume window updates
etc
Change History (23)
comment:2 Changed 7 years ago by
Owner: | changed from Antoine Martin to alas |
---|
comment:3 Changed 7 years ago by
comment:4 Changed 7 years ago by
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?
Maybe XPRA_CONTROL=1?
comment:5 Changed 7 years ago by
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.
comment:6 Changed 7 years ago by
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.)
comment:7 Changed 7 years ago by
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.
comment:8 Changed 7 years ago by
I launched the xpra server on a just-yum-updated Fedora 19 vm with the command dbus-launch xpra --no-daemon --bind-tcp=0.0.0.0:1202 --start-child=xterm --start-child=xterm start :16
I then launched the osx client through a terminal window with the command ./xpra attach tcp:10.0.32.172:1202 --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.
comment:9 Changed 7 years ago by
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:
- scale window "1" by half:
xpra control :10 scaling 1 1:2
- scale all windows by two thirds:
xpra control :10 scaling "*" 2:3
comment:10 Changed 7 years ago by
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.
comment:11 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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:
- cursors (usually around 4 to 10KB)
- clipboard data (varies - has an upper limit)
- picture data in
RGB
encoding (or when we send smaller regions asRGB
with h264/vpx video encoders) - hello packets (non-critical as this happens just once on startup)
It would be nice to see more verbosity in the xpra control :display help command
Yes, it would be...
comment:12 Changed 7 years ago by
Further enhancements:
- r5145 allows us to request the client to show the "session info" dialog
- r5146 allows us to choose which tab is shown (both from keyboard shortcuts and remote server requests)
Use it like so:
xpra control :10 client show_session_info
or:
xpra control :10 client show_session_info Statistics
comment:13 Changed 7 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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="
Showing:
client.connection.compression=lz4 client.connection.encoder=bencode
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 self._add_packet_to_queue(*self._get_packet_cb()) 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.
comment:14 Changed 7 years ago by
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 success $ xpra info | egrep "connection.encoder=|connection.compression=" client.connection.compression=lz4 client.connection.encoder=bencode
All worked with no issue
comment:15 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:16 Changed 7 years ago by
comment:17 Changed 7 years ago by
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:
- Set auto-refresh to 0.5 seconds for all windows (the two versions are equivalent):
xpra control auto-refresh 0.5 xpra control auto-refresh 0.5 '*'
- Disable (value=0) auto-refresh for window id 4:
xpra control auto-refresh 0 4
- Full quality refresh of window 2 and 7:
xpra control refresh 2 7
- Set scaling to 1:3 for all windows:
xpra control scaling 1:3
- Disable scaling for window 5 and 6:
xpra control scaling 1:1 5 6
- Set minimum quality to 60 for all windows:
xpra control min-quality 60 '*'
- In 0.14, we also add an optional
strict
(ornostrict
) argument to the encoding control:xpra control encoding strict jpeg
- Use nostrict to return to the default, more dynamic encoding selection. Here we switch windows 5 and 8 to h264:
xpra control encoding nostrict h264 5 8
etc...
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.
comment:18 Changed 7 years ago by
Priority: | minor → major |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
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=0.0.0.0:10000
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.
comment:19 Changed 7 years ago by
Owner: | changed from alas to aradtech |
---|---|
Status: | reopened → new |
Note:
XPRA_SCALING=1
is not necessary, scaling is enabled by default.- for debugging, you can use
-d scaling
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:
xpra control
itself- tests/xpra/clients/test_change_settings.py does exactly that (the logic for connecting and authenticating is in the superclass it shares with
xpra control
)
comment:21 Changed 7 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:22 Changed 6 years ago by
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.
comment:23 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/461
Good enough for a round of testing.
This will be very useful for implementing more selective debugging (#411).
Notes:
:10
") because it is easier, but any authenticated client can control the serverUndocumented features...:
control sound-output start [codec]
" : at present, the codec is usually chosen automatically, but may be specified as an extra argument - though again, this may change.. beware, this is not an API.Testing
Unless otherwise stated, all the commands given below should exit with no error code ("
0
"):help
" should give the list of supported commands:XPRA_SOUND_DEBUG=1
to get more debug logging)