Hey,
I've started looking into removing the gralloc method
GRALLOC_MODULE_PERFORM_GET_DRM_FD.
The issues around this seems to be two parts:
1) Finding the right device to open
2) Sharing the device between components
Finding the right device to open
--------------------------------
Using a static path for the device is problematic if an image is used on more
than a single HW revision, since no static device <-> device path mapping can be
guaranteed.
For a single HW revision the device <-> device path mapping will probably be the
same, but it is still dependent on the order of devices being probed during
initialization.
Previously I've hacked up a solution for selecting the device path from an
Android property. This property still has to be set somewhere, and I ended up
having the bootloader provide it since it was device specific anyway. But it was
hardly a neat solution, and I don't see any other static solutions that are all
that much more neat. But suggestions are welcome.
So that leaves probing, I'm not sure what a good probing solution would look at
this point.
Sharing the device between components
-------------------------------------
Currently the device is used by drm_hwc, gbm_gralloc and mesa.
drm_hwc opens the *primary* node in DrmResources::Init() and creates an internal
model of what properties/components the device has.
gbm_gralloc uses the *render* node during in gbm_dev_create().
Mesa uses uses the *render* node during dri_screen creation in
dri2_create_screen() and for loading the driver in dri2_initialize_android().
However, problematically, drm_hwc uses OpenGL composition as a fallback method,
and when doing so mesa has to be able to import buffers, which means mesa has to
use a *primary* node.
The way this is currently worked around in production systems seems to be to
disable drm master authentication. This is at least what ChromeOS & Intel are
doing as far as I understand it.
So this ended up being more if a problem statement than a sketch for a solution,
but maybe let's start here and make sure we all start at the same place.
Rob.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
