similar to: [PATCH 0/4] Overlay / format improvements

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

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

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

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

All fields in struct nouveau_framebuffer appear to be obsolete. The data structure can be replaced by struct drm_framebuffer entirely. Patch 1 removes several unused fields from struct nouveau_framebuffer. Patch 2 moves the field vma to struct nouveau_fbdev. The information in vma is only relevant for fbdev emulation, and as such he field is only used there. Patch 3 removes nvbo from struct

Pick up the correct source rectangle from framebuffer. Without this multihead setups are not working correctly. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c

Pick up the correct source rectangle from framebuffer. Without this multihead setups are not working correctly. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c

Because all drivers currently use gem objects for framebuffer planes, the virtual create_handle() is not required. This change adds a struct drm_gem_object *gems[4] field to drm_framebuffer and removes create_handle() function pointer from drm_framebuffer_funcs. The corresponding *_create_handle() function is removed from each driver. In many cases this change eliminates a struct *_framebuffer

Because all drivers currently use gem objects for framebuffer planes, the virtual create_handle() is not required. This change adds a struct drm_gem_object *gems[4] field to drm_framebuffer and removes create_handle() function pointer from drm_framebuffer_funcs. The corresponding *_create_handle() function is removed from each driver. In many cases this change eliminates a struct *_framebuffer

Because all drivers currently use gem objects for framebuffer planes, the virtual create_handle() is not required. This change adds a struct drm_gem_object *gems[4] field to drm_framebuffer and removes create_handle() function pointer from drm_framebuffer_funcs. The corresponding *_create_handle() function is removed from each driver. In many cases this change eliminates a struct *_framebuffer

Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 31 ++++++++++++++------------ 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c index bc4bc4475a8c..a0f91658c2bc 100644 --- a/drivers/gpu/drm/virtio/virtgpu_plane.c +++

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. Cc: 1882851 at bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. Cc: 1882851 at bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't

Be consistent with the rest of the code base. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++-- drivers/gpu/drm/virtio/virtgpu_plane.c | 12 ++++++------ drivers/gpu/drm/virtio/virtgpu_vq.c | 12 ++++++------ 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h

When going through a disable/enable cycle without changing the framebuffer the optimization added by commit 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't change") causes the screen stay blank. Add a bool to force an update to fix that. v2: use drm_atomic_crtc_needs_modeset() (Daniel). Cc: 1882851 at bugs.launchpad.net Fixes: 3954ff10e06e ("drm/virtio: skip

The buffer object stored in nvbo is also available GEM object in obj[0] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouveau_user_framebuffer_create_handle() with generic GEM helpers. Calls to nouveau_framebuffer_new()

On Fri, May 11, 2018 at 04:59:17PM +0200, Boris Brezillon wrote: > Applying an underscan setup is just a matter of scaling all planes > appropriately and adjusting the CRTC X/Y offset to account for the > horizontal and vertical border. > > Create an vc4_plane_underscan_adj() function doing that and call it from > vc4_plane_setup_clipping_and_scaling() so that we are ready to

The control flow was: if (!y) { ppix = ... } if (y) { ... } else if (x) { use ppix for something } else { use ppix for something } Merge the if(!y) block with the two else branches. This avoids a false-positive in the clang static analyzer, it can't know that !y and x are mutually exclusive. The result looks something like this: if (y) { ... } else { ppix = ... if (x) {

Fix DRM_REFELCT_Y -> DRM_REFLECT_Y. Signed-off-by: Robert Foss <robert.foss at collabora.com> --- drivers/gpu/drm/drm_blend.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c index a0d0d6843288..dee67ef6c670 100644 --- a/drivers/gpu/drm/drm_blend.c +++ b/drivers/gpu/drm/drm_blend.c @@ -129,7 +129,7 @@ *