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 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/
es, tablets, notebooks, etc will need
and want an architecture that looks a lot 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 ag
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 Sourc
e
duplicated 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);
-
| PP_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 ev
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
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.
Similarly
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
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
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_
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-o
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 wil
. ;-)
Rob, Joonyoung, Inkie, any comment on using 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.freedesk
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 the
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 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
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: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
e 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
signature.asc
Description: PGP signature
___
dri-devel mai
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 co
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
signature.asc
Descripti
) && !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
gt; + }
> + } else
> + voltage_tries = 0;
> + voltage = intel_dp->train_set[0] &
> DP_TRAIN_VOLTAGE_SWING_MASK;
> + }
>
> /* Compute new intel_dp-&g
,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) >>
>
patches?
Daniel, 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
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 wrote:
> On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes
> 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 turn
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
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
signature.asc
Description: PGP signature
__
t 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
ob, could 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
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
---
drivers/gpu/drm/drm_crtc.c | 251 +++-
drivers/gpu/drm/drm_
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 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
---
drivers/gpu/drm/drm_crtc.c
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
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
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 get
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/includ
Remove two unused fields from this struct and cleanup/correct the comments.
Signed-off-by: Jesse Barnes
---
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
index b0df23a..a960020
Remove stale entries and update with the latest stuff.
Signed-off-by: Jesse Barnes
---
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
--- a/include/drm
Also fix up the wrapping to 80 columns.
Signed-off-by: Jesse Barnes
---
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
--- a/include/drm/drm_crtc.h
Just some basic comments about the place and function of the structure
and fields.
Signed-off-by: Jesse Barnes
---
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
index a1583d8..a98433a
Just basic verbiage.
Signed-off-by: Jesse Barnes
---
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/include/drm/drm_crtc.h
This is a core mode setting structure that deserves a little verbiage.
Signed-off-by: Jesse Barnes
---
include/drm/drm_crtc.h | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e9f486d..b33713b 100644
--- a
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
---
include/drm/drm_c
Just fix the wrapping mostly.
Signed-off-by: Jesse Barnes
---
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/drm_crtc.h
+++ b/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
---
include/drm/drm_crtc.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index
Including a comment about what the locks are for.
Signed-off-by: Jesse Barnes
---
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..58e6a996 100644
--- a/include
going upstream anyway.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 19 ---
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..df6c01b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/dr
On Mon, 07 Nov 2011 20:26:59 +
Chris Wilson wrote:
> On Mon, 7 Nov 2011 12:03:15 -0800, Jesse Barnes
> wrote:
> > Also fix up the wrapping to 80 columns.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > include/drm/drm_crtc.h | 20 +++-
On Tue, 8 Nov 2011 15:20:37 +0100
Daniel Vetter wrote:
> On Mon, Nov 07, 2011 at 10:02:52AM -0800, 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 t
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.
Acked-by: Alan Cox
Reviewed-by: Rob Clark
Reviewed-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c |
mode_fb_cmd2 using helpers where the old bpp/depth values are
needed.
Acked-by: Alan Cox
Reviewed-by: Rob Clark
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c| 112 +++-
drivers/gpu/drm/drm_crtc_helper.c | 50 -
drivers/gpu/drm
On Tue, 08 Nov 2011 17:50:51 +
Chris Wilson wrote:
> On Tue, 8 Nov 2011 09:38:52 -0800, Jesse Barnes
> wrote:
> > +int drm_mode_getplane(struct drm_device *dev, void *data,
> > + struct drm_file *file_priv)
> > +{
> > + struct drm_mod
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.
Acked-by: Alan Cox
Reviewed-by: Rob Clark
Reviewed-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c |
mode_fb_cmd2 using helpers where the old bpp/depth values are
needed.
Acked-by: Alan Cox
Reviewed-by: Rob Clark
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c| 108 +++-
drivers/gpu/drm/drm_crtc_helper.c | 50 -
drivers/gpu/drm
re
> many other places where we stall in similarly bad ways, still ...
Yes, good point. Will fix.
>
> > +
> > + return ret;
> > +}
> > +
> > +static int
> > +intel_disable_plane(struct drm_plane *plane)
> > +{
> > + struct drm_device *dev = plane->dev;
> >
On Tue, 8 Nov 2011 23:06:57 +0100
Daniel Vetter wrote:
> On Mon, Nov 07, 2011 at 10:02:55AM -0800, 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
>
On Fri, 11 Nov 2011 10:50:00 +
Dave Airlie wrote:
> On Fri, Nov 11, 2011 at 10:47 AM, Dave Airlie wrote:
> > On Tue, Nov 8, 2011 at 9:18 PM, Jesse Barnes
> > wrote:
> >> To properly support the various plane formats supported by different
> >> hardwar
t;
> - memcpy(plane->format_types, formats, format_count);
> + memcpy(plane->format_types, formats, sizeof(uint32_t) * format_count);
> plane->format_count = format_count;
> plane->possible_crtcs = possible_crtcs;
>
Duh thank you.
--
Jesse Barnes, Int
plane_req->crtc_x, plane_req->crtc_y,
>plane_req->crtc_w, plane_req->crtc_h,
Good sanity check (saves the drivers from having to do it), but I
wonder if we can use a better return value like ENOSPC or something to
make it easier for userspace to figure out.
--
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
int32_t format_count);
> extern void drm_plane_cleanup(struct drm_plane *plane);
>
> extern void drm_encoder_cleanup(struct drm_encoder *encoder);
Yeah good fix. I made the structure const at ickle's request (once I
stopped assigning it directly) but didn't
t; + DRM_DEBUG_KMS("Invalid pixel format %x\n", fb->pixel_format);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> fb_width = fb->width << 16;
> fb_height = fb->height << 16;
>
Ye
void *data, struct drm_file *file_priv)
> {
> struct drm_mode_fb_cmd *or = data;
> - struct drm_mode_fb_cmd2 r;
> + struct drm_mode_fb_cmd2 r = {};
> struct drm_mode_config *config = &dev->mode_config;
> struct drm_framebuffer *fb;
> int
code should also indicate that the function succeeded, but
this doesn't hurt.
Acked-by: Jesse Barnes
--
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
plane_req->crtc_y,
>plane_req->crtc_w, plane_req->crtc_h,
Not sure this helps much in practice, since the drivers will have to
validate the target CRTC rect against the actual pipe dimensions anyway.
But it doesn't hurt either, so:
Acked
On Fri, 11 Nov 2011 19:18:52 +0200
Ville Syrjälä wrote:
> On Fri, Nov 11, 2011 at 08:24:18AM -0800, Jesse Barnes wrote:
> > On Fri, 11 Nov 2011 18:04:04 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > >
On Fri, 11 Nov 2011 19:11:39 +0200
Ville Syrjälä wrote:
> On Fri, Nov 11, 2011 at 09:01:46AM -0800, Jesse Barnes wrote:
> > On Fri, 11 Nov 2011 18:04:05 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > H
ff-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 257 +++-
drivers/gpu/drm/drm_drv.c |3 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 75 +-
include/drm/drm_mode.h | 33 ++
5 files changed, 368 inser
mode_fb_cmd2 using helpers where the old bpp/depth values are
needed.
v2: create DRM specific fourcc header file for sharing with libdrm etc
Acked-by: Alan Cox
Reviewed-by: Rob Clark
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c| 109 +++-
drivers
On Mon, 14 Nov 2011 11:47:07 -0800
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 Mon, 14 Nov 2011 11:47:06 -0800
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.
>
> v2: fix ABI of get_plane - move format_type_ptr to the end
ff-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 257 +++-
drivers/gpu/drm/drm_drv.c |3 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 75 +-
include/drm/drm_mode.h | 33 ++
5 files changed, 368 inser
multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
Signed-off-by: Ville Syrjälä
Acked-by: Alan Cox
Reviewed-by: Rob Clark
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/
Hm I get a full white screen with a gray triangle in the lower right
hand corner. I had to modify the resolution the test was searching for
to 1920x1200 instead of 1024x600 since I tested on a DP attached
monitor, and fix the connector id, but other than that it seemed to
work fine.
--
On Mon, 14 Nov 2011 23:16:44 +0200
Ville Syrjälä wrote:
> On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> > +#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) << 8) | \
> > + ((u32)(c) << 16) | ((u32)(d) << 24))
> &
On Mon, 14 Nov 2011 23:24:55 +0200
Ville Syrjälä wrote:
> On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
> > +struct drm_mode_fb_cmd2 {
> > + __u32 fb_id;
> > + __u32 width, height;
> > + __u32 pixel_format; /* fourcc code from videodev2.h */
>
n Cox
Reviewed-by: Rob Clark
Reviewed-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 257 +++-
drivers/gpu/drm/drm_drv.c |3 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 75
multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)
Signed-off-by: Ville Syrjälä
Acked-by: Alan Cox
Reviewed-by: Rob Clark
On Tue, 15 Nov 2011 00:37:47 +0200
Ville Syrjälä wrote:
> On Mon, Nov 14, 2011 at 01:35:57PM -0800, Jesse Barnes wrote:
> > On Mon, 14 Nov 2011 23:24:55 +0200
> > Ville Syrjälä wrote:
> >
> > > On Mon, Nov 14, 2011 at 12:21:55PM -0800, Jesse Barnes wrote:
&g
is. Are there any debug options? Is it
> possible to query the EGLImage for width/height?
Ok maybe the gen3 vs gen4 EGL image code isn't calculating the
width/stride correctly somewhere then. You'd have to walk through the
gbm_dri2.c and egl_dri2.c code and see where the width is
On Tue, 15 Nov 2011 13:42:40 +0200
Ville Syrjälä wrote:
> On Tue, Nov 15, 2011 at 12:40:43PM +1000, Ben Skeggs wrote:
> > On Mon, 2011-11-14 at 12:21 -0800, Jesse Barnes wrote:
> > > Planes are a bit like half-CRTCs. They have a location and fb, but
> > > don
:8, little endian */
> DRM_FOURCC_YVYU... /* [31:0] Cb:Y1:Cr:Y0 8:8:8:8, little endian */
> DRM_FOURCC_VYUY... /* [31:0] Y1:Cb:Y0:Cr 8:8:8:8, little endian */
>
> That leaves no room for guesswork.
Looks great. Want to send Dave an incremental patch? I'll apply the
current
crtc config to avoid unnecessary set_config calls.
Signed-off-by: Jesse Barnes
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..4dd81f3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -739,7 +739,8 @@ int
On Tue, 15 Nov 2011 22:30:36 +0200
Ville Syrjälä wrote:
> On Tue, Nov 15, 2011 at 08:16:04AM -0800, Jesse Barnes wrote:
> > On Tue, 15 Nov 2011 14:57:02 +0200
> > Ville Syrjälä wrote:
> > > I'm fine with fourccs as long as the defines are named and documented
>
make do with just one format definition.
Don't you still need to know the order? I.e. what's in handle[1], U or
V?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel
remove any
> functionality.
What if your surfaces are packed into a single bo? It would be a pain
to move them around in that case...
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri
On Thu, 17 Nov 2011 00:20:44 +0200
Ville Syrjälä wrote:
> On Wed, Nov 16, 2011 at 01:23:01PM -0800, Jesse Barnes wrote:
> > On Wed, 16 Nov 2011 23:19:38 +0200
> > Ville Syrjälä wrote:
> > > Oh and one extra detail just occured to me regarding the three plane
> > &g
On Thu, 17 Nov 2011 19:14:07 +0200
Ville Syrjälä wrote:
> On Thu, Nov 17, 2011 at 09:05:54AM -0800, Jesse Barnes wrote:
> > On Thu, 17 Nov 2011 18:05:14 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > >
On Fri, 18 Nov 2011 22:35:13 +0100
David Herrmann wrote:
> 2011/11/15 Kristian Høgsberg :
> > 2011/11/15 David Herrmann :
> >> 2011/11/15 Kristian Høgsberg :
> >>> On Mon, Nov 14, 2011 at 5:54 PM, Jesse Barnes
> >>> wrote:
> >>>> On Mon
Add structs and functions necessary for the new plane and fb handling code,
including a new header, drm_fourcc.h, that includes the surface formats
supported by various DRM drivers.
Signed-off-by: Jesse Barnes
---
include/drm/Makefile.am |1 +
include/drm/drm.h| 13 -
include
On Tue, 6 Dec 2011 15:23:57 -0800
Jesse Barnes wrote:
> Add structs and functions necessary for the new plane and fb handling code,
> including a new header, drm_fourcc.h, that includes the surface formats
> supported by various DRM drivers.
>
> Signed-off-by: Jesse Barnes
Import the current kernel bits into libdrm for client code.
Signed-off-by: Jesse Barnes
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 43695bd..2923ab4 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -26,6 +26,7 @@ klibdrmincludedir = ${includedir
tian has a few patches outstanding for CEA mode handling.
Getting them in makes sense to me and this patch looks like it's
structured nicely at least (I haven't checked the CEA bits against the
specs though).
Any chance we can get them included for 3.3?
Thanks,
--
Jesse Barnes, Intel Open
ed out was that you don't
seem to be validating the zpos ioctl parameters for sanity. Not sure
if there's much to do, but it may be worth checking for a max zpos or
something...
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mai
Ok no problem. I think Keith just queued up the i915 bits, but I don't
think they've made their way to Dave yet.
Jesse
On Wed, 4 Jan 2012 22:55:31 -0600
Rob Clark wrote:
> note: looks like I need to rebase this patch after exynos drm driver
> was pulled to drm-next.. if there are some other co
101 - 200 of 905 matches
Mail list logo
