The code in xf86sbusBus.c seems too OS-specific to be usable on OpenBSD.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Okay, seems we're not using extensively such hooks in fact. But fix the
expected behaviour at least.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The function was only initializing the boolean xf86ResAccessEnter, which
couldn't get any other value in the life of the server.
The only possible, though suspicious, code was in xf86AccessLeave(), which
could be triggered if AbortDDX is called before xf86AccessInit(). Even so,
such change is safety because no driver would have configured any entity leave
procedure at this point.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
1461b31e40 tests to see if the allocation
of buffer[i] failed after i has been incremented, causing it to look
at the wrong pointer.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Tested-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Other DDXs don't use input hotplugging since config_init was moved to
the DDX in commit d33adcdf03, so there's
no need to link this in.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
The middle mouse clicks return erroneous values after returning from
Fast User Switching.
<rdar://problem/7979468>
http://xquartz.macosforge.org/trac/ticket/389
Signed-off-by: Martin Otte <otte@duke.edu>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Edward Moy <emoy@apple.com>
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
If driver fails to allocate memory for dri2 buffer server would crash
in send_buffers_reply.
Solution is to handle the allocation failure and return BadAlloc to
client.
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Just let Dispatch() check for a noClientException, rather than making
every single dispatch procedure take care of it.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Use the values from xproto rather than duplicating the effort
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This lets the DRI2 clients rely on the server to notify them when they
need to get new buffers. Without this, OpenGL clients poll the server
in glViewport() which can be a performance problems and also isn't
completely correct behaviour.
We bump the DRI2 protocol minor to indicate the availability of the
event, which the DRI2 clients can use to avoid polling. This speeds up
various piglit and oglc test cases as well as real applications.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
ResNoAvoid is #defined to ResBios, but ResBios was removed
from xf86str.h in 4b42448a23
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
This doesn't change any behavior, but it isn't clear whether NullClient
is correct in all cases. As ajax says,
> For most of these changes, I think it's correct to use NullClient,
> since they are server-initiated changes and should not fail for (eg)
> xace reasons. ... At any rate, you're certainly not changing any
> semantics by leaving them all as NullClient, so this patch can't be
> more wrong than before.
The call in CreateGC is particularly questionable.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This doesn't change any behavior, but it isn't clear whether NullClient
is correct in all cases. As ajax says,
> For most of these changes, I think it's correct to use NullClient,
> since they are server-initiated changes and should not fail for (eg)
> xace reasons. ... At any rate, you're certainly not changing any
> semantics by leaving them all as NullClient, so this patch can't be
> more wrong than before.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Previously the callers were only setting errorValue on Success, when
it's ignored, and leaving it alone on failure, when it's sent to the
client.
Since SetFontPath takes the ClientPtr, let it set client->errorValue
instead of letting the callers continue to get it wrong.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The only remaining X-functions used in server are XNF*, the rest is converted to
plain alloc/calloc/realloc/free/strdup.
X* functions are still exported from server and x* macros are still defined in
header file, so both ABI and API are not affected by this change.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
If we don't have a fake front, nothing will happen. The fix was extracted
from a bigger patch from Francisco Jerez.
https://bugs.freedesktop.org/show_bug.cgi?id=27305
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Pauli Nieminen <suokkos@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Fixes regression introduced in 9de0e31746
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Upon resume, X may try to dereference a null pointer, which has been
reported in Debian bug #507916 (http://bugs.debian.org/507916).
Jim Paris came up with a patch which solves the problem for him. Here's
a (hopefully) fixed version of his patch (without the typo).
Cc: Jim Paris <jim@jtan.com>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-By: Matthias Hopf <mhopf@suse.de>
Signed-off-by: Keith Packard <keithp@keithp.com>
Some pixmaps (window pixmaps and scratch pixmaps) don't have the
drawable->id set and thus DRI2 gets confused when using that field
for looking up the DRI2 drawable. Go back to using privates for getting
at the DRI2 drawable from a DrawablePtr. We need to keep the resource
tracking in place so we can remove the DRI2 drawable when the X resource
it was created for goes away. Additionally, we also now track the DRI2
drawable using a client XID so we can reclaim the DRI2 drawable even if
the client goes before the drawable and doesn't destroy the DRI2 drawable.
Tested-by: Owen W. Taylor <otaylor@fishsoup.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
GetPairedDevice() may not always return the keyboard, resulting in a
null-pointer dereference when accessing the XKB state.
For floating devices, the GetMaster() returns the device itself.
X.Org Bug 27573 <http://bugs.freedesktop.org/show_bug.cgi?id=27573>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Tested-by: Ben Hutchings <ben@decadent.org.uk>
Same goes for VERIFY_ALPHA, VERIFY_XIN_PICTURE, and VERIFY_XIN_ALPHA.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
commit 206531f75c added localization files
for ar, add them to the Makefile.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
A few cursor value assignments weren't getting correctly ref counted,
causing leaks of cursor objects.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
We call NIDR on all devices that make it through the config backend.
Including some that have no driver assigned to them (/dev/input/mouse0 for
example). Those ones then simply get ignored by NIDR, but this should not be
noted as an error in the log file.
X_INFO is sufficient, and it may just prevent some bugreports.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
A rewrite of the XWin DDX AIGLX code to actually make it do something useful again
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>
Banked framebuffers are so 1990. As of 7.4 the only drivers remaining
that used this were chips, neomagic, trident, and vesa. vesa only used
it when not using shadowfb, which is broadly undesirable anyway, and no
longer uses it at all as of 2.3.0. neomagic never used it by default,
and support for it is gone in git master. The other two effectively
only ever used it for ISA chips; since ISA support is now gone from
the server, they have been modified to only compile mibank support when
ISA support is available.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Most DGA requests allow at most one client to be using DGA on each
screen. Instead of keeping track of the current client in a
MAXSCREEN-sized array, track it in a per-screen private.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
If a -screen option specifies a screen number higher than any previously
specified, reallocate the vfb-private array of screen-info structs.
If built with a DIX that still has a MAXSCREENS limit, asking for too
many screens won't be detected until InitOutput calls AddScreen.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Inspired by Jon Turney's "Xwin: Simplify screen option processing"
patch, which does something similar for the Xwin server.
Besides making the code more readable, this eliminates most of Xvfb's
references to MAXSCREENS.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
The screen number can be inferred from the position in the vfbScreens
array, and it was only used in two places, so it was hardly important.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Several DDXes allow each screen to have at most one (or in some cases,
exactly one) installed colormap. These all use the same pattern: Declare
a global-lifetime array of MAXSCREENS ColormapPtrs, and index it by
screen number. This patch converts most of those to use screen privates
instead.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
