Age | Commit message (Collapse) | Author | Files | Lines |
|
We should update the serial number even if we just change a single field.
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Having miPointerMove and miPointerMoved is confusing, especially since both
do the same thing bar the event delivery. Also, miPointerMove calls
miPointerMoved which indicates some confusion in the temporal alignment of
cause and effect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
miPointerMoved already has the same code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
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>
|
|
This reverts commit 9120e58556014e514eef9dfe43cdea4b74dc66ae.
Whoops, please revert this patch -- overlay is in use in nvidia drivers,
and it's too late in release cycle to remove it.
I feel really sorry that I kept this patch in my tree. I will submit
another one, removing only XAA overlay hooks which are not used at all.
|
|
The only reference to it in server and drivers is in XAA overlay code which
would segfault as no miInitOverlay is called ever. No segfaults were observed
"in wild", so XAA overlay is probably also unused.
XAA code is modified to act as if miOverlayCopyUnderlay always returned false,
because XAACopyWindow8_32 could only set doUnderlay to true if it's called from
miOverlayMoveWindow or miOverlayResizeWindow, which can only be called if
miInitOverlay has hooked those functions, and no driver (on fd.o) or server code
calls that.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
|
|
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Tested-by: Dan Nicholson <dbn.lists@gmail.com>
|
|
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>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-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>
|
|
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>
|
|
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>
|
|
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>
|
|
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)
|
|
This eliminates a dynamically-allocated MAXSCREENS-sized array.
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)
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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>
|
|
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>
|
|
Reverts part of the effects of 518f3b189b6c8aa28b62837d14309fd06163ccbb,
"mi: don't thrash resources when displaying the software cursor across
screens". The per-screen cache is preserved, and the GCs are still
allocated eagerly, but now it doesn't construct pRootPicture until
somebody attempts to draw an ARGB cursor.
I noticed crashes in Xnest, which doesn't support the RENDER extension,
but I suspect other DDXes that support disabling that extension would
have had issues as well.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Pierre-Loup A. Griffais <pgriffais@nvidia.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>
|
|
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>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Nobody wraps the mi software-cursor sprite rendering implementations.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Please note this patch breaks the ABI.
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Please note this patch breaks the ABI.
Signed-off-by: Oliver McFadden <oliver.mcfadden@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
The exceptions are ProcChangeGC and CreateGC.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Because that's insane.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Both functions compute a set of spans and either fill them immediately
or accumulate them into a caller-provided buffer.
Computing the spans used only the miTranslate and lineWidth fields of
pGC, and neither could have been changed by the initial
ChangeGC/ValidateGC pair, so it's safe to compute the spans first.
Then both functions consume the spans the same way, so factor that into
a new fillSpans function.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
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.
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>
|
|
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Matt Turner <mattst88@gmail.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>
|
|
miPolyPoint ought to leave the GC unchanged even if it fails. ajax says:
> We have a new winner for the oldest-bug competition! It's actually
> been like that since X11R1:
>
> -rw-r--r--. 1 ajax ajax 2817 1987-09-12 01:20 ddx/mi/mipolypnt.c
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
|
|
Also make it stop being a macro.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
|
|
This does make wide ellipses slower, by a factor of twoish:
946000.0 521000.0 ( 0.55) 10-pixel wide ellipse
98300.0 49900.0 ( 0.51) 100-pixel wide ellipse
17700.0 9310.0 ( 0.53) 500-pixel wide ellipse
16900.0 7980.0 ( 0.47) 100-pixel wide dashed ellipse
16100.0 5370.0 ( 0.33) 100-pixel wide double-dashed ellipse
But no one cares, and it's a modest size win:
text data bss dec hex filename
1773824 69552 59288 1902664 1d0848 hw/vfb/Xvfb.before
1773112 69552 58648 1901312 1d0300 hw/vfb/Xvfb
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Presumably no implications, especially security-wise.
Signed-off-by: Matthias Hopf <mhopf@suse.de>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This avoids painting the root window when it isn't actually drawable.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
|
|
|
|
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>
|
|
|
|
This changes the DC layer to maintain a persistent set of GCs/pixmaps/pictures
for each pScreen instead of failing to thrash between them when changing
screens.
Signed-off-by: Pierre-Loup A. Griffais <pgriffais@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Peter Hutterer <peter.hutterer@who-t.net>
|