On Mon, Sep 2, 2013 at 9:19 AM, Rob Clark wrote:
> On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter wrote:
>> On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
>>> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
>>> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
>>> >>
>>> >> I
On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter wrote:
> On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
>> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
>> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
>> >>
>> >> I guess if you have multiple encoders + multiple connector
On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> >>
> >> I guess if you have multiple encoders + multiple connectors for the
> >> "ganging" case, then it probably just looks l
On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann
> wrote:
> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> >>
> >> I guess if you have multiple encoders + multiple connectors for the
> >> "ganging" case, then it probably just look
On Thu, Aug 29, 2013 at 04:26:08PM -0700, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l? <
> ville.syrjala at linux.intel.com> wrote:
>
> > On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> > wrote:
> >
> > >
On Thu, Aug 29, 2013 at 04:26:08PM -0700, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
> > On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> > wrote:
> >
> > > 1.
On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
>>
>> I guess if you have multiple encoders + multiple connectors for the
>> "ganging" case, then it probably just looks like 2x displays, and
>> nothing more really needed?
>>
>> I'm a bit f
On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
>>
>> I guess if you have multiple encoders + multiple connectors for the
>> "ganging" case, then it probably just looks like 2x displays, and
>> nothing more really needed?
>>
>> I'm a bit f
On Thu, Aug 29, 2013 at 7:26 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l?
> wrote:
>>
>> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
>> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
>> > wrote:
>>
>> > > 1. The API is geared toward updating one ob
On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote:
> On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann wrote:
> > On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> >>
> >> I guess if you have multiple encoders + multiple connectors for the
> >> "ganging" case, then it probably just looks l
On Thu, Aug 29, 2013 at 7:26 PM, Greg Hackmann wrote:
> On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä
> wrote:
>>
>> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
>> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
>> > wrote:
>>
>> > > 1. The API is geared toward updating one ob
On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> I guess if you have multiple encoders + multiple connectors for the
> "ganging" case, then it probably just looks like 2x displays, and
> nothing more really needed?
>
> I'm a bit fuzzy on what the hw looks like in this "ganging" scenario,
> so
On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark wrote:
> I guess if you have multiple encoders + multiple connectors for the
> "ganging" case, then it probably just looks like 2x displays, and
> nothing more really needed?
>
> I'm a bit fuzzy on what the hw looks like in this "ganging" scenario,
> so
On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> wrote:
>
> > 1. The API is geared toward updating one object at a time. Android's
> graphics
On Thu, Aug 29, 2013 at 12:36 AM, Ville Syrj?l? <
ville.syrjala at linux.intel.com> wrote:
> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> > On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> wrote:
>
> > 1. The API is geared toward updating one object at a time. Android's
> graphi
On Thu, Aug 29, 2013 at 09:01:01AM +0200, Daniel Vetter wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
> >> 1. The API is geared toward updating one object at a time. Android's
> >> graphics stack needs the entire screen updated atomically to avoid
> >> tearing, and on some SoCs to
On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
> wrote:
> > Hi,
> >
> > ADF is an experimental display framework that I designed after
> > experimenting with a KMS-based hardware composer for Android. ADF started
> > as an proof-of-c
On Thu, Aug 29, 2013 at 10:58:51AM +0300, Ville Syrj?l? wrote:
> After that we need to figure out how we can expose them to userspace w/o
> risking breaking stuff too much. Maybe a new ioctl to enumerate private
> planes only? And the maybe only accept direct use of private planes via
> the atomic
On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
>> 1. The API is geared toward updating one object at a time. Android's
>> graphics stack needs the entire screen updated atomically to avoid tearing,
>> and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
>> modeset pa
On Thu, Aug 29, 2013 at 3:58 AM, Ville Syrj?l?
wrote:
>> Imo we should just convert primary planes to real planes so that we
>> can do the same table-based checking for them as we do for secondary
>> planes right now.
>
> My plan for i915 is to convert them to drm_planes but first keep them
> hidd
On Thu, Aug 29, 2013 at 3:36 AM, Ville Syrj?l?
wrote:
> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
>> On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann
>> wrote:
>> > Hi,
>> >
>> > ADF is an experimental display framework that I designed after
>> > experimenting with a KMS-based ha
On Thu, Aug 29, 2013 at 3:01 AM, Daniel Vetter
wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
>>> 1. The API is geared toward updating one object at a time. Android's
>>> graphics stack needs the entire screen updated atomically to avoid tearing,
>>> and on some SoCs to avoid wed
On Thu, Aug 29, 2013 at 3:58 AM, Ville Syrjälä
wrote:
>> Imo we should just convert primary planes to real planes so that we
>> can do the same table-based checking for them as we do for secondary
>> planes right now.
>
> My plan for i915 is to convert them to drm_planes but first keep them
> hidd
On Thu, Aug 29, 2013 at 3:36 AM, Ville Syrjälä
wrote:
> On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
>> On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann wrote:
>> > Hi,
>> >
>> > ADF is an experimental display framework that I designed after
>> > experimenting with a KMS-based hardwa
On Thu, Aug 29, 2013 at 3:01 AM, Daniel Vetter wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
>>> 1. The API is geared toward updating one object at a time. Android's
>>> graphics stack needs the entire screen updated atomically to avoid tearing,
>>> and on some SoCs to avoid wedg
On Thu, Aug 29, 2013 at 10:58:51AM +0300, Ville Syrjälä wrote:
> After that we need to figure out how we can expose them to userspace w/o
> risking breaking stuff too much. Maybe a new ioctl to enumerate private
> planes only? And the maybe only accept direct use of private planes via
> the atomic
On Thu, Aug 29, 2013 at 09:01:01AM +0200, Daniel Vetter wrote:
> On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
> >> 1. The API is geared toward updating one object at a time. Android's
> >> graphics stack needs the entire screen updated atomically to avoid
> >> tearing, and on some SoCs to
On Wed, Aug 28, 2013 at 11:51:59PM -0400, Rob Clark wrote:
> On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann wrote:
> > Hi,
> >
> > ADF is an experimental display framework that I designed after
> > experimenting with a KMS-based hardware composer for Android. ADF started
> > as an proof-of-conc
On Thu, Aug 29, 2013 at 5:51 AM, Rob Clark wrote:
>> 1. The API is geared toward updating one object at a time. Android's
>> graphics stack needs the entire screen updated atomically to avoid tearing,
>> and on some SoCs to avoid wedging the display hardware. Rob Clark's atomic
>> modeset pa
On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann wrote:
> Hi,
>
> ADF is an experimental display framework that I designed after experimenting
> with a KMS-based hardware composer for Android. ADF started as an
> proof-of-concept implemented from scratch, so right now it's a separate
> framework
On Wed, Aug 28, 2013 at 9:51 PM, Greg Hackmann wrote:
> Hi,
>
> ADF is an experimental display framework that I designed after experimenting
> with a KMS-based hardware composer for Android. ADF started as an
> proof-of-concept implemented from scratch, so right now it's a separate
> framework
Hi,
ADF is an experimental display framework that I designed after experimenting
with a KMS-based hardware composer for Android. ADF started as an
proof-of-concept implemented from scratch, so right now it's a separate
framework rather than a patchstack on top of KMS. If there's community
in
Hi,
ADF is an experimental display framework that I designed after experimenting
with a KMS-based hardware composer for Android. ADF started as an
proof-of-concept implemented from scratch, so right now it's a separate
framework rather than a patchstack on top of KMS. If there's community
in
33 matches
Mail list logo
