Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This plumbs the full width color for solid pictures through to fb, exa,
and glamor. External drivers and acceleration code may wish to make a
similar change for sufficiently new servers.
v2: Don't break ABI (Michel Dänzer)
v2.1: Use the (correct) full color in fb too (Michel Dänzer)
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
... instead of its root window. Xwayland's rootless mode empties the
root window border clip since its root window has no storage, but
redirected windows (the only kind it can show) will have a non-empty
border clip anyway, cf. the #ifdef COMPOSITE in miComputeClips. With
this change, non-glamor Xwayland's GetImage actually works.
Other acceleration layers may need to change to account for this, but
this appears to be safe for the existing open source drivers. Only the
xfree86 DDX has any problem with losing its framebuffer on VT switch,
and even then only for UMS drivers (which excludes glamor, uxa, and sna
from consideration). This leaves exa, which already contains code to
evict pixmaps to host memory on VT switch. Since the xfree86 core will
still empty the root clip on VT switch, while the root window itself may
not contain a valid image we won't try to touch it, but GetImage from a
redirected window will now work even when switched away.
Acked-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Formerly we'd zero the image data and then pull out a plane at a time.
It's faster to apply the planemask after the fact, since that turns the
GetImage into a memcpy:
100000.0 101000.0 (1.010) (copy 0xaaaaaaaa) ShmGetImage 10x10 square
42400.0 59400.0 (1.401) (copy 0xaaaaaaaa) ShmGetImage 100x100 square
3040.0 5280.0 (1.737) (copy 0xaaaaaaaa) ShmGetImage 500x500 square
96100.0 95200.0 (0.991) (0xaaaaaaaa) GetImage 10x10 square
29600.0 36800.0 (1.243) (0xaaaaaaaa) GetImage 100x100 square
1850.0 2620.0 (1.416) (0xaaaaaaaa) GetImage 500x500 square
Measured with Xvfb at depth 24 on Skylake i7-6560U.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
v2:
- Require power-of-two bpp in ScreenInit
- Eliminate fbCreatePixmapBpp
v3
- Squash in the exa and glamor changes so we can remove pRotatedPixmap
in the same stroke.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Unlike GetImage, for which the provided planemask restricts the data
delivered, for PutImage in XYPixmap format, all of the planes in the
drawable depth are sent and those outside the plane mask are simply
ignored.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Set a destructor function on pixman images and call fbFinishAccess()
from there, rather than directly from free_pixman_pict(). This ensures
that fbFinishAccess() gets called even if pixman still has a reference
to the image after free_pixman_pict(), as is the case for alphamaps.
[ajax: Squash an unused variable warning in the non-wfb build]
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Arcady Goldmints-Orlov <arcadyg@nvidia.com>
Reviewed-by: Søren Sandmann <ssp@redhat.com>
v2: fixup whitespace
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=54168
Fix errors introducted in 863d528a9f. Said
patch does indeed remove the problematic writes to bad memory, however
it also introduces errors in the algoritm. This patch has the effect of
reverting said patch and adding an if in the proper location to catch
the out of bounds memory write without causing problems to the overall
algorithm.
Signed-off-by: Alex Orange <crazycasta@gmail.com>
Reviewed-by: Peter Harris <pharris@opentext.com>
Tested-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Again, clearly meant to be a fast path, but this turns out not to be the
case.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Appears to have been cargo-culted in from cfb and then never used.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
And remove fbStippleTable since gcc can't figure that out itself.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This is clearly meant to be a fast path, but it appears to be a net
loss at this point.
If you really wanted to ricer-tune here, note that the inner loop of
fbBltOne is a bit too complicated for gcc (at least 4.8.2), it doesn't
specialize the loop for the handful of legal values of bitsPerDst, which
means computing at runtime what could have been const-propped.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
The other paths don't build or work, PCI and other buses are almost
always 32 bit data paths, and X doesn't really support pixels bigger
than that anyway.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
gcc doesn't appear to be smart enough to fold away the indirection here,
even if you make fbLaneTable const.
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This does have one semantic change. FixesCreateRegionFromPicture used to
throw BadImplementation if you tried to create a region from a picture
with no client clip. I changed that to BadMatch here since that more
honestly describes what's going on.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This existed to be passed to the bs recovery routine; since we back all
planes, we don't care.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
A careful read shows that it was always NULL. It hasn't always been; as
the DDX spec indicates, it was the "occluded region that has backing
store", but since that backing store code is long gone, we can nuke it.
mi{,Overlay}WindowExposures get slightly simpler here, and will get even
simpler in just a moment.
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We have a hack in fb layer for a 24bpp screen to use 32bpp images, and
fbCreateWindow() replaces its drawable.bitsPerPixel field
appropriately. But, the problem is that it always replaces when 32bpp
is passed. If the depth is 32, this results in bpp < depth, which is
actually invalid.
Meanwhile, fbCreatePixmap() has a more check and it creates with 24bpp
only when the passed depth <= 24 for avoiding such a problem.
This oneliner patch just adds the similar check in fbCreateWindow().
This (hopefully) fixes the long-standing broken graphics mess of
cirrus KMS with 24bpp.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Keith Packard <keithp@keithp.com>
We fixed fbCloseScreen to use the FreePixmap function so that the
private counts would be updated correctly during CloseScreen. Xvfb
calls FreePixmap and sets devPrivate to NULL before fbCloseScreen is
called; not checking devPrivate before calling would result in a NULL
pointer dereference.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Call FreePixmap() instead of free() to destroy the screen pixmap in
fbCloseScreen().
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This lets other code jump directly into the fb code for fallbacks
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Eric Anholt <eric@anholt.net>
The width parameter is used to disable the blit fast-path (memcpy) when
source and destination rows overlap in memory. This check was added in [0].
Unfortunately, the calculation to determine if source and destination
lines overlapped was incorrect:
(1) it converts width from pixels to bytes, but width is actually in
bits, not pixels.
(2) it adds this byte offset to dst/srcLine, which implicitly converts
the offset from bytes to sizeof(FbBits).
Fix both of these by converting addresses to byte pointers and width
to bytes and doing comparisons on the resulting byte address.
For example:
A 32-bpp 1366 pixel-wide row will have
width = 1366 * 32 = 43712 bits
bpp = 32
(bpp >> 3) = 4
width * (bpp >> 3) = 174848 FbBits
(FbBits *)width => 699392 bytes
So, "careful" was true if the destination line was within 699392 bytes,
instead of just within its 1366 * 4 = 5464 byte row.
This bug causes us to take the slow path for large non-overlapping rows
that are "close" in memory. As a data point, XGetImage(1366x768) on my
ARM chromebook was taking ~140 ms, but with this fixed, it now takes
about 60 ms.
XGetImage() -> exaGetImage() -> fbGetImage -> fbBlt()
[0] commit e32cc0b4c8
Author: Adam Jackson <ajax@redhat.com>
Date: Thu Apr 21 16:37:11 2011 -0400
fb: Fix memcpy abuse
The memcpy fast path implicitly assumes that the copy walks
left-to-right. That's not something memcpy guarantees, and newer glibc
on some processors will indeed break that assumption. Since we walk a
line at a time, check the source and destination against the width of
the blit to determine whether we can be sloppy enough to allow memcpy.
(Having done this, we can remove the check for !reverse as well.)
v3: Convert to byte units
This first checks to make sure the blt is byte aligned, converts all
of the data to byte units and then compares for byte address range
overlap between source and dest.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Build fbcmap_mi.c once, rather than once for each DDX, and make it part of libfb
or libwfb convenience library.
Since 84e8de1271 we don't have fbcmap.c
This is a sort of revert of 17d85387d1
v2: Remove libkdrivestubs.la from configure.ac
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer'
is used throughout the X server for other things, and having duplicate
names generates compiler warnings.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Originally added in early 2009, not being used elsewhere anymore.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
this allows the pixmap dirty helper to be used for reverse optimus,
where the GPU wants to copy from the shared pixmap to its VRAM copy.
[airlied: slave_dst is wrong name now but pointless ABI churn at this point]
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Renaming this function was missed in commit
9cbcb5bd6a, so both libfb.so and libwfb.so define
functions named fbDestroyGlyphCache.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Søren Sandmann <ssp@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Jan Beich
Dave Airlie
Alan Coopersmith
Thierry Reding
Adam Jackson
Peter Hutterer
Eric Anholt
Keith Packard
Arcady Goldmints-Orlov
Alex Orange
Takashi Iwai
Brendan King
Peter Harris
Jon TURNEY
Aaron Plattner