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>
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)
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>
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>
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>
Peter wants to get a larger patch sequence put together and I didn't
read past the commit message to see the 'don't take this patch
please'.
This reverts commit 531ff40301.
Some input drivers need to implement an internal hotplugging scheme for
dependent devices to provide multiple X devices off one kernel device file.
Such dependent devices can be added with NewInputDeviceRequest() but they are
not removed when the config backend calls DeleteInputDeviceRequest(),
leaving the original device to clean up.
Example of the wacom driver:
config/udev calls NewInputDeviceRequest("stylus")
wacom PreInit calls
NewInputDeviceRequest("eraser")
NewInputDeviceRequest("pad")
NewInputDeviceRequest("cursor")
PreInit finishes.
When the device is removed, the config backend only calls
DeleteInputDeviceRequest for "stylus". The driver needs to call
DeleteInputDeviceRequest for the dependent devices eraser, pad and cursor to
clean up properly.
However, when the server terminates, DeleteInputDeviceRequest is called for
all devices - the driver must not remove the dependent devices to avoid
double-frees. There is no method for the driver to detect why a device is
being removed, leading to elaborate guesswork and some amount of wishful
thinking.
Though the input driver's UnInit already supports flags, they are unused.
This patch uses the flags to supply information where the
DeleteInputDeviceRequest request originates from, allowing a driver to
selectively call DeleteInputDeviceRequest when necessary.
Also bumps XINPUT ABI.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
No special memory handling is used to give drivers the maximum flexibility
with the data. Drivers should be able to call realloc on the product string
if needed and perform similar operations.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
For AtomError, this should fix a clang warning; in the other cases it's
just good documentation.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This eliminates a poorly-named, poorly-documented field from the
ScreenRec, using a previously-unused flag bit in each GC instead.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Keith Packard <keithp@keithp.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The structure containing the state of animated cursor was amended within
SpriteInfoRec, removing all previously privates logic to keep such state.
API change: It was removed MAXDEVICES dependency \o/
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
XSELinux was the only consumer of these interfaces and it no longer
needs them.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
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 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>
C89 guarantees alignment of pointers returned from malloc/calloc/realloc, so
stop fiddling with alignment manually and just pass the arguments to library
functions.
Also convert silent error when negative size is passed into function into
warning in log file.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
With Xinerama enabled, event coordinates are relative to Screen 0, so
they can be negative. The new DeviceEvent's coordinates are of type
uint16_t, making screens above and to the left of Screen 0 unusable.
X.Org Bug 24986 <https://bugs.freedesktop.org/show_bug.cgi?id=24986>
Signed-off-by: Chris Humbert <freedesktop@mahadri.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
In the process, fixes a memory leak in CloseDevice, and an unchecked
memory allocation in InitializePredictableAccelerationProperties.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Needed as the privates stuff uses the callbacks before they would have
been defined in dix.h
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
The functions exported by the devPrivates code were poorly documented. I tried
to spruce it up a little.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Bizarre. This seems to never be used before. I left the field in ScreenInfo,
with another name. So, stop looking at it.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
This should be removed together with 49b93df8.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
The rationale behind is because no sane application will use this when we have
modern APIs such DRI2. Besides, as a fact, xfree86 server has already
deprecated this extension in 1998:
http://www.xfree86.org/3.3.6/isc7.html
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This patch was created with:
git ls-files '*.[ch]' | while read f; do unifdef -B -DRENDER -o $f $f; done
Signed-off-by: Keith Packard <keithp@keithp.com>
The name XkbDDXFakeDeviceButton and XkbDDXFakeDeviceMotion is somewhat
misleading, there's no DDX involved in the game at all anymore.
This removes XkbFakeDeviceMotion and XkbFakeDeviceButton from the API where
it arguably shouldn't have been in the first place.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Section 4.6.1 of the XKB spec says that "the initial event always moves the
cursor the distance specified in the action [...]", so skip the
POINTER_ACCELERATE flag for GPE, it would cause double-acceleration.
Potential regression - GPE expects the coordinates to be either relative or
both. XKB in theory allows for x to be relative and y to be absolute (or
vice versa). Let's pretend that scenario has no users.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Simon Thum <simon.thum@gmx.de>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
