Re: [PATCH 1/2] Remove unused local variable pRADEONEnt
On 30 July 2015 at 17:00, Michel Dänzer wrote:
> From: Michel Dänzer
>
> ../../src/radeon_probe.c: In function 'radeon_get_scrninfo':
> ../../src/radeon_probe.c:157:22: warning: variable 'pRADEONEnt' set but not
> used [-Wunused-but-set-variable]
> RADEONEntPtr pRADEONEnt;
> ^
>
> Signed-off-by: Michel Dänzer
For both,
Reviewed-by: Dave Airlie
> ---
> src/radeon_probe.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/src/radeon_probe.c b/src/radeon_probe.c
> index f81ed13..65cf0c9 100644
> --- a/src/radeon_probe.c
> +++ b/src/radeon_probe.c
> @@ -154,7 +154,6 @@ radeon_get_scrninfo(int entity_num, void *pci_dev)
> */
> {
> DevUnion*pPriv;
> -RADEONEntPtr pRADEONEnt;
>
> xf86SetEntitySharable(entity_num);
>
> @@ -166,12 +165,8 @@ radeon_get_scrninfo(int entity_num, void *pci_dev)
>
> xf86SetEntityInstanceForScreen(pScrn, pEnt->index,
> xf86GetNumEntityInstances(pEnt->index) - 1);
>
> -if (!pPriv->ptr) {
> +if (!pPriv->ptr)
> pPriv->ptr = xnfcalloc(sizeof(RADEONEntRec), 1);
> -pRADEONEnt = pPriv->ptr;
> -} else {
> -pRADEONEnt = pPriv->ptr;
> -}
> }
>
> free(pEnt);
> --
> 2.1.4
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/2] radeon: move radeon_pixmap forward declaration into other block
From: Dave Airlie
There is already a radeon_pixmap forward decl here, the #else
block is missing one.
Signed-off-by: Dave Airlie
---
src/radeon_glamor.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/radeon_glamor.h b/src/radeon_glamor.h
index 1ba7049..c77466e 100644
--- a/src/radeon_glamor.h
+++ b/src/radeon_glamor.h
@@ -61,8 +61,6 @@ struct radeon_pixmap;
#define GLAMOR_USE_PICTURE_SCREEN 0
#endif
-struct radeon_pixmap;
-
Bool radeon_glamor_pre_init(ScrnInfoPtr scrn);
Bool radeon_glamor_init(ScreenPtr screen);
void radeon_glamor_screen_init(ScreenPtr screen);
@@ -76,6 +74,8 @@ XF86VideoAdaptorPtr radeon_glamor_xv_init(ScreenPtr pScreen,
int num_adapt);
#else
+struct radeon_pixmap;
+
static inline Bool radeon_glamor_pre_init(ScrnInfoPtr scrn) { return FALSE; }
static inline Bool radeon_glamor_init(ScreenPtr screen) { return FALSE; }
static inline Bool radeon_glamor_create_screen_resources(ScreenPtr screen) {
return FALSE; }
--
2.4.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/2] radeon: cleanup the entity rec
From: Dave Airlie
Some of these were set, some of them were
always opposites, so clean things up.
Signed-off-by: Dave Airlie
---
src/drmmode_display.c | 2 +-
src/radeon.h | 1 -
src/radeon_kms.c | 5 -
src/radeon_probe.c| 4
src/radeon_probe.h| 4
5 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 337ee55..a769013 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1561,7 +1561,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
if (!RADEONZaphodStringMatches(pScrn, s, name))
goto out_free_encoders;
} else {
- if (info->IsPrimary && (num != 0))
+ if (!info->IsSecondary && (num != 0))
goto out_free_encoders;
else if (info->IsSecondary && (num != 1))
goto out_free_encoders;
diff --git a/src/radeon.h b/src/radeon.h
index d6f18fa..88df93f 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -499,7 +499,6 @@ typedef struct {
#endif
Bool IsSecondary;
-Bool IsPrimary;
Bool r600_shadow_fb;
void *fb_shadow;
diff --git a/src/radeon_kms.c b/src/radeon_kms.c
index 2dad0e6..14de0eb 100644
--- a/src/radeon_kms.c
+++ b/src/radeon_kms.c
@@ -1079,7 +1079,6 @@ Bool RADEONPreInit_KMS(ScrnInfoPtr pScrn, int flags)
info = RADEONPTR(pScrn);
info->IsSecondary = FALSE;
-info->IsPrimary = FALSE;
info->pEnt =
xf86GetEntityInfo(pScrn->entityList[pScrn->numEntities - 1]);
if (info->pEnt->location.type != BUS_PCI
#ifdef XSERVER_PLATFORM_BUS
@@ -1097,14 +1096,10 @@ Bool RADEONPreInit_KMS(ScrnInfoPtr pScrn, int flags)
if(xf86IsPrimInitDone(pScrn->entityList[0]))
{
info->IsSecondary = TRUE;
-pRADEONEnt->pSecondaryScrn = pScrn;
}
else
{
- info->IsPrimary = TRUE;
xf86SetPrimInitDone(pScrn->entityList[0]);
-pRADEONEnt->pPrimaryScrn = pScrn;
-pRADEONEnt->HasSecondary = FALSE;
}
}
diff --git a/src/radeon_probe.c b/src/radeon_probe.c
index ad1e96e..f81ed13 100644
--- a/src/radeon_probe.c
+++ b/src/radeon_probe.c
@@ -169,10 +169,8 @@ radeon_get_scrninfo(int entity_num, void *pci_dev)
if (!pPriv->ptr) {
pPriv->ptr = xnfcalloc(sizeof(RADEONEntRec), 1);
pRADEONEnt = pPriv->ptr;
-pRADEONEnt->HasSecondary = FALSE;
} else {
pRADEONEnt = pPriv->ptr;
-pRADEONEnt->HasSecondary = TRUE;
}
}
@@ -271,10 +269,8 @@ radeon_platform_probe(DriverPtr pDriver,
if (!pPriv->ptr) {
pPriv->ptr = xnfcalloc(sizeof(RADEONEntRec), 1);
pRADEONEnt = pPriv->ptr;
-pRADEONEnt->HasSecondary = FALSE;
} else {
pRADEONEnt = pPriv->ptr;
-pRADEONEnt->HasSecondary = TRUE;
}
pRADEONEnt->platform_dev = dev;
}
diff --git a/src/radeon_probe.h b/src/radeon_probe.h
index 958cb23..258c7be 100644
--- a/src/radeon_probe.h
+++ b/src/radeon_probe.h
@@ -132,12 +132,8 @@ typedef struct {
typedef struct
{
-Bool HasSecondary;
Bool HasCRTC2; /* All cards except original Radeon */
-ScrnInfoPtr pSecondaryScrn;
-ScrnInfoPtr pPrimaryScrn;
-
int fd; /* for sharing across zaphod heads */
int fd_ref;
unsigned long fd_wakeup_registered; /* server generation for which fd
has been registered for wakeup handling */
--
2.4.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: adopt for new X server dirty tracking APIs.
Signed-off-by: Dave Airlie --- src/drmmode_display.c | 4 +++- src/radeon_kms.c | 4 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/src/drmmode_display.c b/src/drmmode_display.c index ad2f48b..337ee55 100644 --- a/src/drmmode_display.c +++ b/src/drmmode_display.c @@ -969,7 +969,9 @@ drmmode_set_scanout_pixmap(xf86CrtcPtr crtc, PixmapPtr ppix) screen->height = screenpix->drawable.height = max_height; } drmmode_crtc->prime_pixmap_x = this_x; -#ifdef HAS_DIRTYTRACKING2 +#ifdef HAS_DIRTYTRACKING_ROTATION + PixmapStartDirtyTracking(ppix, screenpix, 0, 0, this_x, 0, RR_Rotate_0); +#elif defined(HAS_DIRTYTRACKING2) PixmapStartDirtyTracking2(ppix, screenpix, 0, 0, this_x, 0); #else PixmapStartDirtyTracking(ppix, screenpix, 0, 0); diff --git a/src/radeon_kms.c b/src/radeon_kms.c index ec8f51c..2dad0e6 100644 --- a/src/radeon_kms.c +++ b/src/radeon_kms.c @@ -287,7 +287,11 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty) PixmapRegionInit(&pixregion, dirty->slave_dst); DamageRegionAppend(&dirty->slave_dst->drawable, &pixregion); +#ifdef HAS_DIRTYTRACKING_ROTATION + PixmapSyncDirtyHelper(dirty); +#else PixmapSyncDirtyHelper(dirty, &pixregion); +#endif radeon_cs_flush_indirect(pScrn); DamageRegionProcessPending(&dirty->slave_dst->drawable); -- 2.4.3 ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/3] radeon: move output name creation to its own function
From: Dave Airlie
The secondary indent is deliberate to make the next patch more
parseable for mst support.
Signed-off-by: Dave Airlie
---
src/drmmode_display.c | 85 ---
1 file changed, 47 insertions(+), 38 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c69abbf..dd79db5 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1195,6 +1195,52 @@ const char *output_names[] = { "None",
#define NUM_OUTPUT_NAMES (sizeof(output_names) / sizeof(output_names[0]))
static void
+drmmode_create_name(ScrnInfoPtr pScrn, drmModeConnectorPtr koutput, char *name,
+ int *num_dvi, int *num_hdmi)
+{
+ {
+ if (koutput->connector_type >= NUM_OUTPUT_NAMES)
+ snprintf(name, 32, "Unknown%d-%d",
koutput->connector_type,
+koutput->connector_type_id - 1);
+#ifdef RADEON_PIXMAP_SHARING
+ else if (pScrn->is_gpu)
+ snprintf(name, 32, "%s-%d-%d",
+output_names[koutput->connector_type],
pScrn->scrnIndex - GPU_SCREEN_OFFSET + 1,
+koutput->connector_type_id - 1);
+#endif
+ else {
+ /* need to do smart conversion here for compat with
non-kms ATI driver */
+ if (koutput->connector_type_id == 1) {
+ switch(koutput->connector_type) {
+ case DRM_MODE_CONNECTOR_DVII:
+ case DRM_MODE_CONNECTOR_DVID:
+ case DRM_MODE_CONNECTOR_DVIA:
+ snprintf(name, 32, "%s-%d",
output_names[koutput->connector_type], *num_dvi);
+ (*num_dvi)++;
+ break;
+ case DRM_MODE_CONNECTOR_HDMIA:
+ case DRM_MODE_CONNECTOR_HDMIB:
+ snprintf(name, 32, "%s-%d",
output_names[koutput->connector_type], *num_hdmi);
+ (*num_hdmi)++;
+ break;
+ case DRM_MODE_CONNECTOR_VGA:
+ case DRM_MODE_CONNECTOR_DisplayPort:
+ snprintf(name, 32, "%s-%d",
output_names[koutput->connector_type],
+koutput->connector_type_id -
1);
+ break;
+ default:
+ snprintf(name, 32, "%s",
output_names[koutput->connector_type]);
+ break;
+ }
+ } else {
+ snprintf(name, 32, "%s-%d",
output_names[koutput->connector_type],
+koutput->connector_type_id - 1);
+ }
+ }
+ }
+}
+
+static void
drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi)
{
RADEONInfoPtr info = RADEONPTR(pScrn);
@@ -1223,44 +1269,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
}
}
- if (koutput->connector_type >= NUM_OUTPUT_NAMES)
- snprintf(name, 32, "Unknown%d-%d", koutput->connector_type,
-koutput->connector_type_id - 1);
-#ifdef RADEON_PIXMAP_SHARING
- else if (pScrn->is_gpu)
- snprintf(name, 32, "%s-%d-%d",
-output_names[koutput->connector_type],
pScrn->scrnIndex - GPU_SCREEN_OFFSET + 1,
-koutput->connector_type_id - 1);
-#endif
- else {
- /* need to do smart conversion here for compat with non-kms ATI
driver */
- if (koutput->connector_type_id == 1) {
- switch(koutput->connector_type) {
- case DRM_MODE_CONNECTOR_DVII:
- case DRM_MODE_CONNECTOR_DVID:
- case DRM_MODE_CONNECTOR_DVIA:
- snprintf(name, 32, "%s-%d",
output_names[koutput->connector_type], *num_dvi);
- (*num_dvi)++;
- break;
- case DRM_MODE_CONNECTOR_HDMIA:
- case DRM_MODE_CONNECTOR_HDMIB:
- snprintf(name, 32, "%s-%d",
output_names[koutput->connector_type], *num_hdmi);
- (*num_hdmi)++;
-
[PATCH 1/3] radeon: stop caching mode resources
From: Dave Airlie
This is step one towards MST connector hotplug support,
it stop caching the mode resources structure, and
just passes a pointer to it around.
Signed-off-by: Dave Airlie
---
src/drmmode_display.c | 35 +++
src/drmmode_display.h | 2 +-
src/radeon_dri2.c | 2 +-
src/radeon_kms.c | 2 +-
4 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index ef5dfbe..c69abbf 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -850,7 +850,7 @@ void drmmode_crtc_hw_id(xf86CrtcPtr crtc)
}
static void
-drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int num)
+drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num)
{
xf86CrtcPtr crtc;
drmmode_crtc_private_ptr drmmode_crtc;
@@ -860,7 +860,7 @@ drmmode_crtc_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode,
int num)
return;
drmmode_crtc = xnfcalloc(sizeof(drmmode_crtc_private_rec), 1);
- drmmode_crtc->mode_crtc = drmModeGetCrtc(drmmode->fd,
drmmode->mode_res->crtcs[num]);
+ drmmode_crtc->mode_crtc = drmModeGetCrtc(drmmode->fd,
mode_res->crtcs[num]);
drmmode_crtc->drmmode = drmmode;
crtc->driver_private = drmmode_crtc;
drmmode_crtc_hw_id(crtc);
@@ -1195,7 +1195,7 @@ const char *output_names[] = { "None",
#define NUM_OUTPUT_NAMES (sizeof(output_names) / sizeof(output_names[0]))
static void
-drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int num, int
*num_dvi, int *num_hdmi)
+drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi)
{
RADEONInfoPtr info = RADEONPTR(pScrn);
xf86OutputPtr output;
@@ -1207,7 +1207,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, int num, int *num_dv
int i;
const char *s;
- koutput = drmModeGetConnector(drmmode->fd,
drmmode->mode_res->connectors[num]);
+ koutput = drmModeGetConnector(drmmode->fd, mode_res->connectors[num]);
if (!koutput)
return;
@@ -1285,7 +1285,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, int num, int *num_dv
goto out_free_encoders;
}
- drmmode_output->output_id = drmmode->mode_res->connectors[num];
+ drmmode_output->output_id = mode_res->connectors[num];
drmmode_output->mode_output = koutput;
drmmode_output->mode_encoders = kencoders;
drmmode_output->drmmode = drmmode;
@@ -1354,7 +1354,7 @@ uint32_t find_clones(ScrnInfoPtr scrn, xf86OutputPtr
output)
static void
-drmmode_clones_init(ScrnInfoPtr scrn, drmmode_ptr drmmode)
+drmmode_clones_init(ScrnInfoPtr scrn, drmmode_ptr drmmode, drmModeResPtr
mode_res)
{
int i, j;
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
@@ -1369,8 +1369,8 @@ drmmode_clones_init(ScrnInfoPtr scrn, drmmode_ptr drmmode)
for (j = 0; j < drmmode_output->mode_output->count_encoders;
j++)
{
int k;
- for (k = 0; k < drmmode->mode_res->count_encoders; k++)
{
- if (drmmode->mode_res->encoders[k] ==
drmmode_output->mode_encoders[j]->encoder_id)
+ for (k = 0; k < mode_res->count_encoders; k++) {
+ if (mode_res->encoders[k] ==
drmmode_output->mode_encoders[j]->encoder_id)
drmmode_output->enc_mask |= (1 << k);
}
@@ -1730,25 +1730,27 @@ drm_wakeup_handler(pointer data, int err, pointer p)
Bool drmmode_pre_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int cpp)
{
int i, num_dvi = 0, num_hdmi = 0;
+ drmModeResPtr mode_res;
xf86CrtcConfigInit(pScrn, &drmmode_xf86crtc_config_funcs);
drmmode->scrn = pScrn;
drmmode->cpp = cpp;
- drmmode->mode_res = drmModeGetResources(drmmode->fd);
- if (!drmmode->mode_res)
+ mode_res = drmModeGetResources(drmmode->fd);
+ if (!mode_res)
return FALSE;
- xf86CrtcSetSizeRange(pScrn, 320, 200, drmmode->mode_res->max_width,
drmmode->mode_res->max_height);
- for (i = 0; i < drmmode->mode_res->count_crtcs; i++)
+ drmmode->count_crtcs = mode_res->count_crtcs;
+ xf86CrtcSetSizeRange(pScrn, 320, 200, mode_res->max_width,
mode_res->max_height);
+ for (i = 0; i < mode_res->count_crtcs; i++)
if (!xf86IsEntityShared(pScrn->entityList[0]) ||
pScrn->confScreen->device->screen == i)
- drmmode_crtc_init(pScrn, drmmode, i);
+ drmmode_crtc_init(pScrn, drmmode, mode_r
[PATCH 3/3] radeon: add support for DP 1.2 display hotplug
From: Dave Airlie
This allows for dynamic creation of conneectors when the
kernel tells us.
Signed-off-by: Dave Airlie
---
src/drmmode_display.c | 174 --
src/drmmode_display.h | 2 +
src/radeon.h | 3 +-
src/radeon_kms.c | 5 ++
4 files changed, 177 insertions(+), 7 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index dd79db5..fc03842 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1194,11 +1194,66 @@ const char *output_names[] = { "None",
#define NUM_OUTPUT_NAMES (sizeof(output_names) / sizeof(output_names[0]))
+static xf86OutputPtr find_output(ScrnInfoPtr pScrn, int id)
+{
+ xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
+ int i;
+ for (i = 0; i < xf86_config->num_output; i++) {
+ xf86OutputPtr output = xf86_config->output[i];
+ drmmode_output_private_ptr drmmode_output;
+
+ drmmode_output = output->driver_private;
+ if (drmmode_output->output_id == id)
+ return output;
+ }
+ return NULL;
+}
+
+static int parse_path_blob(drmModePropertyBlobPtr path_blob, int
*conn_base_id, char **path)
+{
+ char *conn;
+ char conn_id[5];
+ int id, len;
+ char *blob_data;
+
+ if (!path_blob)
+ return -1;
+
+ blob_data = path_blob->data;
+ /* we only handle MST paths for now */
+ if (strncmp(blob_data, "mst:", 4))
+ return -1;
+
+ conn = strchr(blob_data + 4, '-');
+ if (!conn)
+ return -1;
+ len = conn - (blob_data + 4);
+ if (len + 1 > 5)
+ return -1;
+ memcpy(conn_id, blob_data + 4, len);
+ conn_id[len] = '\0';
+ id = strtoul(conn_id, NULL, 10);
+
+ *conn_base_id = id;
+
+ *path = conn + 1;
+ return 0;
+}
+
static void
drmmode_create_name(ScrnInfoPtr pScrn, drmModeConnectorPtr koutput, char *name,
- int *num_dvi, int *num_hdmi)
+ drmModePropertyBlobPtr path_blob, int *num_dvi, int
*num_hdmi)
{
- {
+ xf86OutputPtr output;
+ int conn_id;
+ char *extra_path;
+
+ output = NULL;
+ if (parse_path_blob(path_blob, &conn_id, &extra_path) == 0)
+ output = find_output(pScrn, conn_id);
+ if (output) {
+ snprintf(name, 32, "%s-%s", output->name, extra_path);
+ } else {
if (koutput->connector_type >= NUM_OUTPUT_NAMES)
snprintf(name, 32, "Unknown%d-%d",
koutput->connector_type,
koutput->connector_type_id - 1);
@@ -1241,14 +1296,16 @@ drmmode_create_name(ScrnInfoPtr pScrn,
drmModeConnectorPtr koutput, char *name,
}
static void
-drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi)
+drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, drmModeResPtr
mode_res, int num, int *num_dvi, int *num_hdmi, int dynamic)
{
+ xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
RADEONInfoPtr info = RADEONPTR(pScrn);
xf86OutputPtr output;
drmModeConnectorPtr koutput;
drmModeEncoderPtr *kencoders = NULL;
drmmode_output_private_ptr drmmode_output;
drmModePropertyPtr props;
+ drmModePropertyBlobPtr path_blob = NULL;
char name[32];
int i;
const char *s;
@@ -1257,6 +1314,18 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
if (!koutput)
return;
+ for (i = 0; i < koutput->count_props; i++) {
+ props = drmModeGetProperty(drmmode->fd, koutput->props[i]);
+ if (props && (props->flags & DRM_MODE_PROP_BLOB)) {
+ if (!strcmp(props->name, "PATH")) {
+ path_blob = drmModeGetPropertyBlob(drmmode->fd,
koutput->prop_values[i]);
+ drmModeFreeProperty(props);
+ break;
+ }
+ drmModeFreeProperty(props);
+ }
+ }
+
kencoders = calloc(sizeof(drmModeEncoderPtr), koutput->count_encoders);
if (!kencoders) {
goto out_free_encoders;
@@ -1269,7 +1338,26 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr
drmmode, drmModeResPtr mode_r
}
}
- drmmode_create_name(pScrn, koutput, name, num_dvi, num_hdmi);
+ drmmode_create_name(pScrn, koutput, name, path_blob, num_dvi, num_hdmi);
+ if (path_blob)
+ drmModeFreePropertyBlob(path_blob);
+
+ if (path_blob && dynamic) {
+ /* See
add hotplug connector support
These patches just prepare the DDX for naming DP 1.2 MST connectors properly and to expect hotplug connectors. They are ported from similiar code I wrote for the Intel DDX. kernel support for radeon MST is still WIP, but I should get these upstream I suppose. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Stride of 800x600 framebuffer
> I am very new to DRM and radeon driver, There are many concepts of Linux > graphic system I haven't acquired.I am looking help for a question about drm > framebuffer, it might be very simple to you. Why is stride of 800x600 > framebuffer is 832*4=3328? Actually the number of pitch 832 is derive from The hardware has certain limitations you have to confrom to, this is one of them, the framebuffer is most likely tiled, so has alignment requirements for the tiles. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: displayport detects monitoring, but monitor goes into power saving
On 5 August 2014 18:56, Glen Ogilvie wrote: > Hi, > > I've got a problem, that I'd like a little help with getting to the bottom > of... so looking for a little advise. > > I can't get my laptop's displayport output to drive my monitor, using the > free ati driver. It does work on the legacy driver, from ATI, however, that > only works on X <= 1.12, which is no fun to be stuck with, as no current > distro ships old versions of X. I have a 27 inch dell monitor, so using > HDMI is not great option, as it can't drive a high enough resolution to look > sharp, as I want 2560 x 1440. > > I think Bug 45291 is basically the same problem, and I've updated it to > include my hardware as well. > > I am looking for some advise, as to what I can do to help the smart graphics > driver developers here get to the bottom of this.. as it's becoming a pain > for me to live with a 4 year old Distro, or have to replace my laptop, which > is otherwise working great for me. > > I've tried kernel 3.15.6, which is a great improvement, as the power > management seems to work, so the GPU fan's don't run full speed the whole > time, but still have the issues with displayport. > > So, I assume to help, I could provide xorg logs, dmesg, lspci, dmidecode.. > but what else.. in all of these, no where can I see any errors, as the > monitor is detected.. just no output. Trying the same monitor with hdmi, > works, but the resolution is limited, as HDMI can't drive resolutions above > 1920x1200 as far as I know. file a bug on bugs.freedesktop.org, and attach a boot with drm.debug=6 to start it might be possible to work it out from there. Also the monitor model etc would be good. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: fix use-after-free in modesetting cleanup
From: Dave Airlie
noticed while looking at something else.
Signed-off-by: Dave Airlie
---
src/drmmode_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index fc99128..f22f198 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -966,8 +966,8 @@ drmmode_output_destroy(xf86OutputPtr output)
}
for (i = 0; i < drmmode_output->mode_output->count_encoders; i++) {
drmModeFreeEncoder(drmmode_output->mode_encoders[i]);
- free(drmmode_output->mode_encoders);
}
+ free(drmmode_output->mode_encoders);
free(drmmode_output->props);
drmModeFreeConnector(drmmode_output->mode_output);
free(drmmode_output);
--
1.8.5.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 1/3] radeon: fix naming clashes with multiple GPUs
On Wed, Jul 31, 2013 at 9:21 AM, wrote: > From: Alex Deucher > > The compat naming code for UMS causes problems > with multiple GPU as you may end up with the same > output name on multiple GPUs. > > This may break compatibilty with certain old setups > but it's necessary to properly handles multiple GPUs. I was going to suggest we just add something more to the name, like DVI-I-1-1 or GPU-1-DVI-1, but only do it for secondary GPUs. this would avoid clashes with other drivers in certain conditions as well. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 4/4] EXA/evergreen/ni: accelerate PictOpOver with component alpha
On Tue, Jul 23, 2013 at 8:42 AM, Grigori Goronzy wrote: > On 23.07.2013 00:30, Dave Airlie wrote: >> >> On Mon, Jul 22, 2013 at 2:06 PM, Grigori Goronzy >> wrote: >>> >>> Subpixel text rendering is typically done with a solid src and a >>> pixmap mask. Traditionally, this cannot be accelerated in a single >>> pass and requires two passes [1]. However, we can cheat a little >>> with a constant blend color. >> >> >> The hw should be able to do things in one pass with dual source blending >> afaik. >> > > Yes it can do that, and this was actually my first idea. However, dual > source blending requires additional render target state setup, modifications > to the shaders, and so on. It's likely also a bit slower than single source > blending, after all the shader needs to export twice as much data. > > It might be worthwhile to get back to this to accelerate some of the other > PictOps with component alpha, but using the constant blend color was the > easier and faster solution for the common PictOpOver case. I think it's a > nice trick, I wonder if any other driver implements it? Oh yeah I'm not saying we shouldn't merge this, it looks like a great idea for this case, and is probably faster than dual source. but yeah for the other cases I suspect a single pass is going to be faster than two passes, even with the extra overheads of dual exports. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 4/4] EXA/evergreen/ni: accelerate PictOpOver with component alpha
On Mon, Jul 22, 2013 at 2:06 PM, Grigori Goronzy wrote: > Subpixel text rendering is typically done with a solid src and a > pixmap mask. Traditionally, this cannot be accelerated in a single > pass and requires two passes [1]. However, we can cheat a little > with a constant blend color. The hw should be able to do things in one pass with dual source blending afaik. There is code in the mesa driver to setup dual src blends. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/2] radeon: add libbacklight support.
From: Dave Airlie
This adds randr BACKLIGHT and Backlight properties using libbacklight
as the backend.
Signed-off-by: Dave Airlie
---
configure.ac | 3 +++
src/Makefile.am | 7 ++-
src/drmmode_display.c | 47 +++
src/drmmode_display.h | 9 +
4 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index b4f1d4c..b47f0b7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -81,6 +81,9 @@ PKG_CHECK_MODULES(XEXT, [xextproto >= 7.0.99.1],
HAVE_XEXTPROTO_71="no")
AM_CONDITIONAL(HAVE_XEXTPROTO_71, [ test "$HAVE_XEXTPROTO_71" = "yes" ])
+PKG_CHECK_MODULES(LIBBACKLIGHT, [libbacklight], LIBBACKLIGHT="yes";
AC_DEFINE(HAVE_LIBBACKLIGHT, 1, [libbacklight available]), [LIBBACKLIGHT=no])
+AM_CONDITIONAL(LIBBACKLIGHT, [ test "$LIBBACKLIGHT" = "yes" ])
+
AC_ARG_ENABLE([udev],
AS_HELP_STRING([--disable-udev], [Disable libudev support
[default=auto]]),
[enable_udev="$enableval"],
diff --git a/src/Makefile.am b/src/Makefile.am
index 6b7171e..e777267 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -38,12 +38,17 @@ RADEON_EXA_SOURCES = radeon_exa.c r600_exa.c r6xx_accel.c
r600_textured_videofun
AM_CFLAGS = \
@LIBDRM_RADEON_CFLAGS@ \
@XORG_CFLAGS@ \
-@LIBUDEV_CFLAGS@
+@LIBUDEV_CFLAGS@ \
+ @LIBBACKLIGHT_CFLAGS@
if LIBUDEV
radeon_drv_la_LIBADD += $(LIBUDEV_LIBS)
endif
+if LIBBACKLIGHT
+radeon_drv_la_LIBADD += $(LIBBACKLIGHT_LIBS)
+endif
+
ati_drv_la_LTLIBRARIES = ati_drv.la
ati_drv_la_LDFLAGS = -module -avoid-version
ati_drv_ladir = @moduledir@/drivers
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 6874ede..629b6c3 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -50,6 +50,12 @@
#endif
#define DEFAULT_NOMINAL_FRAME_RATE 60
+#ifdef HAVE_LIBBACKLIGHT
+#define BACKLIGHT_NAME "Backlight"
+#define BACKLIGHT_DEPRECATED_NAME "BACKLIGHT"
+
+static Atom backlight_atom, backlight_deprecated_atom;
+#endif
static Bool
RADEONZaphodStringMatches(ScrnInfoPtr pScrn, const char *s, char *output_name)
@@ -876,6 +882,10 @@ drmmode_output_destroy(xf86OutputPtr output)
drmModeFreeEncoder(drmmode_output->mode_encoders[i]);
free(drmmode_output->mode_encoders);
}
+#ifdef HAVE_LIBBACKLIGHT
+ backlight_destroy(drmmode_output->backlight);
+#endif
+
free(drmmode_output->props);
drmModeFreeConnector(drmmode_output->mode_output);
free(drmmode_output);
@@ -1010,6 +1020,27 @@ drmmode_output_create_resources(xf86OutputPtr output)
}
}
}
+
+#ifdef HAVE_LIBBACKLIGHT
+{
+ RADEONInfoPtr info = RADEONPTR(output->scrn);
+ struct pci_device *dev = info->PciInfo;
+
+ drmmode_output->backlight = backlight_init(dev, 0,
mode_output->connector_type,
+ mode_output->connector_type_id);
+
+ if (drmmode_output->backlight) {
+ drmmode_output->backlight_max =
backlight_get_max_brightness(drmmode_output->backlight);
+ drmmode_output->backlight_active_level =
backlight_get_brightness(drmmode_output->backlight);
+ radeon_create_ranged_atom(output, &backlight_atom,
+ BACKLIGHT_NAME, 0,
drmmode_output->backlight_max,
+ drmmode_output->backlight_active_level,
FALSE);
+ radeon_create_ranged_atom(output, &backlight_deprecated_atom,
+ BACKLIGHT_DEPRECATED_NAME, 0,
drmmode_output->backlight_max,
+ drmmode_output->backlight_active_level,
FALSE);
+ }
+}
+#endif
}
static Bool
@@ -1020,6 +1051,22 @@ drmmode_output_set_property(xf86OutputPtr output, Atom
property,
drmmode_ptr drmmode = drmmode_output->drmmode;
int i;
+#ifdef HAVE_LIBBACKLIGHT
+if (property == backlight_atom || property == backlight_deprecated_atom) {
+ INT32 val;
+
+ if (value->type != XA_INTEGER || value->format != 32 ||
+ value->size != 1)
+ return FALSE;
+
+ val = *(INT32 *)value->data;
+ if (val < 0 || val > drmmode_output->backlight_max)
+ return FALSE;
+
+ backlight_set_brightness(drmmode_output->backlight, val);
+}
+
+#endif
for (i = 0; i < drmmode_output->num_props; i++) {
drmmode_prop_ptr p = &drmmode_output->props[i];
diff --git a/src/drmmode_display.h b/src/drmmode_display.h
index 2fccfda..3d24cf1 100644
--- a/src/drmmode_display.h
+++ b/src/drmmode_display.h
@@ -32,6 +32,10 @@
#include "libudev.h"
#endif
+#ifdef HAVE_LIBBACKLIGHT
+#include &qu
libbacklight support for randr backlight property
xbacklight and gnome would really like to use xrandr to control the backlight if possible, I've just taken the property code from intel driver, and hooked it up to libbacklight from git://git.freedesktop.org/git/libbacklight. The kernel can't deal with this due to the insanity that is ACPI and non-ACPI backlight controls, so lets just hope this works instead! I've only tested this on my T60p ancient piece of crap, appreciate any testing anyone can give it. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/2] radeon: split out radeon_create_ranged_atom for now
From: Dave Airlie
I want to use this to add randr backlight support.
Signed-off-by: Dave Airlie
---
src/drmmode_display.c | 54 ---
1 file changed, 34 insertions(+), 20 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index cd276f3..6874ede 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -912,6 +912,33 @@ drmmode_property_ignore(drmModePropertyPtr prop)
}
static void
+radeon_create_ranged_atom(xf86OutputPtr output, Atom *atom,
+ const char *name, INT32 min, INT32 max,
+ uint64_t value, Bool immutable)
+{
+int err;
+INT32 atom_range[2];
+
+atom_range[0] = min;
+atom_range[1] = max;
+
+*atom = MakeAtom(name, strlen(name), TRUE);
+err = RRConfigureOutputProperty(output->randr_output, *atom,
+ FALSE, TRUE, immutable,
+ 2, atom_range);
+if (err != 0) {
+ xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+ "RRConfigureOutputProperty error, %d\n", err);
+}
+err = RRChangeOutputProperty(output->randr_output, *atom,
+XA_INTEGER, 32, PropModeReplace, 1, &value,
FALSE, TRUE);
+if (err != 0) {
+ xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
+ "RRChangeOutputProperty error, %d\n", err);
+}
+}
+
+static void
drmmode_output_create_resources(xf86OutputPtr output)
{
drmmode_output_private_ptr drmmode_output = output->driver_private;
@@ -942,30 +969,17 @@ drmmode_output_create_resources(xf86OutputPtr output)
drmmode_prop = p->mode_prop;
if (drmmode_prop->flags & DRM_MODE_PROP_RANGE) {
- INT32 range[2];
- INT32 value = p->value;
-
p->num_atoms = 1;
p->atoms = calloc(p->num_atoms, sizeof(Atom));
if (!p->atoms)
continue;
- p->atoms[0] = MakeAtom(drmmode_prop->name,
strlen(drmmode_prop->name), TRUE);
- range[0] = drmmode_prop->values[0];
- range[1] = drmmode_prop->values[1];
- err = RRConfigureOutputProperty(output->randr_output, p->atoms[0],
- FALSE, TRUE,
- drmmode_prop->flags & DRM_MODE_PROP_IMMUTABLE ? TRUE :
FALSE,
- 2, range);
- if (err != 0) {
- xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
- "RRConfigureOutputProperty error, %d\n", err);
- }
- err = RRChangeOutputProperty(output->randr_output, p->atoms[0],
- XA_INTEGER, 32, PropModeReplace, 1, &value, FALSE, TRUE);
- if (err != 0) {
- xf86DrvMsg(output->scrn->scrnIndex, X_ERROR,
- "RRChangeOutputProperty error, %d\n", err);
- }
+
+ radeon_create_ranged_atom(output, &p->atoms[0],
+ drmmode_prop->name,
+ drmmode_prop->values[0],
+ drmmode_prop->values[1],
+ p->value,
+ drmmode_prop->flags &
DRM_MODE_PROP_IMMUTABLE ? TRUE : FALSE);
} else if (drmmode_prop->flags & DRM_MODE_PROP_ENUM) {
p->num_atoms = drmmode_prop->count_enums + 1;
p->atoms = calloc(p->num_atoms, sizeof(Atom));
--
1.8.2.1
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Problems with multiple monitors in Ubuntu 13.04
> > I have two 6450 cards in my Ubuntu 13.04 system with three monitors. This is > a recent install with no binary drivers installed and no additional X ppa's > installed. I can get X to display output on the primary monitor, and I can > see all three in xrandr: > > Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384 > HDMI-0 disconnected (normal left inverted right x axis y axis) > DVI-0 connected 2560x1440+0+0 (normal left inverted right x axis y axis) > 597mm x 336mm >2560x1440 60.0*+ > VGA-0 disconnected (normal left inverted right x axis y axis) > HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 475mm x 267mm >1920x1080 60.0*+ >1280x1024 75.0 60.0 >1152x864 75.0 >1024x768 75.1 60.0 >800x60075.0 60.3 >640x48075.0 60.0 >720x40070.1 > DVI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) > 475mm x 267mm >1920x1080 60.0*+ >1280x1024 75.0 60.0 >1152x864 75.0 >1024x768 75.1 60.0 >800x60075.0 60.3 >640x48075.0 60.0 >720x40070.1 > VGA-1 disconnected (normal left inverted right x axis y axis) > > > The second and third monitor are on (out of power save mode) but show no > input. However, XFCE seems to detect them as I have two wallpapers stacked > on top of each other, one at the main monitor's 2560x1440 resolution and one > at a 1920x1080 resolution (see > http://edolnx-public.objects.dreamhost.com/Screenshot%20-%2005072013%20-%2009_10_02%20AM.png > ). Attempting to make any changes with xrandr causes X to crash with a > SIGSEGV. Here's a log: http://paste.ubuntu.com/5640585/ Any ideas? You probably need to setup an xorg.conf like you always have before for dual-card setups like that. It might be possible to make it work better if you plug two monitors into the first card and one into second, you'll be using GPU offload, so the second GPU won't be doing anything more than displaying what the first is showing. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] radeon/man: ColorTiling2D is by default on for r6xx-cayman
Do we mention anywhere we need mesa 9.0? Dave. On Fri, Nov 2, 2012 at 10:51 PM, Alex Deucher wrote: > Pushed. thanks! > > On Fri, Nov 2, 2012 at 8:30 AM, Andreas Boll > wrote: >> Signed-off-by: Andreas Boll >> --- >> man/radeon.man |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/man/radeon.man b/man/radeon.man >> index de1f6ec..55d6bb9 100644 >> --- a/man/radeon.man >> +++ b/man/radeon.man >> @@ -237,7 +237,7 @@ will be disabled if the drm module is too old or if the >> current display configur >> does not support it. KMS ColorTiling2D is only supported on R600 and newer >> chips. >> .br >> The default value is >> -.B off >> +.B on >> for R/RV6XX, R/RV7XX, RS780, RS880, EVERGREEN, and CAYMAN. >> .TP >> .BI "Option \*qEnablePageFlip\*q \*q" boolean \*q >> -- >> 1.7.10.4 >> >> ___ >> xorg-driver-ati mailing list >> xorg-driver-ati@lists.x.org >> http://lists.x.org/mailman/listinfo/xorg-driver-ati > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master' - 8 commits
> > I think you also need to prevent the acceleration code from using > RADEON_GEM_DOMAIN_VRAM when these are used for the destination, or they > will be migrated into VRAM anyway? Yeah probably should for completeness, we should never be rendering to a slave pixmap anyways, just copying, maybe I should just block every op except copy to them. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH xf86-video-r128] Add EXA support
On Tue, Jul 17, 2012 at 6:43 PM, Michel Dänzer wrote: > On Mon, 2012-07-16 at 12:56 -0700, Connor Behan wrote: >> This introduces EXA acceleration which can improve performance and allow >> 2D acceleration to be used without XAA. Implemented hooks are Solid, >> Copy and Composite. They appear to pass all rendercheck tests, except >> the gradient test which XAA also fails. Tested on multiple color depths, >> with and without DRI, with and without the composite extension. Hardware >> cursor, Xvideo and page flipping are supported as well. >> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=47866 This patch breaks r128 build, look at tinderbox.x.org for results. But since XAA removal, info->accel isn't there, but this patch also sets info->accel = FALSE, which is totally wrong, it should at least be info->accel = NULL, surrounded by #ifdef HAVE_XAA_H Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: dropping UMS - xf86-video-ati-7.0.0
On Fri, Jun 15, 2012 at 3:53 PM, Roland Scheidegger wrote: > Am 14.06.2012 21:19, schrieb Dave Airlie: >> I'm seriously thinking of resurrecting the kms killing branch, can >> anyone give me a reason not too, >> >> we'd fork the current master into a UMS branch and move on. > > Aren't there still some OS using this driver but not supporting kms? > Though I guess it doesn't actually matter for them if they need to use > the ums branch instead... > Otherwise sounds good to me. There hasn't been anything new in UMS world really in 2-3 years, I'd rather split it off and let those who care about it deal with it, a lot of changes have broken UMS recently. So far its also 61k loc less to worry about, along with reducing the complexity of the macros and spaghetti useEXA, XAA code. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: dropping UMS - xf86-video-ati-7.0.0
On Fri, Jun 15, 2012 at 9:35 AM, Michel Dänzer wrote: > On Don, 2012-06-14 at 20:19 +0100, Dave Airlie wrote: >> I'm seriously thinking of resurrecting the kms killing branch, > > I'm not opposed, it's becoming rather painful to keep UMS building, let > alone working. > >> can anyone give me a reason not too, > > Not sure a reason is enough, someone would need to step up and take care > of UMS vs. ongoing development. > >> we'd fork the current master into a UMS branch and move on. > > Sounds good. Might even allow cleaning up the UMS code as well for > someone so inclined. Okay I've pushed a branch kms-only to the master repo I've only build tested it, now for the fun bit. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
dropping UMS - xf86-video-ati-7.0.0
I'm seriously thinking of resurrecting the kms killing branch, can anyone give me a reason not too, we'd fork the current master into a UMS branch and move on. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
radeontool 1.6.3
I've dropped a radeontool release in http://people.freedesktop.org/~airlied/radeontool/ changes below: Alex Deucher (3): add latest chip families from the ddx add radeonreg program radeonreg: add radeonreg regs all option Dave Airlie (4): evergreen : more regs radeontool: update pci ids radeontool: add support for parsing OF ibm,* setup tables update version Jonathan Nieder (12): avoid -Wformat-security warnings teach fatal() to write newline avivotool: make card detection and mapping errors non-fatal avivotool, radeonreg: make fatal errors exit use continue statement to simplify "for each PCI device" loop avivotool, radeonreg: completely skip early cards with --skip exit "for each PCI device" loop as soon as Radeon device is found radeontool, avivotool: remove unnecessary region autodetection magic switch to modern pci_device_map_range API include errno string in more messages radeontool: document functions that require mapped control region radeontool: make card detection and mapping errors non-fatal Rafał Miłecki (6): avivotool: allow reading regs from given range avivotool: allow reading basic audio info on Evergreen avivotool: allow reading HDMI related regs on R600 avivotool: dump current audio state on Evergreen avivotool: dump enabled HDMI blocks on Evergreen avivotool: dump whole HDMI block on Evergreen Tormod Volden (2): radeontool: add missing newline to error message prefix fatal error messages with "fatal error:" ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH/RFC v2 0/10] Re: avivotool: error out unless there is exactly one control and fb region
2012/3/9 Rafał Miłecki : > W dniu 28 lutego 2012 07:13 użytkownik Rafał Miłecki > napisał: >> 2012/2/25 Jonathan Nieder : >>> Alex Deucher wrote: >>> region 0 is always the frame buffer and region 2 is always mmio. radeontool and avivotool should be cleaned up the same way radeonreg is. >>> >>> Thanks, makes perfect sense. Here's a reroll that does that. >>> >>> The motivation is still patches 7 (libpciaccess API churn) and 10 >>> (unfriendly behavior when run as non-root). The rest of the patches >>> are cleanups or small potential improvements noticed in the process of >>> writing those two. >>> >>> Still untested, since my radeon is still temporarily out of >>> commission. Compiles at least. :) >> >> Seems to work on my RV620. I can still read and write regs, values look >> alright. > > Dave: have you received this patchset? Should we push this? > > I'm considering creating one more patch for avivotool, maybe you could > consider making a new release in some next future? I've pushed all of these out, not really watching this list enough. If you have another patch let me know and I can make a 1.7 release. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] radeon: r200 depth buffers are always tiled
On Mon, Dec 5, 2011 at 9:13 PM, Roland Scheidegger wrote: > Am 05.12.2011 21:51, schrieb Dave Airlie: >> On Mon, Dec 5, 2011 at 8:08 PM, Roland Scheidegger >> wrote: >>> IIRC this is not only true for r200. Might be true for r300 too, and >>> r100 (possibly not rv100) even. Looks good otherwise though. >> >> Yeah I've been trying to solve it as I find it, I found it definitely >> on rv250/rv280, r200 I'm not 100% sure on but will check that. >> >> my rv100 definitely doesn't need it, but I don't have simple access to >> an rv200 or r100 yet, might be able to get an M7 tomorrow. >> >> Good point for r300->r500 should probably check that, but we should be >> enabling tiling on those by default anyways. >> > > I think it might be always tiled for anything below r600 except the > rv100 (and the igp-based rv100s). Of course, with different tiling patterns. > I'm not 100% sure though, but I remember some differences there between > r100 and rv100 (it is possible though just the tiling pattern was > different). Okay so I've tested now on an M7 laptop, and it has always tiled depth, r200, rv250 and rv280 are always tiled, and my rv100 has never tiled. The code in mesa now passes readPixSanity on all the ancient crap^Wradeons I can beg or borrow access to. In theory color tiling should also work fine enabled, and it seems to, not seeing and piglit regressions apart from noise between tiled/untiled runs. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] radeon: r200 depth buffers are always tiled
On Mon, Dec 5, 2011 at 8:08 PM, Roland Scheidegger wrote: > IIRC this is not only true for r200. Might be true for r300 too, and > r100 (possibly not rv100) even. Looks good otherwise though. Yeah I've been trying to solve it as I find it, I found it definitely on rv250/rv280, r200 I'm not 100% sure on but will check that. my rv100 definitely doesn't need it, but I don't have simple access to an rv200 or r100 yet, might be able to get an M7 tomorrow. Good point for r300->r500 should probably check that, but we should be enabling tiling on those by default anyways. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: r200 depth buffers are always tiled
From: Dave Airlie
When we do the allocations we need to make sure the always tiled
nature is taken into account.
Signed-off-by: Dave Airlie
---
src/radeon.h |1 +
src/radeon_dri2.c |8
src/radeon_exa.c |3 +++
3 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/radeon.h b/src/radeon.h
index 34f6f53..91c7b62 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -1667,6 +1667,7 @@ static __inline__ int radeon_timedout(const struct
timeval *endtime)
enum {
RADEON_CREATE_PIXMAP_TILING_MACRO = 0x1000,
RADEON_CREATE_PIXMAP_TILING_MICRO = 0x2000,
+RADEON_CREATE_PIXMAP_DEPTH = 0x4000, /* for r200 */
};
#endif /* _RADEON_H_ */
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 8789d73..9fd3658 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -121,6 +121,8 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
flags = RADEON_CREATE_PIXMAP_TILING_MICRO;
else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferDepthStencil:
if (info->ChipFamily >= CHIP_FAMILY_R600) {
@@ -132,6 +134,8 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
need_enlarge = 1;
} else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferBackLeft:
case DRI2BufferBackRight:
@@ -271,6 +275,8 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
flags = RADEON_CREATE_PIXMAP_TILING_MICRO;
else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferDepthStencil:
/* macro is the preferred setting, but the 2D detiling for software
@@ -282,6 +288,8 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
need_enlarge = 1;
} else
flags = RADEON_CREATE_PIXMAP_TILING_MACRO |
RADEON_CREATE_PIXMAP_TILING_MICRO;
+ if (IS_R200_3D)
+ flags |= RADEON_CREATE_PIXMAP_DEPTH;
break;
case DRI2BufferBackLeft:
case DRI2BufferBackRight:
diff --git a/src/radeon_exa.c b/src/radeon_exa.c
index f3daec0..95646ab 100644
--- a/src/radeon_exa.c
+++ b/src/radeon_exa.c
@@ -473,6 +473,9 @@ void *RADEONEXACreatePixmap2(ScreenPtr pScreen, int width,
int height,
if (usage_hint & RADEON_CREATE_PIXMAP_TILING_MICRO)
tiling |= RADEON_TILING_MICRO;
}
+ if ((usage_hint & RADEON_CREATE_PIXMAP_DEPTH) && IS_R200_3D)
+ tiling |= RADEON_TILING_MACRO | RADEON_TILING_MICRO;
+
}
/* Small pixmaps must not be macrotiled on R300, hw cannot sample them
--
1.7.6.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 3/5] Fix https://bugzilla.novell.com/show_bug.cgi?id=474071.
Same problem, bug isn't public. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH 2/5] Disable DRI by default on IA64.
On Fri, Nov 4, 2011 at 3:42 PM, Johannes Obermayr
wrote:
> See: https://bugzilla.novell.com/show_bug.cgi?id=437651
> ---
You are not authorized to access bug #437651.
Open the bug or fix the commit msg :)
Dave.
> src/radeon_driver.c | 5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/src/radeon_driver.c b/src/radeon_driver.c
> index 293897a..2cfe36a 100644
> --- a/src/radeon_driver.c
> +++ b/src/radeon_driver.c
> @@ -2387,8 +2387,11 @@ static Bool RADEONPreInitDRI(ScrnInfoPtr pScrn)
> return FALSE;
> }
> }
> -
> +#if !defined (__ia64__)
> if (!xf86ReturnOptValBool(info->Options, OPTION_DRI, TRUE)) {
> +#else
> + if (!xf86ReturnOptValBool(info->Options, OPTION_DRI, FALSE)) {
> +#endif
> xf86DrvMsg(pScrn->scrnIndex, X_INFO,
> "Direct rendering forced off\n");
> return FALSE;
> --
> 1.7.7
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [Help][RS780E][mipsel]Screen corruption sometimes
2011/8/8 Chen Jie : > Hi, > > 在 2011年8月7日 下午4:35，Chen Jie 写道： >> 2011/8/4 Michel Dänzer : >>> You can try booting with radeon.test=1 and see in dmesg if the transfer >>> tests triggered by that succeed. >> Seems has some test failure, see attachment radeon.test.log > I did the same test on a x86 machine with RS780E, running ubuntu > 10.10(linux 2.6.35), BO move testing reports no error. > > Maybe some arch-depend problems? You might want to try some of 3.1-rc1 kernel drm radeon code, Ben Herrenschmidt did a bunch of powerpc fixes that might be required on MIPS. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#616301: xserver-xorg-video-radeon:screen goes black, system hangs after 2sec:[youtube(FF/Opera)-reset req.]
On Mon, Mar 7, 2011 at 4:36 AM, Ben Hutchings wrote: > On Sun, 2011-03-06 at 13:08 -0500, Alex Deucher wrote: >> On Fri, Mar 4, 2011 at 8:50 PM, Ben Hutchings wrote: >> > On Fri, 2011-03-04 at 21:01 +0200, Faidon Liambotis wrote: >> >> severity 616301 critical >> >> thanks >> > >> > No, not unless it will affect a large proportion of users. >> > >> >> My system locks up whenever I click on a YouTube video link since >> >> yesterday. I can probably live without YouTube :), but in any case this >> >> shouldn't happen. >> >> >> >> This isn't a singled out case nor in exotic, possibly faulty, hardware. >> >> It's on a standard 1½-year old Dell OptiPlex 780 desktop with a Radeon >> >> HD card (one of the standard configurations) and this is on a stock >> >> squeeze system. >> >> >> >> The findings so far seem to suggest this is a Mesa issue; I'd probably >> >> file it under "Linux kernel bugs" (or even DoS bugs) but I'm not sure >> >> where to properly file such bugs in the post-KMS stack world. >> > >> > If there is a kernel driver involved then it should be assigned to the >> > kernel. Even without KMS, a Mesa driver should be considered untrusted >> > and should not be able to trigger a crash or hang. With KMS, this >> > applies to the X driver too. >> > >> >> With or without KMS, the userspace acceleration drivers can certainly >> cause GPU hangs if the 3D engine is programmed with some combination >> of commands it doesn't like. > > You can't solve the halting problem but you can implement a watchdog, > can't you? > We do, we reset the GPU 10s after it hangs, but this depends on a lot of things going our way. Occasionally we do reset the GPU when we shouldn't as well. However if there is an issue in the kernel, ddx or mesa driver, constants resets will pretty much DoS the GPU. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Two mouse/display problems on Evergreen
On Sat, Dec 11, 2010 at 4:40 AM, Bruce Guenter wrote: > Hi. > > I'm having a problem with my X system after replacing my video card. > The mouse and display freeze for about 1/10th of a second every roughly > 10 seconds when moving the mouse. When the mouse is not moving, no > freezes are observed. I have been using glxgears as a simple program to > show the freezes, and the glitches visible in its movements are > consistent with the mouse motion pauses. As well, when the pauses > happen, the FPS reported by glxgears consistently drop by about 3-4%. > The same stalls are observed when no GL applications are running, and I > am not using a compositing window manager. Sounds like output polling but I can't see why you'd be getting it on that card. echo 0 > /sys/module/drm_kms_helper/parameters/poll Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#591061: Leak still present.
Proposed patch to remove leak attached.
Dave.
On Tue, Sep 28, 2010 at 6:42 PM, Eduardo I. wrote:
> Hi Cyril, thanks for the heads up.
>
> Unfortunately I still seem to be able to leak memory in the exact same
> way. I'm reporting this back at RH's bugzilla.
>
> I'm attaching ttm/drm related entries in vmallocinfo just in case.
>
> --
> Eduardo.
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
>
From 086970d5b8371bc38d25bfc9b3a59328bce7a6f9 Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date: Wed, 29 Sep 2010 13:31:07 +1000
Subject: [PATCH] drm/ttm: remove race and optimise evicting destroyed buffers.
A race condition was identifed that led to a leak of the BOs, when
a bo was on the delayed delete list and was selected for eviction,
the code would enter
thread 1 (evict) -- thread2 (dd)
bo added to delayed destroy list
take lru lock
ttm_mem_evict_first called
- reserve locked
- remove from lru
- drop lru lock
take lru lock
try del from lru - get put_count == 0
try to reserve locked
- drop lru lock to wait unreserved
call bo_evict
unreserve buffer
- take lru lock
- add back to lru
- unreserver
- drop lru lock
take lru lock due to unreserved
unbind ttm
drop put_count references (which is 0)
despite being on the lru/swap lru lists.
leak due to never losing reference
The obvious quick fix is to try the bo from the ddestroy list if we
are going to evict it, however if we are going to evict a buffer that
is going to be destroyed we should just destroy it instead, its more
likely to be a lighter-weight operation than evict + delayed destroy.
This patch check is a bo that we are about to evict is actually on the
destroy list and if it is, it unreserves it (without adding to lru),
and cleans up its references. It should then get destroyed via
normal ref counting means.
proposed fix for:
https://bugzilla.redhat.com/show_bug.cgi?id=615505
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=591061
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index cb4cf7e..60689b1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -689,7 +689,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
struct ttm_mem_type_manager *man = &bdev->man[mem_type];
struct ttm_buffer_object *bo;
int ret, put_count = 0;
-
+ bool destroy = false;
retry:
spin_lock(&glob->lru_lock);
if (list_empty(&man->lru)) {
@@ -719,6 +719,13 @@ retry:
}
put_count = ttm_bo_del_from_lru(bo);
+
+ /* is the buffer currently on the delayed destroy list? */
+ if (!list_empty(&bo->ddestroy)) {
+ list_del_init(&bo->ddestroy);
+ destroy = true;
+ put_count++;
+ }
spin_unlock(&glob->lru_lock);
BUG_ON(ret != 0);
@@ -726,8 +733,13 @@ retry:
while (put_count--)
kref_put(&bo->list_kref, ttm_bo_ref_bug);
- ret = ttm_bo_evict(bo, interruptible, no_wait_reserve, no_wait_gpu);
- ttm_bo_unreserve(bo);
+ if (destroy) {
+ atomic_set(&bo->reserved, 0);
+ ret = ttm_bo_cleanup_refs(bo, !no_wait_gpu);
+ } else {
+ ret = ttm_bo_evict(bo, interruptible, no_wait_reserve, no_wait_gpu);
+ ttm_bo_unreserve(bo);
+ }
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
--
1.7.2.3
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Eyefinity support
On Mon, Sep 20, 2010 at 8:36 AM, Felix Blanke wrote: > Yeah. > > I have buyed a third monitor and now need a video card for it :) > > I want to buy a HD 5770 (flex-edition from sapphire) to use 3 monitors via > DVI. > Open-source would be mutch nicer to use then the closed source driver :) Only if you use active displayport->dvi convertors. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] dri2: Reference count DRI2 buffers
2010/8/21 Oldřich Jedlička : > On Friday 20 August 2010 11:05:40 Christopher James Halse Rogers wrote: >> On Fri, 2010-08-20 at 07:55 +0200, Oldřich Jedlička wrote: >> > On Friday 20 August 2010 02:04:35 Christopher James Halse Rogers wrote: >> > > On Thu, 2010-08-19 at 21:23 +0200, Oldřich Jedlička wrote: >> > > > On Thursday 19 August 2010 10:57:21 Christopher James Halse Rogers > wrote: >> > > > > When a client calls ScheduleSwap we set up a kernel callback when >> > > > > the relevent vblank event occurs. However, it's possible for the >> > > > > client to go away between calling ScheduleSwap and the vblank >> > > > > event, resulting in the buffers being destroyed before they're >> > > > > passed to radeon_dri2_frame_event_handler. >> > > > >> > > > I was also thinking about the solution and did some xorg-server >> > > > investigation. Personally I don't like comparing pointer values >> > > > (ClientPtr), because it could be the same - sequence >> > > > malloc/free/malloc could return the same pointer value. >> > > >> > > Yeah, there is a chance that a stray DRI2_SwapBuffersComplete event >> > > could be written to an uninterested client. It certainly won't try to >> > > write to an invalid client, though, so it shouldn't crash X. And it is >> > > reasonably unlikely that a client will go away and a new client will >> > > both fill the same slot *and* get the same memory address - there's a >> > > lot of memory allocation going on in the surrounding code. >> > >> > Question is if the client can handle this :-) >> > >> > > > Here are two other possible solutions: >> > > > >> > > > 1. Add a "uniqueId" (increasing number with each client) to >> > > > ClientRec. Then you can compare something really unique. On the >> > > > other hand this needs change in xorg-server. >> > > > >> > > > 2. Use AddCallback(&ClientStateCallback, >> > > > our_client_state_changed_method, 0) during driver initialization to >> > > > detect that any client went away and invalidate its events (add >> > > > field "valid" in event). That would be even better than solution 1 - >> > > > no change of xorg-server is needed. Each client could have private >> > > > data too - double-linked list of pending events - registered with >> > > > dixRegisterPrivateKey(). The event would be removed from the list >> > > > only when it is valid (otherwise the prev/next list pointers would >> > > > be invalid too). Invalid events would be ignored in the handler, >> > > > they would be only freed. >> > > >> > > I thought about that, too. It seemed a bit excessive for the driver to >> > > maintain a list of clients as they come and go just for the purpose of >> > > not sending an event when a client quits. >> > >> > There is no need to have a list of clients. Each client would have the >> > list of events kept in the client's devPrivate area (registered with >> > dixRegisterPrivateKey, found by dixLookupPrivate) - ony the event list >> > head is necessary: >> > >> > 1. The event would have "prev" and "next" pointers for the purposes of >> > the list and a new "valid" boolean field. >> > >> > 2. Register Client State callback by the call to AddCallback and call >> > dixRegisterPrivateKey in the driver initialization routine. Add >> > RemoveCallback in the driver shut-down routine. >> > >> > 3. Whenever new client connects, the list head would be set to 0 (done in >> > the Client State callback). This step is probably unnecessary if the >> > area is set to 0 via calloc (I'm just not sure). >> > >> > 4. Whenever the new event is created, dixLookupPrivate would get the >> > client's list head and the new event would be added to the list head. >> > >> > 5. Whenever the client dies (recognized in the Client State callback), >> > the list would be walked-through and events invalidated (valid=false). >> > >> > 6. For valid events (valid==true) on event callback the event would be >> > removed from the list (just modify the event's prev's "next" and event's >> > next's "prev" pointers, eventually modifying the client's list head). >> > >> > 7. For invalid events (valid==false) the list would stay unmodified >> > (because of the list head modification on freed client's memory), only >> > the event would be freed. >> > >> > This looks to me like a few lines of code for each point, nothing big. >> >> Ah, right. That's the reverse of what I was thinking; it's more >> reasonable. >> >> It still seems a bit heavyweight to me for this corner case. > > Yeah, looks so. I think it is now the ATI driver developpers turn to say what > they want - if your patch is good or needs enhancing. > >> > > The pointer comparison is quick, cheap, and ensures we won't crash X. >> > >> > Yes, that should work most of the time :-) But this might add some >> > hard-to- reproduce problem with client getting unwanted message. >> > >> > > > Personally I like solution 2, because it fully uses xorg-server >> > > > facilities. But I don't know if this isn't too much or if there >> > > > e
Re: Debian bugs: 588601, 588602: xpress 200m 5955 => resume from suspend fails with KMS enabled
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=580b4fffbbdc3c899ee1f8189ba321bd60b48840 I added this qurik upstream, it may need to be extended to other rs4xx, its worth a try. Dave. On Sat, Jul 10, 2010 at 4:13 PM, Andres Cimmarusti < andrescimmaru...@yahoo.com> wrote: > I dedicated a large portion of the day to finding a clue to this one. > Following this advice: > http://lxr.linux.no/#linux+v2.6.34.1/Documentation/power/s2ram.txt > I was able to extract a trace from the failed resume process: > > Magic number: 0:981:799 > hash matches drivers/base/power/main.c:523 > pci :01:05.0: hash matches > ec PNP0C09:00: hash matches > > The first hash match is none other than my ATI Radeon card as I easily > verified with lspci: > > 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M > 5955 (PCIE) > > However, the above link says that the likely culprit in the failed resume > process is the last hash match. This corresponds to the EC driver: > http://lxr.free-electrons.com/source/drivers/acpi/ec.c > > My card was, till recently, listed under embedded graphics at the AMD/ATI > website. So there appears to be some conflict when using KMS between radeon > and ec that causes the kernel to hang (that explains why I can't ssh into my > computer to get a trace). For this reason I've cloned the original bug and > reported the copy as a kernel bug. > I will try to delve deeper into the matter by activating more verbose > debugging symbols for acpi. > > I would appreciate some advice and guidance, since I'm flying half-blind (I > will try to follow the information present here > http://ubuntuforums.org/showthread.php?t=505890) > > Cheers, > > Andres > > > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[ANNOUNCE] xf86-video-ati 6.13.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stable release of xf86-video-ati for the 6.13.x series. Main features: server 1.9 support, evergreen accel disabled explicitly, kms uevent + sync support, rn50 fixes, enable color tiling on kms on r300->r500. xv cleanup and large vertex number fixes. Alex Deucher (35): change version post release radeon: don't setup Xv on rn50 radeon: add some new pci ids Xv overlay: set scalerwidth to 1920 on r3xx/r4xx chips atom: disable TV encoder when VGA is in use radeon: add support for pll algo selection radeon/kms: fix crash when using more than two heads radeon/kms: fix possible crtc mask for evergreen Xv: track vtx_count, is_planar in port priv r1xx textured video: split into prepare and draw functions r2xx textured video: split into prepare and draw functions r3xx textured video: split into prepare and draw functions r5xx textured video: split into prepare and draw functions r1xx texvid: deal with large numbers of verts r2xx texvid: deal with large numbers of verts r3xx texvid: deal with large numbers of verts r5xx texvid: deal with large numbers of verts r3xx-r5xx: fix vertex units r3xx: fix gb pipe setup for SE cards radeon: fix pll_out_min default for pre-avivo r1xx/r2xx EXA: handle RepeatNone properly with transforms r2xx exa: fix typo in 27c3326863deae36bc35e2c3b73fffd400208ff1 dri2: use radeon_pick_best_crtc() evergreen: explicitly disable accel on evergreen radeon: fix rn50 cloning with kms r6xx/r7xx accel: remove some duplicate emits and minor clean up r6xx/r7xx: reorg default and clipping state emit r6xx/r7xx: remove unnecessary state emit r3xx-r5xx Xv: disable bicubic filtering by default radeon: fix depth 16 with ums r6xx/r7xx: macro safety fixes r6xx/r7xx accel: add back some additional default state r6xx/r7xx: fix miscount in state emit r6xx shader: use ADDR() for CF_DWORD0 remove rv100 quirk Cooper Yuan (1): Remove HDP_SOFT_RESET function, there is no need to reset HDP block. Dave Airlie (8): kms: add uevent support. radeon: add FireMV 2400 pci id. xv: fix Xv on M6/RV100 under KMS. drmmode: fix big endian issue with properties. radeon: set proper stride for cursor in tiling flags. radeon: fixup last fix, use CURSOR_WIDTH not RADEON_CURSOR_WIDTH. radeon: fix support for 1.9 server master. set version for release Gaetan Nadon (1): COPYING: replace stub file with actual copyright notices Jerome Glisse (1): kms: add support for the MSC swap & sync API Marek Olšák (3): r3xx-r5xx: fix texturing with small macrotiled pixmaps rs740: follow macro-switch too r3xx-r5xx: enable color tiling by default on KMS Michel Dänzer (3): FB/MMIO_cnt should be ints, not pointers. Convert x(c)alloc/xfree to m/calloc/free. DRI2: Fix up confusion between windows and pixmaps. Owain Ainsworth (1): Reference count shared driver mappings. Owain G. Ainsworth (3): Remove remnants of the ShowCache option. Kill per-context SAREA support. Make consistent use of fbOffset and share fb mappings. Wolfram (1): r6xx/r7xx: fix ums cmd buffer leak git tag: xf86-video-ati-6.13.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.13.1.tar.bz2 MD5: d65ae11cc66146c7006dbf5acebde413 xf86-video-ati-6.13.1.tar.bz2 SHA1: 74a8e647e3149af0b1eb1baf58ef1b69b44f0228 xf86-video-ati-6.13.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.13.1.tar.gz MD5: 7f76bb3503eebe328a48733fa22ae7a8 xf86-video-ati-6.13.1.tar.gz SHA1: 913f9c15e53e7aed32aa8ec5d265875892932879 xf86-video-ati-6.13.1.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkwz0aAACgkQ6acWQe8WxxrhPwCeMJ9Y00/THlaKSkAOpG04rIR6 d+0AoKee2Crf5Bk1i9YNi9YczCseom5X =Vzhn -END PGP SIGNATURE- ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
radeon-vbos branch
I've just pushed a branch with a patch in it to use VBOs for vertex data on r300->r500 GPUs. This should provide a benefit due to the vertex data no longer having to be copied to the GPU in-kernel, and also allowing more state to be in a single indirect buffer. It is only enabled under KMS. It needs a bit more testing before I push it to master, in theory r100 and r200 could be ported to use the code as well. On my rv370 Lenovo T43 laptop, this gets x11perf aa10text from 320 reps @ 0.0020 msec (507000.0/sec): Char in 80-char aa line (Charter 10) to 320 reps @ 0.0018 msec (546000.0/sec): Char in 80-char aa line (Charter 10) Thats a fairly lowly by today's standards Pentium-M 1.8. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Error in rs400_gart_adjust_size
On Sun, Apr 25, 2010 at 11:58 PM, Jerome Glisse wrote: > On Sat, Apr 24, 2010 at 02:17:50PM +0200, Daniel Klaffenbach wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi everyone, >> >> I noticed a strange line in dmesg when KMS is enabled and I wondered how to >> get rid of it: >> >> [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size (because of >> ASIC >> bug ?) >> >> KMS is very unstable for me and I feel like this error could be a reason. >> >> This is the device in question: >> > > We have to play somemore with X200M but i think we had issue with GART > size bigger than 32M in the past, i am adding that to my todo list. > I will keep you posted. from memory it was rs480+4GB RAM where the issue arose. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: HD5770 bringup
On Sun, Apr 11, 2010 at 6:00 AM, Mark Knecht wrote: > OK, so I'm searching around for instructions on doing right this but > I'm not finding them yet. That's leaving me poking around and of > course that never goes well. I'll post some data and keep some records > in case others try this again later. I don't want to post here too > much and wear out my welcome but I really want to see a desktop today > if possible. Don't use radeonhd, use -ati or radeon (same thing) Also get a really recent kernel with evergreen support for KMS, the UMS support isn't great and will probbaby remain sub-par. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] Mark highly predictable branches as likely/unlikely
On Wed, 2010-04-07 at 19:25 -0400, Matt Turner wrote: > On Wed, Apr 7, 2010 at 7:15 PM, Dave Airlie wrote: > > On Wed, 2010-04-07 at 18:49 -0400, Matt Turner wrote: > >> Highly predicatble branches include > >> - unlikely: error conditions, such as those leading to > >> - RADEON_FALLBACK > >> - goto fail > >> - return FALSE (as an error > >> - likely: if (info->useEXA) > > > > Can we limit these to fastpaths? > > > > i.e. no need in atombios or drmmode code or anywhere like that. > > > > I expect you just want it in the accel/exa/xv codepaths. > > > > Dave. > > Sure. I can strip out the others and resend if you'd like, or you > could just commit the parts you think are appropriate. I don't imagine > there would be any ill effects from including the patch for files like > src/atombios_output.c|2 +- > src/drmmode_display.c|6 +- > though. This wasn't a blind find'n'replace, so the ones included > should be pretty good. Its more for our sanity, and future maintainance cost. likely/unlikely isn't worth the effort, also these have to be maintained going forward, in case some path becomes more likely or unlikely. The kernel has a real problem using these in the wrong places and I'd hate for it to spread. like when the standard code was for kfree was if (ptr) kfree(ptr) and kfree contains an if (unlikely(!ptr)), then someone removed all the if (ptr) and it suddenly became a lot more likely. Dave. > > Thanks, > Matt ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: R600, S-Video TV out for PAL, and horizontal rolling
Not sure it ever worked I think I remembered seeing something similiar last time I tried PAL I just haven't had time to get back to it. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: ATI 6.12.4 on ultraSparc runs slow
On Thu, Mar 25, 2010 at 8:05 AM, Alex Deucher wrote: > 2010/3/24 jean-francois simon : >> >> 2010/3/24 Michel Dänzer >>> >>> > so it is PIO not DMA? just curious, where is the code that is doing >>> > that transfer? >>> >>> shadowUpdatePacked() in xserver/miext/shadow/shpacked.c . >>> >>> >> very interesting thanks. >> i can see that this transfer is being triggered by something called the >> shadow block handler. and i am thinking maybe this is not done often enough, >> thus explaning the slow videos? > > More likely the write to vram performance is better on x86 since you > are using write combining. Yes definitely this, most non-x86 CPUs don't have mtrr/write combining support, which really helps for shadowfb situations. The only thing I can think to do is possible some sparc specific optimisations to the copying that may or may not speed it up. I know Linux/sparc has mostly working DRM, since davem plays quake3 on his. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Release planned for KMS/kernel 2.6.33?
2010/2/27 Ernst Sjöstrand : > Hasn't there been exceptionally few releases recently? > Maybe there's a point in making releases more often in the future, the whole > release early release often principle. Shorter iterations with a more > defined scope, etc... > > Or maybe this was just because of the KMS transition and it will never > be like this again? KMS is all that has been happening really, I suppose some stuff has gone into master we should have released like displayport, but I don't think the UMS paths have seen a lot of testing outside myself/Alex. But yeah we've mainly be waiting for KMS kernel side to be out of staging. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: ATI Rage Mobility P/M - Mach64 kernel module source - is it available anywhere?
> > I found a couple of well-documented posts relative to this issue, which > indicate that the source was recently removed from the mesa/drm tree at > anongit.freedesktop.org and is now available in the kernel tree under > drivers/gpu/drm directory. Its still not upstream, we'd need to clean the code up from the libdrm (its in the version control just not in master, you need to back a few tags) The code would need to be ported to the kernel (maybe in staging) then make to pass checkpatch.pl Dave. > > Since I did no see anything with a file name such as mach64.c in this > directory, I was wondering if the source was available anywhere at this > point in time, and if not, if there are any plans to reinstate it. > > Thanks, > > CJ > > > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon : Exclude some memory zone
2010/1/11 Jerome Glisse : > On Sun, Jan 10, 2010 at 07:06:41PM +0100, José JORGE wrote: >> A Segunda 04 Janeiro 2010 23:46:32 José JORGE você escreveu: >> > The question : is it possible by myself to change the radeon driver to >> > ignore a memory zone of a video card? Something like the badram patch for >> > linux kernel? >> Just if someone had the time to answer simply forget it, or maybe done with >> lots of work, I'd thank him... > > It's doable, i think best way would be to allocate a serie of BO > covering the damaged area using the new ttm allocator which allow > to specify addr of BO. Then you need to pin all those BO. Maybe > the trickier part is to design the commandline argument to allow > such thing. Most GPU memory is interleaved so if one chip is broken you can't just ignore it linearly, its probably possible to reconfigure the memory controller but I can't imaging a 256-bit memory bus working at 192-bit so well, and you'd lose more than one RAM chip. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: RV710 much slower on kms
On Sat, Dec 26, 2009 at 2:54 AM, Dr. David Alan Gilbert wrote: > Hi, > I'm running an RV710 on 2.6.33-rc2 and it works great without KMS; > but with KMS it's a lot slower and I can see X eating a lot of CPU > even when not much is happening. > > It seems to start off OK, but then really starts eating it - I've > seen X eating ~80% of one core running a simple flash game, and even > saw the system when apparently idle eating over 50% of one core > (but that stopped after reboot). The CPU is an i7-860. > The time in that last idle case all seems to be userspace time, > strace'ing X shows it was doing a lot of ioctl's to the DRI. > > I'm running X 1.6.5 (I'm using the Ubuntu xorg-edgers packages for everything > other than the kernel; I'm on Ubuntu 9.10 as the base system). > > I've included two xorg.0.log's; one with kms and one without. > > If you need any other debug, just ask. Get a new X server really is the answer, 1.7.x has improved EXA mainly to deal with kms drivers. radeon KMS on pre-1.7 servers isn't something I'd forsee a distro wanting to ship. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Releases question
2009/12/17 Tomáš Chvátal : > Hi, > I would like to ask you to start considering creating some rc/beta/alpha > snapshot of upcoming driver series 6.13 (or what ever you decide to call > it). > > There are quite few users trying to test the KMS features and i was > pointing them out to our live package for ATI drivers, but i think it > might be more convinient to provide some snapshot for them (commits > fixing the KMS behaviour in the driver itself are not so common lately > so it might be possible). We might have an ABI break on libdrm_radeon to make it maintainable which would make having any sort of released tarball a pain. when we move the kernel driver out of staging it should all trickle down. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [PATCH] Fix unused variable warnings.
On Tue, Dec 1, 2009 at 11:26 AM, Kusanagi Kouichi wrote: > On 2009-11-30 11:13:20 -0500, Alex Deucher wrote: >> On Thu, Nov 26, 2009 at 11:30 PM, Kusanagi Kouichi >> wrote: >> > r6xx_accel.c: In function 'wait_3d_idle_clean': >> > r6xx_accel.c:117: warning: unused variable 'info' >> > r6xx_accel.c: In function 'wait_3d_idle': >> > r6xx_accel.c:132: warning: unused variable 'info' >> > r6xx_accel.c: In function 'cp_set_surface_sync': >> > r6xx_accel.c:282: warning: unused variable 'info' >> > r6xx_accel.c: In function 'fs_setup': >> > r6xx_accel.c:385: warning: unused variable 'info' >> > r6xx_accel.c: In function 'vs_setup': >> > r6xx_accel.c:408: warning: unused variable 'info' >> > r6xx_accel.c: In function 'ps_setup': >> > r6xx_accel.c:435: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_alu_consts': >> > r6xx_accel.c:465: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_bool_consts': >> > r6xx_accel.c:479: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_vtx_resource': >> > r6xx_accel.c:491: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_tex_resource': >> > r6xx_accel.c:524: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_tex_sampler': >> > r6xx_accel.c:591: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_screen_scissor': >> > r6xx_accel.c:643: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_vport_scissor': >> > r6xx_accel.c:656: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_generic_scissor': >> > r6xx_accel.c:672: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_window_scissor': >> > r6xx_accel.c:686: warning: unused variable 'info' >> > r6xx_accel.c: In function 'set_clip_rect': >> > r6xx_accel.c:700: warning: unused variable 'info' >> > r6xx_accel.c: In function 'draw_immd': >> > r6xx_accel.c:1109: warning: unused variable 'info' >> > r6xx_accel.c: In function 'draw_auto': >> > r6xx_accel.c:1147: warning: unused variable 'info' >> > >> > These are really unused. >> >> info is used in the accel macros when XF86DRM_MODE is defined. >> >> Alex > > Oops! Then, how about this patch? I've fixed this properly in the patch I just pushed to -ati. without ugly ifdefs. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH] radeon: avoid using hw pixmaps when we have little VRAM.
From: Dave Airlie
This patch returns NULL for pixmap creation when we are using
mixed pixmaps and the pixmap has a size.
The size check is necessary for the front buffer.
We add a flag to force pixmap creation for certain pixmaps
that need to be hw, like the DRI2 and Xv ones.
Idea from Michel and workarounds from Ben Skeggs.
Signed-off-by: Dave Airlie
---
src/radeon.h|1 +
src/radeon_dri2.c |8
src/radeon_exa.c| 12 +++-
src/radeon_textured_video.c |2 ++
4 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/src/radeon.h b/src/radeon.h
index 5cdc3db..c959c56 100644
--- a/src/radeon.h
+++ b/src/radeon.h
@@ -888,6 +888,7 @@ typedef struct {
Bool accelOn;
Bool useEXA;
#ifdef USE_EXA
+Bool exa_force_create;
XF86ModReqInfoexaReq;
#endif
#ifdef USE_XAA
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index db46d27..56c00a3 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -65,6 +65,8 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
int count)
{
ScreenPtr pScreen = drawable->pScreen;
+ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
+RADEONInfoPtr info = RADEONPTR(pScrn);
BufferPtr buffers;
struct dri2_buffer_priv *privates;
PixmapPtr pixmap, depth_pixmap;
@@ -120,7 +122,9 @@ radeon_dri2_create_buffers(DrawablePtr drawable,
if (attachments[i] == DRI2BufferDepth) {
depth_pixmap = pixmap;
}
+ info->exa_force_create = TRUE;
exaMoveInPixmap(pixmap);
+ info->exa_force_create = FALSE;
driver_priv = exaGetPixmapDriverPrivate(pixmap);
r = radeon_gem_get_kernel_name(driver_priv->bo, &buffers[i].name);
if (r)
@@ -143,6 +147,8 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
unsigned int format)
{
ScreenPtr pScreen = drawable->pScreen;
+ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
+RADEONInfoPtr info = RADEONPTR(pScrn);
BufferPtr buffers;
struct dri2_buffer_priv *privates;
PixmapPtr pixmap, depth_pixmap;
@@ -198,7 +204,9 @@ radeon_dri2_create_buffer(DrawablePtr drawable,
if (attachment == DRI2BufferDepth) {
depth_pixmap = pixmap;
}
+info->exa_force_create = TRUE;
exaMoveInPixmap(pixmap);
+info->exa_force_create = FALSE;
driver_priv = exaGetPixmapDriverPrivate(pixmap);
r = radeon_gem_get_kernel_name(driver_priv->bo, &buffers->name);
if (r)
diff --git a/src/radeon_exa.c b/src/radeon_exa.c
index 99a93a4..a985624 100644
--- a/src/radeon_exa.c
+++ b/src/radeon_exa.c
@@ -391,6 +391,11 @@ void *RADEONEXACreatePixmap(ScreenPtr pScreen, int size,
int align)
RADEONInfoPtr info = RADEONPTR(pScrn);
struct radeon_exa_pixmap_priv *new_priv;
+if (info->accel_state->exa->flags & EXA_MIXED_PIXMAPS) {
+if (size != 0 && !info->exa_force_create && info->vram_size <=
(32*1024*1024))
+return NULL;
+}
+
new_priv = xcalloc(1, sizeof(struct radeon_exa_pixmap_priv));
if (!new_priv)
return NULL;
@@ -421,7 +426,12 @@ void *RADEONEXACreatePixmap2(ScreenPtr pScreen, int width,
int height,
uint32_t size;
uint32_t tiling = 0;
int pixmap_align = 0;
-
+
+if (info->accel_state->exa->flags & EXA_MIXED_PIXMAPS) {
+if (width != 0 && height != 0 && !info->exa_force_create &&
info->vram_size <= (32*1024*1024))
+return NULL;
+}
+
if (usage_hint) {
if (info->allowColorTiling) {
if (usage_hint & RADEON_CREATE_PIXMAP_TILING_MACRO)
diff --git a/src/radeon_textured_video.c b/src/radeon_textured_video.c
index 39c7574..7396f6f 100644
--- a/src/radeon_textured_video.c
+++ b/src/radeon_textured_video.c
@@ -349,7 +349,9 @@ RADEONPutImageTextured(ScrnInfoPtr pScrn,
#ifdef USE_EXA
if (info->useEXA) {
/* Force the pixmap into framebuffer so we can draw to it. */
+ info->exa_force_create = TRUE;
exaMoveInPixmap(pPriv->pPixmap);
+ info->exa_force_create = FALSE;
}
#endif
--
1.6.5.2
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: broken msi interrupts with radeon rv570 on amd 8151 agp bridge
On Fri, Nov 6, 2009 at 6:10 AM, Alex Deucher wrote: > On Thu, Nov 5, 2009 at 9:06 AM, Matthew Wilcox wrote: >> On Thu, Nov 05, 2009 at 01:57:10PM +0100, Daniel Vetter wrote: >>> When starting a failsafe X session and starting glxgears (which should >>> cause plenty of interrupts to be generated), /proc/interrupts shows >>> absolutely no MSI interrupts arriving. There are no other devices in this >>> box using MSI interrupts. >>> >>> I've also tried with the lastest -linus git tree merged in, with the same >>> effects. >>> >>> Booting with "pci=nomsi" works around the issue. I dunno whether this is a >>> pci or radeon issue therefore I'm posting to both lists. lspci -v (as >>> root) is attached below. >> >> That sucks, and we need to fix it. >> >> It's almost certainly a chipset issue, so my suspicion falls primarily >> on this device: >> 04:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8151 AGP Bridge (rev >> 14) (prog-if 00 [Normal decode]) >> >> We have a number of quirks to handle MSIs (both disabling their use, and >> programming the feature in bridges that the BIOS forgot to set up) on >> HyperTransport machines already; could you send both lspci -t and >> lspci -vvvnn (as root) to the linux-pci list? > > > While working on irq support for newer radeons I've noticed a similar > issue on an rs780 board, but only with the integrated graphics chip > (1002:9610). MSIs work fine on the PCIE slots and other integrated > peripherals. When I enable MSIs on the integrated graphics chip, I > get no MSI interrupts arriving for that device. Other MSI enabled > devices work fine. I haven't had a chance to test any other rs780 > systems with integrated graphics yet. > Actually I suspect this is different, I'm guessing the PCIE<->AGP bridge on the radeon card is screwing up the MSI, I suspect we shouldn't enable MSI on AGP cards ever. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master'
> > > > radeon: fix build without kms > > Sorry about that, I'll try to check this before pushing in the future. > > Thanks for fixing it up. > No worries I'm starting to wonder if I can come up with a cleaner away, because I never test this build path either. Dave. > > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master'
2009/9/1 Michel Dänzer :
> On Mon, 2009-08-31 at 22:24 -0700, Dave Airlie wrote:
>>
>> commit 22fbd6476f4b3513378e848affc4dd269e9d4498
>> Author: Dave Airlie
>> Date: Tue Sep 1 15:22:57 2009 +1000
>>
>> r100/r200: seriously WRAP is illegal for rectangular textures
>>
>> unless we scale all the bos up to POT
>>
>> diff --git a/src/radeon_exa_render.c b/src/radeon_exa_render.c
>> index 69d8140..c3beadc 100644
>> --- a/src/radeon_exa_render.c
>> +++ b/src/radeon_exa_render.c
>> @@ -415,7 +415,10 @@ static Bool FUNC_NAME(R100TextureSetup)(PicturePtr
>> pPict, PixmapPtr pPix,
>>
>> switch (repeatType) {
>> case RepeatNormal:
>> - txfilter |= RADEON_CLAMP_S_WRAP | RADEON_CLAMP_T_WRAP;
>> + if (txformat & RADEON_TXFORMAT_NON_POWER2)
>> + txfilter |= RADEON_CLAMP_S_CLAMP_LAST |
>> RADEON_CLAMP_T_CLAMP_LAST;
>> + else
>> + txfilter |= RADEON_CLAMP_S_WRAP | RADEON_CLAMP_T_WRAP;
>
> This code doesn't make much sense as is - such a condition should have
> been caught earlier. Maybe R[12]00TextureSetup need the same code as
> R300TextureSetup for info->accel_state->need_src_tile_[xy] or something
> like that.
Ah I'll investigate that tomorrow, that might make more sense.
Dave.
>
>
> --
> Earthling Michel Dänzer | http://www.vmware.com
> Libre software enthusiast | Debian, X and DRI developer
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-driver-ati
>
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: KMS
On Tue, Aug 25, 2009 at 9:31 AM, James Cloos wrote: >> can you post the output of dmesg after loading the radeon drm? > > There is no printk() output when X starts. I used to get: > > Aug 19 05:21:55 [kernel] agpgart-intel :00:00.0: AGP 2.0 bridge > Aug 19 05:21:55 [kernel] agpgart-intel :00:00.0: putting AGP V2 device > into 4x mode > Aug 19 05:21:55 [kernel] radeonfb :01:00.0: putting AGP V2 device into 4x > mode > Aug 19 05:21:55 [kernel] [drm] Setting GART location based on new memory map > Aug 19 05:21:55 [kernel] [drm] Loading R100 Microcode > Aug 19 05:21:55 [kernel] [drm] writeback test succeeded in 1 usecs > > but now get nothing since I turned on CONFIG_DRM_RADEON_KMS and > recompiled ati with enable-kms (and recompiled everything else, too). > sounds like you are missing fbcon support maybe. CONFIG_FRAMEBUFFER_CONSOLE. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master' - 2 commits
> On Sat, 2009-08-22 at 04:18 -0700, Dave Airlie wrote:
> > src/radeon_exa.c |3 +--
> > src/radeon_exa_funcs.c | 35 +++
> > 2 files changed, 36 insertions(+), 2 deletions(-)
> >
> > New commits:
> > commit bac224912c750dc1c85ff2d9b8526dad6c23b572
> > Author: Dave Airlie
> > Date: Sat Aug 22 21:17:59 2009 +1000
> >
> > radeon: don't spec any initial placement for pixmaps.
> >
> > allow the first use to decide placement.
> >
> > diff --git a/src/radeon_exa.c b/src/radeon_exa.c
> > index ec65722..3f3c9ba 100644
> > --- a/src/radeon_exa.c
> > +++ b/src/radeon_exa.c
> > @@ -391,8 +391,7 @@ void *RADEONEXACreatePixmap(ScreenPtr pScreen, int
> > size, int align)
> > return new_priv;
> >
> > new_priv->bo = radeon_bo_open(info->bufmgr, 0, size,
> > - align, RADEON_GEM_DOMAIN_VRAM |
> > - RADEON_GEM_DOMAIN_GTT, 0);
> > + align, 0, 0);
> > if (!new_priv->bo) {
> > xfree(new_priv);
> > ErrorF("Failed to alloc memory\n");
>
> IME this has a significant impact on 2D performance (e.g. x11perf
> -aa10text drops from about 325K/s to about 225K/s, and this is
> noticeable in real apps), until the kernel side avoids unnecessary BO
> copies.
The problem is the API is specced as initial_domain, not domains, so
its incorrect. I'm writing a TTM patch at the moment to avoid BO copies
to VRAM where nothing has yet mapped or touched the BO.
Dave.
>
> Also, current EXA (with EXA_MIXED_PIXMAPS) actually only calls the
> driver CreatePixmap(2) hook just before the first accelerated operation
> on the pixmap. So I'd suggest setting RADEON_GEM_DOMAIN_VRAM |
> RADEON_GEM_DOMAIN_GTT in both hooks.
>
>
> > commit 77f98717d825162da106c6898cdbcbdf5c984ae6
> > Author: Dave Airlie
> > Date: Sat Aug 22 21:16:25 2009 +1000
> >
> > exa/cs: add DFS from GTT optimisation
> >
> > This uses the new libdrm busy interface, once I had this in place
> > I added a error if this happened and it does on my desktop here,
> > so may as well add the optimisation that used to be in my old KMS tree.
> >
> > Signed-off-by: Dave Airlie
> >
> > diff --git a/src/radeon_exa_funcs.c b/src/radeon_exa_funcs.c
> > index e48317f..f937c4e 100644
> > --- a/src/radeon_exa_funcs.c
> > +++ b/src/radeon_exa_funcs.c
> > @@ -507,6 +507,33 @@ out:
> > }
> >
> > static Bool
> > +RADEONDownloadFromScreenGTT(PixmapPtr pSrc, int x, int y, int w,
> > + int h, char *dst, int dst_pitch)
> > +{
> > +struct radeon_exa_pixmap_priv *driver_priv;
> > +int src_pitch = exaGetPixmapPitch(pSrc);
> > +int bpp = pSrc->drawable.bitsPerPixel;
> > +int src_offset;
> > +int r;
> > +
> > +driver_priv = exaGetPixmapDriverPrivate(pSrc);
> > +r = radeon_bo_map(driver_priv->bo, 0);
> > +if (r)
> > + return FALSE;
> > +
> > +src_offset = (x * bpp / 8) + (y * src_pitch);
> > +w *= bpp / 8;
> > +
> > +while (h--) {
> > +memcpy(dst, driver_priv->bo->ptr + src_offset, w);
> > +src_offset += src_pitch;
> > +dst += dst_pitch;
> > +}
> > +radeon_bo_unmap(driver_priv->bo);
> > +return TRUE;
> > +}
> > +
> > +static Bool
> > RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int y, int w,
> > int h, char *dst, int dst_pitch)
> > {
> > @@ -519,11 +546,19 @@ RADEONDownloadFromScreenCS(PixmapPtr pSrc, int x, int
> > y, int w,
> > unsigned bpp = pSrc->drawable.bitsPerPixel;
> > uint32_t scratch_pitch = (w * bpp / 8 + 63) & ~63;
> > Bool r;
> > +uint32_t src_domain;
> > +int busy;
> >
> > if (bpp < 8)
> > return FALSE;
> >
> > driver_priv = exaGetPixmapDriverPrivate(pSrc);
> > +
> > +busy = radeon_bo_is_busy(driver_priv->bo, &src_domain);
> > +
> > +if (src_domain == RADEON_GEM_DOMAIN_GTT)
> > + return RADEONDownloadFromScreenGTT(pSrc, x, y, w, h,
> > + dst, dst_pitch);
>
> RADEONDownloadFromScreenGTT is superfluous, just return FALSE from
> RADEONDownloadFromScreenCS. Also, this doesn't take into account any
> unflushed operations involving the BO.
>
> Below is what I've been testing
Re: Problems with KMS on RS690
On Thu, Jul 16, 2009 at 10:01 AM, Mike Lothian wrote: >> >> You have two cards in that machine? >> >> Dave. >> > > Actually yes > > I've got a Radeon 4650 in there but I'm not using it, should I remove > it completely? > > I was going to switch back to it once the r700 branch is ready > > I thought I'd disabled it completely in the bios I think we have a bug in the kms radeon driver with multi-card, need to investigate. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Problems with KMS on RS690
On Thu, Jul 16, 2009 at 12:55 AM, Mike Lothian wrote: > I'm using that kernel branch > > For libdrm: > > ./configure --prefix=/usr --build=x86_64-pc-linux-gnu > --host=x86_64-pc-linux-gnu --mandir=/usr/share/man > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc > --localstatedir=/var/lib --libdir=/usr/lib64 --prefix=/usr > --datadir=/usr/share --enable-udev --enable-nouveau-experimental-api > --enable-radeon-experimental-api > > * Messages for package x11-libs/libdrm-: > > * GIT update --> > * repository: git://anongit.freedesktop.org/git/mesa/drm > * git fetch -f -u origin master:master > * at the commit: 3f3c5be6f908272199ccf53f108b1124bfe0a00e > * branch: master > > > Fir DDX: > > ./configure --prefix=/usr --build=x86_64-pc-linux-gnu > --host=x86_64-pc-linux-gnu --mandir=/usr/share/man > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc > --localstatedir=/var/lib --libdir=/usr/lib64 --prefix=/usr > --datadir=/usr/share --enable-dri > > > * Messages for package x11-drivers/xf86-video-ati-: > > * GIT update --> > * repository: > git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati > * at the commit: 95d431e8b260dd43cf6d93b90eecab1dc0ec7c26 > * branch: master > > > I've attached the logs (compressed this time) - with KMS I get a black > screen with the X cursor but the system is unusable - without KMS KDE > starts - the problem before was unrelated (policykit problem) You have two cards in that machine? Dave. > > So to reiterate the problem only exist with KMS > > Thanks for the quick responses > > Mike > > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: pushed preparation patch for KMS
2009/7/2 Michel Dänzer : > On Thu, 2009-07-02 at 12:07 +1000, Dave Airlie wrote: >> 2009/7/1 Michel Dänzer : >> > On Tue, 2009-06-30 at 16:38 +1000, Dave Airlie wrote: >> >> >> >> I pushed a patch that prepares the driver accel code for the upcoming >> >> KMS/DRI2 support. >> >> >> >> This mainly sorts out the accel interfaces and tries to hide the mess >> >> that supporting 25 different methods of >> >> accel does. >> >> >> >> Let me know if it breaks anything major, or if there is any insanity >> >> you'd rather see not live much longer. >> >> >> >> I've mainly tried to avoid having an #ifdef XF86DRM_MODE mass. >> > >> > Looking good basically. I haven't noticed any correctness regressions, >> > but x11perf -aa10text seems to have dropped from almost 600k/s to just >> > above 500k/s. Haven't had time to really look into why that is, but one >> > thing I noticed before on kms-support is that we seem to be >> > (re-)emitting some 2D state we never use with EXA, e.g. background >> > colours. It might be worth even trying not to re-emit state that hasn't >> > changed. >> >> what hw was that on? my r500 has no difference before this commit and >> after it with aa10text. > > RV350 in my PowerBook. > >> I'll try and get to some older hw later. We could probably two 2D the same >> as 3D, setup the engine and then do emission, but I'm really trying to >> avoid adding a full state caching + change feature to the DDX. From what I >> can >> see for 2D we probably now emit 4 qwords more than previously. > > Note that I'm not sure the performance regression is related to the 2D > state issue, x11perf -aa10text should be mostly Composite operations in > the hot path. > yeah thats what I was wondering, like maybe the extra if statements in the accel codepaths make a big difference or a bigger diff on powerpc. like really the amount of 3D state emitted shouldn't be that much bigger, unless I'm flushing more often somewhere or reemitting the 3D base state too often. Dave. >> But if I can reproduce it on my older hw I'll try and fix it. > > Great, thanks. I'll also try and see if oprofile gives any hints, though > it probably won't if it's indeed related to the GPU command stream. > > > -- > Earthling Michel Dänzer | http://www.vmware.com > Libre software enthusiast | Debian, X and DRI developer > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: pushed preparation patch for KMS
2009/7/1 Michel Dänzer : > On Tue, 2009-06-30 at 16:38 +1000, Dave Airlie wrote: >> >> I pushed a patch that prepares the driver accel code for the upcoming >> KMS/DRI2 support. >> >> This mainly sorts out the accel interfaces and tries to hide the mess >> that supporting 25 different methods of >> accel does. >> >> Let me know if it breaks anything major, or if there is any insanity >> you'd rather see not live much longer. >> >> I've mainly tried to avoid having an #ifdef XF86DRM_MODE mass. > > Looking good basically. I haven't noticed any correctness regressions, > but x11perf -aa10text seems to have dropped from almost 600k/s to just > above 500k/s. Haven't had time to really look into why that is, but one > thing I noticed before on kms-support is that we seem to be > (re-)emitting some 2D state we never use with EXA, e.g. background > colours. It might be worth even trying not to re-emit state that hasn't > changed. what hw was that on? my r500 has no difference before this commit and after it with aa10text. I'll try and get to some older hw later. We could probably two 2D the same as 3D, setup the engine and then do emission, but I'm really trying to avoid adding a full state caching + change feature to the DDX. From what I can see for 2D we probably now emit 4 qwords more than previously. But if I can reproduce it on my older hw I'll try and fix it. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
pushed preparation patch for KMS
Hi guys I pushed a patch that prepares the driver accel code for the upcoming KMS/DRI2 support. This mainly sorts out the accel interfaces and tries to hide the mess that supporting 25 different methods of accel does. Let me know if it breaks anything major, or if there is any insanity you'd rather see not live much longer. I've mainly tried to avoid having an #ifdef XF86DRM_MODE mass. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[ANNOUNCE] xf86-video-ati 6.9.0.91 - release candidate
use PACKAGE_VERSION_* for radeon version Increase default GART size to 32MB on >=R300 Bryce Harrington (4): radeon: Fix pasto in connector table setup for vga powerbooks Add AGP quirk table Additional AGP quirks Add another AGP quirk Calvin Fong (1): IGP: add support for NTSC tv-out on legacy IGP chips Corbin Simpson (21): Add bicubic texture table, as well as the script used to (re)generate it. To regenerate, just run "python bicubic_table.py > bicubic_table.h". Fixed typos in the bicubic texture tables. Whoops, looks like I'm still asleep. Allocate memory for the bicubic filter texture. Upload bicubic filter to card. This was a LOT easier than I had feared, to be honest. Upload pixel shader to card for r5xx. This was ridiculous. Also it doesn't work yet... Try to get tex coords from the VAP to RS properly when bicubic filtering is enabled. Make vertices emit properly. More bicubic FP buggies. Finally got the fragment program fully working for bicubic filtering on r5xx. Fix constants. Merge upstream changes to vertices, and also add Xv attributes for textured video, including bicubic filtering. Oops, made a mistake with vertices. Bump bicubic cutoff to R580. Force R580-only for bicubic. Update bicubic tables. Enable bicubic filtering for all r5xx HW. Change floats to uint32_t hex. Switch from 32-bit floats to 16-bit half-floats. Switch to Mesa-style 24-bit float packing. r3xx: Various Xv fixes. Fix indentation on IS_R300_3D Xv code. Dave Airlie (42): radeon: drop all use of CPMode. rotate: fix rotation in conf file. rv770 initial support pciid: add radeon HD3850. atombios: use macro to get offset into table atombios: fix typo in mode conversion for panel radeon: make r600 use i2c table lookup for ddc. radeon: add 0x9441 for hd 4870 x2 radeon: fix powerpc build radeon: rename radeon_memory to radeon_legacy_memory. radeon: hopefully fix plls for 30" monitors. atombios: set missing pixel clock atombios: oops typo pciid: add HD3300 - 790GX chipset. radeon: always align dstPitch to 64 bytes for textured video r100/r200: EXA misrenders dst == a8 + dst alpha use. radeon_drm.h: remove kernel defines radeon: fix HDMI having DACs in some BIOSes Stability fixes from radeon-gem-cs Don't mix 2D and 3D in the same IB radeon: apply atom quirks to object table radeon: damn you bios, HDMI cannot have DACs. radeon: memset the pll setting function r600: don't idle engine radeon: fixes from Alex for some output engines DCE32: add support for DCE3.2 digital outputs. radeon: add initial rv730 pciids. atombios: fix issue with Clearing of MM_INDEX 0. atombios: correct fix for previous issue. atombios: fixup parsing of TV tables on r500 and r600 cards. atom/tv: fixup the tv out default if bios doesn't specify atom/tv: enable scaler can set the TV output scaler up. atom: spc3 only requires ucEncoderMode for DIG outputs radeon: use latest atombios constants for TV encoders in set_crtc_source atom/r600: re-enable TV outputs atombios: re-enable TV dpms radeon: tv timings have crev/frev wrong way around for some reason. radeon: add all new pci ids for rv730/rv710 families radeon: setup 3D engine even when no DRI. atombios/tv: add an option to enable atom tv-out for users. radeon: pass distcheck radeon: update to 6.9.0.91 Dennis Kasprzyk (12): Fix texture size, texture filter, vertex offsets, etc. Set helper texture filter correctly. Implement LPR in one instruction. Remove uneeded negations. Heavy optimizations. Remove one constant. Smarter usage of the texture semaphore. Another uneeded SEM_AQUIRE. Move some ALU instructions after the TEX instructions, so we can do something usefull while we are waiting for the texture values. Fixed bicubic fragment program comments. Fix bicubic fp calculation. Fix typos. Egbert Eich (1): Cleanups from rhd port Eygene Ryabinkin (1): Catch unsubstituted macro for PCI region base access Fabio (3): Fix formatting in man page Remove duplicate ATI in some device names man page updates Joseph Adams (1): Add more eMac modes, fix crash in last patch Julien Cristau (2): Link with -lpciaccess and -ldrm if needed Bug#7148: Fix manpage formatting Maciej Cencora (3): Add needed FP registers, etc. for r3xx bicubic Xv. Add r3xx-specific bicubic filtering code. FP, RS, mostly, everything else is shared with r5xx. Enable bicubic Xv on r3xx+. Still some buggies in the actual display, but looks pretty good. Michel Dänz
Re: very slow 3d on Mobility FireGL V5200 with radeon driver
On Mon, Dec 1, 2008 at 4:47 PM, Marc MERLIN <[EMAIL PROTECTED]> wrote: > On Sun, Nov 30, 2008 at 11:15:21AM -0800, Michel Dänzer wrote: >> On Fri, 2008-11-28 at 15:01 -0800, Marc MERLIN wrote: >> > This is with 6.9.0+git20081003.f9826a56-0ubuntu4 with the latest >> > packages from ubuntu jaunty (i.e. bleeding edge). >> > >> > I get the X server to init DRI with both radeonhd and radeon. >> > With radeonhd, the machine deadlocks after I exit the X app (which is >> > slow too) With radeon, things work, but they are quite slow. >> > >> > 1613fps glxgears, 14fps lavalite, and google earth takes 5mn to zoom >> > on a spot. >> >> I don't think Google Earth should be that slow. Maybe something like >> https://bugs.freedesktop.org/show_bug.cgi?id=17929 is biting you. > > I had a look and tried to see what you mean. > I don't get any r300 debug output, but is that because I have AIGLX on? > Would you like me to turn it off? > >> > Is that expected because the driver is still experimental, or bad? >> > (my much other r300 based thinkpad T42p does 3d much faster than this >> > r5xx chip on my thinkpad Z61p). >> >> That's weird. Are you using the same (or at least as similar as >> possible) driver versions and configuration? > > Same config file, I just s/radeonhd/radeon/ > > Drivers are the latest I could get in ubuntu unstable: > ii xserver-xorg-video-radeon 1:6.9.0+git20081003.f9826a56-0ubuntu4 > ii xserver-xorg-video-radeonhd 1.2.3-1 > > I don't mind going to git next, but I'm not even sure if I should prefer > radeon to radeonhd for that chip, or the other way around?] I'm not radeonhd turns on DRI, just use radeon. Dave. > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems & security > what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [radeonhd] 0x94CC:0x1545:0x3650:
On Wed, Aug 13, 2008 at 7:54 PM, Tai Tri Nguyen <[EMAIL PROTECTED]> wrote: > Hi Alex, > > The driver I'm using is from git, the latest version of xf86-video-ati > >>git clone > git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati > > I have just downloaded and compiled again but the issue still exist. > Video can display in 24 bits depth color but perform wrong color. > Do you have any idea for the issue? > I think this is a pixman bug, but I'm not sure, Ben you have any luck tracking it down further? Actually R600 doesn't have surfaces like previous cards so actually we need to program some bits of r600. Dave. > Thanks, > TaiNguyen > > > -Original Message- > From: Alex Deucher [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 12, 2008 9:01 PM > To: Tai Tri Nguyen > Cc: Dave Airlie; [EMAIL PROTECTED]; Tuan Thanh Phan > Subject: Re: [radeonhd] 0x94CC:0x1545:0x3650: > > On Tue, Aug 12, 2008 at 6:52 AM, Tai Tri Nguyen <[EMAIL PROTECTED]> > wrote: >> Hi Dave, >> >> I got an issue wrong color and low frame rate with Radeon HD 2400 Pro >> for PowerPC architect. Everything seems OK but the color showed >> abnormally. I think there's something wrong with the driver or >> configuration. Please feel free to take a look if you can help. > > You're using an old version of the driver which is not big endian aware. > For big endian, you'll need to pull the latest driver bits from git. > Since you are using radeon, you should move this discusssion to > [EMAIL PROTECTED] > > Alex > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and contains information that > is confidential and proprietary to Applied Micro Circuits Corporation or its > subsidiaries. It is to be used solely for the purpose of furthering the > parties' business relationship. All unauthorized review, use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Correctly configuring dual head
On Thu, Jul 3, 2008 at 7:29 PM, Christoph Bartoschek <[EMAIL PROTECTED]> wrote: > Am Mittwoch, 2. Juli 2008 schrieb Alex Deucher: > >> > I've installedd 6.9.0 and it seems as if I can resolve my DPI problems. >> > Unfortunately the rotated display is unbearable slow. One can see the >> > scanline when parts of the desktop are updated. Is there a trick to get >> > the rotated display fast? >> >> Switch to EXA: >> Option "AccelMethod" "EXA" > > Thanks. Now the rotated display is ok. > > However there are two problems: > > 1. If I enter Option "Rotate" "Left" to my monitor section, the driver crashes > on startup. Is this known? > It is now, I've pushed the fix to master. > 2. It seems as if the GPU fan is now running all the time. Is it possible that > the rotated mode is more gpu intensive such that more power is transformed to > heat? Yes, rotation runs the 3D engine in order to do the rotation, so it would need more GPU power. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Problems compilling driver
On Wed, Jun 18, 2008 at 8:09 AM, Alex Deucher <[EMAIL PROTECTED]> wrote: > On Tue, Jun 17, 2008 at 11:12 AM, Helber Maciel Guerra > <[EMAIL PROTECTED]> wrote: >> >> I try to compile from git and have some errors: >> legacy_crtc.c: In function 'radeon_crtc_modeset_ioctl': >> legacy_crtc.c:628: error: 'struct drm_modeset_ctl' has no member named >> 'crtc' >> >> I can't compile since 9d3afbf5fa4110928a9f965df2733c7 >> 9db92ea99 Tue Jun 3 11:40:49 2008 +0200 > > You need a newer drm headers. The build process should do the right > thing, but I think the drm stuff in fedora has issues with this at the > moment. > I've just created a new libdrm package for F9, I've asked for it to be pushed into stable. http://kojipkgs.fedoraproject.org/packages/libdrm/2.4.0/0.13.fc9/ if you can't wait. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: x1250 AIGLX
On Wed, May 7, 2008 at 4:01 AM, Alex Rades <[EMAIL PROTECTED]> wrote: > Hi, > I'm having this error during X startup on my x1250: > > (EE) AIGLX error: Calling driver entry point failed(EE) AIGLX: reverting to > software rendering > > I'm using: > > xserver 1.4 > Mesa 7.0.3 > drm (lib and radeon module) from git master (I've also tried r345-cleanup > but makes no difference) > > do you have ideas? > yes 7.0.3 doesn't support the rs cards. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: X1550 (RV515) with zaphod mode
can you open a bug and attach your conf and logfiles... you might need to try latest git instead of 6.8.0 Dave. On Thu, Apr 17, 2008 at 2:47 AM, Jason Kim <[EMAIL PROTECTED]> wrote: > Driver version: ati-6.8.0 > Video card: Radeon X1550 (RV515) > > I heard zaphod mode has been included again in ati-6.8.0. I tried > dualhead(zaphod) with my X1550, but it never worked. > > Jason > > -- > *** > Jason Kim, Software Developer > http://userful.com > 2nd Floor, 928-6th Ave SW > Calgary, AB T2P 0V5 > Tel: 403-289-2177 EXT: 210 > 866-USERFUL (873-7385) > Fax: 403-206-7010 > > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: X1900 G5 edition and microcode in mesa/drm
On Mon, Mar 31, 2008 at 5:11 AM, Robin H. Johnson <[EMAIL PROTECTED]> wrote: > I'd like to renew my question from back in November 2007, in light of > the fact that the mesa/drm branch now seems to have ATI microcode. > > Previously, I was informed that the X1900 G5 edition cards (PCI ID > 0x7240) would not be supported as they contained OFW (which I disputed > at the time, noting that the card returned only zeros when trying to > read it's ROM, while other OFW cards I had did return their ROM fine) > and no AtomBIOS. > > As the microcode is now in the DRM tree, does this negate the need for > having an AtomBIOS from the card directly? No these two things have nothing to do with each other whatosever. Wierd the G5 editions don't have some sort of useful ROM tables in them or something.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: AMD 780G, anyone?
On Wed, Mar 26, 2008 at 7:56 PM, Magnus Hörlin <[EMAIL PROTECTED]> wrote: > Has anyone managed to get the radeon driver to work on it? I can't, all > I get is "No devices detected". Tried both VGA and HDMI. Catalyst 8.3 > works, but would prefer this. > Thankful for any help. > /Magnus You'll need to get the radeon driver from git, git clone git://git.freedesktop.org/git/xorg/driver/xf86-video-ati cd xf86-video-ati sh autogen.sh --prefix=/usr make make install (may require installing some distro packages). Dave. > > > lspci -v: > 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 > Graphics (prog-if 00 [VGA controller]) > Subsystem: Giga-byte Technology Unknown device d000 > Flags: bus master, fast devsel, latency 0, IRQ 10 > Memory at d800 (32-bit, prefetchable) [size=128M] > I/O ports at ee00 [size=256] > Memory at fdfe (32-bit, non-prefetchable) [size=64K] > Memory at fde0 (32-bit, non-prefetchable) [size=1M] > Capabilities: [50] Power Management version 3 > Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ > Queue=0/0 Enable- > > > dpkg -l: > xserver-xorg 1:7.3+10ubuntu7 > xserver-xorg-video-ati 1:6.8.0-1 > > > > Section "Files" > ModulePath "/usr/lib/xorg/modules" > FontPath "unix/:7100" > EndSection > > Section "Module" > Load "dbe" > Load "extmod" > Load "fbdevhw" > Load "glx" > Load "record" > Load "freetype" > #Load "type1" > Load "dri" > EndSection > > Section "InputDevice" > Identifier "Generic Keyboard" > Driver "kbd" > Option "CoreKeyboard" > Option "XkbRules" "xorg" > Option "XkbModel" "pc105" > Option "XkbLayout" "se" > Option "XkbOptions""lv3:ralt_switch" > EndSection > > Section "InputDevice" > Identifier "Configured Mouse" > Driver "mouse" > Option "CorePointer" > Option "Device""/dev/input/mice" > Option "Protocol" "ImPS/2" > Option "ZAxisMapping" "4 5" > Option "Emulate3Buttons" "true" > EndSection > > Section "Device" > Identifier "Device0" > Driver "radeon" > EndSection > > Section "Monitor" > Identifier "Generic Monitor" > Option "DPMS" > Horizsync 28-84 > Vertrefresh 43-60 > EndSection > > Section "Screen" > Identifier "Default Screen" > Device "Device0" > Monitor "Generic Monitor" > Defaultdepth24 > SubSection "Display" > Modes "1680x1050" > EndSubSection > EndSection > > Section "ServerLayout" > Identifier "Default Layout" > Screen "Default Screen" > Inputdevice "Generic Keyboard" > Inputdevice "Configured Mouse" > EndSection > > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: 2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang
> > Is xf86-driver-ati 6.8.0 not a proper release? I'm pretty sure the > combination of that, 2.6.25-rc3 and CONFIG_DRM_RADEON causes my machine > to become unresponsive. I only tried a git build of the driver after the > released version was causing issues. Yes we made a mistake with 6.8.0 enabling DRI on rs680 chips before we knew it worked for everyone, I may be still able to fix this in the kernel but there is a good chance that it'll require a 6.8.1 userspace, I can't do anything else about it.. Jonathan I appreciate the bug report, I'm more saying to Andrew that getting DRI right on new chipsets is non-trivial as there are lot of configurations we can't test until we actually push the code to users.. and in this case you are one of those.. you might try setting the VRAM in your BIOS to 128MB instead of Auto and seeing it helps.. I'll be trying to fix the problem properly quite soon. The correct workaround is to add Option "DRI" "Off" to xorg.conf or for me to travel back in time and unrelease 6.8.0. Removing the kernel DRI support will just break lots of working systems. Dave. > > Replacing 2.6.25-rc3 with 2.6.24 (still with CONFIG_DRM_RADEON enabled) > results in a machine that boots to GDM successfully. Likewise if I > disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok. > > J. > > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: 2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang
> > results in a machine that boots to GDM successfully. Likewise if I > > disable CONFIG_DRM_RADEON in 2.6.25-rc3 the machine boots to GDM ok. > > is what we wanted to know, thanks. Surely it's a plain old regression? Nope, its a userspace driver problem.. we have not released non-experimental code for that chipset, so its not surprising it fails when the kernel code gets run, but the fix most likely is in userspace not in the kernel. I could disable the userspace DRI code but then where would I find my testers .. if he reads his Xorg log it says DRI is experimental on rs690 and not to come crying.. this is the problem with adding new chipsets, I either wait for 6 months for all the bugs to get kicked out so nobody wins, or I push it upstream so most people win, I could back this out of the kernel, but experimental userspace code isn't a reason for this.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: 2.6.25-rc3 + RS690 + DRM + xf86-video-ati hang
On Mon, 3 Mar 2008, Andrew Morton wrote: > On Sat, 1 Mar 2008 19:35:11 + Jonathan McDowell <[EMAIL PROTECTED]> wrote: > > > If I enable CONFIG_DRM_RADEON under 2.6.25-rc3 then starting up > > X using the xf86-video-ati driver (6.8.0 or latest git) causes the > > machine to become unresponsive; while it still pings and will accept > > incoming connections they never actually complete and it's not possible > > to login over a serial console (the actual video console doesn't display > > anything and the monitor reports a loss of sync). > > > > Disabling the kernel DRM option results in X running successfully. > > Likewise 2.6.24 works fine with DRM enabled, presumably because the > > support for the RS690 was only added in 2.6.25-rc > > > > The last messages from the kernel before it becomes unresponsive are: > > > > [drm] Setting GART location based on new memory map > > [drm] Loading R300 Microcode > > [drm] writeback test succeeded in 1 usecs > > > > The motherboard in question is an ASUS M2A-VM HDMI, with the analog VGA > > output being used. The machine is running an AMD64 with Debian unstable. > > I have put the output of lspci, a non drm Xorg.log and a drm Xorg.log > > at: > > > > http://the.earth.li/~noodles/xorg-ati-drm/lspci > > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-nodrm > > http://the.earth.li/~noodles/xorg-ati-drm/Xorg.0.log-drm > > > > If I can provide any more useful information please let me know. > > > > Did 2.6.24 work OK with all the same userspace software? > We haven't actually released any userspace software properly yet, its all experimental at this point until we debug the hardware some more.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Final split of -ati wrapper and -radeon?
On Tue, Mar 4, 2008 at 2:59 AM, Alex Deucher <[EMAIL PROTECTED]> wrote: > On Mon, Mar 3, 2008 at 11:44 AM, Luc Verhaegen <[EMAIL PROTECTED]> wrote: > > On Sat, Mar 01, 2008 at 04:55:56PM +0100, Luc Verhaegen wrote: > > > Now that -mach64 and -r128 are separate drivers, is there any reason to > > > still keep the ati wrapper and the radeon driver in the same tree? > > yeah, doesn't really matter to me. > Splitting the -ati wrapper out even further would be nice, I'd still like to have it as we need to not trash current users xorg.conf. Granted we could just special case ati in the server ;-) Dave. > Alex > > > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Compile error on git master?
> > /bin/sh ../libtool --tag=CC --mode=compile i486-linux-gnu-gcc > -DHAVE_CONFIG_H -I. -I.. -I../../src-I/usr/include/xorg > -I/usr/include/drm -I/usr/include/X11/dri -Wall -g -O2 -Wall -MT > radeon_bios.lo -MD -MP -MF .deps/radeon_bios.Tpo -c -o radeon_bios.lo > ../../src/radeon_bios.c >i486-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../../src > -I/usr/include/xorg -I/usr/include/drm -I/usr/include/X11/dri -Wall -g > -O2 -Wall -MT radeon_bios.lo -MD -MP -MF .deps/radeon_bios.Tpo -c > ../../src/radeon_bios.c -fPIC -DPIC -o .libs/radeon_bios.o > ../../src/radeon_bios.c: In function 'RADEONGetBIOSInfo': > ../../src/radeon_bios.c:162: error: 'AtomBiosArgRec' undeclared (first use > in this function) > ../../src/radeon_bios.c:162: error: (Each undeclared identifier is reported > only once > ../../src/radeon_bios.c:162: error: for each function it appears in.) > ../../src/radeon_bios.c:162: error: expected ';' before 'atomBiosArg' > > Any ideas? Not sure what happened but re-run autogen.sh and it should work okay.. Dave. > > Marius > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
radeon zaphod the return...
Okay if you take a look at the zaphod-lolz branch http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/?h=zaphod-lolz I've managed to bring back zaphod without majorly impacting on the driver, randr-1.2 actually makes it quite easy to implement. Each head in theory still exports randr-1.2 interfaces in non-Xinerama mode I'd like to merge this into master quickly and also into atombios-support so I can do this on r500 class cards. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
new irc channel #radeon on freenode
I've just registered #radeon on freenode IRC network. This channel is for end user support of the radeon driver. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon R500 support
On Nov 21, 2007 9:27 AM, GerbilSoft <[EMAIL PROTECTED]> wrote: > I tested out the atombios-support branch of xf86-driver-ati on my ThinkPad > T60p (2623-DDU; FireGL V5200; 1600x1200 LCD), and it doesn't seem to work > correctly. The display is all garbled, though the desktop environment does > start up. When switching back to the RadeonHD driver via blind typing in > console, the previous desktop image does show up for a few seconds before > RadeonHD clears the screen, so I'm thinking there's an LVDS setting problem. > I have attached the Xorg.log file from this run. > Could you try it again with the latest code? I think agd5f pushed some LVDS fixes.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: xf86-video-ati: Branch 'master'
On Nov 21, 2007 2:50 AM, Brice Goglin <[EMAIL PROTECTED]> wrote: > Dave Airlie wrote: > > commit c8872603454e6a4ffed9fc7d9adc2c364a429608 > > Author: Dave Airlie <[EMAIL PROTECTED]> > > Date: Tue Nov 20 22:33:39 2007 +1000 > > > > radeon: restructure pci ids to avoid effort later > > > > This uses a single file with all the pciids and parameters for radeon > > family and setup in it. I don't run the perl script at build time to > > avoid > > a perl dependency on build but adding pci ids should be done via the > > csv file > > with openoffice or gnumeric if possible. > > The following PCI ids were in the old atipciids.h but are not in the new > ati_pciids_gen.h. Some of them seem to exists according to the pci ids > database, should they be supported? Do we know anything about the other > ones? > The driver never supported any of them, as in they weren't used.. a lot of them were secondary ids.. so unless someone complained before now I don't think it matters. Dave. > Cheers, > Brice > > 3151 M24 [FireMV 2400] > 3153 > 3156 > 3E51 > 3E52 > 3E53 > 3E56 > 4964 Radeon RV250 Id [Radeon 9000] > 4965 Radeon RV250 Ie [Radeon 9000] > 4A54 R420 [Radeon X800 VE] > 4C65 Radeon RV250 Le [Radeon Mobility 9000 M9] > 4C6E Radeon RV250 Ln [Radeon Mobility 9000 M9] (Secondary) > 5149 Radeon R200 QI > 514A Radeon R200 QJ > 514B Radeon R200 QK > 514E Radeon R200 QN [Radeon 8500LE] > 514F Radeon R200 QO [Radeon 8500LE] > 5461 > 5463 > 5465 > 5466 > 5467 > 5836 > 5837 > 5B61 > 5B66 > 5B67 > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon X200M help offered
> and with disable_lowimpact_fallback=1: > > [EMAIL PROTECTED] ~/src $ disable_lowimpact_fallback=1 googleearth > ATTENTION: default value of option disable_lowimpact_fallback overridden > by environment. > Fatal error in __driConfigOptions line 129, column 0: illegal default > value: 1. > Google Earth has caught signal 6. disable_lowimpact_fallback=true perhaps.. Mesa-7.0.1 isn't all that good on xpress 200M, it doesn't do clipping properly.. there is a patch in Fedora which backports r300 from master for xpress200m support.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon X200M help offered
> > I've got a laptop with a Radeon Xpress 200M, and am wondering what I > can do to help with getting 3D hardware acceleration to work properly, > more specifically, is there a place where the basics are listed on how > to 'hack' on the driver(I'm also prepared to test stuff)? Also, is > this the correct list to be mailing, or should I mail the MESA list > instead? It should for a large value of work, googleearth and stuff wfm... compiz not so much.. compiz needs a small test program written doing what it does.. I think we might have a problem with different data going into the driver when it comes direct vs indirect.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: Radeon 7500 no 3D-funktion in X.org 7.2
Wierd you have direct rendering.. I'm not sure why you don't get glxgears working.. It looks like SuSE have some wierd patches to Mesa for updated drivers the lack of drirc shouldn't matter.. so does LIBGL_DEBUG=verbose glxgears give anything different.. Dave. > > # LIBGL_DEBUG=verbose glxinfo > name of display: :0.0 > libGL: XF86DRIGetClientDriverName: 5.2.0 radeon (screen 0) > libGL: OpenDriver: trying /usr/lib/dri/updates/radeon_dri.so > libGL error: dlopen /usr/lib/dri/updates/radeon_dri.so failed > (/usr/lib/dri/updates/radeon_dri.so: cannot open shared object file: No > such file or directory) > libGL: OpenDriver: trying /usr/lib/dri/radeon_dri.so > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 4, (OK) > drmOpenByBusid: Searching for BusID pci::01:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 4, (OK) > drmOpenByBusid: drmOpenMinor returns 4 > drmOpenByBusid: drmGetBusid reports pci::01:00.0 > libGL error: > Can't open configuration file /etc/drirc: No such file or directory. > libGL error: > Can't open configuration file /root/.drirc: No such file or directory. > display: :0 screen: 0 > direct rendering: Yes > server glx vendor string: SGI > server glx version string: 1.2 > server glx extensions: > GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, > GLX_OML_swap_method, > GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, > GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer > client glx vendor string: SGI > client glx version string: 1.4 > client glx extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, > GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_MESA_allocate_memory, > GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, > GLX_MESA_swap_frame_usage, GLX_OML_swap_method, > GLX_OML_sync_control, > GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, > GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap > GLX extensions: > GLX_ARB_get_proc_address, GLX_ARB_multisample, > GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_MESA_copy_sub_buffer, > GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, > GLX_OML_swap_method, > GLX_SGI_make_current_read, GLX_SGI_video_sync, GLX_SGIS_multisample, > GLX_SGIX_fbconfig > OpenGL vendor string: Tungsten Graphics, Inc. > OpenGL renderer string: Mesa DRI Radeon 20061018 AGP 4x x86/MMX+/3DNow! > +/SSE TCL > OpenGL version string: 1.3 Mesa 7.0.1 > OpenGL extensions: > GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, > GL_ARB_texture_border_clamp, GL_ARB_texture_compression, > GL_ARB_texture_cube_map, GL_ARB_texture_env_add, > GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, > GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, > GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, > GL_ARB_vertex_buffer_object, GL_ARB_window_pos, GL_EXT_abgr, > GL_EXT_bgra, > GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, > GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, > GL_EXT_compiled_vertex_array, GL_EXT_convolution, > GL_EXT_copy_texture, > GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram, > GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, > GL_EXT_secondary_color, GL_EXT_separate_specular_color, > GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, > GL_EXT_texture3D, > GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, > GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, > GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, > GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, > GL_EXT_texture_rectangle, GL_EXT_vertex_array, > GL_APPLE_packed_pixels, > GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, > GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, > GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, > GL_NV_light_max_exponent, GL_NV_texture_rectangle, > GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix, > GL_SGI_color_table, GL_SGIS_generate_mipmap, > GL_SGIS_texture_border_clamp, > GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod > glu version: 1.3 > glu extensions: > GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess > >visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat > -- > 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None > 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow > 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow > 0x26 16 tc 0 1
Re: Radeon 7500 no 3D-funktion in X.org 7.2
> > I am not sure to be in the right list. If not please tell me. > > Well I have just installed OpenSuSE 10.3 with X.org 7.2. > In the docs for X.org 7.0 I have fount the ATI Radeon 7500 fully > supportet in 2D and 3D-Funktion. However my graphics-adapter does not > work in 3D, but I need for google-earth. > The monitor is a flat panel with 1280x1024 pixels and DVI-Input. > I have adjustedt 16 bpp for color-deph. > > glxgears > libGL error: open DRM failed (Operation not permitted) > libGL error: reverting to (slow) indirect rendering try running LIBGL_DEBUG=verbose glxinfo and working out what went wrong.. my best guess is permissions on /dev/dri/card0 Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#444223: xserver-xorg-video-ati: RS480 (radeon express X200G series): display goes to sleep after upgrade to latest unstable/sid
On 9/28/07, Junichi Uekawa <[EMAIL PROTECTED]> wrote: > Hi, > > > > I've tried unstable and experimental versions, but the display goes to > > > sleep after starting up X, and I see nothing. I can enter username / > > > password in what is probably a gdm login screen, and I can hear disk > > > activity, so I assume it starts and it thinks it's running. > > > > > > > Is this a laptop? What outputs does it actually have and which are in > > use? It looks like it has a bogus connector table, or some sort of > > weird connector. As such the driver is probably lighting up the wrong > > output. > > > This is a desktop PC, hp dx5150MT. It has DVI-out and D-sub analogue > output; which DVI is connected to the display. > It's most likely an external DVI chip, so maybe Alex can quirk it if you figure out the correct connector table. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: ppracer + xf86-video-ati = some colors/objects garbeled
> > to test the xf86-video-ati git HEAD with my ATI Radeon > Mobility X300 (M22) 5460 (PCIE) I tried the ppracer. Performance looks > really ok, but some objects on the track and some patches of white > (which might be supposed to be ice?!) have funny random colors. > > Any idea? Sounds like a Mesa bug probably dri-devel is a better place, or log a bug in freedesktop.org against the Mesa r300 driver.. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Bug#439322: xserver-xorg-video-ati: xrandr does not detect VGA monitor
On 8/27/07, Marcus Better <[EMAIL PROTECTED]> wrote: > Hi, > > there are no differences as far as I can see in version 6.7.192-1. The xrandr > commands give me: > > ~$ xrandr --addmode VGA-0 1024x768 > ~$ xrandr > Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 768 > VGA-0 disconnected (normal left inverted right x axis y axis) >1024x768 60.0 > LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x > 0mm >1024x768 60.0*+ >800x60060.3 >640x48059.9 > S-video connected 800x600+0+0 (normal left inverted right x axis y axis) 0mm x > 0mm >800x60059.9*+ 60.3 > ~$ xrandr --output VGA-0 --mode 1024x768 > xrandr: cannot find crtc for output VGA-0 > ~$ xrandr -v > Server reports RandR version 1.2 > > But perhaps my xrandr version is too old. WIll 1.2.2 it be available in the > archive anytime soon? it might worth trying to add an xrandr --output S-video --off Dave. > > Marcus > > ___ > xorg-driver-ati mailing list > xorg-driver-ati@lists.x.org > http://lists.x.org/mailman/listinfo/xorg-driver-ati > > > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
merging of ATI driver randr-1.2 work
Hi, After talking with Alex we decided that the randr 1.2 for radeon should be the default working state going forward, we are putting all our development effort into it and really the old code is an evolutionary dead end for the core developers. So to this end I've branched ati-6.7-branch from the current master with a view to releasing 6.7 from that branch sooner rather than later, and merged the randr-1.2 branch into ATI master, with a view to releasing a 6.7.191 pre-release containing randr-1.2 support. I know ppl will complain about losing zaphod mode, but really we don't have the developer capacity on this project to deal with the overheads for zaphod. If someone can find a way to add it back without streaming crap throughout the driver I'm all ears. Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: [Bug 12068] r300: compiz has poor performance
> > > --- Comment #10 from [EMAIL PROTECTED] 2007-08-21 15:34 PST --- > I had a look at the site. do you think that those 2 are enough? or others > should be applied too? > xserver-1.3.0-newglx-offscreen-pixmaps.patch > xserver-1.3.0-exaupgrade.patch > You also need the mesa7 patch and of course Mesa 7.0.1 Dave. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
