Doesn't really belong here anyway.
Signed-off-by: Jesse Barnes
---
include/drm/drm_crtc.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8020798..b0df23a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm
Just some cleanups for unused fields in drm_crtc.h and some comment
corrections. I also removed a few DRM_ERRORs from drm_crtc.c (things
actually weren't as bad as I feared).
Next step is to remove a whole slew of DRM_DEBUG calls unless people are
really attached to them. I find them to just
We restore the CRTC, encoder, and connector configurations, but if the
mode set failed, the attached display may have been turned off, so we
need to try set_config again to restore things to the way they were.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc_helper.c | 13
To save power when the sprite is full screen, we can disable the primary
plane on the same pipe. Track the sprite status and enable/disable the
primary opportunistically.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|1 +
drivers/gpu/drm/i915/intel_sprite.c | 19
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
sprite support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915/i915_reg.h | 123
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
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 | 251 +++-
drivers/gpu/drm/drm_drv.c
Ok this one includes all the minor feedback from last week, and should
satisfy Daniel and Jakob enough to get their Reviewed-bys.
You can ignore the final patch in the series; it's a WIP power saving
feature, but the other ones are working well here.
Thanks,
Jesse
ld you please tell me about why do you need
> them.?
Daniel seemed to think that some of the formats might have ambiguous
pitches or offsets, so being able to specify one for each possible
component seems like a good idea.
Also, for planar formats packed into a single buffer object handle
(th
component seems like a good idea.
Also, for planar formats packed into a single buffer object handle
(through driver specific multiplexing or non-zero offsets), individual
pitches and offsets may be required.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
Ok this one includes all the minor feedback from last week, and should
satisfy Daniel and Jakob enough to get their Reviewed-bys.
You can ignore the final patch in the series; it's a WIP power saving
feature, but the other ones are working well here.
Thanks,
Jesse
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 jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c | 251 +++-
drivers
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
sprite support functions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/Makefile|1 +
drivers/gpu/drm/i915
To save power when the sprite is full screen, we can disable the primary
plane on the same pipe. Track the sprite status and enable/disable the
primary opportunistically.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h|1 +
drivers/gpu/drm/i915/intel_sprite.c | 19
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915
We restore the CRTC, encoder, and connector configurations, but if the
mode set failed, the attached display may have been turned off, so we
need to try set_config again to restore things to the way they were.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm
Just some cleanups for unused fields in drm_crtc.h and some comment
corrections. I also removed a few DRM_ERRORs from drm_crtc.c (things
actually weren't as bad as I feared).
Next step is to remove a whole slew of DRM_DEBUG calls unless people are
really attached to them. I find them to just
Doesn't really belong here anyway.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8020798..b0df23a 100644
--- a/include/drm/drm_crtc.h
Remove two unused fields from this struct and cleanup/correct the comments.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h | 18 --
1 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
Remove stale entries and update with the latest stuff.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a960020..ad2a605 100644
Also fix up the wrapping to 80 columns.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h | 20 +++-
1 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ad2a605..6ab20f8 100644
Just some basic comments about the place and function of the structure
and fields.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
Just basic verbiage.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6ab20f8..a1583d8 100644
--- a/include/drm/drm_crtc.h
+++ b
We never used initial_x/y or the force_encoder_id, so drop those fields
and proide a basic description of the others.
Really, the ELD bits belong in drm_display_info rather than directly in
the connector, but that's a separate cleanup.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Just fix the wrapping mostly.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b33713b..a0c7dc6 100644
--- a/include/drm
This is actually a core structure with a big future ahead of it. Make
it a little less mysterious.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_crtc.h b
Including a comment about what the locks are for.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 003cba2
On Mon, 07 Nov 2011 20:26:59 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, 7 Nov 2011 12:03:15 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Also fix up the wrapping to 80 columns.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/drm/drm_crtc.h
but above function cannot detect it.
Oh that's a mistake on my part. RGB24 is generally bpp=32. I'll fix
that.
This is just a compatibility function, so it only needs to handle cases
used by current code. I expect future code to use the fourcc values
directly.
Thanks,
--
Jesse Barnes, In
in device specific update_plane, but can do in
> drm_mode_setplane?
Yeah it should probably be done in setplane if there's no error. Fixed.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Nam
detect it.
Oh that's a mistake on my part. RGB24 is generally bpp=32. I'll fix
that.
This is just a compatibility function, so it only needs to handle cases
used by current code. I expect future code to use the fourcc values
directly.
Thanks,
--
Jesse Barnes, Intel Open Source Technology
On Thu, 3 Nov 2011 11:21:18 -0700
Jesse Barnes wrote:
> On Wed, 2 Nov 2011 15:33:04 -0700
> Jesse Barnes wrote:
>
> > On Wed, 2 Nov 2011 13:03:19 -0700
> > Jesse Barnes wrote:
> >
> > > Planes are a bit like half-CRTCs. They have a location and fb, bu
, have you been beaten down enough to acquiesce to that? Alan,
does this look usable for your stuff?
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
D
,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
>
> cur.t8 = (pp_on & PANEL_LIGHT_ON_DELAY_MASK) >>
> PANEL_LIGHT_ON_DELAY_SHIFT;
> -
> +
> cur.t9 = (pp_off & PANEL_LIGHT_OFF_DELAY_MASK) >>
>
}
> + } else
> + voltage_tries = 0;
> + voltage = intel_dp->train_set[0] &
> DP_TRAIN_VOLTAGE_SWING_MASK;
> + }
>
> /* Compute new intel_dp->train_set as requ
is_edp(intel_dp) && !is_pch_edp(intel_dp))
> - ironlake_edp_pll_off(encoder);
> ironlake_edp_panel_vdd_off(intel_dp, false);
> +
> + if (is_cpu_edp(intel_dp))
> + ironlake_edp_pll_off(encoder);
But here it looks like you're shu
gister until it shows the correct values.
Modulo what we already discussed on irc about the PP_READY bit, and the
CodingStyle nitpicks (newlines before {? come on, this isn't X :),
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
-- next part
On Thu, 3 Nov 2011 13:55:50 -0500
Rob Clark wrote:
> On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes
> wrote:
> > On Thu, 3 Nov 2011 18:29:14 +0100
> > Daniel Vetter wrote:
> >
> >> Hi all,
> >>
> >> I've discussed this a bit on irc and consens
the latest code; I clamp things in
the top level function now. But take a look and see if I'm missing one
of the cases you cover here.
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: applicatio
On Wed, 2 Nov 2011 13:03:23 -0700
Jesse Barnes wrote:
> Add new ioctls for getting and setting the current destination color
> key. This allows for simple overlay display control by matching a color
> key value in the primary plane before blending the overlay on top.
>
> Signe
On Wed, 2 Nov 2011 13:03:22 -0700
Jesse Barnes wrote:
> The video sprites support various video surface formats natively and can
> handle scaling as well. So add support for them using the new DRM core
> overlay support functions.
>
> Signed-off-by: Jesse Barnes
> ---
Upda
On Wed, 2 Nov 2011 13:03:21 -0700
Jesse Barnes wrote:
> The old overlay block has all sorts of quirks and is very different than
> ILK+ video sprites. So rename it to legacy to make that clear and clash
> less with core overlay support.
This one has been dropped. I'm calling thing
On Wed, 2 Nov 2011 13:03:20 -0700
Jesse Barnes wrote:
> To properly support the various plane formats supported by different
> hardware, the kernel must know the pixel format of a framebuffer object.
> So add a new ioctl taking a format argument corresponding to a fourcc
> name from
On Wed, 2 Nov 2011 15:33:04 -0700
Jesse Barnes wrote:
> On Wed, 2 Nov 2011 13:03:19 -0700
> 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
g, Inkie, any comment on using fourcc vs rolling our own
surface definitions?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836
On Thu, 3 Nov 2011 15:11:55 +0100
Daniel Vetter wrote:
> On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote:
> > In response to feedback, I've adjusted the new addfb2 ioctl to take per
> > component pitch and offset args. Generally, the offset[0] field will be
On Thu, 3 Nov 2011 15:11:55 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote:
In response to feedback, I've adjusted the new addfb2 ioctl to take per
component pitch and offset args. Generally, the offset[0] field will be
0, but it's
fourcc vs rolling our own
surface definitions?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Wed, 2 Nov 2011 15:33:04 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 2 Nov 2011 13:03:19 -0700
Jesse Barnes jbar...@virtuousgeek.org 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
On Wed, 2 Nov 2011 13:03:20 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
On Wed, 2 Nov 2011 13:03:21 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
This one has been dropped. I'm
On Wed, 2 Nov 2011 13:03:22 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes jbar
On Wed, 2 Nov 2011 13:03:23 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top
in
the top level function now. But take a look and see if I'm missing one
of the cases you cover here.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel
On Thu, 3 Nov 2011 13:55:50 -0500
Rob Clark rob.cl...@linaro.org wrote:
On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Thu, 3 Nov 2011 18:29:14 +0100
Daniel Vetter dan...@ffwll.ch wrote:
Hi all,
I've discussed this a bit on irc and consensus seems
register until it shows the correct values.
Modulo what we already discussed on irc about the PP_READY bit, and the
CodingStyle nitpicks (newlines before {? come on, this isn't X :),
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
))
+ ironlake_edp_pll_off(encoder);
But here it looks like you're shutting it off, then downing the link?
Should this be reordered?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri
, and
the DP compliance test should catch any grievous errors, so aside from
the bug fix hunk which should be split out:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
PANEL_LIGHT_ON_DELAY_MASK)
PANEL_LIGHT_ON_DELAY_SHIFT;
-
+
cur.t9 = (pp_off PANEL_LIGHT_OFF_DELAY_MASK)
PANEL_LIGHT_OFF_DELAY_SHIFT;
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology
stuff?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, 03 Nov 2011 15:30:57 -0700
Keith Packard kei...@keithp.com wrote:
On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
A few comments on this one (also, is it strictly required to fix your
bug)?
I think so; the panel definitely was not happy when I
On Thu, 3 Nov 2011 11:21:18 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 2 Nov 2011 15:33:04 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 2 Nov 2011 13:03:19 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
Planes are a bit like half-CRTCs. They have
On Wed, 2 Nov 2011 13:03:19 -0700
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.
Accidentally left out the ->destroy hook in this one. The drm-ove
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c
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
In response to feedback, I've adjusted the new addfb2 ioctl to take per
component pitch and offset args. Generally, the offset[0] field will be
0, but it's conceivable that some metadata could be stored at the start
of a given buffer, and an offset[0] allows the client to skip past that.
SEQUENCE_STATE_MASK)
> +#define IDLE_ON_VALUE(PP_ON | 0 | PP_SEQUENCE_NONE | 0
>| PP_SEQUENCE_STATE_ON_IDLE)
Note that PP_READY will incorrectly depend on some other register
values, so in some configs the panel will happily power up even if
PP_READY is
licated code than fragile code...
Reviewed-by: Jesse Barnes
But I was curious about this hunk:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp = enc_to_intel_dp(encoder);
-
On Tue, 1 Nov 2011 23:20:25 -0700
Keith Packard wrote:
> No persistent data was ever stored here, so link_status is instead
> allocated on the stack as needed.
>
> Signed-off-by: Keith Packard
> ---
I like this cleanup.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, In
off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c | 37 +++--
> 1 files changed, 19 insertions(+), 18 deletions(-)
Can't we just set UNLOCK_REGS at load time and have asserts sprinkled
here and there?
--
Jesse Barnes, Intel Open Source Technology C
kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 37 +++--
1 files changed, 19 insertions(+), 18 deletions(-)
Can't we just set UNLOCK_REGS at load time and have asserts sprinkled
here and there?
--
Jesse Barnes, Intel Open Source Technology Center
code than fragile code...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
But I was curious about this hunk:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp = enc_to_intel_dp(encoder
(PP_ON | 0 | PP_SEQUENCE_NONE | 0
| PP_SEQUENCE_STATE_ON_IDLE)
Note that PP_READY will incorrectly depend on some other register
values, so in some configs the panel will happily power up even if
PP_READY isn't set yet...
--
Jesse Barnes, Intel Open Source Technology
On Tue, 1 Nov 2011 23:20:25 -0700
Keith Packard kei...@keithp.com wrote:
No persistent data was ever stored here, so link_status is instead
allocated on the stack as needed.
Signed-off-by: Keith Packard kei...@keithp.com
---
I like this cleanup.
Reviewed-by: Jesse Barnes jbar
In response to feedback, I've adjusted the new addfb2 ioctl to take per
component pitch and offset args. Generally, the offset[0] field will be
0, but it's conceivable that some metadata could be stored at the start
of a given buffer, and an offset[0] allows the client to skip past that.
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
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 jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
drivers
On Wed, 2 Nov 2011 13:03:19 -0700
Jesse Barnes jbar...@virtuousgeek.org 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.
Accidentally left out the -destroy hook in this one. The drm
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers
like the DRM layer, with
authentication for rendering clients, an command submission ioctl for
acceleration, and memory management, so I expect most of the driver
growth to be in DRM in the near future.
And I totally agree with Dave about having a kmscon. I really wish
someone would imp
management, so I expect most of the driver
growth to be in DRM in the near future.
And I totally agree with Dave about having a kmscon. I really wish
someone would implement it so I could have my VTs spinning on a cube.
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
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/
On Wed, 26 Oct 2011 14:40:07 +0900
Joonyoung Shim jy0922.s...@samsung.com 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
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
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
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
&g
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches and fix plane disable vs unpin ordering bug
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915
On Tue, 25 Oct 2011 11:46:55 +0200
Jesse Barnes wrote:
> I've given up waiting for someone to implement support for these
> ioctls on another platform before they're merged, but I have received
> a lot of feedback on the interfaces, and it sounds like they're ok.
> I've al
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
>
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim wrote:
> 10/25/2011 06:46 PM, Jesse Barnes ? ?:
> > I've given up waiting for someone to implement support for these
> > ioctls on another platform before they're merged, but I have
> > received a lot of feedback on the inte
If the source and destination size are different, try to scale the sprite on the
corresponding CRTC.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_overlay2.c | 14 --
2 files changed, 17 insertions(+), 2 deletions
301 - 400 of 836 matches
Mail list logo
