| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
They define macros such as "check()" which causes our code to break as
we have methods with that name.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
The new vnc_home_t type for HOME/.vnc directory was added to the policy,
backed by a name transition. The vnc_session_t domain can manage files
and directories of this type.
|
| |
| |
| |
| |
| |
| |
| | |
The permissions set to manage directories and files with the nfs_t type
is allowed when the use_nfs_home_dirs boolean is turned on.
Resolves: https://github.com/TigerVNC/tigervnc/issues/1189
|
| |
| |
| |
| |
| |
| | |
Sections and rules blocks reordered according to the Style guide.
https://github.com/TresysTechnology/refpolicy/wiki/StyleGuide
|
| |
| |
| |
| |
| |
| | |
Style guide [1] issues only. No impact on policy functionality.
[1] - https://github.com/TresysTechnology/refpolicy/wiki/StyleGuide
|
| | |
|
| | |
|
|\ \ |
|
| | | |
|
| | | | |
| \ \ | |
| \ \ | |
| \ \ | |
|\ \ \ \ \
| |_|_|/ /
|/| | | |
| | | | | |
'fix-case-insensitive-fs' of https://github.com/arichardson/tigervnc
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
I am cross-compiling from macOS for a FreeBSD-derived system so my host
file system is case insensitive but the target isn't. Without this change
I get the following warnings which show that the vnc "Input.h" is being
included from mi/mi.h instead of the xserver "input.h":
```
In file included from /Users/alex/cheri/xvnc-server/hw/vnc/Input.c:33:
/Users/alex/cheri/xvnc-server/mi/mi.h:55:10: warning: non-portable path to file '"Input.h"'; specified path differs in case from file name on disk [-Wnonportable-include-path]
#include "input.h"
^~~~~~~~~
"Input.h"
```
|
| | |/ /
| | | |
| | | |
| | | |
| | | | |
Without this change I get CMake errors due to use of ${FLTK_INCLUDE_DIR}
and references to the non-existent vncviewer target.
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
Some operating systems such as FreeBSD don't define a HOST_NAME_MAX
macro. The portable approach to determine the real host name limit is
calling sysconf(_SC_HOST_NAME_MAX) so do that instead.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes regression introduced by the extended clipboard extension.
Previously it was possible for the server to hold on to the CLIPBOARD
selection even if another application took ownership of PRIMARY. This is
important to handle the common use case of selecting something in order
to paste over it.
The new request based model doesn't readily support this as we assume
the client has lost its data once we push the new PRIMARY selection to
it. So to handle this we have the maintain a cache of the client's data,
and make sure to fill that cache before we do anything that might cause
the client to lose the data.
|
| | |
| | |
| | |
| | |
| | | |
We only need to check the event type once, and preferably early, and
avoid doing more work than necessary.
|
| | |
| | |
| | |
| | |
| | | |
We don't want the log to spam every time this parameter is used so only
complain from the parses when the value is changed.
|
| | |
| | |
| | |
| | |
| | | |
This class is generic and should not reference a specific instance of
it.
|
| | |
| | |
| | |
| | | |
Try to be consistent with existing log messages.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix some indentation issues and make sure everything* uses CamelCase.
* MonitorArrangement is left as snake_case in order to pretend it is an
independent FLTK widget class.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
MonitorArrangement (in the options dialog) never changes when the system
monitor configuration changes. Therefore, the user can get into a state
where the reality doesn't match what is shown (when a monitor is
added/removed, resolution or position changed etc).
All these changes triggers an event in FLTK
(FL_SCREEN_CONFIGURATION_CHANGED). This commit adds an event handler in
MonitorArrangement and refreshes the widget whenever that event occurs.
Because Fl_Handler does not have a void*-argument (and we must be able
to access the widget from our handler callback) a static set of
instances have been added, which all will receive the events.
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It might be useful to have more information about a monitor when
configuring its settings in the Options menu. Therefore, this commit
adds support for showing additional information about a monitor
(resolution and platform-specific name).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There are no guarantees from the WM that calling `fullscreen_screens`
with all monitor indices set to `-1` results in the window's current
monitor being used. Because FullScreenMode uses the word "current"
we want to explicitly ask the WM to use that monitor.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The user might not always want to use all monitors when in fullscreen
mode, but instead only a few. This commit adds support for configuring
selected monitors from command line, in the config file and graphically
in the options menu.
Because it might be hard to guarantee the consistency of monitor
identifiers coming from third-parties (for example FLTK), it has been
decided to use our own numerical identifier. This identifier is based on
the monitor's positions. The mapping between this identifier and the
indices used by FLTK is done by MonitorIndicesParameter.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before this commit, `FullScreen` and `FullScreenAllMonitors` could be
used to configure whether to use the current monitor in fullscreen,
or all monitors in fullscreen.
This commit deprecates `FullScreenAllMonitors` in favour of
`FullScreenMode` (which can either be `current` or `all`). This allows
for additional modes to be added, without the risk of having invalid
states (for example two activate two different fullscreen modes at the
same time).
A new concept has been added; read-only parameters. They are parameters
that will be read, but never written back. This allows for migration
paths to be constructed, where a parameter can be taken to consideration
but then for example be discarded, logged or changed into something else.
This has been used for `FullScreenAllMonitors` to provide a migration
path. On startup of vncviewer, if `FullScreenAllMonitors` is enabled,
`FullScreenMode=all` will be automatically enabled instead. The next
time the configuration file is written to disk, `FullScreenAllMonitors`
will then be removed.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, it was assumed that all monitors (and especially the primary
monitor, index 0) was inside the window when we calculate the position
of the overlay.
That might not always be the case, for example when using fullscreen
mode over a narrower set of monitors. This commit does so the overlay is
positioned correctly based on the actual window size, instead of what we
expect it to be.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
cocoa_capture_displays it captures all displays enclosed by the
window_rect. If a set of displays were captured, but the configuration of
what monitors to use changed, a second call would only add to the set
of captured displays. Therefore, if the user enabled
FullScreenAllMonitors (all displays captured) and then disabled it (only
one display captured) they would get into a state were monitors not used
for the VNC session still were captured (which on macOS for example,
results in displays being unusable for other things).
This has now been fixed, resulting in monitors outside the window_rect
not being unnecessarily captured.
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It was only possible to capture either the current, or all displays
previously. This could become an issue if you want to show a vnc session
over only a selected set of displays, because then we only want to
capture those displays.
The solution in the commit was chosen because it handles all cases - by
looking at what monitors are enclosed by the viewport the implementation
is independent on any configuration, but instead captures the monitors
actually being used.
|
|/ /
| |
| |
| |
| | |
The call of gnutls_set_default_priority_append() expects a normal priority
string, which means it must not start with ':'.
|
|\ \ |
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Xvnc was originally based on Xvfb, but it's just confusing to keep the
names. So change all prefix to "vnc" instead to clearly mark things as
part of TigerVNC.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
It isn't really useful as it behaves just like starting multiple
servers, so remove it in favour of keeping things simple.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a development flag with no real use, so remove it to clean up
the code.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Remove stuff we don't use, and get it more in sync with Xvfb for easier
comparison.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
This was removed years ago.
|
| | | |
| | | |
| | | |
| | | | |
The memory leak this worked around was fixed in X.org 1.16.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Keep everything in one place to make it easier to read.
This also removes the call to RRInit() as that is done implicitly
anyway.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
There's been a common one since X.org 1.11, so use that instead of our
own copy.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't build for that platform anyway, so this is just a remnant from
Xvfb.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With the 1.20.x releases there has been features and API changes even on
patch level versions, so we need to update our macros to handle these as
well.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a pointless remnant of Xvfb. We never print the id of the shared
memory, so no other application can access this memory anyway.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This hasn't been supported or used in many years, so clean out the final
remnants.
|
| | | |
| | | |
| | | |
| | | | |
This hasn't been used since xorg-server 1.1 so get rid of it.
|
| | | |
| | | |
| | | |
| | | | |
This is consistent with other ddx behaviour.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This is what all the other ddx variants use, so do the same in Xvnc to
be consistent.
|