Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

This is for different render/display settings to be able
to flip the screen buffer for display.

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

For second entity reuse.

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

Screen is primary, GPUScreen is not primary.

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

All devives marded with AllInOne and passed to modesetting driver
will use the same screen.

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

This reverts commit d3d4ff0.

This function is needed for importing pixmap created by render
node for display node.

Signed-off-by: Qiang Yu <Qiang.Yu@amd.com>

No driver is using these, as far as I know.

v2: Tripwire the entity hook arguments to xf86Config*Entity, fix
documentation (Eric Anholt)

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Most of this is a legacy of the old "extmod" design where you could load
_some_ extensions dynamically but only if the server had been built with
support for them in the first place.

Note that since we now only initialize the DPMS extension if at least
one screen supports it, we no longer need DPMSCapableFlag: if it would
be false, we would never read its value.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Following on from the previous change, this adds a DPMS hook to the
ScreenRec and uses that to infer DPMS support. As a result we can drop
the dpms stub code from Xext.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Rather than setting up a per-screen private, just conditionally
initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
that to determine whether DPMS is supported.

We also move the "turn the screen back on at CloseScreen" logic into the
DPMS extension's (new) reset hook. This would be a behavior change for
the non-xfree86 servers, if any of them had non-stub DPMS support.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

A null pointer dereference can occur in dmxSync, because TimerForce
does not handle a null pointer.

dmxSyncTimer is set to NULL a few lines above on a certain condition,
which happened on my machine. The explicit NULL check allowed me to
start Xdmx again without a segmentation fault.

Reviewed-by: Adam Jackson <ajax@redhat.com>

Declared as unsigned short in xkb/xkbAccessX.c.

Signed-off-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

GLX_ARB_create_context, which we aspire to support, allows making GL 3.0
or newer contexts current with null current drawables. Strictly this
might not be legal for pre-3.0 contexts, but there's no harm in allowing
it anyway.

Signed-off-by: Adam Jackson <ajax@redhat.com>

The X Server never generates a global config.h, and instead all these
paths are including dix-config.h or xorg-config.h.

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

It had nothing left in it that was used but wasn't in dix-config.h.

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

The actual code was gone in 2781995,
but some checks remained.

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

ajax deleted the evdev driver in the removal of fbdev and the linux
backend.

Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Eric Anholt <eric@anholt.net>

No matter what libdrm version was installed, it always set
the GLAMOR_HAS_DRM_NAME_FROM_FD_2 conditional to 1.
This obviously leads to compilation problems.

Fixes: 9232835 ("glamor: use drmGetDeviceNameFromFD2 when available")
Signed-off-by: Mariusz Bialonczyk <manio@skyboo.net>
Reviewed-and-Tested-by: Qiang Yu <Qiang.Yu@amd.com>

There is no pixmap associated with source-only pictures.

Fixes Xephyr -fakexa crashing on startup.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Multiple calls to xf86EdidMonitorSet (which can be triggered e.g. by
running xrandr) would potentially keep adding the same modes, causing
the Monitor->Modes list to keep growing larger and using up more memory.

Fix this by calling xf86PruneDuplicateModes after adding the modes
returned by xf86DDCGetModes. This makes sure there's only one instance
of each unique mode in the list.

v2:
* Replace semicolon with {} for empty for loop (Emil Velikov)
* Slightly tweak commit log to avoid minor inaccuracy about what
  xf86PruneDuplicateModes does

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99521
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

None of this is actually wired up to anything, so we can also remove the
devPrivates from the DamageRec. The DamageExtRec is what would need
devPrivates for selinux labeling, in principle.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

If a client sends a RecordUnregisterClients request with an nClients
field larger than INT_MAX / 4, an integer overflow leads to an
out of boundary access in RecordSanityCheckClientSpecifiers.

An example line with libXtst would be:
XRecordUnregisterClients(dpy, rc, clients, 0x40000001);

Reviewed-by: Adam Jackson <ajax@redhat.com>

Same trick as in fb: just do a normal GetImage and deal with the
planemask on the CPU if you have to. Since the software fallback hit for
glamor is pretty brutal, this is a much more impressive win for glamor
than it was for fb:

  11100.0  87700.0 (7.901) (copy 0xaaaaaaaa) ShmGetImage 10x10 square
   9840.0  47800.0 (4.858) (copy 0xaaaaaaaa) ShmGetImage 100x100 square
   1550.0   4240.0 (2.735) (copy 0xaaaaaaaa) ShmGetImage 500x500 square
   9450.0  78900.0 (8.349) (0xaaaaaaaa) GetImage 10x10 square
   6910.0  30900.0 (4.472) (0xaaaaaaaa) GetImage 100x100 square
    431.0   2020.0 (4.687) (0xaaaaaaaa) GetImage 500x500 square

Measured with Xephyr -glamor on Skylake GT3e.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Formerly we'd zero the image data and then pull out a plane at a time.
It's faster to apply the planemask after the fact, since that turns the
GetImage into a memcpy:

  100000.0  101000.0 (1.010) (copy 0xaaaaaaaa) ShmGetImage 10x10 square
   42400.0   59400.0 (1.401) (copy 0xaaaaaaaa) ShmGetImage 100x100 square
    3040.0    5280.0 (1.737) (copy 0xaaaaaaaa) ShmGetImage 500x500 square
   96100.0   95200.0 (0.991) (0xaaaaaaaa) GetImage 10x10 square
   29600.0   36800.0 (1.243) (0xaaaaaaaa) GetImage 100x100 square
    1850.0    2620.0 (1.416) (0xaaaaaaaa) GetImage 500x500 square

Measured with Xvfb at depth 24 on Skylake i7-6560U.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Copied from Mesa with no modifications.  Gives us Geminilake PCI IDs.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Eric Anholt <eric@anholt.net>

Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY
is raised, in which case the texture returned is zero.

But the texture value is not checked in glamor_create_fbo() and glamor
will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0:

  Truncated backtrace:
  Thread no. 1 (10 frames)
   #4 glamor_pixmap_ensure_fb at glamor_fbo.c:57
   #5 glamor_create_fbo_from_tex at glamor_fbo.c:112
   #6 glamor_create_fbo at glamor_fbo.c:159
   #7 glamor_create_fbo_array at glamor_fbo.c:210
   #8 glamor_create_pixmap at glamor.c:226
   #9 compNewPixmap at compalloc.c:536
   #10 compAllocPixmap at compalloc.c:605
   #11 compCheckRedirect at compwindow.c:167
   #12 compRealizeWindow at compwindow.c:267
   #13 RealizeTree at window.c:2617

Check the value returned by _glamor_create_tex() in glamor_create_fbo()
and return NULL in the texture is zero.

All callers of glamor_create_fbo() actually check the returned value and
will use a fallback code path if it's NULL.

Please cherry-pick this to active stable branches.

Bugzilla: https://bugzilla.redhat.com/1433305
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

v2:
- Require power-of-two bpp in ScreenInit
- Eliminate fbCreatePixmapBpp

v3
- Squash in the exa and glamor changes so we can remove pRotatedPixmap
  in the same stroke.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>

There's really no reason to pretend to support this, apps hate it, all
we're doing is giving people a way to injure themselves. It doesn't work
anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810.
Rip out all the logic for handling 24bpp pixmaps and framebuffers, and
silently ignore the old options that would ask for it.

The cirrus alpine driver has been updated to default to 16bpp, and both
it and the i810 driver can now use the 32->24 conversion code in shadow
if they want. All other drivers support 32bpp. Configurations that
explicitly request 24bpp in order to fit in VRAM will be broken now
though.

v2: Fix command line options to silently ignore 24bpp rather than fail

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>