Hey Tomasz,
On 01/15/2018 04:03 PM, Tomasz Figa wrote:
On Tue, Jan 16, 2018 at 12:00 AM, Rob Herring wrote:
On Mon, Jan 15, 2018 at 7:09 AM, Robert Foss wrote:
Hey,
On 01/13/2018 12:49 AM, Gurchetan Singh wrote:
We can define accessor functions too (not ptrs), then the struct is
opaq
On Tue, Jan 16, 2018 at 12:00 AM, Rob Herring wrote:
> On Mon, Jan 15, 2018 at 7:09 AM, Robert Foss
> wrote:
>> Hey,
>>
>> On 01/13/2018 12:49 AM, Gurchetan Singh wrote:
>>>
>>> We can define accessor functions too (not ptrs), then the struct is
>>> opaque
>>> and you can do your own acc
On Mon, Jan 15, 2018 at 7:09 AM, Robert Foss wrote:
> Hey,
>
> On 01/13/2018 12:49 AM, Gurchetan Singh wrote:
>>
>> We can define accessor functions too (not ptrs), then the struct is
>> opaque
>> and you can do your own accessor implementation if aligning is not
>> possible
>> or desi
Hey,
On 01/13/2018 12:49 AM, Gurchetan Singh wrote:
We can define accessor functions too (not ptrs), then the struct is opaque
and you can do your own accessor implementation if aligning is not possible
or desired.
Accessor functions in libdrm sound good to me.
Alright, this seem
>
> We can define accessor functions too (not ptrs), then the struct is opaque
> and you can do your own accessor implementation if aligning is not possible
> or desired.
>
Accessor functions in libdrm sound good to me.
On Fri, Jan 12, 2018 at 11:44 AM, Rob Herring wrote:
> On Fri, Jan 12, 2018
On Fri, Jan 12, 2018 at 2:29 AM, Tomasz Figa wrote:
> Hi Rob,
>
> On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss
> wrote:
>> Heya,
>>
>>
>> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>>
>>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>>> wrote:
So the plan is for alloc_handle_t to n
>
> Alright, so if I understand this correctly importing process would always
> call gralloc registerBuffer(), which means that the FPs would always be
> correct and usable by the importing process?
Yes, the Android framework calls registerBuffer() when importing the buffer
to a different process
Hi Rob,
On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss wrote:
> Heya,
>
>
> On 12/22/17 1:09 PM, Tomasz Figa wrote:
>>
>> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
>> wrote:
>>>
>>> So the plan is for alloc_handle_t to not be sub-classed by the
>>> implementations, but have all necessary i
On 1/12/18 9:29 AM, Tomasz Figa wrote:
Hi Rob,
On Fri, Jan 12, 2018 at 5:26 AM, Robert Foss wrote:
Heya,
On 12/22/17 1:09 PM, Tomasz Figa wrote:
On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
wrote:
So the plan is for alloc_handle_t to not be sub-classed by the
implementations, but
>
> So I had a look into implementing this, and using function pointers is
> problematic due to this struct being passed between processes which would
> prevent mesa calling a function assigned in gbm_gralloc for example.
Which function? In theory, anything with a dependency on libdrm and a
gral
Heya,
On 12/22/17 1:09 PM, Tomasz Figa wrote:
On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
wrote:
So the plan is for alloc_handle_t to not be sub-classed by the
implementations, but have all necessary information that an implementation
would need?
If so, how do we reconcile the implement
On Fri, 2017-12-22 at 21:09 +0900, Tomasz Figa wrote:
> On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
> wrote:
> > So the plan is for alloc_handle_t to not be sub-classed by the
> > implementations, but have all necessary information that an
> > implementation
> > would need?
> >
> > If so, h
On Fri, Dec 22, 2017 at 10:09 AM, Gurchetan Singh
wrote:
> So the plan is for alloc_handle_t to not be sub-classed by the
> implementations, but have all necessary information that an implementation
> would need?
>
> If so, how do we reconcile the implementation specific information that is
> ofte
On 21 December 2017 at 18:14, Rob Herring wrote:
> On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
> wrote:
>> Hi Robert,
>>
>> Thanks for looking into this! We need to decide if we want:
>>
>> (1) A common struct that implementations can subclass, i.e:
>>
>> struct blah_gralloc_handle {
>>
So the plan is for alloc_handle_t to not be sub-classed by the
implementations, but have all necessary information that an implementation
would need?
If so, how do we reconcile the implementation specific information that is
often in the handle:
https://github.com/intel/minigbm/blob/master/cros_
On Wed, Dec 13, 2017 at 5:02 PM, Gurchetan Singh
wrote:
> Hi Robert,
>
> Thanks for looking into this! We need to decide if we want:
>
> (1) A common struct that implementations can subclass, i.e:
>
> struct blah_gralloc_handle {
> alloc_handle_t alloc_handle;
> int x, y, z;
>
>
+Kalyan Kondapally
On Wed, 2017-12-13 at 15:02 -0800, Gurchetan Singh wrote:
> Hi Robert,
>
> Thanks for looking into this! We need to decide if we want:
>
> (1) A common struct that implementations can subclass, i.e:
>
> struct blah_gralloc_handle {
> alloc_handle_t alloc_handle;
> in
Hi Robert,
Thanks for looking into this! We need to decide if we want:
(1) A common struct that implementations can subclass, i.e:
struct blah_gralloc_handle {
alloc_handle_t alloc_handle;
int x, y, z;
}
(2) An accessor library that vendors can implement, i.e:
struct drmAndro
This series moves {gbm,drm,cros}_gralloc_handle_t struct to libdrm,
since at least 4 implementations exist, and share a lot of contents.
The idea is to keep the common stuff defined in one place, and libdrm
is the common codebase to all of these platforms.
Additionally, having this struct defined
19 matches
Mail list logo
