If egl display is enabled, use GL scanout geometry to check intersection
with the monitor area. This solves displaying GL display without
software canvas (currently d->area is empty and gl drawing fails)
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
d->ready is updated based on monitor area & canvas. In case of GL
rendering, update it based on monitor area & scanout and add check
before drawing update.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The following changes will call these functions from spice-widget-egl.c
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The GLArea is realized lazily, when it is made visible in
set_egl_enabled(). The egl context is initialized once the GLArea is
realized. Enable egl before updating the scanout.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Add a new GL status field to check if the GL context is ready. This
helps debugging races where GL is called before the context is ready.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
The egl call is already inside a X11 conditional block.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Since spice-gtk 57df040cc, the SpiceDisplay no longer forces its own
window. Get allocation instead of window size. This fixes a "top
border" issue in spicy with gtk+ >= 3.19.8.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
According to gtk_widget_queue_draw_area() documentation:
"The region here is specified in widget coordinates. Widget coordinates
are a bit odd; for historical reasons, they are defined as
widget->window coordinates for widgets that return TRUE for
gtk_widget_get_has_window(), and are relative to widget->allocation.x ,
widget->allocation.y otherwise."
Since spice-gtk 57df040cc, the SpiceDisplay no longer forces its own
window. During gtk+ 3.19.8, gtk stack also no longer use its own
window (commit 9d0e8401). In order to make drawing update resilient to
such changes, add a function applying offset if necessary.
This solves drawing glitches and perceived slowness with spice-gtk git
and gtk+ >= 3.19.8.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
epoxy/egl.h header is not provided by mingw-epoxy package.
Let's avoid egl usage when building using mingw then.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Marc-André Lureau <mlureau@redhat.com>
It was used to notify the (deprecated) auto-clipboard property of
the SpiceDisplay everytime the SpiceGtkSession emits its auto-clipboard
notify.
The commit 70a00b8fcc removed the property
from SpiceDisplay causing a runtime warning:
GLib-GObject-WARNING **: g_object_notify: object class 'SpiceDisplay' has no property named 'auto-clipboard'
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Make GtkGlArea optional allows to lower gtk+ requirement to
3.10 (required for GtkStack). However, gl display is unsupported on
wayland with gtk+ < 3.16.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
GtkGLArea is the proper modern way to have opengl in an gtk+
application. Unfortunately, it may use various backends and interfaces
to initialize it, but dmabuf image sharing requires egl atm.
This patch keeps using our egl setup on X11, while it uses gtkglarea on
known gdk backend based on egl, such as the wayland one. This brings
wayland support for local gl to spice-gtk.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Move the GtkDrawingArea in a GtkStack, so other widgets can be switched
to for the display: the next patch adds a GtkGLArea for an opengl
rendering. One can imagine other display widgets to show text etc..
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
3.16 is the minimal version for GtkGLArea widget, used in following
patches.
Drop conditional epoxy support, as it is now required by gtk+.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Breaking ABI is a good time to remove deprecated code.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Not so many systems require gtk+ 2.0 these days, let's move on.
This drops the old python bindings (non-gir based), and the
unsteady/experimental gtk2-only XShm support.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Do not leak internals of SpiceGrabSequence in public headers. This makes also
the class final, which let us extend more easily without fear of breaking ABI.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
Hook to spice-glib events to show the GL scanout.
The opengl context is created with egl, and is currently
x11-only (supporting wayland with bare-egl doesn't seem trivial).
Using GtkGLArea is left for a future series, since SpiceDisplay widget
is a GtkDrawingArea and can't be replaced without breaking
ABI. Furthermore, GtkGLArea won't work on non-egl contexts, so this
approach is necessary on gtk+ < 3.16 or X11 (because gdk/x11 uses glx).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
While "#if USE_FOO" checks for the value of the variable USE_FOO,
"#ifdef" checks whether USE_FOO is defined or not.
It means, if we had something like: #define USE_FOO 0, we would have:
#if USE_FOO
/* Any code in here would NOT be compiled */
#endif
#ifdef USE_FOO
/* Any code in here would be compiled */
#endif
No problem was faced on spice-gtk till now because either USE_FOO is not
defined or defined as 1, but let's try to have it standardized.
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
For size-allocate, it's simpler to connect to the signal rather than
override the default signal handler since there is no automatic chaining
to parent handler otherwise. Doing this removes the need to have a
window.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Acked-by: Victor Toso <victortoso@redhat.com>
When using multiple monitors moving mouse between monitors releases
keyboard grab.
Reproduce bug
-Open multiple monitors remote-viewer session
-Click on one of the monitors to get focus & keyboard-grab
-Move mouse to another monitor and try keyboard command (do not click)
At this point all keyboard commands are being executed on the client
machine instead of the remote machine
I added keyboard_has_focus and mouse_has_pointer variables at the
session and now these properties are being tested for the session
instead for the current widget (works also when using alt-tab).
Resolves: rhbz#1275231
Acked-by: Pavel Grunt <pgrunt@redhat.com>
This header is the single include needed for all gtk-related
functionality, similar to spice-client.h. Generate a compiler warning if
a different header is included.
When a display channel is associated with a particular SpiceDisplay
widget, it previously set the display to 'enabled' unconditionally.
There is a couple of problems with this behavior.
First, simply because a display widget has an associated display
channel, it doesn't necessarily mean that the display is enabled. On
linux guests, for instance, a display channel can have up to 4 displays
for one channel, and perhaps only one of them is enabled. So, we
shouldn't set the display to 'enabled' until we actually receive a
monitors configuration message indicating that this display is enabled.
The second problem is that this was triggering the client to send down a
new monitors-config message to the server. This message is completely
unnecessary since it is triggered by a message from the server. We
should only be sending down new monitor configurations in response to
changes from the client, not from the server.
Each monitor on a Windows guest is represented as a separate, single-headed
device with its own framebuffer. When there are multiple monitors, all
monitors but one will have a non-zero xy config position. But even in
these cases the whole area (frame-buffer) of each monitor should be
updated.
Addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1202419
Updating the display causes weird behaviors in virt-viewer, like
re-resizing to a previous monitor config when, after changing the
display resolution (through System > PReferences > Displays). the agent
reconnects.
It is not perfect yet, because when the agent reconnects the guest
resizes to the previous config and switch to the proper one, but this
seems more like an agent bug than a spice-gtk one.
