On Wed, 2 Nov 2011 02:20:58 + (UTC)
Inki Dae wrote:
> Sorry, there is my missing point. please, ignor step 6 ~ 9.
> if user requests setplane then drm_mode_setplane function gets fb and crtc
> object to update the overlay corresponding to plane id. at that time I think
> we could know which
Hi, Jesse.
Jesse Barnes virtuousgeek.org> writes:
>
> On Mon, 31 Oct 2011 11:40:57 + (UTC)
> Inki Dae gmail.com> wrote:
> > below is my simple idea.
> > 1. user requests buffer allocation with pixel format and resolution
through
> > gem framework.
> > 2. gem framework checks pixel format
On Mon, 31 Oct 2011 11:40:57 + (UTC)
Inki Dae wrote:
> below is my simple idea.
> 1. user requests buffer allocation with pixel format and resolution through
> gem framework.
> 2. gem framework checks pixel format.
> 3. specific gem framework allocates buffers as plane count according to the
Hi, all.
SW Kim gmail.com> writes:
>
> Daniel Vetter ffwll.ch> writes:
>
> [snip]
>
> > > struct drm_mode_fb_cmd2 {
> > > __u32 fb_id;
> > > __u32 width, height;
> > > __u32 pixel_format; /* fourcc code from videodev2.h */
> > > __u64 priv; /* private data, depends on pixelformat */
On Wed, 26 Oct 2011 14:40:07 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
>
> [snip]
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 8020798..d7f03aa 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -44,6 +44,7 @@
Daniel Vetter ffwll.ch> writes:
[snip]
> > struct drm_mode_fb_cmd2 {
> > __u32 fb_id;
> > __u32 width, height;
> > __u32 pixel_format; /* fourcc code from videodev2.h */
> > __u64 priv; /* private data, depends on pixelformat */
> >
[snip]
> > struct {
> > __u32 pitch;
> >
On Tue, Oct 25, 2011 at 11:43:09AM -0500, Rob Clark wrote:
> On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes
> wrote:
> > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> > index 34a0d22..dafe8df 100644
> > --- a/include/drm/drm_mode.h
> > +++ b/include/drm/drm_mode.h
> > @@ -272,8 +2
Here's a diff I can roll in if it looks ok. It adds the ability to
specify multiple handles for a single fb to better accommodate planar
configs. I think Rob has convinced me that this is a good idea...
comments appreciated.
Thanks,
Jesse
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/dr
On Tue, Oct 25, 2011 at 02:26:07PM +0100, Alan Cox wrote:
> > As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
> > - fbs are not reference counted, hence when destroying we need to disable
> > all crtcs (and now also planes) that use them. drm_framebuffer_cleanup
> > d
On Tue, 25 Oct 2011 14:26:07 +0100
Alan Cox wrote:
> > As discussed with Jesse on irc, drm fb handling is fragile. Current
> > rules:
> > - fbs are not reference counted, hence when destroying we need to
> > disable all crtcs (and now also planes) that use them.
> > drm_framebuffer_cleanup does t
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter wrote:
> On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
> > Planes are a bit like half-CRTCs. They have a location and fb, but
> > don't drive outputs directly. Add support for handling them to the
> > core KMS code.
> >
> > Signe
On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
> Planes are a bit like half-CRTCs. They have a location and fb, but
> don't drive outputs directly. Add support for handling them to the core
> KMS code.
>
> Signed-off-by: Jesse Barnes
As discussed with Jesse on irc, drm fb handli
On Tue, 25 Oct 2011 19:53:02 +0900
Joonyoung Shim wrote:
> > +/**
> > + * drm_plane - central DRM plane control structure
> > + * @dev: DRM device this plane belongs to
> > + * @kdev: kernel device
> > + * @attr: kdev attributes
> > + * @head: for list management
> > + * @base: base mode object
>
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
drivers/gpu/drm/drm_drv.c |3
14 matches
Mail list logo
