crtc->{x,y} is always 0 when xf86DefaultScreenLimits() is called, so we
calculate too small an area for the initial framebuffer and force a resize
to happen.
This commit fixes the code to use desired{X,Y} instead, which contains the
initial output positions.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The internals of XTest are used by Xi and Xkb, and both Xi and Xkb are
always required, so it makes little sense to have XTest place data in
a devPrivate, especially a devPrivate which is only available when the
XTest extension is enabled.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Input only windows aren't DRAWABLE_WINDOW, but casting them to a
PixmapPtr is a bit harsh, and unlikely to get the appropriate privates
structure. use WindowDrawable instead which checks for both
input-output and input-only windows.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Eric Anholt <eric@anholt.net>
Make sure all of the private keys used by the test code are
initialized before being used.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Robert Hooker <sarvatt@ubuntu.com>
A glyph allocation consists of :
GlyphRec
numScreens * PicturePtr
glyph privates
Tell the dix private bits to start past the picture pointers.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Previously there was two branches of code with small discrepancies between them
(especially prop->valid_values field was not free(3)ed). Extract the common
routine and fix double-free prop->valid_values in RRDestroyOutputProperty by
the way.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
This patch has been generated by the following Coccinelle semantic patch:
@@
expression E;
@@
-if(E) { free(E); }
+free(E);
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Marcin Baczyński <marbacz@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Marcin Baczyński <marbacz@gmail.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
This makes hw/dmx/glxProxy/unpack.h more closely resemble glx/unpack.h,
and fixes the "unused variable 'swapEnd'" and "unused variable 'swapPC'"
warnings.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This would cause all kinds of fun, in particular Xnest would crash at startup.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This key is used to store the currently installed colormap and must be
registered before we can use it.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This macro originally checked to see if the Render screen private
index had been allocated. When the privates were changed the first
time, there wasn't any need to check as dixLookupPrivate would simply
return NULL in that case. Now that we care, check to see if the key
has been initialized before asking for the value.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Some users of the shadow code don't call shadowInit, just shadowSetup
and so make sure the key is initialized there.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
exa_priv.h exposes the privates to the rest of the exa code, and yet
the declarations of the privates wasn't fixed when the exa.c versions were.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
When doing the devPrivate API conversion, I missed this as there was
also a local private key which wasn't ever used.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
midispcur was abusing the CursorScreenKey to index the cursor_bits
privates, it also had a MAXSCREENS array of keys to index device
privates. Switch both of these to the new dixCreatePrivateKey API and
store a pointer to that in the screen private.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Keys need to persist through server reset so that the private system
can be cleaned up in dixResetPrivates. In particular, this means that
keys cannot live in objects freed at reset time. This API provides
suitable object lifetime by having the privates code free the key in
the reset path.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Each key now declares which object type it belongs to, this permits
keys for different types to share the same offset within the allocated
privates. As a special case for XSELinux, a key may be allocated as
PRIVATE_XSELINUX which will allow it to continue to be used across the
relevant object types.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
This patch only changes the API, not the implementation of the
devPrivates infrastructure. This will permit a new devPrivates
implementation to be layed into the server without requiring
simultaneous changes in every devPrivates user.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com>
The CursorScreenKey array is supposed to be used by the DDX for cursor
private data, but midispcur was abusing it to hold cursor bits private
information. Create a separate set of privates for the dispcur cursor
bits information.
This also renames the device private index and macros to better
reflect their usage:
miDCSpriteKey -> miDCDeviceKey
MIDCBUFFER -> miGetDCDevice
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
For predefined resource types, the offset of the devPrivates field was
already kept in a constant table. The only non-predefined type needing
this treatment was dbeDrawableResType, which is just a magic alias for
RT_PIXMAP.
This patch special-cases looking up RC_DRAWABLE offsets and uses the
table directly for everything else.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
This makes the region code changes source compatible with existing
code, although none of them are used within the server source itself.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This makes all of the previous macros into inline functions and also
turns all of the direct calls to pixman region code into inline
functions as well.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This is a combination of a huge mechanical patch and a few small
fixups required to finish the job. They were reviewed separately, but
because the server does not build without both pieces, I've merged
them together at this time.
The mechanical changes were performed by running the included
'fix-region' script over the whole tree:
$ git ls-files | grep -v '^fix-' | xargs ./fix-region
And then, the white space errors in the resulting patch were fixed
using the provided fix-patch-whitespace script.
$ sh ./fix-patch-whitespace
Thanks to Jamey Sharp for the mighty fine sed-generating sed script.
The hand-done changes involve removing functions from dix/region.c
that duplicate inline functions in include/regionstr.h, along with
their declarations in regionstr.h, mi.h and mispans.h.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This prepares the file to be moved from mi to dix. This patch
was done mechanically with the included scripts 'fix-miregion' run over
the entire X server and 'fix-miregion-private' run over
include/regionstr.h and mi/miregion.c.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This fixes a regression in miext/rootless from 643cb6e87c
Found-by: tinderbox
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Pierre-Loup A. Griffais <pgriffais@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
xserver fails to detect libsha1. Problem is that configure checks for
sha1.pc when libsha1 provides libsha1.pc.
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
xorg.conf has been used since the X11R6.7 release in April 2004.
6 years has been a generous transition period for users to
"mv XF86Config xorg.conf" and for distros to update their
configuration tools and packages.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: James Cloos <cloos@jhcloos.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
xorg.conf has been used since the X11R6.7 release in April 2004.
6 years has been a generous transition period for users to
"mv XF86Config xorg.conf" and for distros to update their
configuration tools and packages.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: James Cloos <cloos@jhcloos.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Classic strlen/strcpy mistake of
foo = malloc(strlen(bar));
strcpy(foo, bar);
Testcase: valgrind Xephyr :1
==8591== Invalid write of size 1
==8591== at 0x4A0638F: strcpy (mc_replace_strmem.c:311)
==8591== by 0x605593: _XkbCopyGeom (xkbUtils.c:1994)
==8591== by 0x605973: XkbCopyKeymap (xkbUtils.c:2118)
==8591== by 0x6122B3: InitKeyboardDeviceStruct (xkbInit.c:560)
==8591== by 0x4472E2: CoreKeyboardProc (devices.c:577)
==8591== by 0x447162: ActivateDevice (devices.c:530)
==8591== by 0x4475D6: InitCoreDevices (devices.c:672)
==8591== by 0x4449EE: main (main.c:254)
==8591== Address 0x6f96505 is 0 bytes after a block of size 53 alloc'd
==8591== at 0x4A0515D: malloc (vg_replace_malloc.c:195)
==8591== by 0x6054B7: _XkbCopyGeom (xkbUtils.c:1980)
==8591== by 0x605973: XkbCopyKeymap (xkbUtils.c:2118)
==8591== by 0x6122B3: InitKeyboardDeviceStruct (xkbInit.c:560)
==8591== by 0x4472E2: CoreKeyboardProc (devices.c:577)
==8591== by 0x447162: ActivateDevice (devices.c:530)
==8591== by 0x4475D6: InitCoreDevices (devices.c:672)
==8591== by 0x4449EE: main (main.c:254)
Reported-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by-and-apologised-for: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Since reallocating the backing pixmap can fail, we need to try and do
it before any other side effects of reconfiguring the window happen.
This changes the ConfigNotify hook to return status, and moves the
composite window reconfiguration wrappers to ConfigNotify. They all
basically did the same thing, so we can drop the MoveWindow,
ResizeWindow, ChangeBorderWidth wrappers, and allow ConfigNotify to do
all the work. If reallocation fails we fail before we send any
confiureNotify events, or enter the area we can't recover from.
The only place we now enforce 32k limits are in EXA/UXA/fb, so drivers
that don't use this should probably deal with it in their pixmap
allocate if they don't already.
This also breaks ABI, so we need an alternate fix for older servers,
working on the X server makes me realise why I'm a kernel hacker.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This fuses two loops in each function, eliminating an intermediate
MAXSCREENS-sized array from each.
Aside from being more efficient, I believe this is equivalent to the
previous implementation, since
- each per-screen GC has the graphicsExposures flag set the same way,
and
- the REGION_* macros ignore their screen argument.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
Every screen region consists of a single rectangle, so initializing a
stack-allocated region for each screen on-demand does no heap allocation
and is fast.
This eliminates a MAXSCREENS-sized array.
The REGION_UNINIT calls are no-ops since no boxes are actually allocated
for a single-rectangle region, but it seemed wiser to include them.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
This hides a MAXSCREENS-sized array as an implementation detail of
panoramiX.c rather than an exported global.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
Many references to the dixScreenOrigins array already had the
corresponding screen pointer handy, which meant they usually looked like
"dixScreenOrigins[pScreen->myNum]". Adding a field to ScreenRec instead
of keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix declared the dixScreenOrigins array, I figure allocating a
screen private for these values is overkill.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
Many references to the WindowTable array already had the corresponding
screen pointer handy, which meant they usually looked like
"WindowTable[pScreen->myNum]". Adding a field to ScreenRec instead of
keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix uses this data, a screen private entry isn't appropriate.
xf86-video-dummy currently uses WindowTable, so it needs to be updated
to reflect this change.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
Most references to the savedScreenInfo array already had the
corresponding screen pointer handy, which meant they usually looked like
"savedScreenInfo[pScreen->myNum]". Adding a field to ScreenRec instead
of keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix uses this data, a screen private entry isn't appropriate.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
It's been commented-out for three and a half years and nobody seems to
be missing it enough to resurrect it.
Besides deleting code that is untested and therefore buggy, this saves a
little memory for each pointer device on each screen.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>