- 22 Sep, 2013 1 commit
-
-
Siarhei Siamashka authored
Because a wide range of embedded ARM devices are actually supported (Allwinner A1X/A20, Raspberry Pi, ODROID-X, Rockchip, ...) and are getting some sort of performance improvement and/or hardware acceleration, the DDX driver needs a vendor neutral name. Resolves https://github.com/ssvb/xf86-video-fbturbo/issues/10 Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 31 Jul, 2013 1 commit
-
-
Siarhei Siamashka authored
When enabled, it tries to avoid tearing in OpenGL ES applications. Works on sunxi hardware in the case if the hardware overlay (sunxi disp layer) is used for a DRI2 window. The name of this option and the description in the man page has been borrowed from intel and radeon drivers. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 18 Jul, 2013 1 commit
-
-
Harm Hanemaaijer authored
Add the "XVHWOverlay" boolean xorg.conf option to make it possible to disable the XV acceleration feature using display layers on sunxi hardware. Signed-off-by: Harm Hanemaaijer <fgenfb@yahoo.com>
-
- 16 Jul, 2013 1 commit
-
-
Siarhei Siamashka authored
Proper layer sharing between XV and DRI2 still needs to be implemented. Additionally we still need NEON and/or G2D "textured overlay" as a fallback solution for the composited desktop (NEON optimized XV is going to be useful for a wide range of ARM devices). A bit of performance tuning is also necessary. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 12 Jun, 2013 3 commits
-
-
Siarhei Siamashka authored
This should be useful for Raspberry Pi. When reading uncached source buffers, the VFP optimized overlapped two-pass blit is roughly 2-3 times slower than memcpy in cached memory. Which makes it reasonably competitive compared to ShadowFB (considering that ShadowFB allocates an extra buffer, does extra memory copies which take time and thrash L2 cache, etc.). It even provides a slight performance advantage in a more or less realistic use case (scrolling in xterm), which needs reads from the framebuffer: ==== Before (xf86-video-fbdev with ShadowFB) ==== $ time DISPLAY=:0 xterm +j -maximized -e cat longtext.txt real 1m50.245s user 0m1.750s sys 0m0.800s ==== After (xf86-video-sunxifb without ShadowFB) ==== $ time DISPLAY=:0 xterm +j -maximized -e cat longtext.txt real 1m27.709s user 0m1.690s sys 0m0.920s We get decent results even when reading from the framebuffer. However in many typical workloads (excluding scrolling and dragging windows) the framebuffer is primarily used as write-only. In write-only use cases ShadowFB is just pure overhead. So getting rid of it is a very good idea as this improves overall graphics performance. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
Siarhei Siamashka authored
A small typo in a function argument and C compiler happily accepting void pointers instead of something else is a dangerous combo. Need to be more careful. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
Siarhei Siamashka authored
This patch implements a heuristics, which enables backing store for some windows. When backing store is enabled for a window, the window gets a backing pixmap (via automatic redirection provided by composite extension). It acts a bit similar to ShadowFB, but for individual windows. The advantage of backing store is that we can avoid "expose event -> redraw" animated trail in the exposed area when dragging another window on top of it. Dragging windows becomes much smoother and faster. But the disadvantage of backing store is the same as for ShadowFB. That's a loss of precious RAM, extra buffer copy when somebody tries to update window content, potentially skip of some frames on fast animation (they just do not reach screen). Also hardware accelerated scrolling does not currently work for the windows with backing store enabled. We try to make the best use of backing store by enabling backing store for all the windows that are direct children of root, except the one which has keyboard focus (either directly or via one of its children). In practice this heuristics seems to provide nearly perfect results: 1) dragging windows is fast and smooth. 2) the top level window with the keyboard focus (typically the application that a user is working with) is G2D accelerated and does not suffer from any intermediate buffer copy overhead. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 07 Jun, 2013 2 commits
-
-
Siarhei Siamashka authored
With the fallback to CPU backend for unsupported blits and also threshold for avoiding small blits, now G2D should always provide best overall performance. The users of recent versions of xf86-video-sunxifb are supposed to also have a reasonably recent version of linux-sunxi kernel. Which includes the following fix: https://github.com/linux-sunxi/linux-sunxi/commit/3d49345343a1535b The users of old kernels are going to see screen corruption on dragging windows and scrolling. They just should upgrade :) Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
Siarhei Siamashka authored
The G2D driver only supports framebuffer->framebuffer blits and also can't be used to accelerate dragging windows to the right (without hacking the kernel driver to do two-pass blit there). This patch adds fallback to NEON optimized CPU backend instead of resorting to use poorly performing fbBlt in these cases. Note: we assume that ioctls normally do not fail (even if they do, the slow old style fallback to fbBlt is not the worst thing to worry about). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 30 Mar, 2013 1 commit
-
-
Siarhei Siamashka authored
Should be useful for better performance when moving windows and scrolling on the devices without a dedicated 2D hardware accelerator (Allwinner A13). Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 26 Mar, 2013 1 commit
-
-
Siarhei Siamashka authored
The sunxi_x_g2d.c file contains the midlayer code for hooking the G2D optimized blit into xserver. But in fact it does not strictly need to depend on anything sunxi specific. So now we introduce a simple "blt2d_i" interface struct which specifically provides a pointer to the accelerated blit function. And just use this interface struct instead of the whole "sunxi_disp_t". This allows to easily reuse the same code for other non-G2D or even non-sunxi blit implementations in the future. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 22 Mar, 2013 1 commit
-
-
Siarhei Siamashka authored
It might be not statically compiled into kernel (for example in Fedora), so we should try to explictly load it. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 17 Mar, 2013 2 commits
-
-
Siarhei Siamashka authored
Reported-by: Maurice de la Ferté <kadava@gmx.de> Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
Siarhei Siamashka authored
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>
-
- 14 Mar, 2013 2 commits
-
-
Siarhei Siamashka authored
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>
-
Siarhei Siamashka authored
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>
-
- 12 Mar, 2013 1 commit
-
-
Siarhei Siamashka authored
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 24 Jan, 2013 1 commit
-
-
Siarhei Siamashka authored
The driver can use sunxi display controller layers for fully visible windows, avoiding expensive memory copy.
-
- 20 Jan, 2013 4 commits
-
-
Siarhei Siamashka authored
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.
-
Siarhei Siamashka authored
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".
-
Siarhei Siamashka authored
It is going to be included by multiple different source files.
-
Siarhei Siamashka authored
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.
-
- 25 Sep, 2012 1 commit
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- 05 Jun, 2012 3 commits
-
-
Dave Airlie authored
Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Generated using util/modular/x-driver-screen-scrn-conv.sh Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
-
- 17 Dec, 2010 1 commit
-
-
Paulo Zanoni authored
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>
-
- 10 Nov, 2010 3 commits
-
-
Cyril Brulebois authored
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>
-
Cyril Brulebois authored
Signed-off-by: Cyril Brulebois <kibi@debian.org> Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Julien Cristau <jcristau@debian.org>
-
Cyril Brulebois authored
Signed-off-by: Cyril Brulebois <kibi@debian.org> Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Julien Cristau <jcristau@debian.org>
-
- 08 Feb, 2010 1 commit
-
-
Julien Cristau authored
Fixes crash in CloseScreen(). Signed-off-by: Julien Cristau <jcristau@debian.org> Tested-by: Cyril Brulebois <kibi@debian.org>
-
- 14 Dec, 2009 1 commit
-
-
Adam Jackson authored
Signed-off-by: Adam Jackson <ajax@redhat.com>
-
- 28 Jul, 2009 2 commits
-
-
Dave Airlie authored
-
Dave Airlie authored
-
- 28 May, 2009 1 commit
-
-
Adam Jackson authored
-
- 04 Mar, 2009 1 commit
-
-
Adam Jackson authored
-
- 24 Nov, 2008 1 commit
-
-
Adam Jackson authored
-
- 12 Oct, 2007 1 commit
-
-
Matthias Hopf authored
-
- 22 Jan, 2007 1 commit
-
-
Ian Romanick authored
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.
-
- 31 Dec, 2006 1 commit
-
-
Michel Dänzer authored
We were determining it from the mode which is current at X server startup, which may have a completely different pitch.
-