| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| | |
Lay the groundwork for a more intelligent selection of GPU in systems
that have multiple cards. This initial implementation simply picks the
first GPU that we have permission to open.
|
| |
| |
| |
| |
| | |
Allows users to use a secondary GPU, or to disable DRI3 in case of
issues.
|
| |
| |
| |
| |
| |
| |
| |
| | |
One GNOME developer had a bad experience with VNC one time, and
therefore all VNC must forever be punished.
Avoid detection by GNOME so that animations aren't forcefully disabled
without any option for the user to re-enable them.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This provides buffer sync with the primary render node of the system (if
available). By doing so, OpenGL and Vulkan can use the render node for
acceleration.
This first implementation is extremely pessimistic and synchronises
buffers whenever there's even a slight chance they will be used.
|
| |
| |
| |
| |
| |
| |
| | |
It was incorrectly designed to only build properly if built as part of
the "Xorg" server and could fail to build when just "Xvnc" was built.
Backport of upstream commits 0ce93e5 and acc581c.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Windows aren't always directly shown, e.g. when the desktop is
composited. We should not be sending screen updates for these as the
framebuffer didn't actually change.
In the case of CopyWindow, we're even sending the wrong screen data,
which is how this bug was discovered.
|
|\ \
| | |
| | | |
Updates for package builds
|
| | | |
|
| | | |
|
|\ \ \
| | |/
| |/| |
|
| | |
| | |
| | |
| | | |
These are no longer used in the versions of Xorg currently in use.
|
| | |
| | |
| | |
| | |
| | | |
No current distribution uses anything older, so let's make things easier
for us to maintain.
|
| | |
| | |
| | |
| | |
| | | |
Ubuntu 18.04 has been EOL for almost a year, so remove those packages so
we can ease our maintenance burden.
|
| | |
| | |
| | |
| | |
| | |
| | | |
Things do not need to be this complicated. We can make sure the VNC
extension is always included in a much cleaner way, at least since Xorg
1.16.
|
| | |
| | |
| | |
| | | |
This hasn't been needed since Xorg 1.16.
|
| | |
| | |
| | |
| | |
| | | |
Unclear why this was ever needed. libX11 is for X11 clients, and we're
building a server.
|
| | |
| | |
| | |
| | |
| | | |
Make things a bit easier to maintain. This style is also more in line
with what is being done for other DDX.
|
| | |
| | |
| | |
| | | |
This has never actually been used, as far as I can tell.
|
| | |
| | |
| | |
| | |
| | | |
Rather than disabling this, make sure the build can find the relevant
file.
|
| | |
| | |
| | |
| | |
| | | |
VENDOR_RELEASE has been available as a #define since Xorg 1.7, so let's
use that and remove all of our custom magic.
|
|\| |
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Run the frame clock at a slow 1 Hz if there are no clients connected.
This is similar to what a normal X server does when the screen is
blanked, and should keep applications waiting for the frame tick happy.
Note that we still only keep the frame clock running if there is any
application that are interested in it. Otherwise we still stop it
completely.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If there is something interested in synchronizing to a frame tick, then
keep the frame clock running, even if there are no updates.
This is need mainly when something starts rendering, but also when
something renders much slower than the frame clock (so it is essentially
constantly "starting"). Such an application will not draw anything until
it gets a new frame tick, which it won't get as the frame clock is
waiting for something to start drawing.
|
| |
| |
| |
| |
| |
| | |
This marks the timer as started again, before we call out to various
external places that might be confused by the frame timer reporting that
it is stopped.
|
| |
| |
| |
| |
| |
| |
| | |
This makes it possible for applications to synchronize their updates to
the updates sent out to clients. This avoids tearing, and could in the
future also help with rate limiting applications to what the client can
actually show.
|
| | |
|
| |
| |
| |
| |
| | |
Let's avoid requring these as a desktop implementation can now set up
everything in the init() method.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The desktop isn't completely paused just because there are no clients,
so it might still need some support from the server object.
This is primarily an issue for headless servers, where they need to
continue emulating things even without clients. A scraping server can
generally go completely passive if there are no clients.
|
| | |
|
| |
| |
| |
| |
| |
| | |
One-shot timers are more common, so let's change the API a bit to make
that use case simpler. This API also makes it more clear what is
happening.
|
| |
| |
| |
| | |
They were badly formatted, way longer than the normal 72 columns.
|
| |
| |
| |
| |
| |
| | |
It currently won't ever be called with an empty list of timers, but it
is a public function so that might happen in the future. Make sure this
case is handled without crashes.
|
| |
| |
| |
| |
| | |
It is much more sane to treat "0" as "a timer is ready NOW", so let's
change to using -1 as the invalid timeout value.
|
| |
| |
| |
| | |
This should have been done in a4308c9.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Repeating a timer can be done in two ways:
* Returning true from the handler
* Calling start() again in the handler
The latter is useful if you want to change the timer interval.
If both are used, then it becomes ambiguous when the timer should fire
again.
Detect this case and warn about it. Current implementation will respect
the new interval given to start(), rather than the interval set before
running the handler.
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Avoid duplicating this complexity in too many places.
At the same time make the interface more identical to regular mkdir(),
for familiarity.
|
| | |
| | |
| | |
| | |
| | | |
This is an often changed database, so it is better suited for
$XDG_STATE_HOME rather than the more static $XDG_DATA_HOME.
|
| | |
| | |
| | |
| | |
| | | |
This is only needed because of an historical type change of the legacy
directory, so avoid doing it anywhere else.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The syslog file descriptor will be closed when we are cleaning up in
preparation for running the vncserver script, so we need to explicitly
reopen things in case we need to log errors.
At the same time, try to be polite and explicitly close the log when
appropriate.
|
| | |
| | |
| | |
| | |
| | | |
E.g. pam_env.so might modify this variable, so we should see what we get
out of PAM when building a log file path.
|
|/ /
| |
| |
| |
| |
| | |
There is too much variation between distributions for us to have a good
PAM configuration that works everywhere. Try to make this more obvious
by having a comment at the top of the file.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Specifies that the server must ignore all keyboard or mouse events sent
by the client.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2180903
Signed-off-by: Carlos Santos <casantos@redhat.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Move these RFB specific things to rfb::VNCServer, for clarity.
Signed-off-by: Pierre Ossman <ossman@cendio.se>
Signed-off-by: Carlos Santos <casantos@redhat.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
They must belong to the rfb namespace, not to the SConnection class.
Also add an AccessNone constant, since it's better to use a mnemonic
symbol rather than zero to initialize the accessRights members.
Signed-off-by: Carlos Santos <casantos@redhat.com>
|
| | |
| | |
| | |
| | |
| | | |
It's perfectly fine to give a NULL pointer if the length has explicitly
been specified as zero.
|
|\ \ \
| | | |
| | | | |
Allow for alternative user config locations, deprecate `~/.vnc` in favour of XDG Base Directory Specification paths
|
| | | | |
|