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>
Since we no longer support OS-independent custom elfloader modules,
we don't need to put the OS-dependent modules into os-specific subdirs
any more.
We do however still need to install the stubs version of this module
on non-Linux platforms, since a number of drivers link to functions
in it, even when built on non-Linux platforms.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Previously the code was using AC_CHECK_LIB, guaranteeing whether the library
is correct by tracking sha1_begin function. This paranoic checking is not
necessary given there's only one libsha1 in the market, which surely contains
such function.
Moreover, this patch now improves a bit the sha1 implementation checking
behavior using pkg-config to find the right flags that needs to link against.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Some drivers use DRI protocol but implement their own kernel rendering
manager. For these drivers, libdrm becomes useless. --disable-libdrm
configure parameter can be used to disable libdrm support in dri2.
To provide ABI/API compatibility for libdrm based drivers, libdrm call
is wrapped in ifdef.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
With this new hook, drmAuthMagic becomes useless and should be deprecated.
You might want to implement AuthMagic on driver side instead.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Propagate the shape kind all the way to SetShape to avoid performing non-input
operations such as revalidating the tree and generating exposures when only
changing a window's input shape.
Signed-off-by: Pierre-Loup A. Griffais <pgriffais@nvidia.com>
Acked-by: Aaron Plattner<aplattner@nvidia.com>
Reviewed-by: Daniel Stone<daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
The move of the PCI device id probing into a separate file neglected to
return the number of found devices, and so the PCI devices were being
overwritten by the default entries for vesa and fbdev.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tiago Vignatti <tiago.vignatti@nokia.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
miDbePositionWindow allocates two pixmaps: a front buffer, and a back buffer.
If the buffers are supposed to be initialized, it validates a GC against the
front buffer, then uses it to fill and/or copy both the front buffer *and* the
back buffer, without revalidating. If the acceleration architecture needs
different GC funcs for the two pixmaps -- for example if allocation of the front
buffer exhausted video memory -- then this can cause crashes because the GC is
not validated for the back buffer pixmap.
Fix this by performing the rendering for the front buffer first, then
revalidating against the back buffer before performing the back buffer
rendering.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
We just never initialised the malloced value.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Makes the use of IsMaster in ProcChangeKeyboardControl consistent with other
similar loops.
Signed-off-by: Nicolas George <nicolas.george@normalesup.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Just some extra clarification as pointed out by Dan Nicholson,
and that memcpy should have been a memcmp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
For absolute input devices (E.G. touchscreens) in multi-head setups,
we need a way to bind the device to an randr output. This adds the
infrastructure to the server to allow us to do so.
positionSprite() scales input coordinates to the dimensions of the shared
(total) screen frame buffer, so to restrict motion to an output we need to
scale/rotate/translate device coordinates to a subset of the frame buffer
before passing them on to positionSprite.
This is done here using a 3x3 transformation matrix, which is applied to
the device coordinates using homogeneous coordinates, E.G.:
[ c0 c1 c2 ] [ x ]
[ c3 c4 c5 ] * [ y ]
[ c6 c7 c8 ] [ 1 ]
Notice: As input devices have varying input ranges, the coordinates are
first scaled to the [0..1] range for generality, and afterwards scaled
back up.
E.G. for a dual head setup (using same resolution) next to each other, you
would want to scale the X coordinates of the touchscreen connected to the
both heads by 50%, and translate (offset) the coordinates of the rightmost
head by 50%, or in matrix form:
left: right:
[ 0.5 0 0 ] [ 0.5 0 0.5 ]
[ 0 1 0 ] [ 0 1 0 ]
[ 0 0 1 ] [ 0 0 0 ]
Which can be done using xinput:
xinput set-prop <left> --type=float "Coordinate Transformation Matrix" \
0.5 0 0 0 1 0 0 0 1
xinput set-prop <right> --type=float "Coordinate Transformation Matrix" \
0.5 0 0.5 0 1 0 0 0 1
Likewise more complication setups involving more heads, rotation or
different resolution can be handled.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
commit c2d0b3b437
"xfree86: store the InputAttributes in the input device."
introduced the new API. Bump the input version so drivers can handle this
appropriately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Daniel Stone deleted the API for these in 2006, in commit
96e32805d1.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Eric Anholt made the corresponding fix in glx/render2swap.c in commit
49d38ab232.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Mikhail fixed the corresponding Xallocs, but missed these uses of Xfree
in commit 3f3ff971ec.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
