File your talk now, while there are still
> some useful slots available.
>
> Also, for those who have filed already but who have left their abstracts
> open, please get those filed in ASAP. Your talk will be only be ordered
> in when at least the basics are provided.
Hey Luc,
aniel requested via IRC that I try with a different capture
> card; I've switched to a HVR-1600 (cx18 driver instead of saa7134), and I've
> also tried with the X server forcibly quiesced via kill -STOP.
>
> Quiescing the X server doesn't help; however, the HVR-1600 does no
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 | 235 +++-
drivers/gpu/drm/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
---
drivers/gpu/drm/drm_crtc.c
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
The video sprites support video surface formats natively and can handle
scaling 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 | 52
t altogether, or we preserve the idea of a
"primary" plane (whatever that means for a given platform) that's tied
to each CRTC, which each additional plane described in a separate
structure. Z order and blend restrictions will have to be communicated
separately I think...
Thanks,
--
ery much custom to DRM.
If that's the only issue you have, we could easily rename that
structure or add conversion funcs to a smaller structure if that's what
you need.
Dave's point is that we can't ditch the existing code without
introducing a lot of risk; it would be
rn and avoid the overhead.
>
> Signed-off-by: Jon Mason
> ---
Applied to linux-next, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.o
d *startwrite, *startread;
> int offset;
> - int bytesperline = dev->vbi_width;
> + int bytesperline;
>
> if (dev == NULL) {
> em28xx_isocdbg("dev is null\n");
> return;
> }
> + bytesperline = dev->v
10 matches
Mail list logo
