GFX and SurfaceBits commands share a common codec backend.
Recreating all codec context on GFX initialization will break
clients that are decoding SurfaceBits codec while having the GFX
channel initialized.
(cherry picked from commit 91a6ac131370c48a742b8bcc58ad188bb7ed60f8)
the discrete axis event gives changes in steps just like the
xfreerdp version uses. This way scrolling can be implemented
consistent with the behaviour of xfreerdp
(cherry picked from commit 2cce37a82a08b0a7c24302a6819371218dea1ec6)
Removes the changes to connection type in gcc_write_client_core_data and
adds some checks if network detection is enabled when receiving network
detection requests.
(cherry picked from commit 43825e364e9580eab08cae84dfd8021d16828730)
I personally find it more convenient to have pasted data written to
the X11 PRIMARY selection, so that I can paste it with a fast middle-
button click, than to write to CLIPBOARD which typically needs a key
sequence or menu action.
This commit adds a command-line option to let me express that
preference: now I can say "/clipboard:use-selection:PRIMARY" on the
command line, which not only enables clipboard transfer but also says
which X selection I want it to talk to. The previous options
"+clipboard" and "-clipboard" are also still supported.
(cherry picked from commit 64948b96c4c4640078ce563b165a907251fd6f20)
Now you can give an option the combination of flags
COMMAND_LINE_VALUE_OPTIONAL and COMMAND_LINE_VALUE_BOOL. If you do,
then all three of the syntaxes +foo, -foo and /foo:value are allowed
at once, and the receiving code can tell the difference because the
Value field is set to BoolValueTrue, BoolValueFalse or a valid char
pointer.
(cherry picked from commit 22c6b375d4ae9bf9dcac74d3360d0042673f1353)
A selection owner is supposed to respond to a request for the
selection target TIMESTAMP by providing the X server time at which the
selection was written. There was a /* TODO */ comment in xf_cliprdr
where the code to do that should have been.
The absence of this can cause a problem when pasting into some X
clients. xtightvncviewer, in particular, will give up the attempt to
read from the clipboard at all if it doesn't get a satisfactory
response to the initial TIMESTAMP request - and the non-answer zero
value "CurrentTime" counts as unsatisfactory. It won't be happy with
anything short of a real X server time value.
(Checking the VNC source code, that's because it reads both PRIMARY
and CLIPBOARD and picks the one with the later timestamp. So it does
depend on the timestamps existing.)
When you're writing to the selection in response to a normal X event
like a mouse click or keyboard action, you get the selection timestamp
by copying the time field out of that X event. Here, we're doing it on
our own initiative, so we have to _request_ the X server time. There
isn't a GetServerTime request in the X protocol, so I work around it
by setting a property on our own window, and waiting for a
PropertyNotify event to come back telling me it's been done - which
will have a timestamp we can use.
(cherry picked from commit fcabbc9707e23b94d7e82021e997578fb20c9313)
* The display resolution change message was prone to a race condition
* Check for actual fullscreen state instead of settings
* Assume 75dpi for display resolution to mm conversion
(cherry picked from commit 13c8a60b7095c141321cd2d09f3e36466d54a748)
