If `need_rotate` is TRUE, we should check for the right rotate.

Delightfully this is undefined even though CARD16 is an "unsigned" type,
because it's an unsigned short, which C promotes to signed int because
everything is stupid.

Again, memset(0, ...) is undefined.

If we don't have any recording contexts just skip all this. Note this
also skips a pointless trip through malloc(0)/free.

The first time we get here, eventQueue->events is NULL.

The hits keep coming.

Again, we need all of the bits of an unsigned int to make this work.

The masks we end up building will occupy all 32 bits of an unsigned int,
which means we had better build the shifts out of unsigned ints, because
left-shifting a signed int all the way into the sign bit is undefined.

When we set these up initially, no subsystems have allocated any
privates yet, so the storage address will be null, and memset(NULL, ...)
is undefined.

Caused assertion failures / crashes with Xorg.

Closes: #916

Apps using randr to change the resolution when going fullscreen, in
combination with _NET_WM_STATE_FULLSCREEN to tell the window-manager (WM)
to make their window fullscreen, expect the WM to give the fullscreen window
the size of the emulated resolution as would happen when run under Xorg (*).

We need the WM to emulate this behavior for these apps to work correctly,
with Xwaylands resolution change emulation. For the WM to emulate this,
it needs to know about the emulated resolution for the Windows owning
client for each monitor.

This commit adds a _XWAYLAND_RANDR_EMU_MONITOR_RECTS property, which
contains 4 Cardinals (32 bit integers) per monitor with resolution
emulation info. Window-managers can use this to get the emulated
resolution for the client and size the window correctly.

*) Since under Xorg the resolution will actually be changed and after that
going fullscreen through NET_WM_STATE_FULLSCREEN will size the window to
be equal to the new resolution.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Games based on the allegro gaming library or on ClanLib-1.0 do not size
their window to match the fullscreen resolution, instead they use a
window covering the entire screen, drawing only the fullscreen resolution
part of it.

This commit adds a check for these games, so that we correctly apply a
viewport to them making fullscreen work properly for these games under
Xwayland.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Add support for fake mode changes using viewport, for apps which want to
change the resolution when going fullscreen.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

crtc->mode reflects the mode set through the xrandr extension, once we
add support for also changing the mode through the vidmode extension this
will no longer correctly reflect the emulated resolution.

Add a new xwlVidModeGetCurrentRRMode helper which determines the mode by
looking at the emulated_mode instead.

Likewise add a xwlVidModeGetRRMode helper and use that in
xwlVidModeCheckModeForMonitor/xwlVidModeCheckModeForDriver to allow any
mode listed in the randr_output's mode list.

This is a preparation patch for adding emulated mode/resolution change
support to Xwayland's XF86 vidmode extension emulation.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This is a preparation patch for adding emulated mode/resolution change
support to Xwayland's XF86 vidmode extension emulation, using the
Wayland viewport extension.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Add support for per client randr-resolution change emulation using viewport,
for apps which want to change the resolution when going fullscreen.

Partly based on earlier work on this by Robert Mader <robert.mader@posteo.de>

Note SDL2 and SFML do not restore randr resolution when going from
fullscreen -> windowed, I believe this is caused by us still reporting the
desktop resolution when they query the resolution.  This is not a problem
because when windowed the toplevel window size includes the window-decorations
so it never matches the emulated resolution.

One exception would be the window being resizable in Windowed mode and the
user resizing the window so that including decorations it matches the
emulated resolution *and* the window being at pos 0x0. But this is an
extreme corner case. Still I will submit patches upstream to SDL2
and SFML to always restore the desktop resolution under Xwayland,
disabling resolution emulation all together when going windowed.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Add support for storing per output randr/vidmode emulated resolution
into the per client data.

Since we do not have a free/delete callback for the client this uses
a simple static array. The entries are tied to a specific output by the
server_output_id, with a server_output_id of 0 indicating a free slot
(0 is the "None" Wayland object id).

Note that even if we were to store this in a linked list, we would still
need the server_output_id as this is *per client* *per output*.

This is a preparation patch for adding randr/vidmode resolution
change emulation.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Add per client private data, which for now is empty.

This is a preparation patch for adding randr/vidmode resolution
change emulation.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This adds the RandR 1.2 interface to xwayland and allows modes
advertised by the compositor to be set in an undistructive manner.

With this patch, applications that try to set the resolution will usually
succeed and work while other apps using the same xwayland
instance are not affected at all.

The RandR 1.2 interface will be needed to implement fake-mode-setting and
already makes applications work much cleaner and predictive when a mode
was set.

[hdegoede@redhat.com: Make crtc_set only succeed if the mode matches
 the desktop resolution]
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This is a preparation patch for adding support for apps which want to
change the resolution when they go fullscreen because they are hardcoded
to render at a specific resolution, e.g. 640x480.

Follow up patches will fake the mode-switch these apps want by using
WPviewport to scale there pixmap to cover the entire output.
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

When a viewport is set, damage will only work properly when using
wl_surface_damage_buffer instead of wl_surface_damage.

When no viewport is set, there should be no difference between
surface and buffer damage.

This is a preparation patch for using viewport to add support for fake
mode-changes through xrandr for apps which want to change the resolution
when going fullscreen.

Changes by Hans de Goede <hdegoede@redhat.com>:
-Split the damage changes out into their own patch
-Add xwl_surface_damage helper
-Also use buffer_damage / the new helper for the present and cursor code
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This commit adds support for the wayland wp_viewport extension, note
nothing uses this yet.

This is a preparation patch for adding support for fake mode-changes through
xrandr for apps which want to change the resolution when going fullscreen.

[hdegoede@redhat.com: Split the code for the extension out into its own patch]
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Request-handlers as registered in the requestVector array, always get
passed the clientPtr for the client which sent the request.
But the implementation of many request-handlers typically consists of
a generic handler calling implementation specific callbacks and / or
various helpers often multiple levels deep and in many cases the clientPtr
does not get passed to the callbacks / helpers.

This means that in some places where we would like to have access to the
current-client, we cannot easily access it and fixing this would require
a lot of work and often would involve ABI breakage.

This commit adds a GetCurrentClient helper which can be used as a
shortcut to get access to the clienPtr for the currently being processed
request without needing a lot of refactoring and ABI breakage.

Note using this new GetCurrentClient helper is only safe for code
which only runs from the main thread, this new variable MUST NOT be used
by code which runs from signal handlers or from the input-thread.

The specific use-case which resulted in the creation of this patch is adding
support for emulation of randr / vidmode resolution changes to Xwayland.
This emulation will not actually change the monitor resolution instead it
will scale any window with a size which exactly matches the requested
resolution to fill the entire monitor. The main use-case for this is
games which are hard-coded to render at a specific resolution and have
sofar relied on randr / vidmode to change the monitor resolution when going
fullscreen.

To make this emulation as robust as possible (e.g. avoid accidentally scaling
windows from other apps) we want to make the emulated resolution a per client
state. But e.g. the RRSetCrtc function does not take a client pointer; and is
a (used) part of the Xorg server ABI (note the problem is not just limited
to RRSetCrtc).
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>

This commit adds DRI3/glamor support, effectively translating into
hardware GPU support.

Theoretically it should be possible to use DRM/GPU drivers such as
virtio or vgem, although only the intel i915 driver is currently tested.

Since Xvfb does no modeset, it opens the render node. Currently that is
fixed to "/dev/dri/renderD128" and will be tweaked with future commits.

Specific use-cases are left for the reader - testing glamor, GL driver
or others.

v2: Drop GLAMOR_NO_XV, use GLAMOR_FOR_XORG instead (Michel Dänzer)
v3: Fix build w/o glamor
v4:
 - Split out glamor dependency patch for meson (Pekka)
 - Enhance commit message (Pekka)
 - Use O_CLOEXEC with open() (Pekka)
 - Enhance error path, memory leak comments (Pekka)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Currently glamor depends on epoxy and gbm, even the autotools build
enforces that.

Follow suite and do the same for the meson build.

v1: Split out from larger patch (Pekka)
Signed-off-by: Emil Velikov <emil.velikov@collbora.com>

v2: Enhance commit message (Pekka)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

DDX such as Xorg, Xwayland & Xephyr do not destroy the pixmap before
they call into CloseScreen. At the same time Xvfb (support for glamor
coming with later commit) do.

As such the pixmap will be NULL and we'll crash out.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

DDX such as Xorg, Xwayland & Xephyr do not destroy the pixmap before
they call into CloseScreen. At the same time Xvfb (support for glamor
coming with later commit) do.

As such the pixmap will be NULL and we'll crash out.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Currently we wrap the EGL CloseScreen/DestroyPixmap callbacks after the
glamor ones. Thus upon teardown, we'll end calling things in the wrong
order.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

As of last commit, all of glamor_egl ix xf86 agnostic, so adjust the
includes and drop the GLAMOR_FOR_XORG instances.

Note the macro is still used for glamor_xv_init() which pulls xf86.

v2: Drop GLAMOR_FOR_XORG guards (Michel Dänzer)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Currently we parse through xf86Info.debug to check if we the modifiers
should be disabled. Handle that within DDX and pass GLAMOR_NO_MODIFIERS
into the glamor_init() flags.

This allows individual DDX control over the setting - say when modifiers
are woking OK with one implementation and not the other.

Most importantly, this removes the final xf86 piece from the codebase.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Move from the xf86 specific ScrnInfoRec::privates, to the dix private
handling. Since there's no FreeScreen function in ScreenPtr, fold the
former within the existing CloseScreen.

Users, such as modesetting are updated, and out of tree drivers will
need equivalent, yet trivial, patch.

Note: we need to ensure that the screen private is unset and the screen
callbacks are restored in our CloseScreen function.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

We'll use the function within glamor_egl_close_screen() with next patch.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

The following two members of glamor_egl_screen_private has been unused
for a little while now.
 CreateScreenResources
 CloseScreen
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Much of glamor already use LogMessage() so we might as well be
consistent. This effectively paves the way of making glamor-egl xf86
agnostic.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>

Siiiigh.

Previous commit e6ef2b12 missed a spot.

When using mesa with libglvnd support, mesa will no longer install the
gl, glx, egl pkg-config files but instead let libglvnd provide them.
libglvnd maintainers decided to change the versioning as it was
mesa-specific previously. Now the libraries have versions of the API
they expose[1].
This causes problems when building the X server:

  checking for glproto >= 1.4.17 gl >= 9.2.0... no
  configure: error: Package requirements (glproto >= 1.4.17 gl >= 9.2.0) were not met:

  Requested 'gl >= 9.2.0' but version of gl is 1.2

Lower the version requirement to 1.2 to allow building against libglvnd
provided libraries

[1] https://github.com/NVIDIA/libglvnd/commit/0dfaea2bcb7cdcc785f95e244223bd004a2d7fba

This reverts commit a9537cfd.

This is buildable again since !244

There is a race when reseting the XServer that causes spriteInfo to be
NULL in GetPairedDevice resulting a segfault and subsequent crash. The
problem was noticed when opening a connection, creating master devices,
destroying master devices and closing the connection during testing.
Signed-off-by: Arthur Williams <taaparthur@gmail.com>