| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Use TRUE and FALSE like dix does.
|
|
|
|
| |
there's no need for that variable to be tri-state
|
| |
|
|
|
|
| |
We have it disabled by default but there hasn't been a way to enable it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rep->generic.sequenceNumber is of type CARD16
state->sequence is of type unsigned long
Converting state->sequence to an int as it has been done since the
first version of nxcomp I know of (1.3.0-18 from 2003) is wrong here
because for numbers > INT_MAX this will result in a negative number,
which, after applying the 16bit modulo, will not match
rep->generic.sequenceNumber.
Example with numbers:
CARD16 c = 24565
unsigned long u = 3179110389
c % 65536 = 24565
u % 65536 = 24565
(int)(u) = -1115856907
(int)(u) % 65536 = -40971
-40971 will not match 24565
To fix this we need to ensure the number stays positive. We use CARD16
for this to match the type in the request which is a 16bit number. On
my system CARD16 is unsigned short which is guaranteed to contain _at
least_ the 0-65,535 range. As there is no upper limit of the range we
cannot drop the modulo because we need this value to be 16bit and not
more.
Thanks to Norm Green for providing log after log until we could
finally identify the reason for him seeing "Xlib: unexpected async
reply (sequence 0x94b01439)!" when pasting stopped working.
|
|
|
|
|
| |
An X reply contains a type which is X_Reply or X_Error. This is not an
opcode which is used when installing the handler.
|
|
|
|
| |
Should help in debugging "unexpected async reply" problems
|
| |
|
| |
|
| |
|
|
|
|
|
| |
it was the default for years now, so let's drop the define and include the
code unconditonally.
|
|
|
|
|
| |
was never used in the past years, we were always compiling with
-DNXAGENT_SHAPE2
|
| |
|
|
|
|
|
| |
marking all the code that is not really required when not using
nomachine's nxclient.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Backport of this xorg-xserver commit:
commit 941aeb3b92e644923bd112eef8023f033a140ee6
Author: Olivier Fourdan <ofourdan@redhat.com>
Date: Fri May 13 08:58:58 2016 +0200
randr: Do not update ConnectionInfo if NULL
RRScreenSizeNotify() will update the connection information block, but
if this occurs during initialization before ConnectionInfo is even
initialized, this will lead to a crash.
Simply check for ConnectionInfo prior to update it to avoid the crash.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95337
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes ArcticaProject/nx-libs#1009
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rep->generic.sequenceNumber is of type CARD16
state->sequence is of type unsigned long
Converting state->sequence to an int as it has been done since the
first version of nxcomp I know of (1.3.0-18 from 2003) is wrong here
because for numbers > INT_MAX this will result in a negative number,
which, after applying the 16bit modulo, will not match
rep->generic.sequenceNumber.
Example with numbers:
CARD16 c = 24565
unsigned long u = 3179110389
c % 65536 = 24565
u % 65536 = 24565
(int)(u) = -1115856907
(int)(u) % 65536 = -40971
-40971 will not match 24565
To fix this we need to ensure the number stays positive. We use CARD16
for this to match the type in the request which is a 16bit number. On
my system CARD16 is unsigned short which is guaranteed to contain _at
least_ the 0-65,535 range. As there is no upper limit of the range we
cannot drop the modulo because we need this value to be 16bit and not
more.
Thanks to Norm Green for providing log after log until we could
finally identify the reason for him seeing "Xlib: unexpected async
reply (sequence 0x94b01439)!" when pasting stopped working.
|
|
|
|
| |
It was the only dialog that had a linefeed a the end.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should help with clients requesting window manager actions like
maximizing or minimizing. This is a first version as it only handles
messages of type WM_STATE_CHANGE and _NET_WM_STATE. But ICCCM and EWMH
know some more.
The other direction, setting of properties by the WM, is already
implemented in Rootless.c.
Fixes ArcticaProject/nx-libs#1015
|
| |
|
| |
|
|
|
|
| |
Fixes ArcticaProject/nx-libs#991
|
| |
|
|
|
|
|
| |
Make it obvious that GetWindowProperty() and ChangeWindowProperty are
not derived from dix.
|
|
|
|
| |
by calling the dix version after a check
|
| |
|
| |
|
|
|
|
| |
remove unneccessary parentheses
|
|
|
|
|
|
|
|
| |
make it compile again
Thanks to Simon Matter for reporting this and the patch.
Fixes ArcticaProject/nx-libs#993
|
| |
|
|
|
|
|
|
| |
We can now also drop all remaining NX specific lines from the security.c
see ArcticaProject/nx-libs#988
|
|
|
|
|
|
|
|
| |
This reflects the path where the file is placed after installation.
It also obsoletes the NX_ALTERNATIVEPOLICYFILE.
Fixes ArcticaProject/nx-libs#988
|
| |
|
|
|
|
| |
Fixes ArcticaProject/nx-libs#987
|
|
|
|
|
|
| |
Is required for compilations with musl.
See ArcticaProjects/nx-libs#975 and ArcticaProjects/nx-libs#976
|
| |
|
|
|
|
|
|
|
|
| |
This used to be printed only in TEST mode. Some while ago I had
changed that to WARNING (because it is a warning...). However, this
happens e.g. when running the xscreensaver vfeedback module and it
does not look like it is a problem at all. So let's suppress this
warning again and leave it to the TEST mode as it used to be.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
although there is no functional difference...
|
| |
|
| |
|
|
|
|
| |
PVS finding: "V522 There might be dereferencing of a potential null pointer 'props'"
|
|
|
|
| |
PVS finding: "V522 There might be dereferencing of a potential null pointer 'nxagentConfiguredWindowList'."
|
|
|
|
| |
PVS finding: "V522 There might be dereferencing of a potential null pointer"
|