We need to distinguish if the backing storage of a pixmap
is XRGB2101010 or XBGR2101010, as different gpu hw supports
different formats. NVidia hw prefers XBGR, whereas AMD and
Intel are happy with XRGB.
Use the red channel mask of the first depth 30 visual of
the x-screen to distinguish which hw format to choose.
This fixes desktop composition of color depth 30 windows
when the X11 compositor uses EGL.
v2: Switch from using the visual of the root window to simply
using the first depth 30 visual for the x-screen, as testing
shows that each driver only exports either xrgb ordering or
xbgr ordering for the channel masks of its depth 30 visuals,
so this should be unambiguous and avoid trouble if X ever
supports depth 30 pixmaps on screens with a non-depth 30 root
window visual. This per Michels suggestion.
v3: No change to v2, but spent some time testing this more on
AMD hw, with my software hacked up to intentionally choose
pixel formats/visual with the non-preferred xBGR2101010
ordering on the ati-ddx, also with a standard non-OpenGL
X-Window with depth 30 visual, to make sure that things show
up properly with the right colors on the screen when going
through EGL+OpenGL based compositing on KDE-5. Iow. to confirm
that my explanation to the v2 patch on the mailing list of why
it should work and the actual practice agree (or possibly that
i am good at fooling myself during testing ;).
v4: Drop the local `red_mask` and just `return visual->red_mask`/
`return 0`, as suggested by Eric Engestrom.
Rebased onto current master, to take the cleanup via the new
function dri2_format_for_depth() into account.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Originally dri3 egl surface was wrapped around _EGLSurface.
With next commit we'll add additional attributes, which will be checked
from generic code. Thus in order to access that we need to use
dri2_egl_surface.
The name of the latter is a misnomer - it should really be dri or
dri_common...
Signed-off-by: Yogesh Marathe <yogesh.marathe@intel.com>
[Emil Velikov: commit message, squash the patches appropriately, add
relevant _eglInitSurface hunk to prevent build breakage]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
v2: From Martin Peres
- Tell we are compiling the dri3 backend in configure.ac
- Update the Makefile.am
- get rid of the LIBDRM_HAS_RENDERNODE_SUPPORT macro
- fix some warnings related to EGLuint64KHR to int64_t conversions
- use dri2_get_dri_config to get the __DRIconfig instead of open-coding it
- replace the occasional tabs with spaces
v3: From Martin Peres
- fix and indent problem (Matt Turner)
- drop the authenticate function, use NULL in the vtable instead (Emil)
- drop some useless includes (Emil Velikov)
- mandate libdrm (Emil Velikov)
- link to xcb-dri3 (Kristian Høgsberg)
- convert to the new loader interface for drwable (Kristian)
- remove some dead code after the dropping of some vfuncs (Kristian)
- add a comment on the topic of rendering to the frontbuffer
v4: From Martin Peres
- do not expose the preserved swap behavior (Acked by Eric Anholt)
Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.co.uk>
Mario Kleiner
Eric Engestrom
Yogesh Marathe
Boyan Ding