Displaying 7 results from an estimated 7 matches for "drm_format_uyvi".
Did you mean:
drm_format_uyvy
2019 Jun 03
0
[PATCH] drm/nouveau/kms/nv50-: remove overlay alpha formats
The overlay logic can only do colorkey-based selection, not
alpha-blending.
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
This applies on top of the FP16 patch I sent earlier.
drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 --
drivers/gpu/drm/nouveau/dispnv50/ovly827e.c | 3 ---
drivers/gpu/drm/nouveau/dispnv50/ovly907e.c | 4 ----
drivers/gpu/drm/nouveau/dispnv50/ovly917e.c
2017 Aug 06
4
[PATCH 0/4] Overlay / format improvements
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
2013 Nov 15
4
[PATCH 1/5] drm/nv10/plane: fix format computation
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
2017 May 20
3
[RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes
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
2017 May 20
4
[RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes
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
2013 Sep 08
1
[PATCH] drm/nv10/plane: add plane support for nv10-nv40
Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
---
This has received light testing on NV18 and NV34 cards, using the modetest
tool. Userspace support to use this for xv is not yet ready.
I decided against creating a new "pvideo" engine -- that just seems way too
heavy-handed compared to the ~10 lines of code in disp/nv04.c to deal with the
PVIDEO interrupts.
Even though
2018 Feb 20
4
[PATCH] drm/nouveau: Replace the iturbt_709 prop with the standarad COLOR_ENCODNIG prop
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