[Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 Alex Deucher changed: What|Removed |Added Component|Drivers/DRI/R600|GLX AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org CC||nbowler at draconx.ca --- Comment #4 from Alex Deucher 2010-08-03 21:21:23 PDT --- This looks like a glx bug rather than a driver bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 2/2] drm/radeon/kms: enable underscan option for digital connectors
This connector attribute allows you to enable or disable underscan
on a digital output to compensate for panels that automatically
overscan (e.g., many HDMI TVs). Valid values for the attribute are:
off - forces underscan off
on - forces underscan on
auto - enables underscan if an HDMI TV is connected, off otherwise
default value is auto.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_crtc.c | 36 +---
drivers/gpu/drm/radeon/radeon_connectors.c | 23 +++
drivers/gpu/drm/radeon/radeon_display.c| 41
drivers/gpu/drm/radeon/radeon_encoders.c |5 +++-
drivers/gpu/drm/radeon/radeon_mode.h | 18 +++-
5 files changed, 98 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index a2e65d9..12ad512 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -44,10 +44,6 @@ static void atombios_overscan_setup(struct drm_crtc *crtc,
memset(, 0, sizeof(args));
- args.usOverscanRight = 0;
- args.usOverscanLeft = 0;
- args.usOverscanBottom = 0;
- args.usOverscanTop = 0;
args.ucCRTC = radeon_crtc->crtc_id;
switch (radeon_crtc->rmx_type) {
@@ -56,7 +52,6 @@ static void atombios_overscan_setup(struct drm_crtc *crtc,
args.usOverscanBottom = (adjusted_mode->crtc_vdisplay -
mode->crtc_vdisplay) / 2;
args.usOverscanLeft = (adjusted_mode->crtc_hdisplay -
mode->crtc_hdisplay) / 2;
args.usOverscanRight = (adjusted_mode->crtc_hdisplay -
mode->crtc_hdisplay) / 2;
- atom_execute_table(rdev->mode_info.atom_context, index,
(uint32_t *));
break;
case RMX_ASPECT:
a1 = mode->crtc_vdisplay * adjusted_mode->crtc_hdisplay;
@@ -69,17 +64,16 @@ static void atombios_overscan_setup(struct drm_crtc *crtc,
args.usOverscanLeft = (adjusted_mode->crtc_vdisplay -
(a1 / mode->crtc_hdisplay)) / 2;
args.usOverscanRight = (adjusted_mode->crtc_vdisplay -
(a1 / mode->crtc_hdisplay)) / 2;
}
- atom_execute_table(rdev->mode_info.atom_context, index,
(uint32_t *));
break;
case RMX_FULL:
default:
- args.usOverscanRight = 0;
- args.usOverscanLeft = 0;
- args.usOverscanBottom = 0;
- args.usOverscanTop = 0;
- atom_execute_table(rdev->mode_info.atom_context, index,
(uint32_t *));
+ args.usOverscanRight = radeon_crtc->h_border;
+ args.usOverscanLeft = radeon_crtc->h_border;
+ args.usOverscanBottom = radeon_crtc->v_border;
+ args.usOverscanTop = radeon_crtc->v_border;
break;
}
+ atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t
*));
}
static void atombios_scaler_setup(struct drm_crtc *crtc)
@@ -282,22 +276,22 @@ atombios_set_crtc_dtd_timing(struct drm_crtc *crtc,
u16 misc = 0;
memset(, 0, sizeof(args));
- args.usH_Size = cpu_to_le16(mode->crtc_hdisplay);
+ args.usH_Size = cpu_to_le16(mode->crtc_hdisplay -
(radeon_crtc->h_border * 2));
args.usH_Blanking_Time =
- cpu_to_le16(mode->crtc_hblank_end - mode->crtc_hdisplay);
- args.usV_Size = cpu_to_le16(mode->crtc_vdisplay);
+ cpu_to_le16(mode->crtc_hblank_end - mode->crtc_hdisplay +
(radeon_crtc->h_border * 2));
+ args.usV_Size = cpu_to_le16(mode->crtc_vdisplay -
(radeon_crtc->v_border * 2));
args.usV_Blanking_Time =
- cpu_to_le16(mode->crtc_vblank_end - mode->crtc_vdisplay);
+ cpu_to_le16(mode->crtc_vblank_end - mode->crtc_vdisplay +
(radeon_crtc->v_border * 2));
args.usH_SyncOffset =
- cpu_to_le16(mode->crtc_hsync_start - mode->crtc_hdisplay);
+ cpu_to_le16(mode->crtc_hsync_start - mode->crtc_hdisplay +
radeon_crtc->h_border);
args.usH_SyncWidth =
cpu_to_le16(mode->crtc_hsync_end - mode->crtc_hsync_start);
args.usV_SyncOffset =
- cpu_to_le16(mode->crtc_vsync_start - mode->crtc_vdisplay);
+ cpu_to_le16(mode->crtc_vsync_start - mode->crtc_vdisplay +
radeon_crtc->v_border);
args.usV_SyncWidth =
cpu_to_le16(mode->crtc_vsync_end - mode->crtc_vsync_start);
- /*args.ucH_Border = mode->hborder;*/
- /*args.ucV_Border = mode->vborder;*/
+ args.ucH_Border = radeon_crtc->h_border;
+ args.ucV_Border = radeon_crtc->v_border;
if (mode->flags & DRM_MODE_FLAG_NVSYNC)
misc |= ATOM_VSYNC_POLARITY;
@@ -1176,10 +1170,8 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc,
atombios_crtc_set_pll(crtc, adjusted_mode);
atombios_enable_ss(crtc);
- if (ASIC_IS_DCE4(rdev))
+
[PATCH 1/2] drm/radeon/kms: fix calculation of h/v scaling factors
Prior to this patch the code was dividing the src_v by the dst_h
and vice versa, rather than src_v/dst_v and src_h/dst_h.
This could lead to problems in the calculation of the display
watermarks.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_display.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 283beed..12a5414 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1073,11 +1073,13 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc
*crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_encoder *radeon_encoder;
bool first = true;
+ u32 src_v = 1, dst_v = 1;
+ u32 src_h = 1, dst_h = 1;
list_for_each_entry(encoder, >mode_config.encoder_list, head) {
- radeon_encoder = to_radeon_encoder(encoder);
if (encoder->crtc != crtc)
continue;
+ radeon_encoder = to_radeon_encoder(encoder);
if (first) {
/* set scaling */
if (radeon_encoder->rmx_type == RMX_OFF)
@@ -1087,6 +1089,10 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc
*crtc,
radeon_crtc->rmx_type =
radeon_encoder->rmx_type;
else
radeon_crtc->rmx_type = RMX_OFF;
+ src_v = crtc->mode.vdisplay;
+ dst_v = radeon_crtc->native_mode.vdisplay;
+ src_h = crtc->mode.hdisplay;
+ dst_h = radeon_crtc->native_mode.vdisplay;
/* copy native mode */
memcpy(_crtc->native_mode,
_encoder->native_mode,
@@ -1096,22 +1102,22 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc
*crtc,
if (radeon_crtc->rmx_type != radeon_encoder->rmx_type) {
/* WARNING: Right now this can't happen but
* in the future we need to check that scaling
-* are consistent accross different encoder
+* are consistent across different encoder
* (ie all encoder can work with the same
* scaling).
*/
- DRM_ERROR("Scaling not consistent accross
encoder.\n");
+ DRM_ERROR("Scaling not consistent across
encoder.\n");
return false;
}
}
}
if (radeon_crtc->rmx_type != RMX_OFF) {
fixed20_12 a, b;
- a.full = dfixed_const(crtc->mode.vdisplay);
- b.full = dfixed_const(radeon_crtc->native_mode.hdisplay);
+ a.full = dfixed_const(src_v);
+ b.full = dfixed_const(dst_v);
radeon_crtc->vsc.full = dfixed_div(a, b);
- a.full = dfixed_const(crtc->mode.hdisplay);
- b.full = dfixed_const(radeon_crtc->native_mode.vdisplay);
+ a.full = dfixed_const(src_h);
+ b.full = dfixed_const(dst_h);
radeon_crtc->hsc.full = dfixed_div(a, b);
} else {
radeon_crtc->vsc.full = dfixed_const(1);
--
1.7.1.1
[Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 --- Comment #3 from Casey Jones 2010-08-03 19:26:51 PDT --- This is what I got. f8d81c31cee30821da3aab331a57f484f6a07a5d is the first bad commit commit f8d81c31cee30821da3aab331a57f484f6a07a5d Author: Nick Bowler Date: Wed Jul 14 12:01:49 2010 -0400 dri2: Track event mask in client code. When direct rendering is being used, DRI2 BufferSwapComplete events are sent unconditionally to clients, even if they haven't been requested. This causes error messages to be printed by every freeglut application of the form freeglut (./gears): Unknown X event type: 104 and might confuse other clients. This is a fixed up version of the patch by Jesse Barnes, which drops BufferSwapComplete events if they are not requested by clients. Fixes fdo bug 27962. Signed-off-by: Nick Bowler Signed-off-by: Jesse Barnes -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 --- Comment #2 from Alex Deucher 2010-08-03 18:17:09 PDT --- Can you bisect mesa to see what commit broke it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 --- Comment #1 from Casey Jones 2010-08-03 18:07:16 PDT --- I also tried r600g in my chroot just for kicks, and it crashes as well. Plain old glxgears worked, but the Lwjgl version does not. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29393] New: R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 Summary: R600: libGL crashes using Lwjgl Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: jonescaseyb at gmail.com Created an attachment (id=37560) --> (https://bugs.freedesktop.org/attachment.cgi?id=37560) Full Java error log Lwjgl is a Java binding to OpenGL. Any Lwjgl application or demo crashes libGL.so and forces the Java VM to abort. This is the output from Java: Could not locate symbol glXCreateContextAttribsARB # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb00434a8, pid=19189, tid=2954230640 # # JRE version: 6.0_21-b06 # Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 ) # Problematic frame: # C [libGL.so.1+0x424a8] # # An error report file with more information is saved as: # /root/hs_err_pid19189.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # I'm attaching the mentioned hs_err_pid19189.log I'm using the latest git version of Mesa with a Radeon 4850. KMS is enabled. I'm using the Sun/Oracle JDK, not OpenJDK or IcedTea. I've confirmed that this works on Mesa 7.8.2. It worked on earlier version of 7.9, but sometime in the last few weeks it stopped working. I've been working on my own Lwjgl application, so when I ran into this error I downgraded Mesa to 7.8, but I still have 7.9 in a chroot which I can do further testing on. There are demo applications here: http://lwjgl.org/demos.php I used GLGears. To run a jnlp file from the command line: javaws test.opengl.Gears Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29390] Radeon KMS - Bootup - First Text At 640x480 - Then Blank Screen - Then FB
https://bugs.freedesktop.org/show_bug.cgi?id=29390 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #1 from Alex Deucher 2010-08-03 15:33:37 PDT --- You might try a different distro. This isn't really a driver bug, more a distro start up configuration issue. The latest fedora and ubuntu releases go straight from from the bios post screen to the plymouth boot screen. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29390] Radeon KMS - Bootup - First Text At 640x480 - Then Blank Screen - Then FB
https://bugs.freedesktop.org/show_bug.cgi?id=29390 Alex Deucher changed: What|Removed |Added Product|xorg|DRI Version|7.5 |unspecified Component|Driver/radeonhd |DRM/Radeon AssignedTo|eich at pdx.freedesktop.org|dri-devel at lists.freedesktop ||.org QAContact|xorg-team at lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28628] [r300g] ARB_vp: error: relative address offset too large (163)
https://bugs.freedesktop.org/show_bug.cgi?id=28628 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Marek Ol??k 2010-08-03 15:25:12 PDT --- Fixed by commit 0614006d090902324149387ec150231b647928fd. Closing.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29303] [r300g] compiz segfaults when resizing windows
https://bugs.freedesktop.org/show_bug.cgi?id=29303 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Ol??k 2010-08-03 15:20:52 PDT --- Fixed by commit afbf446de5ad91743e2e2a76799bd87f3eed5f9a. Closing.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29389] [r300g] [bisected] hard locks in openarena with kernel 2.6.35
https://bugs.freedesktop.org/show_bug.cgi?id=29389 Giacomo Perale changed: What|Removed |Added Attachment #37557|text/x-log |text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 7/7] drm/edid: Add modes from CEA short video descriptor codes
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 188 +++-
drivers/gpu/drm/drm_edid_modes.h | 260 ++
2 files changed, 389 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 817ffab..44fd754 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1223,53 +1223,23 @@ add_cvt_modes(struct drm_connector *connector, struct
edid *edid)
return closure.modes;
}
-static void
-do_detailed_mode(struct detailed_timing *timing, void *c)
+/* XXX assumes there's only one */
+static u8 *
+find_cea_block(struct edid *edid)
{
- struct detailed_mode_closure *closure = c;
- struct drm_display_mode *newmode;
-
- if (timing->pixel_clock) {
- newmode = drm_mode_detailed(closure->connector->dev,
- closure->edid, timing,
- closure->quirks);
- if (!newmode)
- return;
+ int i;
+ u8 *ret;
- if (closure->preferred)
- newmode->type |= DRM_MODE_TYPE_PREFERRED;
+ if (!edid)
+ return NULL;
- drm_mode_probed_add(closure->connector, newmode);
- closure->modes++;
- closure->preferred = 0;
+ for (i = 0; i < edid->extensions; i++) {
+ ret = (u8 *)edid + EDID_LENGTH * (i + 1);
+ if (ret[0] == CEA_EXT)
+ return ret;
}
-}
-
-/*
- * add_detailed_modes - Add modes from detailed timings
- * @connector: attached connector
- * @edid: EDID block to scan
- * @quirks: quirks to apply
- */
-static int
-add_detailed_modes(struct drm_connector *connector, struct edid *edid,
- u32 quirks)
-{
- struct detailed_mode_closure closure = {
- connector,
- edid,
- 1,
- quirks,
- 0
- };
-
- if (closure.preferred && !version_greater(edid, 1, 3))
- closure.preferred =
- (edid->features & DRM_EDID_FEATURE_PREFERRED_TIMING);
-
- drm_for_each_detailed_block((u8 *)edid, do_detailed_mode, );
- return closure.modes;
+ return NULL;
}
#define HDMI_IDENTIFIER 0x000C03
@@ -1283,25 +1253,13 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
*/
bool drm_detect_hdmi_monitor(struct edid *edid)
{
- char *edid_ext = NULL;
+ u8 *edid_ext = NULL;
int i, hdmi_id;
int start_offset, end_offset;
bool is_hdmi = false;
- /* No EDID or EDID extensions */
- if (edid == NULL || edid->extensions == 0)
- goto end;
-
- /* Find CEA extension */
- for (i = 0; i < edid->extensions; i++) {
- edid_ext = (char *)edid + EDID_LENGTH * (i + 1);
- /* This block is CEA extension */
- if (edid_ext[0] == 0x02)
- break;
- }
-
- if (i == edid->extensions)
- goto end;
+ if (!(edid_ext = find_cea_block(edid)))
+ return false;
/* Data block offset in CEA extension block */
start_offset = 4;
@@ -1325,11 +1283,116 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
}
}
-end:
return is_hdmi;
}
EXPORT_SYMBOL(drm_detect_hdmi_monitor);
+static int
+add_cea_modes(struct drm_connector *connector, struct edid *edid)
+{
+ u8 *block = find_cea_block(edid);
+ u8 *b, *end;
+ int modes = 0;
+
+ if (!block)
+ return 0;
+
+ if (block[0x01] < 3)
+ return 0; /* SVDs not specified yet */
+
+ b = block;
+ end = block + block[0x02];
+
+ while (b < end) {
+ u8 header = *b;
+ u8 length = header & 0x1f;
+ u8 tag = (header & 0xe0) >> 5;
+
+ if (tag == 2) {
+ int i, m;
+ struct drm_display_mode *mode, *newmode;
+ for (i = 1; i <= length; i++) {
+ m = b[i] & 0x7f;
+ if (m > cea_num_modes) /* XXX warn */
+ continue;
+
+ /*
+* Don't add modes that require pixel repeat,
+* yet. The driver needs to be aware of this
+* and we don't have a mechanism for that.
+*
+* This prunes some modes that don't need
+* repeat; oh well.
+*/
+ mode = _modes[m];
+ if (mode->hdisplay == 1440 ||
+ mode->hdisplay == 2880)
+
[PATCH 6/7] drm/edid: Re-add the reduced blanking modes to the DMT table
Also fix up mode generation to only add RB modes from DMT if it looks
like an RB-capable monitor.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 43 +
drivers/gpu/drm/drm_edid_modes.h | 98 --
drivers/gpu/drm/drm_fb_helper.c |2 +-
include/drm/drm_crtc.h |2 +-
4 files changed, 118 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 66b8b5c..817ffab 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -433,8 +433,17 @@ static void edid_fixup_preferred(struct drm_connector
*connector,
preferred_mode->type |= DRM_MODE_TYPE_PREFERRED;
}
-struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
- int hsize, int vsize, int fresh)
+static bool
+mode_is_rb(struct drm_display_mode *mode)
+{
+ return (mode->htotal - mode->hdisplay == 160) &&
+ (mode->hsync_end - mode->hdisplay == 80) &&
+ (mode->hsync_end - mode->hsync_start == 32) &&
+ (mode->vsync_start - mode->vdisplay == 3);
+}
+
+struct drm_display_mode *
+drm_mode_find_dmt(struct drm_device *dev, int hsize, int vsize, int r, bool rb)
{
int i;
struct drm_display_mode *ptr, *mode;
@@ -444,7 +453,8 @@ struct drm_display_mode *drm_mode_find_dmt(struct
drm_device *dev,
ptr = _dmt_modes[i];
if (hsize == ptr->hdisplay &&
vsize == ptr->vdisplay &&
- fresh == drm_mode_vrefresh(ptr)) {
+ r == drm_mode_vrefresh(ptr) &&
+ rb == mode_is_rb(ptr)) {
/* get the expected default mode */
mode = drm_mode_duplicate(dev, ptr);
break;
@@ -694,7 +704,12 @@ drm_mode_std(struct drm_connector *connector, struct edid
*edid,
}
/* check whether it can be found in default mode table */
- mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate);
+ if (drm_monitor_supports_rb(edid)) {
+ mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, 1);
+ if (mode)
+ return mode;
+ }
+ mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, 0);
if (mode)
return mode;
@@ -722,7 +737,8 @@ drm_mode_std(struct drm_connector *connector, struct edid
*edid,
}
break;
case LEVEL_CVT:
- mode = drm_cvt_mode(dev, hsize, vsize, vrefresh_rate, 0, 0,
+ mode = drm_cvt_mode(dev, hsize, vsize, vrefresh_rate,
+ drm_monitor_supports_rb(edid), 0,
false);
break;
}
@@ -874,15 +890,6 @@ static struct drm_display_mode *drm_mode_detailed(struct
drm_device *dev,
}
static bool
-mode_is_rb(struct drm_display_mode *mode)
-{
- return (mode->htotal - mode->hdisplay == 160) &&
- (mode->hsync_end - mode->hdisplay == 80) &&
- (mode->hsync_end - mode->hsync_start == 32) &&
- (mode->vsync_start - mode->vdisplay == 3);
-}
-
-static bool
mode_in_hsync_range(struct drm_display_mode *mode, struct edid *edid, u8 *t)
{
int hsync, hmin, hmax;
@@ -957,10 +964,6 @@ mode_in_range(struct drm_display_mode *mode, struct edid
*edid,
return true;
}
-/*
- * XXX If drm_dmt_modes ever regrows the CVT-R modes (and it will) this will
- * need to account for them.
- */
static int
drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
struct detailed_timing *timing)
@@ -1025,8 +1028,8 @@ drm_est3_modes(struct drm_connector *connector, struct
detailed_timing *timing)
mode = drm_mode_find_dmt(connector->dev,
est3_modes[m].w,
est3_modes[m].h,
-est3_modes[m].r
-/*, est3_modes[m].rb
*/);
+est3_modes[m].r,
+est3_modes[m].rb);
if (mode) {
drm_mode_probed_add(connector, mode);
modes++;
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 6eb7592..19690cd 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -27,11 +27,7 @@
#include "drmP.h"
#include "drm_edid.h"
-/*
- * Autogenerated from the DMT spec.
- * This table is copied from xfree86/modes/xf86EdidModes.c.
- * But the mode with Reduced blank feature is deleted.
- */
+/*
[PATCH 5/7] drm/edid: Split mode lists out to their own header for readability
... of the code, not of the mode lists.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 354 +---
drivers/gpu/drm/drm_edid_modes.h | 380 ++
2 files changed, 381 insertions(+), 353 deletions(-)
create mode 100644 drivers/gpu/drm/drm_edid_modes.h
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3f59e36..66b8b5c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -33,6 +33,7 @@
#include
#include "drmP.h"
#include "drm_edid.h"
+#include "drm_edid_modes.h"
#define version_greater(edid, maj, min) \
(((edid)->version > (maj)) || \
@@ -386,7 +387,6 @@ static u32 edid_get_quirks(struct edid *edid)
#define MODE_SIZE(m) ((m)->hdisplay * (m)->vdisplay)
#define MODE_REFRESH_DIFF(m,r) (abs((m)->vrefresh - target_refresh))
-
/**
* edid_fixup_preferred - set preferred modes based on quirk list
* @connector: has mode list to fix up
@@ -433,245 +433,6 @@ static void edid_fixup_preferred(struct drm_connector
*connector,
preferred_mode->type |= DRM_MODE_TYPE_PREFERRED;
}
-/*
- * Add the Autogenerated from the DMT spec.
- * This table is copied from xfree86/modes/xf86EdidModes.c.
- * But the mode with Reduced blank feature is deleted.
- */
-static struct drm_display_mode drm_dmt_modes[] = {
- /* 640x350 at 85Hz */
- { DRM_MODE("640x350", DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
- 736, 832, 0, 350, 382, 385, 445, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
- /* 640x400 at 85Hz */
- { DRM_MODE("640x400", DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
- 736, 832, 0, 400, 401, 404, 445, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 720x400 at 85Hz */
- { DRM_MODE("720x400", DRM_MODE_TYPE_DRIVER, 35500, 720, 756,
- 828, 936, 0, 400, 401, 404, 446, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 640x480 at 60Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
- 752, 800, 0, 480, 489, 492, 525, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
- /* 640x480 at 72Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
- 704, 832, 0, 480, 489, 492, 520, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
- /* 640x480 at 75Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 656,
- 720, 840, 0, 480, 481, 484, 500, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
- /* 640x480 at 85Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 36000, 640, 696,
- 752, 832, 0, 480, 481, 484, 509, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
- /* 800x600 at 56Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 36000, 800, 824,
- 896, 1024, 0, 600, 601, 603, 625, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 800x600 at 60Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 4, 800, 840,
- 968, 1056, 0, 600, 601, 605, 628, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 800x600 at 72Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 5, 800, 856,
- 976, 1040, 0, 600, 637, 643, 666, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 800x600 at 75Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 49500, 800, 816,
- 896, 1056, 0, 600, 601, 604, 625, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 800x600 at 85Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 56250, 800, 832,
- 896, 1048, 0, 600, 601, 604, 631, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 848x480 at 60Hz */
- { DRM_MODE("848x480", DRM_MODE_TYPE_DRIVER, 33750, 848, 864,
- 976, 1088, 0, 480, 486, 494, 517, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
- /* 1024x768 at 43Hz, interlace */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 44900, 1024, 1032,
- 1208, 1264, 0, 768, 768, 772, 817, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
- DRM_MODE_FLAG_INTERLACE) },
- /* 1024x768 at 60Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 65000, 1024, 1048,
- 1184, 1344, 0, 768, 771, 777, 806, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
- /* 1024x768 at 70Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 75000, 1024, 1048,
- 1184, 1328, 0, 768, 771, 777, 806, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
- /*
[PATCH 4/7] drm/edid: Rewrite mode parse to use the generic detailed block walk
This brings us in line with the EDID spec recommendation for mode
priority sorting. We still don't extract all the modes we could from
VTB, but VTB is so rare in the wild that I'm not really concerned.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 526 +++-
1 files changed, 273 insertions(+), 253 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9299dd6..3f59e36 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -34,6 +34,10 @@
#include "drmP.h"
#include "drm_edid.h"
+#define version_greater(edid, maj, min) \
+ (((edid)->version > (maj)) || \
+((edid)->version == (maj) && (edid)->revision > (min)))
+
#define EDID_EST_TIMINGS 16
#define EDID_STD_TIMINGS 8
#define EDID_DETAILED_TIMINGS 4
@@ -62,6 +66,13 @@
/* use +hsync +vsync for detailed mode */
#define EDID_QUIRK_DETAILED_SYNC_PP(1 << 6)
+struct detailed_mode_closure {
+ struct drm_connector *connector;
+ struct edid *edid;
+ bool preferred;
+ u32 quirks;
+ int modes;
+};
#define LEVEL_DMT 0
#define LEVEL_GTF 1
@@ -1101,117 +1112,6 @@ static struct drm_display_mode
*drm_mode_detailed(struct drm_device *dev,
return mode;
}
-/*
- * Detailed mode info for the EDID "established modes" data to use.
- */
-static struct drm_display_mode edid_est_modes[] = {
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 4, 800, 840,
- 968, 1056, 0, 600, 601, 605, 628, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 800x600
at 60Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 36000, 800, 824,
- 896, 1024, 0, 600, 601, 603, 625, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 800x600
at 56Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 656,
- 720, 840, 0, 480, 481, 484, 500, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 640x480
at 75Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
- 704, 832, 0, 480, 489, 491, 520, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 640x480
at 72Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 30240, 640, 704,
- 768, 864, 0, 480, 483, 486, 525, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 640x480
at 67Hz */
- { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25200, 640, 656,
- 752, 800, 0, 480, 490, 492, 525, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 640x480
at 60Hz */
- { DRM_MODE("720x400", DRM_MODE_TYPE_DRIVER, 35500, 720, 738,
- 846, 900, 0, 400, 421, 423, 449, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 720x400
at 88Hz */
- { DRM_MODE("720x400", DRM_MODE_TYPE_DRIVER, 28320, 720, 738,
- 846, 900, 0, 400, 412, 414, 449, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 720x400
at 70Hz */
- { DRM_MODE("1280x1024", DRM_MODE_TYPE_DRIVER, 135000, 1280, 1296,
- 1440, 1688, 0, 1024, 1025, 1028, 1066, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 1280x1024
at 75Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 78800, 1024, 1040,
- 1136, 1312, 0, 768, 769, 772, 800, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 1024x768
at 75Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 75000, 1024, 1048,
- 1184, 1328, 0, 768, 771, 777, 806, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 1024x768
at 70Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 65000, 1024, 1048,
- 1184, 1344, 0, 768, 771, 777, 806, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 1024x768
at 60Hz */
- { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER,44900, 1024, 1032,
- 1208, 1264, 0, 768, 768, 776, 817, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE) }, /* 1024x768 at 43Hz */
- { DRM_MODE("832x624", DRM_MODE_TYPE_DRIVER, 57284, 832, 864,
- 928, 1152, 0, 624, 625, 628, 667, 0,
- DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) }, /* 832x624
at 75Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 49500, 800, 816,
- 896, 1056, 0, 600, 601, 604, 625, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 800x600
at 75Hz */
- { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 5, 800, 856,
- 976, 1040, 0, 600, 637, 643, 666, 0,
- DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) }, /* 800x600
at 72Hz */
- { DRM_MODE("1152x864", DRM_MODE_TYPE_DRIVER, 108000,
[PATCH 3/7] drm/edid: Add detailed block walk for VTB extensions
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1bc15a8..9299dd6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -712,6 +712,19 @@ cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void
*closure)
}
static void
+vtb_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
+{
+ unsigned int i, n = min((int)ext[0x02], 6);
+ u8 *det_base = ext + 5;
+
+ if (ext[0x01] != 1)
+ return; /* unknown version */
+
+ for (i = 0; i < n; i++)
+ cb((struct detailed_timing *)(det_base + 18 * i), closure);
+}
+
+static void
drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb, void *closure)
{
int i;
@@ -729,6 +742,9 @@ drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb,
void *closure)
case CEA_EXT:
cea_for_each_detailed_block(ext, cb, closure);
break;
+ case VTB_EXT:
+ vtb_for_each_detailed_block(ext, cb, closure);
+ break;
default:
break;
}
--
1.7.2
[PATCH 2/7] drm/edid: Add detailed block walk for CEA extensions
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 38 +-
include/drm/drm_edid.h |6 ++
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e668084..1bc15a8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -685,6 +685,33 @@ EXPORT_SYMBOL(drm_mode_find_dmt);
typedef void detailed_cb(struct detailed_timing *timing, void *closure);
static void
+cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
+{
+ int i, n = 0;
+ u8 rev = ext[0x01], d = ext[0x02];
+ u8 *det_base = ext + d;
+
+ switch (rev) {
+ case 0:
+ /* can't happen */
+ return;
+ case 1:
+ /* have to infer how many blocks we have, check pixel clock */
+ for (i = 0; i < 6; i++)
+ if (det_base[18*i] || det_base[18*i+1])
+ n++;
+ break;
+ default:
+ /* explicit count */
+ n = min(ext[0x03] & 0x0f, 6);
+ break;
+ }
+
+ for (i = 0; i < n; i++)
+ cb((struct detailed_timing *)(det_base + 18 * i), closure);
+}
+
+static void
drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb, void *closure)
{
int i;
@@ -696,7 +723,16 @@ drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb,
void *closure)
for (i = 0; i < EDID_DETAILED_TIMINGS; i++)
cb(&(edid->detailed_timings[i]), closure);
- /* XXX extension block walk */
+ for (i = 1; i <= raw_edid[0x7e]; i++) {
+ u8 *ext = raw_edid + (i * EDID_LENGTH);
+ switch (*ext) {
+ case CEA_EXT:
+ cea_for_each_detailed_block(ext, cb, closure);
+ break;
+ default:
+ break;
+ }
+ }
}
static void
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 39e2cc5..5881fad 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -28,6 +28,12 @@
#define EDID_LENGTH 128
#define DDC_ADDR 0x50
+#define CEA_EXT0x02
+#define VTB_EXT0x10
+#define DI_EXT 0x40
+#define LS_EXT 0x50
+#define MI_EXT 0x60
+
struct est_timings {
u8 t1;
u8 t2;
--
1.7.2
[PATCH 1/7] drm: Remove unused fields from drm_display_info
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/drm_edid.c | 15 ---
include/drm/drm_crtc.h | 35 +--
2 files changed, 1 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83d8072..e668084 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1655,23 +1655,8 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
edid_fixup_preferred(connector, quirks);
- connector->display_info.serration_vsync = (edid->input &
DRM_EDID_INPUT_SERRATION_VSYNC) ? 1 : 0;
- connector->display_info.sync_on_green = (edid->input &
DRM_EDID_INPUT_SYNC_ON_GREEN) ? 1 : 0;
- connector->display_info.composite_sync = (edid->input &
DRM_EDID_INPUT_COMPOSITE_SYNC) ? 1 : 0;
- connector->display_info.separate_syncs = (edid->input &
DRM_EDID_INPUT_SEPARATE_SYNCS) ? 1 : 0;
- connector->display_info.blank_to_black = (edid->input &
DRM_EDID_INPUT_BLANK_TO_BLACK) ? 1 : 0;
- connector->display_info.video_level = (edid->input &
DRM_EDID_INPUT_VIDEO_LEVEL) >> 5;
- connector->display_info.digital = (edid->input &
DRM_EDID_INPUT_DIGITAL) ? 1 : 0;
connector->display_info.width_mm = edid->width_cm * 10;
connector->display_info.height_mm = edid->height_cm * 10;
- connector->display_info.gamma = edid->gamma;
- connector->display_info.gtf_supported = (edid->features &
DRM_EDID_FEATURE_DEFAULT_GTF) ? 1 : 0;
- connector->display_info.standard_color = (edid->features &
DRM_EDID_FEATURE_STANDARD_COLOR) ? 1 : 0;
- connector->display_info.display_type = (edid->features &
DRM_EDID_FEATURE_DISPLAY_TYPE) >> 3;
- connector->display_info.active_off_supported = (edid->features &
DRM_EDID_FEATURE_PM_ACTIVE_OFF) ? 1 : 0;
- connector->display_info.suspend_supported = (edid->features &
DRM_EDID_FEATURE_PM_SUSPEND) ? 1 : 0;
- connector->display_info.standby_supported = (edid->features &
DRM_EDID_FEATURE_PM_STANDBY) ? 1 : 0;
- connector->display_info.gamma = edid->gamma;
return num_modes;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 93a1a31..606eb93 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -190,49 +190,16 @@ enum subpixel_order {
*/
struct drm_display_info {
char name[DRM_DISPLAY_INFO_LEN];
- /* Input info */
- bool serration_vsync;
- bool sync_on_green;
- bool composite_sync;
- bool separate_syncs;
- bool blank_to_black;
- unsigned char video_level;
- bool digital;
+
/* Physical size */
unsigned int width_mm;
unsigned int height_mm;
- /* Display parameters */
- unsigned char gamma; /* FIXME: storage format */
- bool gtf_supported;
- bool standard_color;
- enum {
- monochrome = 0,
- rgb,
- other,
- unknown,
- } display_type;
- bool active_off_supported;
- bool suspend_supported;
- bool standby_supported;
-
- /* Color info FIXME: storage format */
- unsigned short redx, redy;
- unsigned short greenx, greeny;
- unsigned short bluex, bluey;
- unsigned short whitex, whitey;
-
/* Clock limits FIXME: storage format */
unsigned int min_vfreq, max_vfreq;
unsigned int min_hfreq, max_hfreq;
unsigned int pixel_clock;
- /* White point indices FIXME: storage format */
- unsigned int wpx1, wpy1;
- unsigned int wpgamma1;
- unsigned int wpx2, wpy2;
- unsigned int wpgamma2;
-
enum subpixel_order subpixel_order;
char *raw_edid; /* if any */
--
1.7.2
[RFC] EDID parser updates
Some cosmetic cleanups, and then some changes to add more modes than we were before. 6 and 7 are the particularly touchy bits; I'd like a bit of volunteer testing before landing it on drm-core-next, particularly on HDMI monitors. Note that this is mostly about doing more with things other than your preferred mode, so be sure to check the mode list you get from RANDR for changes and try all the new ones (if any). - ajax
[Bug 29389] New: [r300g] [bisected] hard locks in openarena with kernel 2.6.35
https://bugs.freedesktop.org/show_bug.cgi?id=29389 Summary: [r300g] [bisected] hard locks in openarena with kernel 2.6.35 Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: ghepeu at virgilio.it Created an attachment (id=37557) --> (https://bugs.freedesktop.org/attachment.cgi?id=37557) git-bisect.log Yesterday I upgraded to kernel 2.6.35 and I had a lockup after playing for a few second at openarena. The day before I had played for a few minutes without any issue (testing r300g) so I immediately suspected the kernel. I'm using a radeon x550 (rv370) with yesterday git snapshot of mesa and xf86-video-ati and xorg-server 1.8.2. Both r300c/DRI/UMS and r300c/DRI2/KMS dont' seem to suffer from the issue, only gallium. Nothing unusual in the logs. I bisected from 2.6.34 (good) to 2.6.35 (bad) and git bisect pointed to commit eb1f8e4f3be898df808e2dfc131099f5831d491d eb1f8e4f3be898df808e2dfc131099f5831d491d is the first bad commit commit eb1f8e4f3be898df808e2dfc131099f5831d491d Author: Dave Airlie Date: Fri May 7 06:42:51 2010 + drm/fbdev: rework output polling to be back in the core. (v4) After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls v4: config lock was a bit agressive, only needed around connector list reading. otherwise it could re-enter. glisse: discard drm_helper_hpd_irq_event v3: Reviewed-by: Michel D??nzer Signed-off-by: Dave Airlie :04 04 01a1bf1ae4e06bfd3ae9ae67b5b5059e964f5ae4 041231a5c060e531ce0d8127c6f7abc79c14ce76 Mdrivers :04 04 b67fd6698fa239d26ca9fa2296ea2403e1eaaf1c cadb905c6d8647313107790ce8b681f4611ee726 Minclude I had to skip a few revisions because opengl didn't work at all and one revision I'm not exactly sure it crashed for the same issue (the symptoms were slightly different, it crashed after maybe two minutes instead of 5-30s) so I'm not sure that that's the real culprit. The bisection run took me a few hours and a lot of reboots, so I'm not exactly eager to try it again... The full git bisect log is attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #10 from Alex Deucher 2010-08-03 11:56:42 PDT --- (In reply to comment #9) > I am awfully sorry, but I am not familiar with git/git-bitsect. > Of course I will try every patch you can over and give you as much as possible > details about the effect. It's very easy. Assuming you have a git tree checked out: git bisect start git bisect good v2.6.34 git bisect bad v2.6.35 After that git will walk you through the rest. It will check out the appropriate commit, at which point you can compile it, test it, and if it's good, run: git bisect good and if it's bad: git bisect bad and git will select the next commit and the process continues. If there is a commit that doesn't boot or build, you can skip it with: git bisect skip See this page for more info: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #15 from Alex Deucher 2010-08-03 11:56:16 PDT --- (In reply to comment #12) > Alex, I am pretty much a 'newb' when it comes to git and the kernel in general > and currently git is making my brain hurt severely. When I have the time I > will > read up more on git and try and work out an easy way to exclude unrelated > commits that break my kernel and include bug fix commits that allow me to > bisect this issue successfully. Any pointers to articles/howtos on dealing > with > this specific kind of issue with git? If there is a commit that doesn't boot or build, you can skip it with: git bisect skip and continue the bisection. See this page for more info: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #9 from peterle at hottemptation.org 2010-08-03 11:41:29 PDT --- I am awfully sorry, but I am not familiar with git/git-bitsect. Of course I will try every patch you can over and give you as much as possible details about the effect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #8 from Alex Deucher 2010-08-03 11:30:16 PDT --- Can you use git bisect between 2.6.34 and 2.6.35 and track down which commit causes the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 24973] [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
https://bugs.freedesktop.org/show_bug.cgi?id=24973 --- Comment #18 from Alex Deucher 2010-08-03 11:28:11 PDT --- (In reply to comment #17) > Great, the Ignore option did the trick! Thanks a bunch! > > While it still feels like a bug, I'd understand if nothing can be done to it > so > we might just as well close it as WONTFIX. You guys decide... "Ignore" means you won't be able to use the connector at all during the life of the xserver. If the Disable/Enable options are broken, that's most likely a xserver issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #7 from peterle at hottemptation.org 2010-08-03 11:16:04 PDT --- Notice: With the patch resuspend need ~7 seconds. Withtout the patch resuspend needs ~ 3 seconds. With old kernel 2.6.34 resuspend need ~ 1 second. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #6 from peterle at hottemptation.org 2010-08-03 11:13:58 PDT --- Just to notice: Switch from X11 to TTY1-6 is also still affected. Switch from TTY1-6 to X11 is, like before, normal - this means: immediately Switching from a TTY without access to /dev/fb* to a TTY with access (running fbida or mplayer) is immediately. Switching from a TTY with access (running fbida or mplayer) is slow. Closing fbida with "q" is also slow. Closing of mplayer with "strg+c" is not possible. mplayer is it totally freaking out. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #5 from peterle at hottemptation.org 2010-08-03 11:08:15 PDT --- Thank you for your help. But the answer is "No". I doesn't fix the slow resuspend (instead it feels slower, no wonder...) and also not the slow TTY-Switch between the terminals if /def/fb* is used. Both problems still exist. To be honestly. Making a delay just longer doesn't look like a well solution. Here is my dmesg output, maybe it helps (last lines): PM: early resume of devices complete after 0.753 msecs ehci_hcd :00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 ehci_hcd :00:1a.0: setting latency timer to 64 HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel :00:1b.0: setting latency timer to 64 ehci_hcd :00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 pci :00:1e.0: setting latency timer to 64 ehci_hcd :00:1d.0: setting latency timer to 64 HDA Intel :00:1b.0: irq 45 for MSI/MSI-X ahci :00:1f.2: setting latency timer to 64 pci :00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18 radeon :02:00.0: setting latency timer to 64 HDA Intel :02:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 HDA Intel :02:00.1: setting latency timer to 64 ath9k :05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 HDA Intel :02:00.1: irq 46 for MSI/MSI-X sd 0:0:0:0: [sda] Starting disk [drm] Clocks initialized ! [drm] ring test succeeded in 1 usecs [drm] ib test succeeded in 0 usecs usb 2-1.5: reset high speed USB device using ehci_hcd and address 3 ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/133 [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing CB5A (len 67, WS 0, PS 0) @ 0xCB89 PM: resume of devices complete after 7531.240 msecs Restarting tasks ... done. video LNXVIDEO:00: Restoring backlight state [ pm_notifier_block : 170 ] event :4 atl1c :03:00.0: irq 47 for MSI/MSI-X ADDRCONF(NETDEV_UP): eth0: link is not ready ADDRCONF(NETDEV_UP): wlan0: link is not ready EXT4-fs (sda1): re-mounted. Opts: commit=0 EXT4-fs (sda2): re-mounted. Opts: commit=0 ath9k: Two wiphys trying to scan at the same time ath9k: Two wiphys trying to scan at the same time wlan0: deauthenticating from 00:1c:10:36:48:42 by local choice (reason=3) wlan0: authenticate with 00:1c:10:36:48:42 (try 1) wlan0: authenticated wlan0: associate with 00:1c:10:36:48:42 (try 1) wlan0: RX AssocResp from 00:1c:10:36:48:42 (capab=0x431 status=0 aid=1) wlan0: associated ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: no IPv6 routers present -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 24973] [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
https://bugs.freedesktop.org/show_bug.cgi?id=24973 --- Comment #17 from Marius Groeger 2010-08-03 10:42:11 PDT --- (In reply to comment #16) > (In reply to comment #15) > > Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are > > accepted and confirmed in Xorg.0.log, but the resolution is still switch to > > 800x600. For some reason the probing seems to override the xorg.conf > > setting. > > Any further ideas? > Two things: > 1) Option "Ignore" "true" in xorg.conf for your S-Video port > 2) or try adding "radeon.tv=0" to your kernel commandline. Great, the Ignore option did the trick! Thanks a bunch! While it still feels like a bug, I'd understand if nothing can be done to it so we might just as well close it as WONTFIX. You guys decide... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27901] GLSL cos/sin functions broken on Mesa R600 driver
https://bugs.freedesktop.org/show_bug.cgi?id=27901 Alain Perrot changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #24 from Alain Perrot 2010-08-03 10:05:39 PDT --- I've seen that Andre's patch has been committed to Mesa repository (commit d6a5f94ea4d03b05c434fcad125d1f9c50c638e8), so I'm closing this bug as fixed. Thanks again! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29355] M92 : Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=29355 --- Comment #4 from Alex Deucher 2010-08-03 09:27:04 PDT --- There's no radeon info in the dmesg. What are the pci ids for your card? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #4 from Alex Deucher 2010-08-03 08:50:40 PDT --- Did the patch in bug 27744 help? If not, can you use git bisect between 2.6.34 and 2.6.35 and track down which commit causes the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bugme-new] [Bug 16488] New: [i915] Framebuffer ID error after suspend/hibernate leading to X crash
On Tue, Aug 3, 2010 at 12:25 AM, Chris Wilson
wrote:
> On Mon, 2 Aug 2010 16:55:03 -0700, Andrew Morton linux-foundation.org> wrote:
>>
>> (switched to email. ?Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Sun, 1 Aug 2010 08:55:49 GMT
>> bugzilla-daemon at bugzilla.kernel.org wrote:
>>
>> > https://bugzilla.kernel.org/show_bug.cgi?id=16488
>>
>> Innocuous-looking one-liner is said to have made Milan's X server even
>> worse than normal.
>
> We go from a random OOPS to a consistent error (and a failing userspace).
> It sounds more likely that we have uncovered a real bug, probably in
> the ddx.
I can't really imagine that that one-liner made the difference. Not
under any normal load. I suspect it just changes some allocation
pattern very subtly, and then the memory scribble (or whatever) that
really causes the bug perhaps changes.
The original oops reported in launchpad was
BUG: unable to handle kernel NULL pointer dereference at 0108
IP: [] intel_release_load_detect_pipe+0x27/0xb0 [i915]
and as far as I can tell, that's due to a load off a NULL crtc, here:
struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
the disassembly is
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 ec 14sub$0x14,%esp
6: 89 5d f4mov%ebx,-0xc(%ebp)
9: 89 75 f8mov%esi,-0x8(%ebp)
c: 89 7d fcmov%edi,-0x4(%ebp)
f: 0f 1f 44 00 00 nopl 0x0(%eax,%eax,1)
14: 8b b0 ec 02 00 00 mov0x2ec(%eax),%esi # crtc = encoder->crtc
1a: 89 c3 mov%eax,%ebx
1c: 8b 80 f4 02 00 00 mov0x2f4(%eax),%eax # dev = encoder->dev
22: 89 d7 mov%edx,%edi
24: 89 45 f0mov%eax,-0x10(%ebp)
27:* 8b 8e 08 01 00 00 mov0x108(%esi),%ecx <-- trapping
instruction (crtc_funcs = crtc->helper_private)
2d: 80 bb 04 03 00 00 00cmpb $0x0,0x304(%ebx) #
intel_encoder->load_detect_temp
34: 75 2a jne0x60
36: 0f b6 46 18 movzbl 0x18(%esi),%eax # crtc->enabled
3a: 84 c0 test %al,%al
in case anybody cares. However, I have no idea how ctrc would be NULL
in the first place there, it comes from
struct drm_encoder *encoder = _encoder->enc;
...
struct drm_crtc *crtc = encoder->crtc;
and I don't know the setup code. It _does_ strike me that the C code does:
...
struct drm_crtc *crtc = encoder->crtc;
struct drm_encoder_helper_funcs *encoder_funcs =
encoder->helper_private;
struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
if (intel_encoder->load_detect_temp) {
encoder->crtc = NULL;
connector->encoder = NULL;
where I react to the fact that first we load "crtc = encoder->crtc"
and dereference that pointer (crtc->helper_private) without checking
whether it might be NULL, and then in some case we clear that field
(encoder->crtc = NULL), so clearly the whole "encoder->crtc" field
_can_ be NULL.
However, I don't see why it should only show up for some people...
Linus
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 Alex Deucher changed: What|Removed |Added Attachment #37545|application/octet-stream|text/plain mime type|| Attachment #37545|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 Alex Deucher changed: What|Removed |Added Attachment #37544|application/octet-stream|text/plain mime type|| Attachment #37544|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 Alex Deucher changed: What|Removed |Added Attachment #37543|application/octet-stream|text/plain mime type|| Attachment #37543|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] light weight drm fbdev panning
On Tue, Aug 3, 2010 at 8:01 AM, James Simmons wrote:
>
> This patch uses the much lighter mode_set_base instead of calling a full
> mode set. Tested on a i915 netbook. Patch should be against drm-core-next.
The kms code should always fallback if appropriate, I've definitely
seen some modesets I thought were triggered by the pan_display
codepath, so I'd expect if we add this, we might some base sets at the
wrong time. Unless we can prove we only get pan_displays when
expected.
Dave.
>
> Signed-By: James Simmons
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 7196620..99889e3 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -730,15 +730,20 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
> *var,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct fb_info *info)
> ?{
> ? ? ? ?struct drm_fb_helper *fb_helper = info->par;
> + ? ? ? struct drm_crtc_helper_funcs *crtc_funcs;
> ? ? ? ?struct drm_device *dev = fb_helper->dev;
> ? ? ? ?struct drm_mode_set *modeset;
> ? ? ? ?struct drm_crtc *crtc;
> - ? ? ? int ret = 0;
> + ? ? ? int ret = -ENXIO;
> ? ? ? ?int i;
>
> ? ? ? ?mutex_lock(>mode_config.mutex);
> ? ? ? ?for (i = 0; i < fb_helper->crtc_count; i++) {
> ? ? ? ? ? ? ? ?crtc = fb_helper->crtc_info[i].mode_set.crtc;
> + ? ? ? ? ? ? ? crtc_funcs = crtc->helper_private;
> +
> + ? ? ? ? ? ? ? if (!crtc_funcs->mode_set_base)
> + ? ? ? ? ? ? ? ? ? ? ? continue;
>
> ? ? ? ? ? ? ? ?modeset = _helper->crtc_info[i].mode_set;
>
> @@ -746,7 +751,8 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
> *var,
> ? ? ? ? ? ? ? ?modeset->y = var->yoffset;
>
> ? ? ? ? ? ? ? ?if (modeset->num_connectors) {
> - ? ? ? ? ? ? ? ? ? ? ? ret = crtc->funcs->set_config(modeset);
> + ? ? ? ? ? ? ? ? ? ? ? ret = crtc_funcs->mode_set_base(crtc, modeset->x,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? modeset->y, crtc->fb);
> ? ? ? ? ? ? ? ? ? ? ? ?if (!ret) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?info->var.xoffset = var->xoffset;
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?info->var.yoffset = var->yoffset;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bugme-new] [Bug 16488] New: [i915] Framebuffer ID error after suspend/hibernate leading to X crash
On Mon, 2 Aug 2010 16:55:03 -0700, Andrew Morton wrote: > > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Sun, 1 Aug 2010 08:55:49 GMT > bugzilla-daemon at bugzilla.kernel.org wrote: > > > https://bugzilla.kernel.org/show_bug.cgi?id=16488 > > Innocuous-looking one-liner is said to have made Milan's X server even > worse than normal. We go from a random OOPS to a consistent error (and a failing userspace). It sounds more likely that we have uncovered a real bug, probably in the ddx. -- Chris Wilson, Intel Open Source Technology Centre
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #3 from peterle at hottemptation.org 2010-08-03 08:06:47 PDT --- Of course I have the problem with delayed resuspend "atombios stuck", too. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #2 from peterle at hottemptation.org 2010-08-03 08:05:54 PDT --- Created an attachment (id=37545) --> (https://bugs.freedesktop.org/attachment.cgi?id=37545) dmesg after resuspend -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29384] New: Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 Summary: Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: peterle at hottemptation.org Created an attachment (id=37543) --> (https://bugs.freedesktop.org/attachment.cgi?id=37543) lspci of acer timelinex 3820tg Hello I made maybe a mistake and don't opened a new bug. But for additional information the old bug could be helpful, see here: https://bugs.freedesktop.org/show_bug.cgi?id=27744 Hardware: Radeon 5650 Kernel: 2.6.34 Status: everything is running fine Hardware: Radeon 5650 Kernel: 2.6.35-rc6 and 2.6.35 Status: everything runs but with glitches I have just use the TTY1-6 and switch between them everything is still okay with "2.6.35" but if the switch between TTY which are running applications with access to /dev/fb0 I got delays around 3 or 4 seconds when I switch away from TTY which is running fbida (framebuffer-image-viewer) or mplayer. I case of mplayer this could lead to an uncontrolable system, only reaching the end of the movie gives here control back (help: MagicSysR, blind reboot or blind killing of mplayer). Switching away from TTY7 with running X11 leads also to an delay around 3 or 4 seconds very similar to the delay which occurs while running fbida. I think a connection between the "stuck atombios" problem and this problem could existed, but I am not sure. This could also a own dedicated problem, so I opened this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #14 from peterle at hottemptation.org 2010-08-03 07:37:05 PDT --- Created an attachment (id=37542) --> (https://bugs.freedesktop.org/attachment.cgi?id=37542) dmesg log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #13 from peterle at hottemptation.org 2010-08-03 07:35:43 PDT --- Hello! I use a Radeon 5650 (Acer TimelineX 3820TG with switch off Intel-Graphics!), all run's fine with Kernel "2.6.34.1" including KMS, Suspend to RAM, tty1-6 Framebuffer and X11 as well as switching between them. With 2.6.35 (and rc6) I have the same "Stuck-Message" as the other people here, but I am afraid this is just the tip of the iceberg! * wakeup from Suspend is slow, according to the "Stuck-Message" * switching between TTY1-6 works normal as long nobody use the /dev/fb0 (interesting) device like fbida or mplayer FBIDA: Loading of a image or switching between images is normal, but switching away from the TTY which is running FBIDA is extremly slow. Switching back to the TTY is as fast as normal. MPLAYER: Same as with mplayer, but here it becomes very difficult to get the system back "under control". Please test this only with short videos, because normally everyting runes fine after mplayer closed itself. I advice to be patient and reboot "blind" or use MagicSysRescue if you don't get the control back. *switching between TTY1-6 and TTY7 (where X11 is launched) is also extremly slow, similar to FBIDA I think the problem behind is much bigger. Someone should check the updates between 2.6.34 and 2.6.35 and if possible fix it fast: window for kernel 2.6.36 is closing in two weeks -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29383] [r300g] Panzers II: terrain textures all black
https://bugs.freedesktop.org/show_bug.cgi?id=29383 --- Comment #1 from Fabio Pedretti 2010-08-03 07:28:17 PDT --- Screnshots here due to size limit: r300g: http://a.imageshack.us/img837/8601/r300g.png r300 classic: http://a.imageshack.us/img192/5466/r300.png -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29383] New: [r300g] Panzers II: terrain textures all black
https://bugs.freedesktop.org/show_bug.cgi?id=29383 Summary: [r300g] Panzers II: terrain textures all black Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: fabio.ped at libero.it With r300g and wine game Panzers II terrain is all black. It's still not perfect also with classic r300 (there is a stripe effect) but at least textures are visible. Screenshots with both drivers are attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Marek Ol??k 2010-08-03 06:56:04 PDT --- Pushed, closing.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 24973] [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
https://bugs.freedesktop.org/show_bug.cgi?id=24973 --- Comment #16 from Daniel 2010-08-03 06:31:26 PDT --- (In reply to comment #15) > Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are > accepted and confirmed in Xorg.0.log, but the resolution is still switch to > 800x600. For some reason the probing seems to override the xorg.conf setting. > Any further ideas? Two things: 1) Option "Ignore" "true" in xorg.conf for your S-Video port 2) or try adding "radeon.tv=0" to your kernel commandline. Option 2 does not work for me as the machine seems to freeze with it. However you might have more luck ;) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29355] M92 : Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=29355 --- Comment #3 from samit vats 2010-08-03 05:56:19 PDT --- Created an attachment (id=37540) --> (https://bugs.freedesktop.org/attachment.cgi?id=37540) dmesg.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 --- Comment #4 from Fabio Pedretti 2010-08-03 05:40:55 PDT --- (In reply to comment #3) > Created an attachment (id=37539) View: https://bugs.freedesktop.org/attachment.cgi?id=37539 Review: https://bugs.freedesktop.org/review?bug=29372=37539 > possible fix v2 > > Ah, of course it does. This fixed patch should work, can you test? Yes, the warnings are no longer printed now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28955] [r300g]: refresh/update/damage issues using compiz.
https://bugs.freedesktop.org/show_bug.cgi?id=28955 --- Comment #5 from Marek Ol??k 2010-08-03 05:40:08 PDT --- Does r300c have this issue? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 Marek Ol??k changed: What|Removed |Added Attachment #37538|0 |1 is obsolete|| --- Comment #3 from Marek Ol??k 2010-08-03 05:31:13 PDT --- Created an attachment (id=37539) View: https://bugs.freedesktop.org/attachment.cgi?id=37539 Review: https://bugs.freedesktop.org/review?bug=29372=37539 possible fix v2 Ah, of course it does. This fixed patch should work, can you test? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 24973] [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
https://bugs.freedesktop.org/show_bug.cgi?id=24973 --- Comment #15 from Marius Groeger 2010-08-03 05:25:41 PDT --- (In reply to comment #14) > Option "Enable" "False" > However, some older xservers (maybe recent ones too), do not deal with enable > false, you need to use: > Option "Disable" "True" Oops :-) However, unfortunately still no luck. "Enable" and "Disable" are accepted and confirmed in Xorg.0.log, but the resolution is still switch to 800x600. For some reason the probing seems to override the xorg.conf setting. Any further ideas? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 --- Comment #2 from Fabio Pedretti 2010-08-03 05:22:31 PDT --- (In reply to comment #1) > Created an attachment (id=37538) View: https://bugs.freedesktop.org/attachment.cgi?id=37538 Review: https://bugs.freedesktop.org/review?bug=29372=37538 > possible fix > > Could you try this patch? It instantly crash with it: Program received signal SIGSEGV, Segmentation fault. r300_bind_rs_state (pipe=0x84f7440, state=0x0) at r300_state.c:1110 1110r300->rs_state.size = 25 + (rs->polygon_offset_enable ? 5 : 0); (gdb) bt #0 r300_bind_rs_state (pipe=0x84f7440, state=0x0) at r300_state.c:1110 #1 0xaf49c09e in blitter_restore_CSOs (ctx=0x85098b0) at util/u_blitter.c:296 #2 0xaf49d5e1 in util_blitter_copy_region (blitter=0x85098b0, dst=0xae65d3f8, subdst=..., dstx=0, dsty=0, dstz=0, src=0xae65d5a0, subsrc=..., srcx=0, srcy=0, srcz=0, width=64, height=64, ignore_stencil=1 '\001') at util/u_blitter.c:837 #3 0xaf30d562 in r300_hw_copy_region (pipe=0x84f7440, dst=0xae65d3f8, subdst=..., dstx=0, dsty=0, dstz=0, src=0xae65d5a0, subsrc=..., srcx=0, srcy=0, srcz=0, width=64, height=64) at r300_blit.c:237 #4 r300_resource_copy_region (pipe=0x84f7440, dst=0xae65d3f8, subdst=..., dstx=0, dsty=0, dstz=0, src=0xae65d5a0, subsrc=..., srcx=0, srcy=0, srcz=0, width=64, height=64) at r300_blit.c:292 #5 0xaf2f4c25 in r300_copy_into_tiled_texture (ctx=0x84f7440, trans=0xae651d88) at r300_transfer.c:78 #6 r300_texture_transfer_destroy (ctx=0x84f7440, trans=0xae651d88) at r300_transfer.c:223 #7 0xaf4c7c1a in u_transfer_destroy_vtbl (pipe=0x84f7440, transfer=0xae651d88) at util/u_resource.c:49 #8 0xaf411f56 in st_texture_image_unmap (st=0x858d828, stImage=0xae651c98) at state_tracker/st_texture.c:168 #9 0xaf4500ea in st_TexImage (ctx=, dims=, target=3553, level=0, internalFormat=32849, width=64, height=64, depth=1, border=0, format=32992, type=5121, pixels=0xaeeab000, unpack=0x855e060, texObj=0xae651a78, texImage=0xae651c98, imageSize=0, compressed_src=0 '\000') at state_tracker/st_cb_texture.c:765 #10 0xaf450afb in st_TexImage2D (ctx=0x854f248, target=3553, level=0, internalFormat=32849, width=64, height=64, border=0, format=32992, type=5121, pixels=0xaeeab000, unpack=0x855e060, texObj=0xae651a78, texImage=0xae651c98) at state_tracker/st_cb_texture.c:798 #11 0xaf3aac54 in _mesa_TexImage2D (target=3553, level=0, internalFormat=32849, width=64, height=64, border=0, format=32992, type=5121, pixels=0xaeeab000) at main/teximage.c:2409 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 --- Comment #1 from Marek Ol??k 2010-08-03 05:17:01 PDT --- Created an attachment (id=37538) View: https://bugs.freedesktop.org/attachment.cgi?id=37538 Review: https://bugs.freedesktop.org/review?bug=29372=37538 possible fix Could you try this patch? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29372] New: [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 Summary: [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629) Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: fabio.ped at libero.it Using the game 0ad pre-alpha3 7732 with RV530 on current git master: 1) start a game 2) clic on Menu -> Settings -> enable Developer Overlay -> OK 3) clic on Pathfinder overlay 4) Move some unit on the maps Hundreds of message like the following appears: r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] expand gamma_set
Expand the crtc_gamma_set function to accept a starting offset. The
reason for this is to eventually use this function for setcolreg from
drm_fb_helper.c. The fbdev colormap function can start at any offset in
the color map.
Signed-by: James Simmons
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4c68f76..a06d1da 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2541,7 +2541,7 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
goto out;
}
- crtc->funcs->gamma_set(crtc, r_base, g_base, b_base, crtc->gamma_size);
+ crtc->funcs->gamma_set(crtc, r_base, g_base, b_base, 0,
crtc->gamma_size);
out:
mutex_unlock(>mode_config.mutex);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f879589..07a430c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4096,15 +4096,12 @@ void intel_crtc_fb_gamma_get(struct drm_crtc *crtc, u16
*red, u16 *green,
}
static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
-u16 *blue, uint32_t size)
+u16 *blue, uint32_t start, uint32_t size)
{
+ int end = (start + size > 256) ? 256 : start + size, i;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int i;
-
- if (size != 256)
- return;
- for (i = 0; i < 256; i++) {
+ for (i = start; i < end; i++) {
intel_crtc->lut_r[i] = red[i] >> 8;
intel_crtc->lut_g[i] = green[i] >> 8;
intel_crtc->lut_b[i] = blue[i] >> 8;
diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c
b/drivers/gpu/drm/nouveau/nv04_crtc.c
index 1c20c08..88bb4ce 100644
--- a/drivers/gpu/drm/nouveau/nv04_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv04_crtc.c
@@ -739,15 +739,13 @@ nv_crtc_gamma_load(struct drm_crtc *crtc)
}
static void
-nv_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b, uint32_t size)
+nv_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b, uint32_t
start,
+ uint32_t size)
{
+ int end = (start + size > 256) ? 256 : start + size, i;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- int i;
-
- if (size != 256)
- return;
- for (i = 0; i < 256; i++) {
+ for (i = start; i < end; i++) {
nv_crtc->lut.r[i] = r[i];
nv_crtc->lut.g[i] = g[i];
nv_crtc->lut.b[i] = b[i];
diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c
b/drivers/gpu/drm/nouveau/nv50_crtc.c
index 5d11ea1..2f5f2f2 100644
--- a/drivers/gpu/drm/nouveau/nv50_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv50_crtc.c
@@ -381,15 +381,12 @@ nv50_crtc_cursor_move(struct drm_crtc *crtc, int x, int y)
static void
nv50_crtc_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
- uint32_t size)
+ uint32_t start, uint32_t size)
{
+ int end = (start + size > 256) ? 256 : start + size, i;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
- int i;
-
- if (size != 256)
- return;
- for (i = 0; i < 256; i++) {
+ for (i = start; i < end; i++) {
nv_crtc->lut.r[i] = r[i];
nv_crtc->lut.g[i] = g[i];
nv_crtc->lut.b[i] = b[i];
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 283beed..64e69fd 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -161,17 +161,13 @@ void radeon_crtc_fb_gamma_get(struct drm_crtc *crtc, u16
*red, u16 *green,
}
static void radeon_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
- u16 *blue, uint32_t size)
+ u16 *blue, uint32_t start, uint32_t size)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- int i;
-
- if (size != 256) {
- return;
- }
+ int end = (start + size > 256) ? 256 : start + size, i;
/* userspace palettes are always correct as is */
- for (i = 0; i < 256; i++) {
+ for (i = start; i < end; i++) {
radeon_crtc->lut_r[i] = red[i] >> 6;
radeon_crtc->lut_g[i] = green[i] >> 6;
radeon_crtc->lut_b[i] = blue[i] >> 6;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index cfaf690..2ff5cf7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -79,7 +79,7 @@ static void vmw_ldu_crtc_restore(struct drm_crtc *crtc)
static void vmw_ldu_crtc_gamma_set(struct drm_crtc *crtc,
u16 *r, u16 *g, u16 *b,
- uint32_t size)
+ uint32_t start, uint32_t size)
{
}
diff --git
[Bug 26428] [KMS] doom3-demo aborts early on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=26428 Fabio Pedretti changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Fabio Pedretti 2010-08-03 00:01:22 PDT --- Patches merged in 2.6.34.2 and 2.6.35. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #17 from Fabio Pedretti 2010-08-02 23:59:18 PDT --- This is also fixed in 2.6.34.2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28411] Output polling causes latency every 10 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=28411 Marius Groeger changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Marius Groeger 2010-08-02 23:04:24 PDT --- Fixed in 2.6.35 final, 29508eb66bfacdef324d2199eeaea31e0cdfaa29 drm/radeon/kms: drop taking lock around crtc lookup. Thanks Dave! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug.
[PATCH] light weight drm fbdev panning
This patch uses the much lighter mode_set_base instead of calling a full
mode set. Tested on a i915 netbook. Patch should be against drm-core-next.
Signed-By: James Simmons
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 7196620..99889e3 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -730,15 +730,20 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
+ struct drm_crtc_helper_funcs *crtc_funcs;
struct drm_device *dev = fb_helper->dev;
struct drm_mode_set *modeset;
struct drm_crtc *crtc;
- int ret = 0;
+ int ret = -ENXIO;
int i;
mutex_lock(>mode_config.mutex);
for (i = 0; i < fb_helper->crtc_count; i++) {
crtc = fb_helper->crtc_info[i].mode_set.crtc;
+ crtc_funcs = crtc->helper_private;
+
+ if (!crtc_funcs->mode_set_base)
+ continue;
modeset = _helper->crtc_info[i].mode_set;
@@ -746,7 +751,8 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var,
modeset->y = var->yoffset;
if (modeset->num_connectors) {
- ret = crtc->funcs->set_config(modeset);
+ ret = crtc_funcs->mode_set_base(crtc, modeset->x,
+ modeset->y, crtc->fb);
if (!ret) {
info->var.xoffset = var->xoffset;
info->var.yoffset = var->yoffset;
[Bug 28459] [r300g] Heroes of Newerth slow and corrupted with libtxc_dxtn.so
https://bugs.freedesktop.org/show_bug.cgi?id=28459 --- Comment #17 from Fabio Pedretti fabio@libero.it 2010-08-02 23:59:18 PDT --- This is also fixed in 2.6.34.2. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26428] [KMS] doom3-demo aborts early on rv280
https://bugs.freedesktop.org/show_bug.cgi?id=26428 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Fabio Pedretti fabio@libero.it 2010-08-03 00:01:22 PDT --- Patches merged in 2.6.34.2 and 2.6.35. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bugme-new] [Bug 16488] New: [i915] Framebuffer ID error after suspend/hibernate leading to X crash
On Mon, 2 Aug 2010 16:55:03 -0700, Andrew Morton a...@linux-foundation.org wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Sun, 1 Aug 2010 08:55:49 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=16488 Innocuous-looking one-liner is said to have made Milan's X server even worse than normal. We go from a random OOPS to a consistent error (and a failing userspace). It sounds more likely that we have uncovered a real bug, probably in the ddx. -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29372] New: [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 Summary: [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629) Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: fabio@libero.it Using the game 0ad pre-alpha3 7732 with RV530 on current git master: 1) start a game 2) clic on Menu - Settings - enable Developer Overlay - OK 3) clic on Pathfinder overlay 4) Move some unit on the maps Hundreds of message like the following appears: r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 Marek Olšák mar...@gmail.com changed: What|Removed |Added Attachment #37538|0 |1 is obsolete|| --- Comment #3 from Marek Olšák mar...@gmail.com 2010-08-03 05:31:13 PDT --- Created an attachment (id=37539) View: https://bugs.freedesktop.org/attachment.cgi?id=37539 Review: https://bugs.freedesktop.org/review?bug=29372attachment=37539 possible fix v2 Ah, of course it does. This fixed patch should work, can you test? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28955] [r300g]: refresh/update/damage issues using compiz.
https://bugs.freedesktop.org/show_bug.cgi?id=28955 --- Comment #5 from Marek Olšák mar...@gmail.com 2010-08-03 05:40:08 PDT --- Does r300c have this issue? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 --- Comment #4 from Fabio Pedretti fabio@libero.it 2010-08-03 05:40:55 PDT --- (In reply to comment #3) Created an attachment (id=37539) View: https://bugs.freedesktop.org/attachment.cgi?id=37539 Review: https://bugs.freedesktop.org/review?bug=29372attachment=37539 possible fix v2 Ah, of course it does. This fixed patch should work, can you test? Yes, the warnings are no longer printed now. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24973] [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
https://bugs.freedesktop.org/show_bug.cgi?id=24973 --- Comment #16 from Daniel di...@betriebsdirektor.de 2010-08-03 06:31:26 PDT --- (In reply to comment #15) Oops :-) However, unfortunately still no luck. Enable and Disable are accepted and confirmed in Xorg.0.log, but the resolution is still switch to 800x600. For some reason the probing seems to override the xorg.conf setting. Any further ideas? Two things: 1) Option Ignore true in xorg.conf for your S-Video port 2) or try adding radeon.tv=0 to your kernel commandline. Option 2 does not work for me as the machine seems to freeze with it. However you might have more luck ;) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29372] [r300g] r300: Warning: cs_count off by 5 at (r300_emit_rs_state, r300_emit.c:629)
https://bugs.freedesktop.org/show_bug.cgi?id=29372 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Marek Olšák mar...@gmail.com 2010-08-03 06:56:04 PDT --- Pushed, closing.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29383] New: [r300g] Panzers II: terrain textures all black
https://bugs.freedesktop.org/show_bug.cgi?id=29383 Summary: [r300g] Panzers II: terrain textures all black Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: fabio@libero.it With r300g and wine game Panzers II terrain is all black. It's still not perfect also with classic r300 (there is a stripe effect) but at least textures are visible. Screenshots with both drivers are attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27744] atombios stuck in loop - during suspend
https://bugs.freedesktop.org/show_bug.cgi?id=27744 --- Comment #13 from pete...@hottemptation.org 2010-08-03 07:35:43 PDT --- Hello! I use a Radeon 5650 (Acer TimelineX 3820TG with switch off Intel-Graphics!), all run's fine with Kernel 2.6.34.1 including KMS, Suspend to RAM, tty1-6 Framebuffer and X11 as well as switching between them. With 2.6.35 (and rc6) I have the same Stuck-Message as the other people here, but I am afraid this is just the tip of the iceberg! * wakeup from Suspend is slow, according to the Stuck-Message * switching between TTY1-6 works normal as long nobody use the /dev/fb0 (interesting) device like fbida or mplayer FBIDA: Loading of a image or switching between images is normal, but switching away from the TTY which is running FBIDA is extremly slow. Switching back to the TTY is as fast as normal. MPLAYER: Same as with mplayer, but here it becomes very difficult to get the system back under control. Please test this only with short videos, because normally everyting runes fine after mplayer closed itself. I advice to be patient and reboot blind or use MagicSysRescue if you don't get the control back. *switching between TTY1-6 and TTY7 (where X11 is launched) is also extremly slow, similar to FBIDA I think the problem behind is much bigger. Someone should check the updates between 2.6.34 and 2.6.35 and if possible fix it fast: window for kernel 2.6.36 is closing in two weeks -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] New: Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 Summary: Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pete...@hottemptation.org Created an attachment (id=37543) -- (https://bugs.freedesktop.org/attachment.cgi?id=37543) lspci of acer timelinex 3820tg Hello I made maybe a mistake and don't opened a new bug. But for additional information the old bug could be helpful, see here: https://bugs.freedesktop.org/show_bug.cgi?id=27744 Hardware: Radeon 5650 Kernel: 2.6.34 Status: everything is running fine Hardware: Radeon 5650 Kernel: 2.6.35-rc6 and 2.6.35 Status: everything runs but with glitches I have just use the TTY1-6 and switch between them everything is still okay with 2.6.35 but if the switch between TTY which are running applications with access to /dev/fb0 I got delays around 3 or 4 seconds when I switch away from TTY which is running fbida (framebuffer-image-viewer) or mplayer. I case of mplayer this could lead to an uncontrolable system, only reaching the end of the movie gives here control back (help: MagicSysR, blind reboot or blind killing of mplayer). Switching away from TTY7 with running X11 leads also to an delay around 3 or 4 seconds very similar to the delay which occurs while running fbida. I think a connection between the stuck atombios problem and this problem could existed, but I am not sure. This could also a own dedicated problem, so I opened this bug. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #2 from pete...@hottemptation.org 2010-08-03 08:05:54 PDT --- Created an attachment (id=37545) -- (https://bugs.freedesktop.org/attachment.cgi?id=37545) dmesg after resuspend -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #3 from pete...@hottemptation.org 2010-08-03 08:06:47 PDT --- Of course I have the problem with delayed resuspend atombios stuck, too. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #37543|application/octet-stream|text/plain mime type|| Attachment #37543|0 |1 is patch|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bugme-new] [Bug 16488] New: [i915] Framebuffer ID error after suspend/hibernate leading to X crash
On Tue, Aug 3, 2010 at 12:25 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, 2 Aug 2010 16:55:03 -0700, Andrew Morton a...@linux-foundation.org
wrote:
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Sun, 1 Aug 2010 08:55:49 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=16488
Innocuous-looking one-liner is said to have made Milan's X server even
worse than normal.
We go from a random OOPS to a consistent error (and a failing userspace).
It sounds more likely that we have uncovered a real bug, probably in
the ddx.
I can't really imagine that that one-liner made the difference. Not
under any normal load. I suspect it just changes some allocation
pattern very subtly, and then the memory scribble (or whatever) that
really causes the bug perhaps changes.
The original oops reported in launchpad was
BUG: unable to handle kernel NULL pointer dereference at 0108
IP: [f8578b97] intel_release_load_detect_pipe+0x27/0xb0 [i915]
and as far as I can tell, that's due to a load off a NULL crtc, here:
struct drm_crtc_helper_funcs *crtc_funcs = crtc-helper_private;
the disassembly is
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 ec 14sub$0x14,%esp
6: 89 5d f4mov%ebx,-0xc(%ebp)
9: 89 75 f8mov%esi,-0x8(%ebp)
c: 89 7d fcmov%edi,-0x4(%ebp)
f: 0f 1f 44 00 00 nopl 0x0(%eax,%eax,1)
14: 8b b0 ec 02 00 00 mov0x2ec(%eax),%esi # crtc = encoder-crtc
1a: 89 c3 mov%eax,%ebx
1c: 8b 80 f4 02 00 00 mov0x2f4(%eax),%eax # dev = encoder-dev
22: 89 d7 mov%edx,%edi
24: 89 45 f0mov%eax,-0x10(%ebp)
27:* 8b 8e 08 01 00 00 mov0x108(%esi),%ecx -- trapping
instruction (crtc_funcs = crtc-helper_private)
2d: 80 bb 04 03 00 00 00cmpb $0x0,0x304(%ebx) #
intel_encoder-load_detect_temp
34: 75 2a jne0x60
36: 0f b6 46 18 movzbl 0x18(%esi),%eax # crtc-enabled
3a: 84 c0 test %al,%al
in case anybody cares. However, I have no idea how ctrc would be NULL
in the first place there, it comes from
struct drm_encoder *encoder = intel_encoder-enc;
...
struct drm_crtc *crtc = encoder-crtc;
and I don't know the setup code. It _does_ strike me that the C code does:
...
struct drm_crtc *crtc = encoder-crtc;
struct drm_encoder_helper_funcs *encoder_funcs =
encoder-helper_private;
struct drm_crtc_helper_funcs *crtc_funcs = crtc-helper_private;
if (intel_encoder-load_detect_temp) {
encoder-crtc = NULL;
connector-encoder = NULL;
where I react to the fact that first we load crtc = encoder-crtc
and dereference that pointer (crtc-helper_private) without checking
whether it might be NULL, and then in some case we clear that field
(encoder-crtc = NULL), so clearly the whole encoder-crtc field
_can_ be NULL.
However, I don't see why it should only show up for some people...
Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29355] M92 : Xserver fails to start
https://bugs.freedesktop.org/show_bug.cgi?id=29355 --- Comment #4 from Alex Deucher ag...@yahoo.com 2010-08-03 09:27:04 PDT --- There's no radeon info in the dmesg. What are the pci ids for your card? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 24973] [r300 KMS] KMS uses wrong display resulution, xrandr causes X to crash
https://bugs.freedesktop.org/show_bug.cgi?id=24973 --- Comment #17 from Marius Groeger marius.groe...@web.de 2010-08-03 10:42:11 PDT --- (In reply to comment #16) (In reply to comment #15) Oops :-) However, unfortunately still no luck. Enable and Disable are accepted and confirmed in Xorg.0.log, but the resolution is still switch to 800x600. For some reason the probing seems to override the xorg.conf setting. Any further ideas? Two things: 1) Option Ignore true in xorg.conf for your S-Video port 2) or try adding radeon.tv=0 to your kernel commandline. Great, the Ignore option did the trick! Thanks a bunch! While it still feels like a bug, I'd understand if nothing can be done to it so we might just as well close it as WONTFIX. You guys decide... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #6 from pete...@hottemptation.org 2010-08-03 11:13:58 PDT --- Just to notice: Switch from X11 to TTY1-6 is also still affected. Switch from TTY1-6 to X11 is, like before, normal - this means: immediately Switching from a TTY without access to /dev/fb* to a TTY with access (running fbida or mplayer) is immediately. Switching from a TTY with access (running fbida or mplayer) is slow. Closing fbida with q is also slow. Closing of mplayer with strg+c is not possible. mplayer is it totally freaking out. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #7 from pete...@hottemptation.org 2010-08-03 11:16:04 PDT --- Notice: With the patch resuspend need ~7 seconds. Withtout the patch resuspend needs ~ 3 seconds. With old kernel 2.6.34 resuspend need ~ 1 second. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #8 from Alex Deucher ag...@yahoo.com 2010-08-03 11:30:16 PDT --- Can you use git bisect between 2.6.34 and 2.6.35 and track down which commit causes the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] EDID parser updates
Some cosmetic cleanups, and then some changes to add more modes than we were before. 6 and 7 are the particularly touchy bits; I'd like a bit of volunteer testing before landing it on drm-core-next, particularly on HDMI monitors. Note that this is mostly about doing more with things other than your preferred mode, so be sure to check the mode list you get from RANDR for changes and try all the new ones (if any). - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm: Remove unused fields from drm_display_info
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 15 ---
include/drm/drm_crtc.h | 35 +--
2 files changed, 1 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 83d8072..e668084 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1655,23 +1655,8 @@ int drm_add_edid_modes(struct drm_connector *connector,
struct edid *edid)
if (quirks (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
edid_fixup_preferred(connector, quirks);
- connector-display_info.serration_vsync = (edid-input
DRM_EDID_INPUT_SERRATION_VSYNC) ? 1 : 0;
- connector-display_info.sync_on_green = (edid-input
DRM_EDID_INPUT_SYNC_ON_GREEN) ? 1 : 0;
- connector-display_info.composite_sync = (edid-input
DRM_EDID_INPUT_COMPOSITE_SYNC) ? 1 : 0;
- connector-display_info.separate_syncs = (edid-input
DRM_EDID_INPUT_SEPARATE_SYNCS) ? 1 : 0;
- connector-display_info.blank_to_black = (edid-input
DRM_EDID_INPUT_BLANK_TO_BLACK) ? 1 : 0;
- connector-display_info.video_level = (edid-input
DRM_EDID_INPUT_VIDEO_LEVEL) 5;
- connector-display_info.digital = (edid-input
DRM_EDID_INPUT_DIGITAL) ? 1 : 0;
connector-display_info.width_mm = edid-width_cm * 10;
connector-display_info.height_mm = edid-height_cm * 10;
- connector-display_info.gamma = edid-gamma;
- connector-display_info.gtf_supported = (edid-features
DRM_EDID_FEATURE_DEFAULT_GTF) ? 1 : 0;
- connector-display_info.standard_color = (edid-features
DRM_EDID_FEATURE_STANDARD_COLOR) ? 1 : 0;
- connector-display_info.display_type = (edid-features
DRM_EDID_FEATURE_DISPLAY_TYPE) 3;
- connector-display_info.active_off_supported = (edid-features
DRM_EDID_FEATURE_PM_ACTIVE_OFF) ? 1 : 0;
- connector-display_info.suspend_supported = (edid-features
DRM_EDID_FEATURE_PM_SUSPEND) ? 1 : 0;
- connector-display_info.standby_supported = (edid-features
DRM_EDID_FEATURE_PM_STANDBY) ? 1 : 0;
- connector-display_info.gamma = edid-gamma;
return num_modes;
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 93a1a31..606eb93 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -190,49 +190,16 @@ enum subpixel_order {
*/
struct drm_display_info {
char name[DRM_DISPLAY_INFO_LEN];
- /* Input info */
- bool serration_vsync;
- bool sync_on_green;
- bool composite_sync;
- bool separate_syncs;
- bool blank_to_black;
- unsigned char video_level;
- bool digital;
+
/* Physical size */
unsigned int width_mm;
unsigned int height_mm;
- /* Display parameters */
- unsigned char gamma; /* FIXME: storage format */
- bool gtf_supported;
- bool standard_color;
- enum {
- monochrome = 0,
- rgb,
- other,
- unknown,
- } display_type;
- bool active_off_supported;
- bool suspend_supported;
- bool standby_supported;
-
- /* Color info FIXME: storage format */
- unsigned short redx, redy;
- unsigned short greenx, greeny;
- unsigned short bluex, bluey;
- unsigned short whitex, whitey;
-
/* Clock limits FIXME: storage format */
unsigned int min_vfreq, max_vfreq;
unsigned int min_hfreq, max_hfreq;
unsigned int pixel_clock;
- /* White point indices FIXME: storage format */
- unsigned int wpx1, wpy1;
- unsigned int wpgamma1;
- unsigned int wpx2, wpy2;
- unsigned int wpgamma2;
-
enum subpixel_order subpixel_order;
char *raw_edid; /* if any */
--
1.7.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/edid: Add detailed block walk for CEA extensions
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 38 +-
include/drm/drm_edid.h |6 ++
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e668084..1bc15a8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -685,6 +685,33 @@ EXPORT_SYMBOL(drm_mode_find_dmt);
typedef void detailed_cb(struct detailed_timing *timing, void *closure);
static void
+cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
+{
+ int i, n = 0;
+ u8 rev = ext[0x01], d = ext[0x02];
+ u8 *det_base = ext + d;
+
+ switch (rev) {
+ case 0:
+ /* can't happen */
+ return;
+ case 1:
+ /* have to infer how many blocks we have, check pixel clock */
+ for (i = 0; i 6; i++)
+ if (det_base[18*i] || det_base[18*i+1])
+ n++;
+ break;
+ default:
+ /* explicit count */
+ n = min(ext[0x03] 0x0f, 6);
+ break;
+ }
+
+ for (i = 0; i n; i++)
+ cb((struct detailed_timing *)(det_base + 18 * i), closure);
+}
+
+static void
drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb, void *closure)
{
int i;
@@ -696,7 +723,16 @@ drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb,
void *closure)
for (i = 0; i EDID_DETAILED_TIMINGS; i++)
cb((edid-detailed_timings[i]), closure);
- /* XXX extension block walk */
+ for (i = 1; i = raw_edid[0x7e]; i++) {
+ u8 *ext = raw_edid + (i * EDID_LENGTH);
+ switch (*ext) {
+ case CEA_EXT:
+ cea_for_each_detailed_block(ext, cb, closure);
+ break;
+ default:
+ break;
+ }
+ }
}
static void
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 39e2cc5..5881fad 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -28,6 +28,12 @@
#define EDID_LENGTH 128
#define DDC_ADDR 0x50
+#define CEA_EXT0x02
+#define VTB_EXT0x10
+#define DI_EXT 0x40
+#define LS_EXT 0x50
+#define MI_EXT 0x60
+
struct est_timings {
u8 t1;
u8 t2;
--
1.7.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/edid: Add detailed block walk for VTB extensions
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1bc15a8..9299dd6 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -712,6 +712,19 @@ cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void
*closure)
}
static void
+vtb_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
+{
+ unsigned int i, n = min((int)ext[0x02], 6);
+ u8 *det_base = ext + 5;
+
+ if (ext[0x01] != 1)
+ return; /* unknown version */
+
+ for (i = 0; i n; i++)
+ cb((struct detailed_timing *)(det_base + 18 * i), closure);
+}
+
+static void
drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb, void *closure)
{
int i;
@@ -729,6 +742,9 @@ drm_for_each_detailed_block(u8 *raw_edid, detailed_cb *cb,
void *closure)
case CEA_EXT:
cea_for_each_detailed_block(ext, cb, closure);
break;
+ case VTB_EXT:
+ vtb_for_each_detailed_block(ext, cb, closure);
+ break;
default:
break;
}
--
1.7.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] drm/edid: Re-add the reduced blanking modes to the DMT table
Also fix up mode generation to only add RB modes from DMT if it looks
like an RB-capable monitor.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 43 +
drivers/gpu/drm/drm_edid_modes.h | 98 --
drivers/gpu/drm/drm_fb_helper.c |2 +-
include/drm/drm_crtc.h |2 +-
4 files changed, 118 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 66b8b5c..817ffab 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -433,8 +433,17 @@ static void edid_fixup_preferred(struct drm_connector
*connector,
preferred_mode-type |= DRM_MODE_TYPE_PREFERRED;
}
-struct drm_display_mode *drm_mode_find_dmt(struct drm_device *dev,
- int hsize, int vsize, int fresh)
+static bool
+mode_is_rb(struct drm_display_mode *mode)
+{
+ return (mode-htotal - mode-hdisplay == 160)
+ (mode-hsync_end - mode-hdisplay == 80)
+ (mode-hsync_end - mode-hsync_start == 32)
+ (mode-vsync_start - mode-vdisplay == 3);
+}
+
+struct drm_display_mode *
+drm_mode_find_dmt(struct drm_device *dev, int hsize, int vsize, int r, bool rb)
{
int i;
struct drm_display_mode *ptr, *mode;
@@ -444,7 +453,8 @@ struct drm_display_mode *drm_mode_find_dmt(struct
drm_device *dev,
ptr = drm_dmt_modes[i];
if (hsize == ptr-hdisplay
vsize == ptr-vdisplay
- fresh == drm_mode_vrefresh(ptr)) {
+ r == drm_mode_vrefresh(ptr)
+ rb == mode_is_rb(ptr)) {
/* get the expected default mode */
mode = drm_mode_duplicate(dev, ptr);
break;
@@ -694,7 +704,12 @@ drm_mode_std(struct drm_connector *connector, struct edid
*edid,
}
/* check whether it can be found in default mode table */
- mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate);
+ if (drm_monitor_supports_rb(edid)) {
+ mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, 1);
+ if (mode)
+ return mode;
+ }
+ mode = drm_mode_find_dmt(dev, hsize, vsize, vrefresh_rate, 0);
if (mode)
return mode;
@@ -722,7 +737,8 @@ drm_mode_std(struct drm_connector *connector, struct edid
*edid,
}
break;
case LEVEL_CVT:
- mode = drm_cvt_mode(dev, hsize, vsize, vrefresh_rate, 0, 0,
+ mode = drm_cvt_mode(dev, hsize, vsize, vrefresh_rate,
+ drm_monitor_supports_rb(edid), 0,
false);
break;
}
@@ -874,15 +890,6 @@ static struct drm_display_mode *drm_mode_detailed(struct
drm_device *dev,
}
static bool
-mode_is_rb(struct drm_display_mode *mode)
-{
- return (mode-htotal - mode-hdisplay == 160)
- (mode-hsync_end - mode-hdisplay == 80)
- (mode-hsync_end - mode-hsync_start == 32)
- (mode-vsync_start - mode-vdisplay == 3);
-}
-
-static bool
mode_in_hsync_range(struct drm_display_mode *mode, struct edid *edid, u8 *t)
{
int hsync, hmin, hmax;
@@ -957,10 +964,6 @@ mode_in_range(struct drm_display_mode *mode, struct edid
*edid,
return true;
}
-/*
- * XXX If drm_dmt_modes ever regrows the CVT-R modes (and it will) this will
- * need to account for them.
- */
static int
drm_gtf_modes_for_range(struct drm_connector *connector, struct edid *edid,
struct detailed_timing *timing)
@@ -1025,8 +1028,8 @@ drm_est3_modes(struct drm_connector *connector, struct
detailed_timing *timing)
mode = drm_mode_find_dmt(connector-dev,
est3_modes[m].w,
est3_modes[m].h,
-est3_modes[m].r
-/*, est3_modes[m].rb
*/);
+est3_modes[m].r,
+est3_modes[m].rb);
if (mode) {
drm_mode_probed_add(connector, mode);
modes++;
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index 6eb7592..19690cd 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -27,11 +27,7 @@
#include drmP.h
#include drm_edid.h
-/*
- * Autogenerated from the DMT spec.
- * This table is copied from xfree86/modes/xf86EdidModes.c.
- * But the mode with Reduced blank feature is deleted.
- */
+/* Autogenerated from the DMT
[PATCH 7/7] drm/edid: Add modes from CEA short video descriptor codes
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c | 188 +++-
drivers/gpu/drm/drm_edid_modes.h | 260 ++
2 files changed, 389 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 817ffab..44fd754 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1223,53 +1223,23 @@ add_cvt_modes(struct drm_connector *connector, struct
edid *edid)
return closure.modes;
}
-static void
-do_detailed_mode(struct detailed_timing *timing, void *c)
+/* XXX assumes there's only one */
+static u8 *
+find_cea_block(struct edid *edid)
{
- struct detailed_mode_closure *closure = c;
- struct drm_display_mode *newmode;
-
- if (timing-pixel_clock) {
- newmode = drm_mode_detailed(closure-connector-dev,
- closure-edid, timing,
- closure-quirks);
- if (!newmode)
- return;
+ int i;
+ u8 *ret;
- if (closure-preferred)
- newmode-type |= DRM_MODE_TYPE_PREFERRED;
+ if (!edid)
+ return NULL;
- drm_mode_probed_add(closure-connector, newmode);
- closure-modes++;
- closure-preferred = 0;
+ for (i = 0; i edid-extensions; i++) {
+ ret = (u8 *)edid + EDID_LENGTH * (i + 1);
+ if (ret[0] == CEA_EXT)
+ return ret;
}
-}
-
-/*
- * add_detailed_modes - Add modes from detailed timings
- * @connector: attached connector
- * @edid: EDID block to scan
- * @quirks: quirks to apply
- */
-static int
-add_detailed_modes(struct drm_connector *connector, struct edid *edid,
- u32 quirks)
-{
- struct detailed_mode_closure closure = {
- connector,
- edid,
- 1,
- quirks,
- 0
- };
-
- if (closure.preferred !version_greater(edid, 1, 3))
- closure.preferred =
- (edid-features DRM_EDID_FEATURE_PREFERRED_TIMING);
-
- drm_for_each_detailed_block((u8 *)edid, do_detailed_mode, closure);
- return closure.modes;
+ return NULL;
}
#define HDMI_IDENTIFIER 0x000C03
@@ -1283,25 +1253,13 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
*/
bool drm_detect_hdmi_monitor(struct edid *edid)
{
- char *edid_ext = NULL;
+ u8 *edid_ext = NULL;
int i, hdmi_id;
int start_offset, end_offset;
bool is_hdmi = false;
- /* No EDID or EDID extensions */
- if (edid == NULL || edid-extensions == 0)
- goto end;
-
- /* Find CEA extension */
- for (i = 0; i edid-extensions; i++) {
- edid_ext = (char *)edid + EDID_LENGTH * (i + 1);
- /* This block is CEA extension */
- if (edid_ext[0] == 0x02)
- break;
- }
-
- if (i == edid-extensions)
- goto end;
+ if (!(edid_ext = find_cea_block(edid)))
+ return false;
/* Data block offset in CEA extension block */
start_offset = 4;
@@ -1325,11 +1283,116 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
}
}
-end:
return is_hdmi;
}
EXPORT_SYMBOL(drm_detect_hdmi_monitor);
+static int
+add_cea_modes(struct drm_connector *connector, struct edid *edid)
+{
+ u8 *block = find_cea_block(edid);
+ u8 *b, *end;
+ int modes = 0;
+
+ if (!block)
+ return 0;
+
+ if (block[0x01] 3)
+ return 0; /* SVDs not specified yet */
+
+ b = block;
+ end = block + block[0x02];
+
+ while (b end) {
+ u8 header = *b;
+ u8 length = header 0x1f;
+ u8 tag = (header 0xe0) 5;
+
+ if (tag == 2) {
+ int i, m;
+ struct drm_display_mode *mode, *newmode;
+ for (i = 1; i = length; i++) {
+ m = b[i] 0x7f;
+ if (m cea_num_modes) /* XXX warn */
+ continue;
+
+ /*
+* Don't add modes that require pixel repeat,
+* yet. The driver needs to be aware of this
+* and we don't have a mechanism for that.
+*
+* This prunes some modes that don't need
+* repeat; oh well.
+*/
+ mode = cea_modes[m];
+ if (mode-hdisplay == 1440 ||
+ mode-hdisplay == 2880)
+
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #9 from pete...@hottemptation.org 2010-08-03 11:41:29 PDT --- I am awfully sorry, but I am not familiar with git/git-bitsect. Of course I will try every patch you can over and give you as much as possible details about the effect. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29384] Slow switch between TTY1-TTY6 with /dev/fb0 or X11 involved
https://bugs.freedesktop.org/show_bug.cgi?id=29384 --- Comment #10 from Alex Deucher ag...@yahoo.com 2010-08-03 11:56:42 PDT --- (In reply to comment #9) I am awfully sorry, but I am not familiar with git/git-bitsect. Of course I will try every patch you can over and give you as much as possible details about the effect. It's very easy. Assuming you have a git tree checked out: git bisect start git bisect good v2.6.34 git bisect bad v2.6.35 After that git will walk you through the rest. It will check out the appropriate commit, at which point you can compile it, test it, and if it's good, run: git bisect good and if it's bad: git bisect bad and git will select the next commit and the process continues. If there is a commit that doesn't boot or build, you can skip it with: git bisect skip See this page for more info: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29389] New: [r300g] [bisected] hard locks in openarena with kernel 2.6.35
https://bugs.freedesktop.org/show_bug.cgi?id=29389 Summary: [r300g] [bisected] hard locks in openarena with kernel 2.6.35 Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ghe...@virgilio.it Created an attachment (id=37557) -- (https://bugs.freedesktop.org/attachment.cgi?id=37557) git-bisect.log Yesterday I upgraded to kernel 2.6.35 and I had a lockup after playing for a few second at openarena. The day before I had played for a few minutes without any issue (testing r300g) so I immediately suspected the kernel. I'm using a radeon x550 (rv370) with yesterday git snapshot of mesa and xf86-video-ati and xorg-server 1.8.2. Both r300c/DRI/UMS and r300c/DRI2/KMS dont' seem to suffer from the issue, only gallium. Nothing unusual in the logs. I bisected from 2.6.34 (good) to 2.6.35 (bad) and git bisect pointed to commit eb1f8e4f3be898df808e2dfc131099f5831d491d eb1f8e4f3be898df808e2dfc131099f5831d491d is the first bad commit commit eb1f8e4f3be898df808e2dfc131099f5831d491d Author: Dave Airlie airl...@redhat.com Date: Fri May 7 06:42:51 2010 + drm/fbdev: rework output polling to be back in the core. (v4) After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls v4: config lock was a bit agressive, only needed around connector list reading. otherwise it could re-enter. glisse: discard drm_helper_hpd_irq_event v3: Reviewed-by: Michel Dänzer mic...@daenzer.net Signed-off-by: Dave Airlie airl...@redhat.com :04 04 01a1bf1ae4e06bfd3ae9ae67b5b5059e964f5ae4 041231a5c060e531ce0d8127c6f7abc79c14ce76 Mdrivers :04 04 b67fd6698fa239d26ca9fa2296ea2403e1eaaf1c cadb905c6d8647313107790ce8b681f4611ee726 Minclude I had to skip a few revisions because opengl didn't work at all and one revision I'm not exactly sure it crashed for the same issue (the symptoms were slightly different, it crashed after maybe two minutes instead of 5-30s) so I'm not sure that that's the real culprit. The bisection run took me a few hours and a lot of reboots, so I'm not exactly eager to try it again... The full git bisect log is attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29303] [r300g] compiz segfaults when resizing windows
https://bugs.freedesktop.org/show_bug.cgi?id=29303 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Marek Olšák mar...@gmail.com 2010-08-03 15:20:52 PDT --- Fixed by commit afbf446de5ad91743e2e2a76799bd87f3eed5f9a. Closing.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28628] [r300g] ARB_vp: error: relative address offset too large (163)
https://bugs.freedesktop.org/show_bug.cgi?id=28628 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Marek Olšák mar...@gmail.com 2010-08-03 15:25:12 PDT --- Fixed by commit 0614006d090902324149387ec150231b647928fd. Closing.. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29390] Radeon KMS - Bootup - First Text At 640x480 - Then Blank Screen - Then FB
https://bugs.freedesktop.org/show_bug.cgi?id=29390 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Product|xorg|DRI Version|7.5 |unspecified Component|Driver/radeonhd |DRM/Radeon AssignedTo|e...@pdx.freedesktop.org|dri-de...@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29390] Radeon KMS - Bootup - First Text At 640x480 - Then Blank Screen - Then FB
https://bugs.freedesktop.org/show_bug.cgi?id=29390 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #1 from Alex Deucher ag...@yahoo.com 2010-08-03 15:33:37 PDT --- You might try a different distro. This isn't really a driver bug, more a distro start up configuration issue. The latest fedora and ubuntu releases go straight from from the bios post screen to the plymouth boot screen. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: fix calculation of h/v scaling factors
Prior to this patch the code was dividing the src_v by the dst_h
and vice versa, rather than src_v/dst_v and src_h/dst_h.
This could lead to problems in the calculation of the display
watermarks.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_display.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 283beed..12a5414 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1073,11 +1073,13 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc
*crtc,
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct radeon_encoder *radeon_encoder;
bool first = true;
+ u32 src_v = 1, dst_v = 1;
+ u32 src_h = 1, dst_h = 1;
list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
- radeon_encoder = to_radeon_encoder(encoder);
if (encoder-crtc != crtc)
continue;
+ radeon_encoder = to_radeon_encoder(encoder);
if (first) {
/* set scaling */
if (radeon_encoder-rmx_type == RMX_OFF)
@@ -1087,6 +1089,10 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc
*crtc,
radeon_crtc-rmx_type =
radeon_encoder-rmx_type;
else
radeon_crtc-rmx_type = RMX_OFF;
+ src_v = crtc-mode.vdisplay;
+ dst_v = radeon_crtc-native_mode.vdisplay;
+ src_h = crtc-mode.hdisplay;
+ dst_h = radeon_crtc-native_mode.vdisplay;
/* copy native mode */
memcpy(radeon_crtc-native_mode,
radeon_encoder-native_mode,
@@ -1096,22 +1102,22 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc
*crtc,
if (radeon_crtc-rmx_type != radeon_encoder-rmx_type) {
/* WARNING: Right now this can't happen but
* in the future we need to check that scaling
-* are consistent accross different encoder
+* are consistent across different encoder
* (ie all encoder can work with the same
* scaling).
*/
- DRM_ERROR(Scaling not consistent accross
encoder.\n);
+ DRM_ERROR(Scaling not consistent across
encoder.\n);
return false;
}
}
}
if (radeon_crtc-rmx_type != RMX_OFF) {
fixed20_12 a, b;
- a.full = dfixed_const(crtc-mode.vdisplay);
- b.full = dfixed_const(radeon_crtc-native_mode.hdisplay);
+ a.full = dfixed_const(src_v);
+ b.full = dfixed_const(dst_v);
radeon_crtc-vsc.full = dfixed_div(a, b);
- a.full = dfixed_const(crtc-mode.hdisplay);
- b.full = dfixed_const(radeon_crtc-native_mode.vdisplay);
+ a.full = dfixed_const(src_h);
+ b.full = dfixed_const(dst_h);
radeon_crtc-hsc.full = dfixed_div(a, b);
} else {
radeon_crtc-vsc.full = dfixed_const(1);
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29393] New: R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 Summary: R600: libGL crashes using Lwjgl Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: jonescas...@gmail.com Created an attachment (id=37560) -- (https://bugs.freedesktop.org/attachment.cgi?id=37560) Full Java error log Lwjgl is a Java binding to OpenGL. Any Lwjgl application or demo crashes libGL.so and forces the Java VM to abort. This is the output from Java: Could not locate symbol glXCreateContextAttribsARB # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb00434a8, pid=19189, tid=2954230640 # # JRE version: 6.0_21-b06 # Java VM: Java HotSpot(TM) Server VM (17.0-b16 mixed mode linux-x86 ) # Problematic frame: # C [libGL.so.1+0x424a8] # # An error report file with more information is saved as: # /root/hs_err_pid19189.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # I'm attaching the mentioned hs_err_pid19189.log I'm using the latest git version of Mesa with a Radeon 4850. KMS is enabled. I'm using the Sun/Oracle JDK, not OpenJDK or IcedTea. I've confirmed that this works on Mesa 7.8.2. It worked on earlier version of 7.9, but sometime in the last few weeks it stopped working. I've been working on my own Lwjgl application, so when I ran into this error I downgraded Mesa to 7.8, but I still have 7.9 in a chroot which I can do further testing on. There are demo applications here: http://lwjgl.org/demos.php I used GLGears. To run a jnlp file from the command line: javaws test.opengl.Gears Thanks. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 --- Comment #1 from Casey Jones jonescas...@gmail.com 2010-08-03 18:07:16 PDT --- I also tried r600g in my chroot just for kicks, and it crashes as well. Plain old glxgears worked, but the Lwjgl version does not. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 --- Comment #2 from Alex Deucher ag...@yahoo.com 2010-08-03 18:17:09 PDT --- Can you bisect mesa to see what commit broke it? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29393] R600: libGL crashes using Lwjgl
https://bugs.freedesktop.org/show_bug.cgi?id=29393 --- Comment #3 from Casey Jones jonescas...@gmail.com 2010-08-03 19:26:51 PDT --- This is what I got. f8d81c31cee30821da3aab331a57f484f6a07a5d is the first bad commit commit f8d81c31cee30821da3aab331a57f484f6a07a5d Author: Nick Bowler nbow...@draconx.ca Date: Wed Jul 14 12:01:49 2010 -0400 dri2: Track event mask in client code. When direct rendering is being used, DRI2 BufferSwapComplete events are sent unconditionally to clients, even if they haven't been requested. This causes error messages to be printed by every freeglut application of the form freeglut (./gears): Unknown X event type: 104 and might confuse other clients. This is a fixed up version of the patch by Jesse Barnes, which drops BufferSwapComplete events if they are not requested by clients. Fixes fdo bug 27962. Signed-off-by: Nick Bowler nbow...@draconx.ca Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
