dri-devel September 2018

dri-devel@lists.freedesktop.org

276 participants
1899 discussions

Start a nNew thread

vc4 in v4.19-rc2
by Sergey Suloev 06 Sep '18

06 Sep '18

Hi, Eric, I found a critical issue with vc4 in v4.19-rc2. See log. https://pastebin.com/PDUW99Na Thank you, Sergey

1 1

[PATCH] drm: refuse ADDFB2 ioctl for broken bigendian drivers
by Gerd Hoffmann 06 Sep '18

06 Sep '18

Drivers must set the quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() compat code work correctly on bigendian machines. If they don't they interpret pixel_format values incorrectly for bug compatibility, which in turn implies the ADDFB2 ioctl does not work correctly then. So block it to make userspace fallback to ADDFB. Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- drivers/gpu/drm/drm_ioctl.c | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index ea10e9a26a..08e48bda23 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -469,6 +469,29 @@ static int drm_copy_field(char __user *buf, size_t *buf_len, const char *value) return 0; } +static int drm_mode_addfb2_check(struct drm_device *dev, + void *data, struct drm_file *file_priv) +{ +#ifdef __BIG_ENDIAN + if (!dev->mode_config.quirk_addfb_prefer_host_byte_order) { + /* + * Drivers must set the + * quirk_addfb_prefer_host_byte_order quirk to make + * the drm_mode_addfb() compat code work correctly on + * bigendian machines. + * + * If they don't they interpret pixel_format values + * incorrectly for bug compatibility, which in turn + * implies the ADDFB2 ioctl does not work correctly + * then. So block it to make userspace fallback to + * ADDFB. + */ + return -EINVAL; + } +#endif + return drm_mode_addfb2(dev, data, file_priv); +} + /* * Get version information * @@ -645,7 +668,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = { DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl, DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb, DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb_ioctl, DRM_UNLOCKED), - DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2, DRM_UNLOCKED), + DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2_check, DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_MODE_RMFB, drm_mode_rmfb_ioctl, DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_MODE_PAGE_FLIP, drm_mode_page_flip_ioctl, DRM_MASTER|DRM_UNLOCKED), DRM_IOCTL_DEF(DRM_IOCTL_MODE_DIRTYFB, drm_mode_dirtyfb_ioctl, DRM_MASTER|DRM_UNLOCKED), -- 2.9.3

2 1

[PATCH weston 2/3] compositor-drm: Add support for drm plane FB_DAMAGE_CLIPS property
by Deepak Rawat 06 Sep '18

06 Sep '18

The plane property FB_DAMAGE_CLIPS provides a way mark damaged regions on the plane in framebuffer coordinates of the framebuffer attached to the plane. This patch adds a new member "damage" to compositor version of drm_plane_state and set FB_DAMAGE_CLIPS property whenever damage is available. Signed-off-by: Deepak Rawat <drawat(a)vmware.com> Cc: dri-devel(a)lists.freedesktop.org --- libweston/compositor-drm.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c index 6a87a296..30f6fce9 100644 --- a/libweston/compositor-drm.c +++ b/libweston/compositor-drm.c @@ -129,6 +129,7 @@ enum wdrm_plane_property { WDRM_PLANE_FB_ID, WDRM_PLANE_CRTC_ID, WDRM_PLANE_IN_FORMATS, + WDRM_PLANE_FB_DAMAGE_CLIPS, WDRM_PLANE__COUNT }; @@ -171,6 +172,7 @@ static const struct drm_property_info plane_props[] = { [WDRM_PLANE_FB_ID] = { .name = "FB_ID", }, [WDRM_PLANE_CRTC_ID] = { .name = "CRTC_ID", }, [WDRM_PLANE_IN_FORMATS] = { .name = "IN_FORMATS" }, + [WDRM_PLANE_FB_DAMAGE_CLIPS] = { .name = "FB_DAMAGE_CLIPS" }, }; /** @@ -403,6 +405,8 @@ struct drm_plane_state { bool complete; + pixman_region32_t damage; /* damage sent to kernel */ + struct wl_list link; /* drm_output_state::plane_list */ }; @@ -1306,6 +1310,7 @@ drm_plane_state_alloc(struct drm_output_state *state_output, assert(state); state->output_state = state_output; state->plane = plane; + pixman_region32_init(&state->damage); /* Here we only add the plane state to the desired link, and not * set the member. Having an output pointer set means that the @@ -1336,6 +1341,7 @@ drm_plane_state_free(struct drm_plane_state *state, bool force) wl_list_remove(&state->link); wl_list_init(&state->link); state->output_state = NULL; + pixman_region32_fini(&state->damage); if (force || state != state->plane->state_cur) { drm_fb_unref(state->fb); @@ -1373,6 +1379,7 @@ drm_plane_state_duplicate(struct drm_output_state *state_output, if (src->fb) dst->fb = drm_fb_ref(src->fb); dst->output_state = state_output; + pixman_region32_init(&dst->damage); dst->complete = false; return dst; @@ -2409,6 +2416,33 @@ drm_mode_ensure_blob(struct drm_backend *backend, struct drm_mode *mode) return ret; } +static int +plane_add_damage(drmModeAtomicReq *req, struct drm_backend *backend, + struct drm_plane_state *plane_state) +{ + struct drm_plane *plane = plane_state->plane; + pixman_box32_t *rects; + uint32_t blob_id; + int n_rects; + int ret; + + if (!pixman_region32_not_empty(&plane_state->damage)) + return 0; + + rects = pixman_region32_rectangles(&plane_state->damage, &n_rects); + + ret = drmModeCreatePropertyBlob(backend->drm.fd, rects, + sizeof(*rects) * n_rects, &blob_id); + if (ret != 0) + return ret; + + ret = plane_add_prop(req, plane, WDRM_PLANE_FB_DAMAGE_CLIPS, blob_id); + if (ret != 0) + return ret; + + return 0; +} + static int drm_output_apply_state_atomic(struct drm_output_state *state, drmModeAtomicReq *req, @@ -2477,6 +2511,7 @@ drm_output_apply_state_atomic(struct drm_output_state *state, plane_state->dest_w); ret |= plane_add_prop(req, plane, WDRM_PLANE_CRTC_H, plane_state->dest_h); + ret |= plane_add_damage(req, backend, plane_state); if (ret != 0) { weston_log("couldn't set plane state\n"); -- 2.17.1

2 1

[PATCH] drm: Reject unknown legacy bpp and dpeth for drm_mode_addfb ioctl
by Chris Wilson 06 Sep '18

06 Sep '18

Since this is handling user provided bpp and depth, we need to sanity check and propagate the EINVAL back rather than assume what the insane client intended and fill the logs with DRM_ERROR. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- So I am presuming that r.pixel_format == 0 is rejected elsewhere for the internal users (as if any would deliberately provoke the error)! --- drivers/gpu/drm/drm_fourcc.c | 4 ++-- drivers/gpu/drm/drm_framebuffer.c | 5 ++++- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c index 35c1e2742c27..34595c5b55c9 100644 --- a/drivers/gpu/drm/drm_fourcc.c +++ b/drivers/gpu/drm/drm_fourcc.c @@ -69,8 +69,8 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth) fmt = DRM_FORMAT_ARGB8888; break; default: - DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n"); - fmt = DRM_FORMAT_XRGB8888; + DRM_DEBUG("bad bpp [%d] and depth [%d]\n", bpp, depth); + fmt = 0; break; } diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 781af1d42d76..7641bddfe367 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -112,12 +112,15 @@ int drm_mode_addfb(struct drm_device *dev, struct drm_mode_fb_cmd *or, struct drm_mode_fb_cmd2 r = {}; int ret; + r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth); + if (!r.pixel_format) + return -EINVAL; + /* convert to new format and call new ioctl */ r.fb_id = or->fb_id; r.width = or->width; r.height = or->height; r.pitches[0] = or->pitch; - r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth); r.handles[0] = or->handle; if (r.pixel_format == DRM_FORMAT_XRGB2101010 && -- 2.19.0.rc1

2 7

[RFC] UAPI: Check headers by compiling all together as C++
by David Howells 06 Sep '18

06 Sep '18

Here's a set of patches that inserts a step into the build process to make sure that the UAPI headers can all be built together with C++ (if the compiler being used supports C++). All but the final patch perform fixups, including: (1) Fix member names that conflict with C++ reserved words by providing alternates that can be used anywhere. An anonymous union is used so that that the conflicting name is still available outside of C++. (2) Fix the use of flexible arrays in structs that get embedded (which is illegal in C++). (3) Remove the use of internal kernel structs in UAPI structures. (4) Fix symbol collisions. (5) Replace usage of u32 and co. with __u32 and co. (6) Fix use of sparsely initialised arrays (which g++ doesn't implement). (7) Remove some use of PAGE_SIZE since this isn't valid outside of the kernel. And lastly: (8) Compile all of the UAPI headers (with a few exceptions) together as C++ to catch new errors occurring as part of the regular build process. The patches can also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=ua… Thanks, David --- David Howells (11): UAPI: drm: Fix use of C++ keywords as structural members UAPI: keys: Fix use of C++ keywords as structural members UAPI: virtio_net: Fix use of C++ keywords as structural members UAPI: bcache: Fix use of embedded flexible array UAPI: coda: Don't use internal kernel structs in UAPI UAPI: netfilter: Fix symbol collision issues UAPI: nilfs2: Fix use of undefined byteswapping functions UAPI: sound: Fix use of u32 and co. in UAPI headers UAPI: ndctl: Fix g++-unsupported initialisation in headers UAPI: ndctl: Remove use of PAGE_SIZE UAPI: Check headers build for C++ Makefile | 1 include/linux/ndctl.h | 22 ++++ include/uapi/drm/i810_drm.h | 7 + include/uapi/drm/msm_drm.h | 7 + include/uapi/linux/bcache.h | 2 include/uapi/linux/coda_psdev.h | 4 + include/uapi/linux/keyctl.h | 7 + include/uapi/linux/ndctl.h | 20 ++- include/uapi/linux/netfilter/nfnetlink_cthelper.h | 2 include/uapi/linux/netfilter_ipv4/ipt_ECN.h | 9 -- include/uapi/linux/nilfs2_ondisk.h | 21 ++-- include/uapi/linux/virtio_net.h | 7 + include/uapi/sound/skl-tplg-interface.h | 106 +++++++++--------- scripts/headers-c++.sh | 124 +++++++++++++++++++++ 14 files changed, 255 insertions(+), 84 deletions(-) create mode 100644 include/linux/ndctl.h create mode 100755 scripts/headers-c++.sh

5 7

[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
by bugzilla-daemon＠freedesktop.org 06 Sep '18

06 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #12 from Alan W. Irwin <Alan.W.Irwin1234(a)gmail.com> --- (In reply to Michel Dänzer from comment #10) > [T]hat looks like an RCU or other core kernel issue, not directly > related to the graphics drivers. Hi Michel: If so, should I report that probable non-graphics kernel bug (with my crash-report tarball) elsewhere? Or do you suggest I just forget it until I see what are the remote graphics results of idle=nomwait over the course of the next couple of weeks AND (if that is a success) the direct graphics results of idle=nomwait for a couple of more weeks after that? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v2 0/3] Compute CRC with cursor plane support
by Haneen Mohammed 06 Sep '18

06 Sep '18

This patchset adds cursor plane support and compute CRC for output frame with cursor and primary plane. changes in v2: - clear alpha channel before computing crc for XRGB plane format - add module option 'enable_cursor' to enable/disable cursor support Haneen Mohammed (3): drm/vkms: Add cursor plane support drm/vkms: Compute CRC with Cursor Plane drm/vkms: Enable/Disable cursor support with module option drivers/gpu/drm/vkms/vkms_crc.c | 154 ++++++++++++++++++++++++----- drivers/gpu/drm/vkms/vkms_drv.c | 4 + drivers/gpu/drm/vkms/vkms_drv.h | 18 +++- drivers/gpu/drm/vkms/vkms_output.c | 19 +++- drivers/gpu/drm/vkms/vkms_plane.c | 43 +++++--- 5 files changed, 196 insertions(+), 42 deletions(-) -- 2.17.1

1 3

[PATCH] Fixes: fc2a69f3903d ("drm/atomic: Handling the case when, setting old crtc for plane")
by Karsten Hohmeier 06 Sep '18

06 Sep '18

Original commit causes "plane A assertion failure" on lid close/lid open with older HP Compaq 6720s laptops (Intel Mobile GME965/GLE960). Full bug report at "https://bugs.freedesktop.org/show_bug.cgi?id=107827". --- drivers/gpu/drm/drm_atomic.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 895741e9cd7d..a59ded403657 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1433,9 +1433,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state *plane_state, { struct drm_plane *plane = plane_state->plane; struct drm_crtc_state *crtc_state; - /* Nothing to do for same crtc*/ - if (plane_state->crtc == crtc) - return 0; + if (plane_state->crtc) { crtc_state = drm_atomic_get_crtc_state(plane_state->state, plane_state->crtc); -- 2.11.0

6 5

[linux-next] DDC responded, but no EDID for %s errors
by Sergey Senozhatsky 06 Sep '18

06 Sep '18

Hi, My dmesg is filled up with these errors nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 [..] nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for VGA-1 [..] Basically, a message every 10s or so. Any chance we can make them go away? -ss

2 3

[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
by bugzilla-daemon＠freedesktop.org 06 Sep '18

06 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #11 from Alan W. Irwin <Alan.W.Irwin1234(a)gmail.com> --- Thanks for that idle=nomwait suggestion which I have now just tried (verified by irwin@merlin> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-amd64 root=UUID=1e45a1ee-a5d6-4327-9a7b-2663ffc0b157 ro rootwait quiet idle=nomwait ) and I now indeed have a stable result. However, that is currently just for the last 5 minutes in remote access mode. :-) So we will see how this goes for, say, the next two weeks, to see if I can beat my last 4.17.17 remote access uptime record of 6 days. With regard to your MB BIOS update suggestion, I am going to hold back on that for a while since the techs from a local computer company that assembled my box in May felt such updates were dangerous and therefore a last resort. And that is also the consistent advice I have gotten for the other 3 Linux boxes I have had assembled for me since I started using Linux in 1996. Of course, this year may be a special case with all the Meltdown (although not for this AMD hardware) and many variants of SPECTRE out there so I do plan to update the BIOS within the next couple of months on the assumption that the SPECTRE BIOS mitigations recommended by AMD to ASUS for this hardware (PRIME B350+ MB with AMD Ryzen 7 1700 CPU, 64GB RAM, and ASUS RX 550 graphics card) will have matured by then. But before I implement that planned BIOS update, I am hoping that the current cutting-edge Linux graphics stack (which according to a senior Phoronix poster works well for the RX 560) will also give me stable direct-display results for the RX 550 once that version of the graphics stack propagates to Debian Testing. I estimate that propagation time will be a couple of more months based on how quickly elements of the cutting-edge Linux graphics stack such as the kernel has propagated in the past from upstream to Debian Testing. In sum, it is a waiting game now to see if your idle=nomwait suggestion restores the complete Linux stability I was used to with my old box (for Debian Oldstable = Jessie) for at least the remote display case, and if that stability is obviously much better (i.e., at least a couple of weeks uptime with no lockups) then I will try the direct display case again with idle=nomwait to see if it makes that case stable as well. Thanks, Michel, for your on-going helpful suggestions for dealing with this troubling instability issue (these troubling instability issues?) for my new Linux box. Alan -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2018