On Mon, May 30, 2016 at 09:47:53AM -0400, Rob Clark wrote:
> On Mon, May 30, 2016 at 5:32 AM, Daniel Vetter wrote:
> > drm_hwcomposer (developed by Google) is a generic hwc implementation along
> > the lines of weston and any other generic kms compositor. I think it makes
> > a lot of sense to aim
On 05/25/2016 10:06 PM, Rob Clark wrote:
> On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
>> On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
>>> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
- Is the size/width really independent of e.g. rotation/pixel format/...
On Mon, May 30, 2016 at 02:09:17PM +0530, Archit Taneja wrote:
>
>
> On 05/25/2016 10:06 PM, Rob Clark wrote:
> >On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
> >>On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
> >>>On 05/25/2016 12:40 PM, Daniel Vetter wrote:
> - Is t
On Mon, May 30, 2016 at 10:38 AM, Daniel Vetter wrote:
> On Mon, May 30, 2016 at 09:47:53AM -0400, Rob Clark wrote:
>> On Mon, May 30, 2016 at 5:32 AM, Daniel Vetter wrote:
>> > drm_hwcomposer (developed by Google) is a generic hwc implementation along
>> > the lines of weston and any other gener
On Mon, May 30, 2016 at 5:32 AM, Daniel Vetter wrote:
> On Mon, May 30, 2016 at 02:09:17PM +0530, Archit Taneja wrote:
>>
>>
>> On 05/25/2016 10:06 PM, Rob Clark wrote:
>> >On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
>> >>On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
>>
On Wed, May 25, 2016 at 7:57 PM, Rob Clark wrote:
>> As far as virtualizing the resources goes. I think that would need a
>> whole new API. Or at least a separate set of objects perhaps. I'm too
>> lazy to dig up all the old arguments now, but I'm pretty sure there
>> were many. If this would be d
On Wed, May 25, 2016 at 12:36:53PM -0400, Rob Clark wrote:
> On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
> > On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
> >> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
> >> >- Is the size/width really independent of e.g. rotation/pixe
On 05/25/2016 12:40 PM, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 12:03:39PM +0530, Archit Taneja wrote:
>> High resoultion modes (4K/5K) are supported by encoder/crtc hardware, but
>> the backing hardware planes to scanout these buffers generally don't
>> support such large widths. Two (or
On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
> >- Is the size/width really independent of e.g. rotation/pixel format/...
> > Should it be the maximum that's possible under best circumstance (things
> > could still fail), or the mi
On Wed, May 25, 2016 at 1:20 PM, Ville Syrjälä
wrote:
> On Wed, May 25, 2016 at 12:36:53PM -0400, Rob Clark wrote:
>> On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
>> > On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
>> >> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
>> >
On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
>> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
>> >- Is the size/width really independent of e.g. rotation/pixel format/...
>> > Should it be the maximum that's possible under
High resoultion modes (4K/5K) are supported by encoder/crtc hardware, but
the backing hardware planes to scanout these buffers generally don't
support such large widths. Two (or more) hardware planes are used in
conjunction to scan out the entire width.
One way to support this is to virtualize the
On Wed, May 25, 2016 at 12:03:39PM +0530, Archit Taneja wrote:
> High resoultion modes (4K/5K) are supported by encoder/crtc hardware, but
> the backing hardware planes to scanout these buffers generally don't
> support such large widths. Two (or more) hardware planes are used in
> conjunction to s
13 matches
Mail list logo
