search for: drm_format_uyvy

...-git a/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c b/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c index cc417664f823..9c074db9b5be 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c +++ b/drivers/gpu/drm/nouveau/dispnv50/ovly507e.c @@ -160,9 +160,7 @@ ovly507e_format[] = { DRM_FORMAT_YUYV, DRM_FORMAT_UYVY, DRM_FORMAT_XRGB8888, - DRM_FORMAT_ARGB8888, DRM_FORMAT_XRGB1555, - DRM_FORMAT_ARGB1555, 0 }; diff --git a/drivers/gpu/drm/nouveau/dispnv50/ovly827e.c b/drivers/gpu/drm/nouveau/dispnv50/ovly827e.c index aaa9fe5a4fc8..2e68fc736fe1 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/ovly827e.c +++...

This was all kicked off by me figuring out how the PPC byteswap thing worked. In the end, we're keeping the implicit byteswap based on architecture, but also expose the correctly supported formats, and fix some overlay details. Overlay framebuffers have various funky requirements that should be enforced at framebuffer creation time (these are set apart by their YUV formats). Further, I

Otherwise none of the format checks pass, since the width was still in 16.16 encoding. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- This must have been some sort of last-second cleanup I made and forgot to test, because with this code, there's no way it could ever have worked... drivers/gpu/drm/nouveau/dispnv04/overlay.c | 17 +++++++++-------- 1 file changed, 9

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only

This came out of some debugging I was doing to figure out how BE mode works on this hardware. Among other things, it came out that we're not exposing 16-bpp mode support and that the ARGB8888 mode that we do expose is broken. Also the overlay logic was pretty broken, I must have only tested with very "normal" overlay buffer sizes with modetest before. That said, this code has only

...ruct drm_property *brightness; + struct drm_property *hue; + struct drm_property *saturation; + struct drm_property *iturbt_709; + } props; + + int colorkey; + int contrast; + int brightness; + int hue; + int saturation; + int iturbt_709; +}; + +static uint32_t formats[] = { + DRM_FORMAT_NV12, + DRM_FORMAT_UYVY, +}; + +/* Sine can be approximated with + * http://en.wikipedia.org/wiki/Bhaskara_I's_sine_approximation_formula + * sin(x degrees) ~= 4 x (180 - x) / (40500 - x (180 - x) ) + * Note that this only works for the range [0, 180]. + * Also note that sin(x) == -sin(x - 180) + */ +static inline int...

From: Ville Syrjälä <ville.syrjala at linux.intel.com> Replace the ad-hoc iturbt_709 property with the new standard COLOR_ENCODING property. Compiles, but not tested. Cc: Daniel Vetter <daniel at ffwll.ch> Cc: nouveau at lists.freedesktop.org Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Ilia Mirkin <imirkin at alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala at