[Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Robert Foss]

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.