dpms.h is provided by libXext, but nothing in our configure.ac is
verifying that we have libXext's headers. Fortunately we only need the
definitions in dpmsconst.h (which dpms.h included for us), which is in
xorgproto and thus implied by having an xserver DDK to build against.

And we're even trying to include dpmsconst.h when we think we have it,
meaning when HAVE_XEXTPROTO_71 is defined, but while many other drivers
define that macro in their configure.ac, we for no particularly good
reason do not. Oops. But since xextproto is about ten years old by now
we can probably just safely include it unconditionally.

The CtrlProc for our keyboard driver incorrectly mapped
the device private to a SpiceKbd* intead of to a InputInfoPtr.

That resulted in led state being written into the driver name
for our driver structure, instead of into the led state.

That, in turn, led to a cool bug where if you pressed caps lock,
the two second sync timer in the spice server would cause it to
attempt to correct the state by pressing caps lock to get the
states to match.  Since the states will never match, the caps
lock effectively cycles on and off every two seconds.
Signed-off-by: Jeremy White <jwhite@codeweavers.com>
Acked-by: Victor Toso <victortoso@redhat.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Otherwise we will can hit a segfault qxl_surface_kill()

 │717     void
 │718     qxl_surface_kill (qxl_surface_t *surface)
 │719     {
 │720         struct evacuated_surface_t *ev = surface->evacuated;
 │721
 │722         if (ev)
 │723         {
 │724             /* server side surface is already destroyed (via reset), don't
 │725              * resend a destroy. Just mark surface as not to be recreated */
 │726             ev->pixmap = NULL;│
 │727             if (ev->image)│
 │728                 pixman_image_unref (ev->image);
 │729             if (ev->next)
 │730                 ev->next->prev = ev->prev;
 │731             if (ev->prev)
>│732                ev->prev->next = ev->next;
 │733             free(ev);
 │734             surface->evacuated = NULL;
 │735             return;
 │736         }

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1641793Signed-off-by: Victor Toso <victortoso@redhat.com>

The xrandr output name used by the QXL driver is based on the drm
connector type, but the names do not match the kernel names (see
/drivers/gpu/drm/drm_connector.c) or the modesetting driver names (see
hw/xfree86/drivers/modesetting/drmmode_display.c). Making these more
consistent will require less driver-specific special-case code if a user
wants to match an xrandr output to a drm connector.

Note that this patch should not actually change any behavior, since the
QXL driver only uses the 'Virtual' connector type, so this is done only
for consistency.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>

The QXL driver names its outputs starting at 0 (e.g. Virtual-0,
Virtual-1, etc). This code was presumably copy/pasted from a different
driver, and is not necessary for the QXL driver. Other drivers simply
use the kernel connector_type_id which starts at 1. For example, the
modesetting driver changed from 0-based names to 1-based names for the
same reason in xserver commit 139e36dd.

This will help to make it easier to identify which xrandr outputs belong
to which drm connector without requiring as many driver-specific
special-cases.

This change might effect custom xorg configurations that references a
specific output name. But the same change was made in modesetting driver
despite that possibility.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>

This prevents crashes when multiple QXL devices are configured in a VM.

https://bugzilla.redhat.com/show_bug.cgi?id=1428340

The client could have said anything here, and if what they said doesn't
actually name an atom NameForAtom() will return NULL, and strcmp() will
be unhappy about that.

[copied from xserver d4995a3936ae283b9080fdaa0905daa669ebacfc]
Signed-off-by: Adam Jackson <ajax@redhat.com>

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>

Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>

Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>

Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>

With python3, without universal_newlines=True, Popen().stdout.read()
will return a byte array, while find(str) expects to operate on a
string.
I've checked that this still works with python2 as well.

This allows Xspice to run when using python3 instead of python2

This reverts commit bfb72407.
This was pushed by mistake.

With the Xorg 1.19 codepaths, the 'event_mask' field of SpiceWatch is
only useful for sanity checking the event we get from Xorg. This commit
assumes Xorg is sane, and removes this extra field.

spiceqxl_*.c files are Xspice-only code. They contain a few uses of
malloc/strdup, and none of these are checked for failure. It's better to
replace these with xfnalloc/xnfstrdup which are provided by the X server
and cannot fail (aborts on failure).
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>

In newer X.org versions, it's no longer supported to modify the set of
FDs passed to a BlockHandler method to get notified when the FD has data
to be read. This was limited anyway as we could only get read events
this way, and had to do our own polling to get notified about socket
writeability.

Starting from xserver 1.19, the supported way of doing this is to use
the SetNotifyFd/RemoveNotifyFd API, which is actually a much better way
as it matches very well the 'watch' API spice-server expects Xspice to
implement.

This commit switches to that new API, which removes the need for
RegisterBlockAndWakeupHandlers().
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Uri Lublin <uril@redhat.com>

Group the options more logically and improve their descriptions.
Add the missing help strings for Xspice --help and standardize the
messages to start with a lowercase and not end with a period.
In the Xorg configuration, always show the default in the
commented-out sample.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>

xspice needs to be updated to cope with some X.Org 1.19 API changes,
better to make that explicit at configure time rather than letting
people discover the hard way (it builds with warnings but will not work)
that it's broken.

This should help with bug #974198

This is not working properly at the moment.

Signed-off-by: Francois Gouget <fgouget@codeweavers.com>

qxl_resize_primary_to_virtual() was using pScrn->pScreen != NULL to check
if createScreenResources has been called. But starting with xserver 1.19
pScrn->pScreen is non NULL even before createScreenResources is called,
causing an invalid access to the screenPixmap in
qxl_resize_primary_to_virtual().

This commit fixes this.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1381045Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>

More recent versions of Xfont have a different API (with namespacing
for libXfont functions.) Check for xfont2.pc and if found, use that, and
use the new API. The rational for preferring libXfont2 is that as a recent
change the xserver module looks for and requires libXfont2, and it's better
not to have both versions of the library in process.

Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Jeremy White <jwhite@codeweavers.com>

Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Signed-off-by: Jeremy White <jwhite@codeweavers.com>

SpiceCoreInterface::timer_add() is used by spice-server for integration
with external mainloops. timer_add() is only meant to create a disabled
timer, this timer will then be started with a call to timer_start().

The current implementation in Xspice creates a timer which will trigger
in a very long time, assuming this will never happen. This 'forever' is
1,000,000 seconds, which amounts to 11 days. After that time, some
timers which are meant to be disabled (eg migration related timers in
spice-server) fire, then causing a crash with some failed assertions.

Instead of creating the X timer right away in timer_add(), we can wait
until timer_start() is called before starting it, which avoids this
issue.

This lets the client free the audio resources when an audio application
is not actually playing anything, typically because playback is paused.
This matches QEMU's behavior.
As a side benefit it stops the client's mm-time from being stuck (due
to the audio backend's delay updates being applied to the mm-time of
the last audio message) which lets video streams play in this situation.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>

This lets the client free the audio resources when they are not needed.
This matches QEMU's behavior.
As a side benefit it stops the client's mm-time from being stuck (due
to the audio backend's delay updates being applied to the mm-time of
the last audio message, that is the channel's creation) when no audio
application is running.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>

can_feed() depends on the time and thus could return false in
process_fifos(), causing it to stop reading from the fifos, and then
true in watch_or_wait() so that the wall_timer would not be set, but
the fifos would not be watched either because they already contain
data to process. The audio playback would then come to a stop.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>

Signed-off-by: Francois Gouget <fgouget@codeweavers.com>

Simply keep reading from the fifos in reasonably sized chunks.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>

This avoids compilation errors with -Werror on 32 bit systems and is
more correct than a direct cast.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>

We don't need to update the screen when we use a temporary or
offscreen pixmap.