We mostly use #ifdef throughout the tree, and this lets the generated
config.h files just be #define TOKEN instead of #define TOKEN 1.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Found when the meson conversion set the symbol to defined, instead of
defined to 1.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Without this, assertion failures can make life hard for users and those
trying to help them.
v2:
* Change commit log wording slightly to "can make life hard", since
apparently e.g. logind can alleviate that somewhat.
* Set default handler for SIGABRT in
hw/xfree86/common/xf86Init.c:InstallSignalHandlers() and
hw/xquartz/quartz.c:QuartzInitOutput() (Eric Anholt)
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The number for it was merged to drm_mode.h in kernel 4.7, and the
output_names[] array just requires that we slot in new strings in
order.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The previous misc.h code went out of its way to allow swapping of
unaligned pointers to values. However, the members of an X
request/response are always naturally aligned within the struct, and
the buffers containing a request/response will also be aligned to at
least 8 bytes, so we can just drop it.
text data bss dec hex filename
before: 2215167 51552 132016 2398735 249a0f hw/xfree86/Xorg
after: 2214919 51552 132016 2398487 249917 hw/xfree86/Xorg
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Peter noted a weirdness in my new bswap code, which could use some
tests to justify it.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The clever pointer tricks were actually not working, and we were doing
the byte-by-byte moves in general. By just doing the memcpy and
obvious byte swap code, we end up generating actual byte swap
instructions, thanks to optimizing compilers.
text data bss dec hex filename
before: 2240807 51552 132016 2424375 24fe37 hw/xfree86/Xorg
after: 2215167 51552 132016 2398735 249a0f hw/xfree86/Xorg
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
The build defines these, so having the defaults is just a way for the
build system's configuration to get out of sync with the code.
v2: Drop #ifndefs around the other two defines.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
parser/scan.c was checking for #ifdef XCONFIGFILE and XCONFIGDIR and
defaulting to "xorg.conf", and "xorg.conf.d", so if you had changed
__XCONFIGFILE__ to anything else, it would have got out of sync.
Settle on the name without gratuitous underscores.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Fixes warning from Solaris linker:
ld: warning: symbol 'test_data' has differing sizes:
(file tests-protocol-xigetselectedevents.o value=0x418;
file tests-protocol-xigetclientpointer.o value=0x18);
tests-protocol-xigetselectedevents.o definition taken
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It appears that on some hardware/diver combo such as nv30/nouveau, using
GL_ALPHA as format for 8-bit depth will cause an incomplete attachment
error (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT) when trying to bind the
texture.
As a result, the FBO is NULL and glamor segfaults when trying to access
the FBO width/height in pixmap_priv_get_scale() in glamor_xv_render().
This happens with glamor-xv which uses 8-bit pixmaps, meaning that on
such hardware/driver, trying to play a video using Xv will lead to a
crash of the Xserver. This affects Xwayland, Xephyr, modesetting driver
with glamor accel.
But the use of an FBO is not actually needed for glamox-xv, so by
disabling FBO at pixmap creation, we can avoid the issue entirely.
Fix suggested by Eric Anholt <eric@anholt.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=100710
Fixes: https://bugzilla.redhat.com/1412814
Reviewed-by: Eric Anholt <eric@anholt.net>
This dumps a ton of configure-time checks for system endian macros.
Given that we're marking the mixed-endian fixup code as cold, getting
at the system macros is a waste of code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
As far back as the initial import, it seems to have been exposed, and
there's no explanation why the test happened in the initial xserver
import.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Be more precise in describing the return value.
Signed-off-by: Roman Gilg <subdiff@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
E.g. because Xinerama is enabled.
Fixes crash on startup and wrong colours in that case.
Bugzilla: https://bugs.freedesktop.org/100293
Bugzilla: https://bugs.freedesktop.org/100294
Fixes: 62f4405257 ("xfree86/modes: Move gamma initialization to
xf86RandR12Init12 v2")
Tested-by: Mariusz Bialonczyk <manio@skyboo.net>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Despite all the careful planning of the kernel, a link may become
insufficient to handle the currently-set mode. At this point, the
kernel should mark this particular configuration as being broken
and potentially prune the mode before setting the offending connector's
link-status to BAD and send the userspace a hotplug event. This may
happen right after a modeset or later on.
Upon receiving a hot-plug event, we iterate through the connectors to
re-apply the currently-set mode on all the connectors that have a
link-status property set to BAD. The kernel may be able to get the
link to work by dropping to using a lower link bpp (with the same
display bpp). However, the modeset may fail if the kernel has pruned
the mode, so to make users aware of this problem a warning is outputed
in the logs to warn about having a potentially-black display.
This patch does not modify the current behaviour of always propagating
the events to the randr clients. This allows desktop environments to
re-probe the connectors and select a new resolution based on the new
(currated) mode list if a mode disapeared. This behaviour is expected in
order to pass the Display Port compliance tests.
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The Contributor Covenant applies to all fd.o-hosted resources, including
lists and Bugzilla. Add a note to the README, reminding people to act
like human beings.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
All fd.o HTTP services are now HTTPS-only (with redirects, but still).
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Otherwise xcb will treat our attempt to send xv requests as a connection
error (quite reasonably: we're asking it to emit a request for which
there is no defined major opcode), and we'll die quietly the first time
we hit KdBlockhandler.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Dead code since:
commit 8aacf47e17
Author: Adam Jackson <ajax@redhat.com>
Date: Fri Oct 4 12:58:19 2013 -0400
glx: Remove DRI1 AIGLX (v2)
Signed-off-by: Adam Jackson <ajax@redhat.com>
DRM_EVENT_CONTEXT_VERSION is the latest context version supported by
whatever version of libdrm is present. modesetting was blindly asserting
it supported whatever version that may be, even if it actually didn't.
With libdrm 2.4.78, setting a higher context version than 2 will attempt
to call the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Stone <daniels@collabora.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>
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 27819950e4,
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: 9232835bd1 ("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>
This ends up passing 0 as the bpp argument to fb screen setup, which is
not really the best plan.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We were binding the screen pixmap as the dash and sampling its alpha,
which is usually just 1.0 (no dashing at all).
Please cherry-pick this to active stable branches.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
This code is using GetImage to accumulate a logical view of the window
image (since the windows will be clipped to their containing screen),
and then PutImage to load that back into the pixmap. What it wasn't
doing was constructing a region for the obscured areas of the window and
emitting graphics exposures for same.
v2: Fix coordinate translation when the source is the root window
v3: Create sourceBox with the right coordinates initially instead of
translating (Keith Packard)
v4: Clamp the region to 15 bits to avoid overflow (Keith Packard)
Signed-off-by: Adam Jackson <ajax@redhat.com>
