GitLab

Explain that AIGLX is normally expected to fail and the users should
not really worry about it. Also provide a warning in the case if the
driver has been compiled without libUMP support (it could be that
the user actually wanted 3D acceleration, but just has not installed
all the needed dependencies).
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

This initial G2D support code can speed up moving windows in XFCE. Currently
disabled by default, but can be enabled by editing /etc/X11/xorg.conf and
adding the following line to the "Device" section:

        Option          "AccelMethod" "G2D"
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Avoid creating a new mapping because that's a waste of the virtual address
space. Also we are going to use this xserver framebuffer mapping address
for testing whether window backing pixmaps are allocated in the framebuffer
and can be accelerated by G2D.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The existing kernel driver from Allwinner for G2D accelerator
is quite bad because ioctls are synchronous and blocking the
caller thread, compromise security (basically it is a backdoor
for copying data in memory between any arbitrary physical
addresses) and have high overhead (each individual fill or
blit operation needs an ioctl). But we need to start with
something, so use this stuff as a placeholder.

The g2d_driver.h header file is taken from linux-sunxi-3.4
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Actually they are converted to 32x32 with 256 color palette. In the
case if we have more than 256 unique colors, the color components
of the pixels are reduced from 8-bit to 7-bit, then to 6-bit if
necessary and so on (until we reduce the number of unique colors
so that they can fit the palette). In the worst case we may
theoretically end up with just 2 bits per A, R, G and B channels,
but in practice 7 or 6 bits seem to be enough.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The modern desktops may use ARGB cursors. As the current
sunxi display controller support code can't handle this
type of cursor yet, the X server fallbacks to a software
cursor which is not visible under layers and ruining user
experience.

This patch adds empty implementations for "UseHWCursorARGB"
and "LoadCursorARGB" functions which just return error for
now (so that the X server still fallbacks to software cursor).
However we also introduce callback functions responsible for
notifying the DRI2 code about enabling/disabling the use of
hardware cursor. So that now hardware overlays are disabled
when switching to software cursor and re-enabled again when
switching back to hardware cursor.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

Testing with gnome-shell revealed a problem. We need to migrate
pixmaps into UMP buffers in order to allow the GLESv2 based
compositing manager to actually access the content of redirected
windows, rendered by X11 applications into offscreen pixmaps.

Just to make sure that we don't add any unneeded overhead for 2D
(neither extra CPU cycles nor the increase for unrelated pixmaps
memory footprint), a hash table (currently uthash [1]) is used
for connecting DRI2-enabled pixmaps with UMP buffers. The lookups
are only performed on DRI2 buffer creation and pixmap destruction.

1. http://troydhanson.github.com/uthash/

Reported-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

The driver can use sunxi display controller layers for fully visible
windows, avoiding expensive memory copy.

Hardware cursor is necessary because it is also visible on
top of sunxi disp layers, while software cursor is not.

FIXME: there is one minor problem with negative cursor
positions. The hardware does not support them, so such
positions are just set to 0 for now. In the future this
can be solved better by changing the cursor picture and
showing only the parts which are visible on screen.

Note: the header file "sunxi_disp_ioctl.h" is GPL licensed. So until
it is gets a MIT/X11 replacement, the DDX driver is GPL licensed as
a whole. The individual source files still have their own license.
Also in order to avoid any possible confusion, the MIT/X11 license
header from COPYING has been added to "fbdev.c" and "fbdev_priv.h".

It is going to be included by multiple different source files.

As there is no way for the hardware specific bits to be accepted
in xf86-video-fbdev, we need a new driver with its own name.

Signed-off-by: Adam Jackson <ajax@redhat.com>

Signed-off-by: Dave Airlie <airlied@redhat.com>

Generated using util/modular/x-driver-screen-scrn-conv.sh
Signed-off-by: Dave Airlie <airlied@redhat.com>

fbdev seems to be the only video driver without MOD_CLASS_VIDEODRV
Signed-off-by: Paulo Zanoni <pzanoni@mandriva.com>
Reviewed-by: Jesse Adkins <jesserayadkins@gmail.com>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Use XV from server's xorg-server.h to determine whether to perform XV
initialization.
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Signed-off-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Julien Cristau <jcristau@debian.org>

Fixes crash in CloseScreen().
Signed-off-by: Julien Cristau <jcristau@debian.org>
Tested-by: Cyril Brulebois <kibi@debian.org>

Signed-off-by: Adam Jackson <ajax@redhat.com>

To build VESA driver for use with pci-rework Xserver, add --enable-pciacces
to the configure command line.  Otherwise, the "traditional" VESA driver will
be built.

We were determining it from the mode which is current at X server startup,
which may have a completely different pitch.

Based on Adam Jackson's shadow framebuffer fixes in xf86-video-vesa.

Add a couple of items while we're at it.