44cb9578c0
Reverse PRIME seems to be designed with discrete graphics as a sink in mind, designed to do an extra copy from sysmem to vidmem to prevent a discrete chip from needing to scan out from sysmem. The criteria it used to detect this case is if we are a GPU screen and Glamor accelerated. It's possible for i915 to fulfill these conditions, despite the fact that the additional copy doesn't make sense for i915. Normally, you could just set AccelMethod = none as an option for the device and call it a day. However, when running with modesetting as both the sink and the source, Glamor must be enabled. Ideally, you would be able to set AccelMethod individually for devices using the same driver, but there seems to be a bug in X option parsing that makes all devices on a driver inherit the options from the first detected device. Thus, glamor needs to be enabled for all or for none until that bug (if it's even a bug) is fixed. Nonetheless, it probably doesn't make sense to do the extra copy on i915 even if Glamor is enabled for the device, so this is more user friendly by not requiring users to disable acceleration for i915. v1: N/A v2: N/A v3: N/A v4: Initial commit v5: Unchanged v6: Rebase onto ToT v7: NULL check and free drmVersionPtr Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Goins <agoins@nvidia.com> |
||
---|---|---|
composite | ||
config | ||
damageext | ||
dbe | ||
dix | ||
doc | ||
dri3 | ||
exa | ||
fb | ||
glamor | ||
glx | ||
hw | ||
include | ||
m4 | ||
man | ||
mi | ||
miext | ||
os | ||
present | ||
pseudoramiX | ||
randr | ||
record | ||
render | ||
test | ||
Xext | ||
xfixes | ||
Xi | ||
xkb | ||
.dir-locals.el | ||
.gitignore | ||
autogen.sh | ||
configure.ac | ||
COPYING | ||
devbook.am | ||
docbook.am | ||
fix-miregion | ||
fix-miregion-private | ||
fix-patch-whitespace | ||
fix-region | ||
Makefile.am | ||
manpages.am | ||
README | ||
xorg-server.m4 | ||
xorg-server.pc.in | ||
xserver.ent.in |
X Server The X server accepts requests from client applications to create windows, which are (normally rectangular) "virtual screens" that the client program can draw into. Windows are then composed on the actual screen by the X server (or by a separate composite manager) as directed by the window manager, which usually communicates with the user via graphical controls such as buttons and draggable titlebars and borders. For a comprehensive overview of X Server and X Window System, consult the following article: http://en.wikipedia.org/wiki/X_server All questions regarding this software should be directed at the Xorg mailing list: http://lists.freedesktop.org/mailman/listinfo/xorg Please submit bug reports to the Xorg bugzilla: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg The master development code repository can be found at: git://anongit.freedesktop.org/git/xorg/xserver http://cgit.freedesktop.org/xorg/xserver For patch submission instructions, see: http://www.x.org/wiki/Development/Documentation/SubmittingPatches For more information on the git code manager, see: http://wiki.x.org/wiki/GitPage