[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
https://bugs.freedesktop.org/show_bug.cgi?id=89987 --- Comment #3 from James Le Cuirot --- Created attachment 115025 --> https://bugs.freedesktop.org/attachment.cgi?id=115025=edit vdpauinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/b525fbb5/attachment.html>
[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
https://bugs.freedesktop.org/show_bug.cgi?id=89987 --- Comment #2 from James Le Cuirot --- Forgot to mention that whatever DPM glitch is going on seems limited to VDPAU. I fired up Portal, which is fairly challenging for this card, and it ran just fine. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/503f074f/attachment.html>
[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
https://bugs.freedesktop.org/show_bug.cgi?id=89987 --- Comment #1 from James Le Cuirot --- Created attachment 115024 --> https://bugs.freedesktop.org/attachment.cgi?id=115024=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/a97f5b29/attachment.html>
[Bug 89987] Slow VDPAU (rv770_restrict_performance_levels_before_switch failed)
https://bugs.freedesktop.org/show_bug.cgi?id=89987 Bug ID: 89987 Summary: Slow VDPAU (rv770_restrict_performance_levels_before_switch failed) Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: chewi at gentoo.org Created attachment 115023 --> https://bugs.freedesktop.org/attachment.cgi?id=115023=edit dmesg I have a Radeon HD4670 on a Gentoo Linux system. 1080p playback was working fine under 3.17 but has since slowed to a crawl. I have done back to 3.17 to check that it still works despite numerous updates to userspace and it does. 3.18 flat out refuses to work, with vdpauinfo claiming that H.264 is not supported. I know that Radeon video acceleration was in a transition during this period so best to ignore that. Under 3.19.3 and 4.0-rc7, vdpauinfo reports that H.264 is supported but playback is very slow. How slow? Low quality 1080p is very jumpy. High quality 1080p (Blu-ray) barely moves at all. Probably something like 0.1fps. When attempting playback, though mplayer or VLC, the following error appears in dmesg. [drm:rv770_dpm_set_power_state [radeon]] *ERROR* rv770_restrict_performance_levels_before_switch failed This led me to try booting with radeon.dpm=0. Under the high profile, low quality is smooth and high quality improves to just jumpy. Under the dynpm method, both are smooth. I have two displays connected using Zaphod mode, both normally at 1080p. If I disconnect the second, playback is smooth. If I set the second to some low resolution like 720x480 but play 1080p video on the first, playback is smooth. I'm not sure whether this behaviour is a symptom or a cause. I tried enabling DRI3 to see if that would help but no. I can't bisect the kernel because UVD acceleration is new. There has probably not been a commit so far where it did work under this setup. Here's some further info. Card: Advanced Micro Devices, Inc. [AMD/ATI] RV730 XT [Radeon HD 4670] Kernels: 3.19.3 and 4.0-rc7 Mesa: 10.5.2 xorg-server: 1.17.1 xf86-video-ati: 7.5.0 and 5921ba4ca705a0d919515626088f3948cc4848c1 Desktop: XFCE (no compositing) This has similarities to bug #69120 but I believe that to be a different issue because it involves much older kernel versions and a lot has changed since then, plus it used to work for me until 3.18. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/43c1de38/attachment.html>
[PATCH] drm/atomic: Add for_each_{connector, crtc, plane}_in_state helper macros
On Fri, Apr 10, 2015 at 02:58:39PM +0300, Ander Conselvan de Oliveira wrote:
> This saves some typing whenever a iteration over all the connector,
> crtc or plane states in the atomic state is written, which happens
> quite often.
>
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Ander Conselvan de Oliveira intel.com>
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c| 62 +++--
> drivers/gpu/drm/drm_atomic_helper.c | 253
> +++-
> include/drm/drm_atomic.h| 24
> 3 files changed, 117 insertions(+), 222 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 57efdbe..68236bd 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -909,14 +909,13 @@ int
> drm_atomic_connectors_for_crtc(struct drm_atomic_state *state,
> struct drm_crtc *crtc)
> {
> - int i, num_connected_connectors = 0;
> -
> - for (i = 0; i < state->num_connector; i++) {
> - struct drm_connector_state *conn_state;
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
>
> - conn_state = state->connector_states[i];
> + int i, num_connected_connectors = 0;
>
> - if (conn_state && conn_state->crtc == crtc)
> + for_each_connector_in_state(state, connector, conn_state, i) {
> + if (conn_state->crtc == crtc)
> num_connected_connectors++;
> }
>
> @@ -968,19 +967,16 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> {
> struct drm_device *dev = state->dev;
> struct drm_mode_config *config = >mode_config;
> - int nplanes = config->num_total_plane;
> - int ncrtcs = config->num_crtc;
> + struct drm_plane *plane;
> + struct drm_plane_state *plane_state;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> int i, ret = 0;
>
> DRM_DEBUG_ATOMIC("checking %p\n", state);
>
> - for (i = 0; i < nplanes; i++) {
> - struct drm_plane *plane = state->planes[i];
> -
> - if (!plane)
> - continue;
> -
> - ret = drm_atomic_plane_check(plane, state->plane_states[i]);
> + for_each_plane_in_state(state, plane, plane_state, i) {
> + ret = drm_atomic_plane_check(plane, plane_state);
> if (ret) {
> DRM_DEBUG_ATOMIC("[PLANE:%d] atomic core check
> failed\n",
>plane->base.id);
> @@ -988,13 +984,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> }
> }
>
> - for (i = 0; i < ncrtcs; i++) {
> - struct drm_crtc *crtc = state->crtcs[i];
> -
> - if (!crtc)
> - continue;
> -
> - ret = drm_atomic_crtc_check(crtc, state->crtc_states[i]);
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + ret = drm_atomic_crtc_check(crtc, crtc_state);
> if (ret) {
> DRM_DEBUG_ATOMIC("[CRTC:%d] atomic core check failed\n",
>crtc->base.id);
> @@ -1006,13 +997,7 @@ int drm_atomic_check_only(struct drm_atomic_state
> *state)
> ret = config->funcs->atomic_check(state->dev, state);
>
> if (!state->allow_modeset) {
> - for (i = 0; i < ncrtcs; i++) {
> - struct drm_crtc *crtc = state->crtcs[i];
> - struct drm_crtc_state *crtc_state =
> state->crtc_states[i];
> -
> - if (!crtc)
> - continue;
> -
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> if (crtc_state->mode_changed ||
> crtc_state->active_changed) {
> DRM_DEBUG_ATOMIC("[CRTC:%d] requires full
> modeset\n",
> @@ -1210,6 +1195,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> struct drm_atomic_state *state;
> struct drm_modeset_acquire_ctx ctx;
> struct drm_plane *plane;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> unsigned plane_mask = 0;
> int ret = 0;
> unsigned int i, j;
> @@ -1313,15 +1300,9 @@ retry:
> }
>
> if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - int ncrtcs = dev->mode_config.num_crtc;
> -
> - for (i = 0; i < ncrtcs; i++) {
> - struct drm_crtc_state *crtc_state =
> state->crtc_states[i];
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> struct drm_pending_vblank_event *e;
>
> - if (!crtc_state)
> - continue;
> -
> e = create_vblank_event(dev, file_priv, arg->user_data);
> if (!e) {
>
[PATCH 3/3] drm/msm: drop redundant debug output
wait_for_completion_timeout returns 0 in case of timeout and never
return < 0 so there is no additional information in printing the
value of time_left here as it will always be 0, thus it can be dropped.
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc7 (localversion-next is -next-20150410)
drivers/gpu/drm/msm/edp/edp_ctrl.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 9ef361c..3739e80 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -1033,8 +1033,7 @@ static void edp_ctrl_off_worker(struct work_struct *work)
time_left = wait_for_completion_timeout(>idle_comp,
msecs_to_jiffies(500));
if (!time_left)
- DBG("%s: idle pattern timedout, %lu\n",
- __func__, time_left);
+ DBG("%s: idle pattern timedout\n", __func__);
edp_state_ctrl(ctrl, 0);
--
1.7.10.4
[PATCH 2/3] drm/msm: wait_for_completion_timeout return is never negative
wait_for_completion_timeout returns >= 0 but never
negative - so the error check should be against equality
to 0 not <= 0.
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc7 (localversion-next is -next-20150410)
drivers/gpu/drm/msm/edp/edp_ctrl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 831acd6..9ef361c 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -1032,7 +1032,7 @@ static void edp_ctrl_off_worker(struct work_struct *work)
time_left = wait_for_completion_timeout(>idle_comp,
msecs_to_jiffies(500));
- if (time_left <= 0)
+ if (!time_left)
DBG("%s: idle pattern timedout, %lu\n",
__func__, time_left);
--
1.7.10.4
[PATCH 1/3] drm/msm: match wait_for_completion_timeout return type
return type of wait_for_completion_timeout is unsigned long not int, this
patch assigns the return value of wait_for_completion_timeout to an
appropriately typed and named variable.
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc7 (localversion-next is -next-20150410)
drivers/gpu/drm/msm/edp/edp_ctrl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
b/drivers/gpu/drm/msm/edp/edp_ctrl.c
index 0ec5abd..831acd6 100644
--- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
+++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
@@ -1018,7 +1018,7 @@ static void edp_ctrl_off_worker(struct work_struct *work)
{
struct edp_ctrl *ctrl = container_of(
work, struct edp_ctrl, off_work);
- int ret;
+ unsigned long time_left;
mutex_lock(>dev_mutex);
@@ -1030,11 +1030,11 @@ static void edp_ctrl_off_worker(struct work_struct
*work)
reinit_completion(>idle_comp);
edp_state_ctrl(ctrl, EDP_STATE_CTRL_PUSH_IDLE);
- ret = wait_for_completion_timeout(>idle_comp,
+ time_left = wait_for_completion_timeout(>idle_comp,
msecs_to_jiffies(500));
- if (ret <= 0)
- DBG("%s: idle pattern timedout, %d\n",
- __func__, ret);
+ if (time_left <= 0)
+ DBG("%s: idle pattern timedout, %lu\n",
+ __func__, time_left);
edp_state_ctrl(ctrl, 0);
--
1.7.10.4
[Bug 87047] gputest pixmark tests fail on Barts
https://bugs.freedesktop.org/show_bug.cgi?id=87047 --- Comment #1 from almos --- Still the same with mesa 10.4.2. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/f971cad4/attachment.html>
[Bug 89968] 10.5 garbled screen with Enlightenment E19.
https://bugs.freedesktop.org/show_bug.cgi?id=89968 Apostolos B. changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/4a7d5e3d/attachment.html>
[PATCH] drm/radeon: use 0-255 rather than 0-100 for pwm fan range
On 05/02/2015 11:49, Christian König wrote:
> Am 04.02.2015 um 23:27 schrieb Alex Deucher:
>> 0-255 seems to be the preferred range for the pwm interface.
>>
>> Signed-off-by: Alex Deucher
> Yeah, using 100 on a 8bit pwm timer sounds rather obviously wrong.
>
> Patch is Reviewed-by: Christian König
>
>> ---
>>drivers/gpu/drm/radeon/radeon_pm.c | 8 ++--
>>1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
>> b/drivers/gpu/drm/radeon/radeon_pm.c
>> index 91e1bd2..9f758d3 100644
>> --- a/drivers/gpu/drm/radeon/radeon_pm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
>> @@ -585,7 +585,7 @@ static ssize_t radeon_hwmon_set_pwm1_enable(struct
>> device *dev,
>> if (err)
>> return err;
>>
>> -switch(value) {
>> +switch (value) {
>> case 1: /* manual, percent-based */
>> rdev->asic->dpm.fan_ctrl_set_mode(rdev, FDO_PWM_MODE_STATIC);
>> break;
>> @@ -608,7 +608,7 @@ static ssize_t radeon_hwmon_get_pwm1_max(struct device
>> *dev,
>> struct device_attribute *attr,
>> char *buf)
>>{
>> -return sprintf(buf, "%i\n", 100); /* pwm uses percent-based fan-control
>> */
>> +return sprintf(buf, "%i\n", 255);
>>}
This is not a standard name as it is not documented in
https://www.kernel.org/doc/Documentation/hwmon/sysfs-interface
Apparently, the pwm value should always have been exposed as 0-255 and I
screwed it up in nouveau by having it be 0-100...
Maybe we should ask pwm*_max to be defined so as new applications could
do the right thing while not having nouveau change its ABI. I guess it
is ok to change it for radeon as there are so few users currently but
the interface has been in nouveau for multiple years already!
[GIT PULL] Synopsis DesignWare HDMI driver development updates
David, Please incorporate the latest Synopsis DesignWare HDMI driver development updates, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-dwhdmi-devel with SHA1 1dbee1a3c38a8792c235048df1d709fc5ca3a185. Apologies for this being late... these are the patches which I queued last week after review on the mailing list, and have been tested by myself and agreed to be pushed for the 4.1 merge window between Yakir Yang and myself. If you're not taking stuff anymore, that's fine, I'll queue for the 4.2 window instead. This set of patches adjust the setup of the HDMI CTS/N values for audio support to be compliant with the work-around given in the iMX6 errata documentation as part of the preparation for integrating audio support for this driver, and also update the HDMI phy configuration for Rockchip devices to improve the HDMI eye pattern. This will update the following files: drivers/gpu/drm/bridge/dw_hdmi.c| 54 - drivers/gpu/drm/imx/dw_hdmi-imx.c | 24 ++--- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 include/drm/bridge/dw_hdmi.h| 5 +-- 4 files changed, 51 insertions(+), 46 deletions(-) through these changes: Russell King (3): drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts() drm: bridge/dw_hdmi: protect n/cts setting with a mutex drm: bridge/dw_hdmi: adjust n/cts setting order Yakir Yang (3): drm: bridge/dw_hdmi: fixed codec style drm: bridge/dw_hdmi: separate VLEVCTRL settting into platform driver drm: rockchip/dw_hdmi-rockchip: improve for HDMI electrical test Many thanks.
[Bug 72819] [855GM] Incorrect drop shadow color on windows and strange white rectangle when showing/hiding GLX-dock...
https://bugs.freedesktop.org/show_bug.cgi?id=72819 Ville Syrjala changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #2 from Ville Syrjala --- The white flash is not a Mesa issue so I'm closing this bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/05f70af7/attachment.html>
[Bug 72819] [855GM] Incorrect drop shadow color on windows and strange white rectangle when showing/hiding GLX-dock...
https://bugs.freedesktop.org/show_bug.cgi?id=72819 --- Comment #1 from Ville Syrjala --- Created attachment 115015 --> https://bugs.freedesktop.org/attachment.cgi?id=115015=edit [PATCH] cairo-dock: Fix white flash when NPOT textures aren't available The white flash looks to be a bug in cairo-dock. This patch fixes it for me, although it's possible some other rendering error will remain since the texture coordinates might no longer be entirely correct since the actual image no longer fills the entire texture. I'm too lazy to register to launchpad so that I could report the bug to cairo-dock. But feel free to forward this patch to cairo-dock developers. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/2edb3e92/attachment.html>
Patch - FreeBSD & NetBSD support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I'm upstreaming a merge of two patches taken from the FreeBSD ports
tree & NetBSD's pkgsrc tree so the credit/blame is not mine. :)
The FreeBSD part resolves building libdrm on a host which may not have
a KMS module loaded hence a sysctl will not be present.
The other part adds NetBSD support.
Regards
Sevan Janiyan
-BEGIN PGP SIGNATURE-
iQIcBAEBCAAGBQJVKK39AAoJENE/+DdOy3tCc0YP/2rME7gJJSNT7kpCVCctr8pt
8yjowGkeYYfiVEDFDhB1ZQ+LL7KEmECAWJjBYCB1P1T3Mzl8LBYbaIBcAQ3rLjsE
vbcuFWmW/xq+WaqzyK1cqxcOXXYnrpXyPG8IkAj1k66TWGJF1QSG9qtEQ/W5W7IC
bVFJtLVCSn3GrY9Kyp1oP0qQW8IHuh+74uDIdXEG1ZMKQtytv0C2AVGBKJIyd37z
KP2v38K0hlmZdLcaBubwI6YBE5/02yTm83SvecApuJO0KyhMKG1qrJRQMXepKV2O
TVuWDlwRWmSjClAOaAmL8RhUpFF1zFqlDiUlsczXGDRqxDErtvRte8TP9ktV2IcN
A61iPZTEDXbPeJxuEX6P4wJSGhqrgd/L7WEXX1FUXKWInohzrKGya2cVi+L8uMjm
c65JAmzA9jyMUebluJlrfGNInN0hZ0lRvwyFEW5PvLKJT//N3ybqHqQXFLvoAjI5
PZrnz9gzPWS6gQiMb3fUr8pFsE7Dxxlqc0RqlNQ6yzpKX6CePPmO5MVb+ktY72ad
cmdCe1J2EXUDIC9/A2y61/3XuS3jrjFSoZzpw4JOYf2TL3jq1NOnUS8XzXDaySJM
ouMV+6ERlcN5DriMvZpx81ZBJWwgP3yyy7nj4CTpivMOU4i1iTbVrLEDv60sMLdY
C/dpQFub+sJzWY2y4s2/
=PAg4
-END PGP SIGNATURE-
-- next part --
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 61d5e01..bb1dcc2 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -771,38 +771,20 @@ int drmCheckModesettingSupported(const char *busid)
if (found)
return 0;
#elif defined (__FreeBSD__) || defined (__FreeBSD_kernel__)
- char kbusid[1024], sbusid[1024];
- char oid[128];
- int domain, bus, dev, func;
- int i, modesetting, ret;
- size_t len;
-
- ret = sscanf(busid, "pci:%04x:%02x:%02x.%d", , , ,
- );
- if (ret != 4)
+ return 0;
+#elif defined(__NetBSD__)
+ int fd;
+ static const struct drm_mode_card_res zero_res;
+ struct drm_mode_card_res res = zero_res;
+ int ret;
+
+ fd = drmOpen(NULL, busid);
+ if (fd == -1)
return -EINVAL;
- snprintf(kbusid, sizeof(kbusid), "pci:%04x:%02x:%02x.%d", domain, bus,
- dev, func);
-
- /* How many GPUs do we expect in the machine ? */
- for (i = 0; i < 16; i++) {
- snprintf(oid, sizeof(oid), "hw.dri.%d.busid", i);
- len = sizeof(sbusid);
- ret = sysctlbyname(oid, sbusid, , NULL, 0);
- if (ret == -1) {
- if (errno == ENOENT)
- continue;
- return -EINVAL;
- }
- if (strcmp(sbusid, kbusid) != 0)
- continue;
- snprintf(oid, sizeof(oid), "hw.dri.%d.modesetting", i);
- len = sizeof(modesetting);
- ret = sysctlbyname(oid, , , NULL, 0);
- if (ret == -1 || len != sizeof(modesetting))
- return -EINVAL;
- return (modesetting ? 0 : -ENOSYS);
- }
+ ret = drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, );
+ drmClose(fd);
+ if (ret == 0)
+ return 0;
#elif defined(__DragonFly__)
return 0;
#endif
@@ -907,7 +889,7 @@ int drmModePageFlip(int fd, uint32_t crtc_id, uint32_t
fb_id,
int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t crtc_id,
uint32_t fb_id, uint32_t flags,
- int32_t crtc_x, int32_t crtc_y,
+ uint32_t crtc_x, uint32_t crtc_y,
uint32_t crtc_w, uint32_t crtc_h,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h)
-- next part --
A non-text attachment was scrubbed...
Name: git-drm.txt.sig
Type: application/octet-stream
Size: 543 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/112f3794/attachment-0001.obj>
[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)
https://bugs.freedesktop.org/show_bug.cgi?id=89980 falaca at gmail.com changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) Version|XOrg git|unspecified OS|All |Linux (All) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/143f3ce9/attachment.html>
[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)
https://bugs.freedesktop.org/show_bug.cgi?id=89980 --- Comment #1 from falaca at gmail.com --- Created attachment 115014 --> https://bugs.freedesktop.org/attachment.cgi?id=115014=edit dmesg -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/e722a321/attachment.html>
[Bug 89980] [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration)
https://bugs.freedesktop.org/show_bug.cgi?id=89980 Bug ID: 89980 Summary: [Regression] Graphical corruption after resuming from suspend (w/ dual monitor configuration) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: falaca at gmail.com Created attachment 115013 --> https://bugs.freedesktop.org/attachment.cgi?id=115013=edit Xorg log This is a regression: Bug is reproducible in Ubuntu 15.04 Beta (Xorg 1.17.1, linux 3.19) and Fedora 22 Alpha (Xorg 1.17.1, linux 4.0) with a Radeon R7 260X video card. I first noticed the issue in Ubuntu 14.04 after I upgraded from Xorg 1.16 to 1.17. The problem does not occur with fglrx. Symptoms: Checkerboard tearing pattern begins to occur in approximately the top 1/8 of the display after resuming from suspend, and does not resolve itself until a reboot. Demonstration of bug in Ubuntu w/ Unity (highlighting menu entries with the mouse): https://www.dropbox.com/s/ez2v03oetppecgx/VID_20150324_020612.mp4?dl=0 Demonstration of bug in Fedora w/ Gnome 3 (maximizing/restoring a window): https://www.dropbox.com/s/85n2iq27zm00dlo/VID_20150410_033406.mp4?dl=0 Steps to reproduce: I can only reproduce this with when I have 2 displays connected. My primary screen is set to 2560x1440, and the secondary screen in portrait mode is set to 1200x1920 on the left-hand side. I have the landscape monitor centered with respect to the portrait one, so y = 240 in ~/.config./monitors.xml. I cannot observe the bug when both screens are aligned at the top, i.e., with y=0 in ~/.config/monitors.xml. I also cannot observe the bug with a single monitor connected, or with both monitors in landscape mode. After setting up the monitor configuration, all that needs to be done to reproduce the corruption is to suspend the system, resume, and observe the top portion of the primary (landscape) display when the screen is changing, e.g., it is apparent when watching full-screen movies or minimizing/maximizing windows as demonstrated in my demo video. Attached: Xorg log and dmesg (w/ kernel parameter drm.debug=14) saved after a suspend/resume cycle -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150411/d6091d75/attachment.html>
