On Wed, Apr 18, 2012 at 09:19:42PM +0300, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrj?l? wrote:
> > On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> > > Also, I'm toying around with ideas to split up the big modeset lock such
> > > that operations tha
On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian H?gsberg wrote:
> One thing that's not clear to me is how we would enable a sprite
> without going through the atomic modeset again. If the atomic modeset
> is all about calculating bandwidth requirements etc, then enabling a
> sprite will affect
On Wed, Apr 18, 2012 at 09:19:42PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> > > Also, I'm toying around with ideas to split up the big modeset lock such
> > > that operations tha
On Wed, Apr 18, 2012 at 09:24:58PM -0400, Kristian Høgsberg wrote:
> One thing that's not clear to me is how we would enable a sprite
> without going through the atomic modeset again. If the atomic modeset
> is all about calculating bandwidth requirements etc, then enabling a
> sprite will affect
On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrjälä wrote:
>> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> > On 04/18/2012 02:25 PM, Rob Clark wrote:
>> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
>> > >
On Wed, Apr 18, 2012 at 10:36 AM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrj?l? wrote:
>> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> > On 04/18/2012 02:25 PM, Rob Clark wrote:
>> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim> > > sam
On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> > Also, I'm toying around with ideas to split up the big modeset lock such
> > that operations that only touch the crtc (like pageflip, plane changes and
> > cursor chan
On Wed, Apr 18, 2012 at 05:55:15PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> >On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> >>On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >>>Last time around I've discussed with people we've ended up with
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
>> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
>> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
>> provide the event such as DRM_MODE_PAGE_FL
On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> > >Last time around I've discussed with people we've ended up with 2 new
> > >ioctls:
> > >
> > >- atomic modeset, to
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the fram
On 04/18/2012 06:06 PM, Ville Syrj?l? wrote:
>> > If you smash everything into one ioctl, I imagine you have plenty of fun
>> > implementing all this. Which is why I prefer to split this up.
> I don't think there's that much differnce. You build up the full device
> state, check it, and when you'
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
> This means that there should be (at least) three separate actions:
> * page flipping: buffers -> planes at next vblank, for a list of
> buffer(s) and plane tuples.
> * setplanes: colour format, position, scaling, ordering, rotation, color
> key, crtc
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>>> Last time around I've discussed with people we've ended up with 2 new
>>> ioctls:
>>>
>>> - atomic modeset, to configure the output st
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>> Last time around I've discussed with people we've ended up with 2 new
>> ioctls:
>>
>> - atomic modeset, to configure the output state on more than one crtc at
>>the same time. Th
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >Last time around I've discussed with people we've ended up with 2 new
> >ioctls:
> >
> >- atomic modeset, to configure the output state on more than one crtc at
> > the same time. T
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 02:25 PM, Rob Clark wrote:
> > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> > wrote:
> >> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> >>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> >>>
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> Last time around I've discussed with people we've ended up with 2 new
> ioctls:
>
> - atomic modeset, to configure the output state on more than one crtc at
>the same time. This is useful to get pll assignement, memory bandwidth
>constrains and
On 04/18/2012 04:26 PM, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
>> On 04/18/2012 02:25 PM, Rob Clark wrote:
>>> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
>>> wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> On Wed, Apr 18, 2012
On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrj?l? wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 02:25 PM, Rob Clark wrote:
> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim > > samsung.com> wrote:
> > >> On 04/18/2012 05:46 PM, Daniel Vetter
On 04/18/2012 02:25 PM, Rob Clark wrote:
> On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> wrote:
>> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
f
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
can change the framebuffer of plane but user can't know completion of
changing the framebuf
On Wed, Apr 18, 2012 at 05:55:15PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 05:27 PM, Daniel Vetter wrote:
> >On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> >>On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >>>Last time around I've discussed with people we've ended up with
On Wed, Apr 18, 2012 at 07:06:10PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> > Also, I'm toying around with ideas to split up the big modeset lock such
> > that operations that only touch the crtc (like pageflip, plane changes and
> > cursor chan
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the fram
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the fram
On 04/18/2012 06:06 PM, Ville Syrjälä wrote:
> If you smash everything into one ioctl, I imagine you have plenty of fun
> implementing all this. Which is why I prefer to split this up.
I don't think there's that much differnce. You build up the full device
state, check it, and when you're read
On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> > >Last time around I've discussed with people we've ended up with 2 new
> > >ioctls:
> > >
> > >- atomic modeset, to
On Wed, 18 Apr 2012 17:55:15 +0200
Marcus Lorentzon wrote:
> The async vs sync makes sense as reason for splitting them. My problem
> lies somewhere in between sync modeset and async flip - async
> crtc/plane/fbs modeset.
> In Wayland and Android HW composer I need to asynchronously flip and do
On Wed, 18 Apr 2012 17:55:15 +0200
Marcus Lorentzon wrote:
> The async vs sync makes sense as reason for splitting them. My problem
> lies somewhere in between sync modeset and async flip - async
> crtc/plane/fbs modeset.
> In Wayland and Android HW composer I need to asynchronously flip and do
On 04/18/2012 05:43 PM, Luc Verhaegen wrote:
This means that there should be (at least) three separate actions:
* page flipping: buffers -> planes at next vblank, for a list of
buffer(s) and plane tuples.
* setplanes: colour format, position, scaling, ordering, rotation, color
key, crtc adheranc
On Wed, 18 Apr 2012 16:58:36 +0200
Marcus Lorentzon wrote:
> On 04/18/2012 04:26 PM, Ville Syrjälä wrote:
> Yes, from previous emails I have seen that we are quite aligned on the
> single-atomic-modeset-with-properties version.
>
> Do you have any actual proposal for this? Like the API at leas
On Wed, 18 Apr 2012 16:58:36 +0200
Marcus Lorentzon wrote:
> On 04/18/2012 04:26 PM, Ville Syrj?l? wrote:
> Yes, from previous emails I have seen that we are quite aligned on the
> single-atomic-modeset-with-properties version.
>
> Do you have any actual proposal for this? Like the API at leas
On 04/18/2012 05:27 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output state on more than
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
>> Last time around I've discussed with people we've ended up with 2 new
>> ioctls:
>>
>> - atomic modeset, to configure the output state on more than one crtc at
>>the same time. Th
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> >Last time around I've discussed with people we've ended up with 2 new
> >ioctls:
> >
> >- atomic modeset, to configure the output state on more than one crtc at
> > the same time. T
On 04/18/2012 04:36 PM, Daniel Vetter wrote:
Last time around I've discussed with people we've ended up with 2 new
ioctls:
- atomic modeset, to configure the output state on more than one crtc at
the same time. This is useful to get pll assignement, memory bandwidth
constrains and similar
On 04/18/2012 04:26 PM, Ville Syrjälä wrote:
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
On 04/18/2012 02:25 PM, Rob Clark wrote:
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 01:31:59PM +09
On Wed, Apr 18, 2012 at 05:26:07PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 02:25 PM, Rob Clark wrote:
> > > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> > > wrote:
> > >> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>
On Wed, Apr 18, 2012 at 04:04:56PM +0200, Marcus Lorentzon wrote:
> On 04/18/2012 02:25 PM, Rob Clark wrote:
> > On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
> > wrote:
> >> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
> >>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> >>>
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim
wrote:
>
> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>>
>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
>>>
>>> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
>>> for a plane. The setplane ioctl (DRM_IOCT
On 04/18/2012 02:25 PM, Rob Clark wrote:
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim wrote:
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The s
On Wed, Apr 18, 2012 at 5:11 AM, Joonyoung Shim wrote:
>
> On 04/18/2012 05:46 PM, Daniel Vetter wrote:
>>
>> On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
>>>
>>> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
>>> for a plane. The setplane ioctl (DRM_IOCTL
On 04/18/2012 05:46 PM, Daniel Vetter wrote:
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
provide the event such as DRM_MODE_PAGE_FLIP_EVENT
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote:
> DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
> for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
> provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
> can change the fram
DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is
for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to
provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl
can change the framebuffer of plane but user can't know completion of
changing the framebuf
46 matches
Mail list logo
