[Really taking this to another thread. Leaving CC as is for the time being.]
On Sat, May 5, 2018 at 4:16 AM Mauro Rossi issor.oruam@gmail.com wrote:
Il 04 mag 2018 19:51, "Alistair Strachan" astrachan@google.com ha scritto:
On Fri, May 4, 2018 at 10:35 AM Sean Paul seanpaul@chromium.org wrote:
On Fri, May 04, 2018 at 05:19:50PM +0000, Mauro Rossi wrote:
[snip]
Another question is for Intel and Chromeos developers: are you planning
to
update your minigbm projects to the new common gralloc_handle.h handle
structure in latest libdrm?
I assume yes, but I'm not hooked in to what's happening with minigbm.
+1. We can take this to another thread. The main issue is that minigbm assumes a 1:1 planes to handles paradigm, the new generic handle does not.
Thanks for the info
I'm personally skeptical about this, but adding Gurchetan, who is a better person to comment on this. My biggest concern is that it might not be possible to define a common handle that is really good for everyone. Also, since the handle would effectively be a stable ABI between independent components, changing it to accommodate for future features (or discovered issues ) would be problematic.
Generally we designed our graphics stack in Chrome OS / ARC++ in a way that does not rely on the handle struct at all, so that we are free to change the struct in any way we want in the future, without any compatibility concerns (such as plane layout isssue mentioned before).
For the needs of EGL and most of other consumers, we are doing well without any API extensions (most of the time we get some more complete struct, such as ANativeWindow(Buffer) and for ambiguous formats we adopted lock_ycbcr method).
Our hwcomposer is the only exception for which we added some perform calls to retrieve data such as HAL pixel format, width, height, stride and backing store (unique ID within some private namespace of the gralloc instance, having similar properties to GEM handle within one DRI FD).
Best regards, Tomasz