The SELinux extension does store a security label in the screen
devPrivates. Fixes crash caused by overwriting another private.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Reported-by: Justin Mattock <justinmattock@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Selection objects were not being allocated with privates, and both
objects had a stray statement that zeroed out the devPrivates field.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
Reported-by: Justin Mattock <justinmattock@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
CurrentTime is used by clients to skip setting the time, but not by the
server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
If the master does not have a button class, recalculating the number of
buttons required for this master dereferences a NULL pointer. Guard against
this, if the master pointer doesn't have a button class, it doesn't need to
update it's number of buttons.
Reproducible:
Two devices on the same master, device NB with axes but no buttons, device
A+B with axes and button .
If NB was the last one to send an event through the master when A+B is
removed from the server, master->button is NULL and leads to the above
NULL-pointer dereference.
X.Org Bug 29669 <http://bugs.freedesktop.org/show_bug.cgi?id=29669>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Right now, Xephyr and others don't get to use XKB on the slave devices.
Which works given that no-one cares about SDs just yet but event processing
is different if the ProcessInputProc isn't wrapped properly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
RegisterPointerDevice() and RegisterKeyboardDevice() were already mapped to
RegisterOtherDevice() and obsolete.
RegisterOtherDevice() was called for all devices and the two assignments can
simply be moved into AddInputDevice(). Purge RegisterOtherDevice() and
pretend it never happened.
*lalalalala*
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
max_keys_per_mod equal to zero is a valid situation so generate_modkeymap
should not return BadAlloc in this case.
Signed-off-by: Adam Tkac <atkac@redhat.com>
Reviewed-by: Patrick E. Kane <pekane52 at gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Devices that send motion events with valuators other than x/y get core
motion events with unchanged x/y coordinates. This confuses some
applications.
If the DeviceEvent does not have the x/y valuators set, return BadMatch on
core conversion, thus skipping the event altogether.
Reported-by: Bartosz Brachaczek <b.brachaczek@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Bartosz Brachaczek <b.brachaczek@gmail.com>
GPE and friends modify the valuators array passed in. Which means any driver
using e.g. xf86PostButtonEventP(..., valuators) twice to emulate a button
click will provide garbage data on the second run.
This is currently affecting the wacom driver, xf86PostButtonEventP() with
valuators is required to have input events with device-specific axis values.
Passing the same valuators in twice, once with press, once with release,
will see the valuators modified in the first call and garbage submitted in
the next one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
From: Dave Airlie <airlied@linux.ie>
We were seeing a crash in the FreeAllResources codepath,
running valgrind revealed this,
==12536== Invalid read of size 4
==12536== at 0x810BCAB: DeliverPropertyEvent (rrproperty.c:33)
==12536== by 0x80958A4: TraverseTree (window.c:227)
==12536== by 0x809593E: WalkTree (window.c:255)
==12536== by 0x810BC66: RRDeliverPropertyEvent (rrproperty.c:53)
==12536== by 0x810BD5D: RRDeleteProperty.clone.0 (rrproperty.c:76)
==12536== by 0x810BD98: RRDeleteAllOutputProperties (rrproperty.c:88)
==12536== by 0x810A36E: RROutputDestroyResource (rroutput.c:407)
==12536== by 0x808DF4E: FreeClientResources (resource.c:859)
==12536== by 0x808E005: FreeAllResources (resource.c:876)
==12536== by 0x8062300: main (main.c:305)
==12536== Address 0x46ba8ac is 4 bytes inside a block of size 164 free'd
==12536== at 0x40057F6: free (vg_replace_malloc.c:325)
==12536== by 0x8087F1F: _dixFreeObjectWithPrivates (privates.c:357)
==12536== by 0x809832A: DeleteWindow (window.c:926)
==12536== by 0x808DF4E: FreeClientResources (resource.c:859)
==12536== by 0x808E005: FreeAllResources (resource.c:876)
==12536== by 0x8062300: main (main.c:305)
Its a use after free on the root window, since we have already deleted it
at this point. This patch checks if the window we are destroying is the root
window and resets the pointer to NULL if it is.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Tested-by: Dave Airlie <airlied@redhat.com>
None of them do anything useful now that pointer acceleration is
entirely handled in the server. (Does not completely nuke yet,
since that would be an API/ABI break.)
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>
commit 1432785839
xkb: release XTEST pointer buttons on physical releases. (#28808)
revealed a bug with the XTEST/PointerKeys interaction.
Events resulting from PointerKeys are injected into the event processing
stream, not appended to the event queue. The events generated for the fake
button press include a DeviceChangedEvent (DCE), a raw button event and the
button event itself. The DCE causes the master to switch classes to the
attached XTEST pointer device.
Once the fake button is processed, normal event processing continues with
events in the EQ. The master still contains the XTEST classes, causing some
events to be dropped if e.g. the number of valuators of the event in the
queue exceeds the XTEST device's number of valuators.
Example: the EQ contains the following events, processed one-by-one, left to
right.
[DCE (dev)][Btn down][Btn up][Motion][Motion][...]
^ XkbFakeDeviceButton injects [DCE (XTEST)][Btn up]
Thus the event sequence processed looks like this:
[DCE (dev)][Btn down][Btn up][DCE (XTEST)][Btn up][Motion][Motion][...]
The first DCE causes the master to switch to the device. The button up event
injects a DCE to the XTEST device, causing the following Motion events to be
processed with the master still being on XTEST classes.
This patch post-fixes the injected event sequence with a DCE to restore the
classes of the original slave device, resulting in an event sequence like
this:
[DCE (dev)][Btn down][Btn up][DCE (XTEST)][Btn up][DCE (dev)][Motion][Motion]
Note that this is a simplified description. The event sequence injected by
the PointerKeys code is injected for the master device only and the matching
slave device that caused the injection has already finished processing on
the slave. Furthermore, the injection happens as part of the the XKB layer,
before the unwrapping of the processInputProc takes us into the DIX where
the DCE is actually handled.
Bug reproducible with a device that reports more than 2 valuators. Simply
cause button releases on the device and wait for a "too many valuators"
warning message.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
When doing Xinerama, we'll dispatch font ops across all backend screens.
If using a font server (such that some operations can sleep), we'll put
the client to sleep once for each screen, but only wake up once, because
we're trying to keep track of the sleep count in _each_ screen's
closure.
Instead, just ask the core whether the client is already asleep.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The current core enter/leave does not cater for device grabs during
enter/leave events. If a window W contains a pointer P1 and a client grabs a
pointer P2, this pointer will not generate enter/leave events inside this
window.
Hack around this by forcing grabbed devices to always send enter/leave
events.
X.Org Bug 27804 <http://bugs.freedesktop.org/show_bug.cgi?id=27804>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Same as the matching key functions. Buttons, like keys, can have two states
for down/up - one posted, one processed. Posted is set during event
generation (usually in the signal handler). Processed is set during event
processing when the event queue is emptied and events are being delivered to
the client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Initializing the dev privates code after allocating the server client
dev privates would cause the memory leak check to fire at server
startup or reset.
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Behaviour of earlier X servers was to deliver the ButtonPress event
unconditionally, regardless of the actual event mask being set. Thus, a
GrabButton event will always deliver the button press event, a GrabKey
always the key press event, etc. Same goes for XI and XI2.
Reproducible with a simple client requesting a button grab in the form of:
XGrabButton(dpy, AnyButton, AnyModifier, win, True, ButtonReleaseMask,
GrabModeAsync, GrabModeAsync, None, None);
On servers before MPX/XI2, the client will receive a button press and
release event. On current servers, the client receives only the release.
Clients that expect the press event to be delivered unconditionally may
leave the user with a stuck grab.
XTS test results for XGrabButton are identical with and without this patch.
This reverts commit 48585bd1e3.
Conflicts:
dix/events.c
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Behaviour of earlier X servers was to deliver the ButtonPress event
unconditionally, regardless of the actual event mask being set. This is
documented in the protocol:
"This request establishes a passive grab. In the future, the pointer is
actively grabbed as described in GrabPointer, the last-pointer-grab time is
set to the time at which the button was pressed (as transmitted in the
ButtonPress event), and the ButtonPress event is reported if all of the
following conditions are true:
<list of conditions, event mask is not one of them>"
Thus, a GrabButton event will always deliver the button press event, a
GrabKey always the key press event, etc. Same goes for XI and XI2.
Reproducible with a simple client requesting a button grab in the form of:
XGrabButton(dpy, AnyButton, AnyModifier, win, True, ButtonReleaseMask,
GrabModeAsync, GrabModeAsync, None, None);
On servers before MPX/XI2, the client will receive a button press and
release event. On current servers, the client receives only the release.
Clients that expect the press event to be delivered unconditionally.
XTS Xlib13 XGrabButton 5/39 now passes.
This reverts commit 48585bd1e3.
Effectively reverts commit 1c612acca8 as well,
the code introduced with 1c612 is not needed anymore.
Conflicts:
dix/events.c
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Keith Packard <keithp@keithp.com>
X server doesn't need to understand fpe internals, so use
register_fpe_functions from libXfont.
It's required to get new version of libXfont, therefore adjust it to be passed
to autoconf.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Replace xstrdup with strdup when either constant string is
being duplicated or argument is guarded by conditionals and
obviously can't be NULL
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Sometimes the vendor and product names aren't specific enough to target
a USB device, so expose the numeric codes in the ID. A MatchUSBID entry
has been added that supports shell pattern matching when fnmatch(3) is
available. For example:
MatchUSBID "046d:*"
The IDs are stored in lowercase hex separated by a ':' like "lsusb" or
"lspci -n".
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Serial input devices lack properties such as product or vendor name. This
makes matching InputClass sections difficult. Add a MatchPnPID entry to
test against the PnP ID of the device. The entry supports a shell pattern
match on platforms that support fnmatch(3). For example:
MatchPnPID "WACf*"
A match type for non-path pattern matching, match_pattern, has been added.
The difference between this and match_path_pattern is the FNM_PATHNAME
flag in fnmatch(3).
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch was generated by the following Perl code:
perl -i -pe 's/([^_])return\s*\(\s*([^(]+?)\s*\)s*;(\s+(\n))?/$1return $2;$4/g;'
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
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>
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 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>
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 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)
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>
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>
ActivateDevice was ignoring errors from DeviceCursorInitialize, so
cursor-related calls failed later. Jeremy Huddleston saw that crash in
miPointerConstrainCursor, while with Xvfb I saw it in
miSpriteRealizeCursor.
miDCDeviceCleanup frees any non-NULL GCs. miDCDeviceInitialize calls
Cleanup on any failure, but if it failed early then some of the pointers
in the miDCBufferPtr were garbage. Switch from malloc to calloc to
ensure everything's initialized safely first.
With these two fixes, if CreateGC fails then the server gracefully fails
in FatalError instead of segfaulting.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
As of e2929db7b7, doPolyText uses pFont
consistently rather than looking it up again from the saved XID.
clang noticed that "oldfid = fid" could run when fid hadn't been
initialized yet.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Tested-by: Jeremy Huddleston <jeremyhu@apple.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The code this comment was referring to was removed in
8b5086250a "Eliminate bogus event resizing."
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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>
Rather than always returning BadValue, associate an error status like
BadWindow with a resource type like RT_WINDOW, and return the
appropriate one for the requested type.
This patch only touches the core protocol resource types. Others still
return BadValue and need to be mapped appropriately.
dixLookupResourceByType can now return BadImplementation, if the caller
asked for a resource type that has not been allocated in the server.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
If filter is NoEventMask (aka CantBeFiltered), grab is null, and the
first event is not in the set of "critical events", then TryClientEvents
simply calls WriteEventsToClient. In that case, it returns 0 for fake or
dead clients, and 1 otherwise. Inline for this special case.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
TryClientEvents already did this; this commit just moves the assignment
one level down so that no event source has to worry about sequence
numbers.
...No event source, that is, except XKB, which inexplicably calls
WriteToClient directly for several events.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This matches the test in TryClientEvents, and is a superset of tests
done by the callers of these functions. The consequence of forgetting
these tests is a server crash, so they're always desirable. In my
opinion, it's better to not require the callers to remember to do these
checks.
For callers that don't do very much work before calling WriteToClient or
WriteEventsToClient, I've removed the redundant checks.
hw/xquartz/xpr/appledri.c has an interesting case: While its check for
"client == NULL" appears redundant with the test in WriteEventsToClient,
it dereferences client to get the sequence number.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=27497
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
dix/colormap.c and dix/gc.c now dereference a ClientPtr, so they need to
include dixstruct.h. Regression introduced by commit
11c69880c7.
Reported-by: Robert Hooker <sarvatt@ubuntu.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Jamey Sharp <jamey@minilop.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>
In order to execute a wire-level ChangeGC request, we need to look up
the resources named by any XIDs in the value-list. Various places in the
server already have pointers to the resources they want to set into the
GC, though, so over time the interface has evolved to accept either XIDs
or pointers, with several different function call signatures used in
different eras.
This patch makes the existing code require pointers to resources rather
than XIDs, and adds a simple wrapper that looks up any XIDs. The old
dixChangeGC API is preserved by delegating to whichever implementation
is appropriate.
This affects error-handling: If any of the XIDs are invalid, then the GC
is unchanged, and its ChangeGC callback is not invoked. This change is
allowed by the protocol spec, which says, "The order in which components
are verified and altered is server-dependent. If an error is generated,
a subset of the components may have been altered."
Signed-off-by: Jamey Sharp <jamey@minilop.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>
Otherwise we can't check that the XIDs this GC is being initialized with
are accessible to this client.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Eamon Walsh <ewalsh@tycho.nsa.gov>
Reviewed-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
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>
In commit 42d6112ec2, Eamon changed
dixChangeGC to require DixUseAccess on any GCFont XID. I think
doPolyText needs to require the same level of access. Otherwise
dixChangeGC could fail when it does the same lookup, which doPolyText
doesn't check for.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Eamon Walsh <ewalsh@tycho.nsa.gov>
Reviewed-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
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>
Using one variant of function/macro makes it easier to fix the code
later.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
FreeResource() keeps clientTable[cid].elements up to date with the
number of resources allocated to the client. The other free
resource functions (FreeResourceByType(),
FreeClientNeverRetainResources() and FreeClientResources()) don't
maintain this invariant.
Typically, the only consequence is that the element count is too high
and we end up allocating the hash table bigger than necessary. However,
FreeResource() also relies on the element count to restart the search if
the list of resources has been changed during a resource destruction
callback. Since FreeResourceByType() doesn't update the count, if we call
that from a resource destruction callback from FreeResource(), the
loop isn't restarted and we end up following an invalid next pointer.
Furthermore, LookupClientResourceComplex() and
FreeClientNeverRetainResources() don't use the element count to detect
if a callback deleted a resource and may end up following an invalid
next pointer if the resource system is called into recursively.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.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>
this shut up some warnings.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Jamey Sharp <jamey@minilop.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>