[Bug 13358] Error: couldn't get an RGB, Double-buffered visual
http://bugs.freedesktop.org/show_bug.cgi?id=13358 --- Comment #11 from [EMAIL PROTECTED] 2007-12-15 07:14 PST --- Hi, I've the same problem on the same platform: amd64 x850 after running glxinfo, dmesg | tail: [drm] Setting GART location based on new memory map [drm] Loading R300 Microcode [drm] writeback test succeeded in 1 usecs Also I manually create a s-link to libGL.so after Mesa installation on Gentoo. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13258] rubik xscreensaver is completely grey
http://bugs.freedesktop.org/show_bug.cgi?id=13258 [EMAIL PROTECTED] changed: What|Removed |Added Component|Drivers/DRI/r300|Mesa core --- Comment #3 from [EMAIL PROTECTED] 2007-12-15 07:29 PST --- I've just managed to reproduce this bug with LIBGL_ALWAYS_INDIRECT=1 set, so I don't think it can be r300 related after all. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13358] Error: couldn't get an RGB, Double-buffered visual
http://bugs.freedesktop.org/show_bug.cgi?id=13358 --- Comment #12 from [EMAIL PROTECTED] 2007-12-15 07:38 PST --- Sorry, I've dummly wrote the r300 initialization kernel output. Not just kernel output aftere glxgears. How can I help debugging? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Proposal for a few minor internal API changes.
Keith Packard wrote:
I'm writing up some documentation for internal DRM interfaces and came
across a couple of interface inconsistencies that seem like they should
get fixed before they start getting used a lot more. If these look like
good changes, I'll continue to search out other similar issues. I'll
just include the header changes in this message.
Make ttm create/destroy APIs consistent. Pass page_flags in create.
Creating a ttm was done with drm_ttm_init while destruction was done with
drm_destroy_ttm. Renaming these to drm_ttm_create and drm_ttm_destroy
makes
their use clearer. Passing page_flags to the create function will allow
that
to know whether user or kernel pages are needed, with the goal of allowing
kernel ttms to be saved for later reuse.
--- linux-core/drm_objects.h
---
index 1dc61fd..66611f6 100644
@@ -297,7 +297,7 @@ struct drm_ttm {
};
-extern struct drm_ttm *drm_ttm_init(struct drm_device *dev, unsigned long
size);
+extern struct drm_ttm *drm_ttm_create(struct drm_device *dev, unsigned long
size, uint32_t page_flags);
extern int drm_bind_ttm(struct drm_ttm *ttm, struct drm_bo_mem_reg *bo_mem);
extern void drm_ttm_unbind(struct drm_ttm *ttm);
extern void drm_ttm_evict(struct drm_ttm *ttm);
@@ -318,7 +318,7 @@ extern int drm_ttm_set_user(struct drm_ttm *ttm,
* Otherwise it is called when the last vma exits.
*/
-extern int drm_destroy_ttm(struct drm_ttm *ttm);
+extern int drm_ttm_destroy(struct drm_ttm *ttm);
#define DRM_FLAG_MASKED(_old, _new, _mask) {\
(_old) ^= (((_old) ^ (_new)) (_mask)); \
Document drm_bo_do_validate. Remove spurious 'do_wait' parameter.
Add comments about the parameters to drm_bo_do_validate, along
with comments for the DRM_BO_HINT options. Remove the 'do_wait'
parameter as it is duplicated by DRM_BO_HINT_DONT_BLOCK.
--- linux-core/drm_objects.h
---
index 66611f6..1c6ca79 100644
@@ -546,7 +546,6 @@ extern struct drm_buffer_object
*drm_lookup_buffer_object(struct drm_file *file_
extern int drm_bo_do_validate(struct drm_buffer_object *bo,
uint64_t flags, uint64_t mask, uint32_t hint,
uint32_t fence_class,
- int no_wait,
struct drm_bo_info_rep *rep);
/*
Document drm_bo_handle_validate. Match drm_bo_do_validate parameter order.
Document parameters and usage for drm_bo_handle_validate. Change parameter
order to match drm_bo_do_validate (fence_class has been moved to after
flags, hint and mask values). Existing users of this function have been
changed, but out-of-tree users must be modified separately.
--- linux-core/drm_objects.h
---
index 1c6ca79..0926b47 100644
@@ -535,9 +535,8 @@ extern int drm_bo_clean_mm(struct drm_device *dev,
unsigned mem_type);
extern int drm_bo_init_mm(struct drm_device *dev, unsigned type,
unsigned long p_offset, unsigned long p_size);
extern int drm_bo_handle_validate(struct drm_file *file_priv, uint32_t
handle,
- uint32_t fence_class, uint64_t flags,
- uint64_t mask, uint32_t hint,
- int use_old_fence_class,
+ uint64_t flags, uint64_t mask, uint32_t hint,
+ uint32_t fence_class, int use_old_fence_class,
struct drm_bo_info_rep *rep,
struct drm_buffer_object **bo_rep);
These all look sensible.
It's a pity that the change above looks like it will allow users of the
old argument order to continue to compile without error despite the
change. It's a bit hard to know how to achieve that though.
When you say 'document xyz', and the documentation doesn't appear in the
patch to the header, where *will* the documentation live??
Keith
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13258] rubik xscreensaver is completely grey
http://bugs.freedesktop.org/show_bug.cgi?id=13258 [EMAIL PROTECTED] changed: What|Removed |Added Component|Mesa core |Drivers/DRI/r300 --- Comment #4 from [EMAIL PROTECTED] 2007-12-15 09:18 PST --- Unless you disable AIGLX, it's the same driver. FWIW, I can confirm the problem with the r300 driver. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Proposal for a few minor internal API changes.
Keith Whitwell wrote:
Keith Packard wrote:
I'm writing up some documentation for internal DRM interfaces and came
across a couple of interface inconsistencies that seem like they should
get fixed before they start getting used a lot more. If these look like
good changes, I'll continue to search out other similar issues. I'll
just include the header changes in this message.
Make ttm create/destroy APIs consistent. Pass page_flags in create.
Creating a ttm was done with drm_ttm_init while destruction was done with
drm_destroy_ttm. Renaming these to drm_ttm_create and drm_ttm_destroy
makes
their use clearer. Passing page_flags to the create function will allow
that
to know whether user or kernel pages are needed, with the goal of
allowing
kernel ttms to be saved for later reuse.
--- linux-core/drm_objects.h
---
index 1dc61fd..66611f6 100644
@@ -297,7 +297,7 @@ struct drm_ttm {
};
-extern struct drm_ttm *drm_ttm_init(struct drm_device *dev, unsigned long
size);
+extern struct drm_ttm *drm_ttm_create(struct drm_device *dev, unsigned long
size, uint32_t page_flags);
extern int drm_bind_ttm(struct drm_ttm *ttm, struct drm_bo_mem_reg *bo_mem);
extern void drm_ttm_unbind(struct drm_ttm *ttm);
extern void drm_ttm_evict(struct drm_ttm *ttm);
@@ -318,7 +318,7 @@ extern int drm_ttm_set_user(struct drm_ttm *ttm,
* Otherwise it is called when the last vma exits.
*/
-extern int drm_destroy_ttm(struct drm_ttm *ttm);
+extern int drm_ttm_destroy(struct drm_ttm *ttm);
#define DRM_FLAG_MASKED(_old, _new, _mask) {\
(_old) ^= (((_old) ^ (_new)) (_mask)); \
Document drm_bo_do_validate. Remove spurious 'do_wait' parameter.
Add comments about the parameters to drm_bo_do_validate, along
with comments for the DRM_BO_HINT options. Remove the 'do_wait'
parameter as it is duplicated by DRM_BO_HINT_DONT_BLOCK.
--- linux-core/drm_objects.h
---
index 66611f6..1c6ca79 100644
@@ -546,7 +546,6 @@ extern struct drm_buffer_object
*drm_lookup_buffer_object(struct drm_file *file_
extern int drm_bo_do_validate(struct drm_buffer_object *bo,
uint64_t flags, uint64_t mask, uint32_t hint,
uint32_t fence_class,
- int no_wait,
struct drm_bo_info_rep *rep);
/*
Document drm_bo_handle_validate. Match drm_bo_do_validate parameter
order.
Document parameters and usage for drm_bo_handle_validate. Change
parameter
order to match drm_bo_do_validate (fence_class has been moved to after
flags, hint and mask values). Existing users of this function have been
changed, but out-of-tree users must be modified separately.
--- linux-core/drm_objects.h
---
index 1c6ca79..0926b47 100644
@@ -535,9 +535,8 @@ extern int drm_bo_clean_mm(struct drm_device *dev,
unsigned mem_type);
extern int drm_bo_init_mm(struct drm_device *dev, unsigned type,
unsigned long p_offset, unsigned long p_size);
extern int drm_bo_handle_validate(struct drm_file *file_priv, uint32_t
handle,
- uint32_t fence_class, uint64_t flags,
- uint64_t mask, uint32_t hint,
- int use_old_fence_class,
+ uint64_t flags, uint64_t mask, uint32_t hint,
+ uint32_t fence_class, int use_old_fence_class,
struct drm_bo_info_rep *rep,
struct drm_buffer_object **bo_rep);
These all look sensible.
It's a pity that the change above looks like it will allow users of the
old argument order to continue to compile without error despite the
change. It's a bit hard to know how to achieve that though.
Could a temporary/dummy parameter be added for a while? Callers that
weren't updated would get an error/warning about too few arguments.
Then remove the dummy at some point in the future.
-Brian
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Proposal for a few minor internal API changes.
On Sat, 2007-12-15 at 16:31 +, Keith Whitwell wrote: These all look sensible. Thanks. It's a pity that the change above looks like it will allow users of the old argument order to continue to compile without error despite the change. It's a bit hard to know how to achieve that though. We can thank the C language for that, but I don't know how to fix it without some artificial changes. My goal is to make future code not have mistakes in argument ordering of the same nature though, by regularizing argument order. When you say 'document xyz', and the documentation doesn't appear in the patch to the header, where *will* the documentation live?? Oh, it's in the source files in gtk-doc format like this: /** * drm_buffer_object_validate: * * @bo: the buffer object to modify * * @fence_class: the new fence class covering this buffer * * @move_unfenced: a boolean indicating whether switching the * memory space of this buffer should cause the buffer to * be placed on the unfenced list. * * @no_wait: whether this function should return -EBUSY instead * of waiting. * * Change buffer access parameters. This can involve moving * the buffer to the correct memory type, pinning the buffer * or changing the class/type of fence covering this buffer * * Must be called with bo locked. */ gtk-doc places the documentation right next to the implementation to encourage them to be kept in sync as changes are made. It's worked well for cairo. I'm just documenting things as I figure them out. I expect to have more API cleanup suggestions after I've got a better picture of the overall structure; I would like to fix things like the drm_bo_handle_validate - drm_bo_do_validate - drm_buffer_object_validate chain where the function names are not clearly disambiguated as to context and purpose. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Proposal for a few minor internal API changes.
On Sat, 2007-12-15 at 10:59 -0700, Brian Paul wrote: Could a temporary/dummy parameter be added for a while? Callers that weren't updated would get an error/warning about too few arguments. Then remove the dummy at some point in the future. We could change the use_old_fence_class into a HINT bit, that would reduce the number of parameters by one and cause compile errors for existing code. I'd rather not intentionally damage the API temporarily though; that seems fairly harsh. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Proposal for a few minor internal API changes.
Keith Packard wrote: On Sat, 2007-12-15 at 10:59 -0700, Brian Paul wrote: Could a temporary/dummy parameter be added for a while? Callers that weren't updated would get an error/warning about too few arguments. Then remove the dummy at some point in the future. We could change the use_old_fence_class into a HINT bit, that would reduce the number of parameters by one and cause compile errors for existing code. I'd rather not intentionally damage the API temporarily though; that seems fairly harsh. Ultimately it's not that big of a deal - if this change makes sense on it's own, then sure go ahead. Otherwise it's only Poulsbo that I can think of being out-of-tree, and we should be able to figure out what's going on there fairly quickly (though obviously we'll forget all about this conversation until after the next merge starts making it behave weirdly). Keith - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Proposal for a few minor internal API changes.
On Sat, 2007-12-15 at 19:53 +, Keith Whitwell wrote: Ultimately it's not that big of a deal - if this change makes sense on it's own, then sure go ahead. Ok, I'll push to master then. Otherwise it's only Poulsbo that I can think of being out-of-tree, and we should be able to figure out what's going on there fairly quickly (though obviously we'll forget all about this conversation until after the next merge starts making it behave weirdly) I'll apologize in advance for your upcoming bug hunting expedition. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13258] rubik xscreensaver is completely grey
http://bugs.freedesktop.org/show_bug.cgi?id=13258 --- Comment #5 from [EMAIL PROTECTED] 2007-12-15 13:28 PST --- OK, disabling AIGLX and using LIBGL_ALWAYS_INDIRECT puts the colours back in my Rubik's cube. So this is R300 specific after all. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
broken suspend, sometimes (drm related) [Was: 2.6.24-rc5-mm1]
On 12/13/2007 11:40 AM, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
Broken @#$%^ suspend, again (and maybe still for a longer time). Unable to
reproduce this with netconsole.
trace led to i915_suspend
callpci_bus_read_config_byte#
movq8(%rbx), %rdi # variable.mmio_map, variable.mmio_map
movq24(%rdi), %rax # variable.handle, D.24395
movl458760(%rax), %eax #, D.24397
address in rax (i.e. dev_priv-mmio_map-handle) is broken, at least it seems so
from the part of the trace and RIP.
movl%eax, 408(%rbx) # D.24397, variable.savePIPEACONF
movq24(%rdi), %rax # variable.handle, temp.676
movl393244(%rax), %eax #, D.24399
in
pci_save_state(dev-pdev);
pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
/* Pipe plane A info */
-- dev_priv-savePIPEACONF = I915_READ(PIPEACONF);
I use distro pm-utils and it chvt's to some terminal, write out the output,
suspend, resume, switch back to X.
The patch I'm currently using for debugging:
Index: BH/drivers/char/drm/i915_drv.c
===
--- BH.orig/drivers/char/drm/i915_drv.c
+++ BH/drivers/char/drm/i915_drv.c
@@ -274,9 +274,18 @@ static int i915_suspend(struct drm_devic
return -ENODEV;
}
+ if (!dev_priv-mmio_map || !dev_priv-mmio_map-handle) {
+ printk(KERN_ERR BAD BAD BAD %p %p\n, dev_priv-mmio_map,
+ dev_priv-mmio_map ? dev_priv-mmio_map-handle : NULL);
+ return -EIO;
+ }
+
pci_save_state(dev-pdev);
pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
+ printk(KERN_ERR \n\n\nmap %p, HANDLE: %p\n\n\n, dev_priv-mmio_map,
+ dev_priv-mmio_map-handle);
+ msleep(5000);
/* Pipe plane A info */
dev_priv-savePIPEACONF = I915_READ(PIPEACONF);
dev_priv-savePIPEASRC = I915_READ(PIPEASRC);
Index: BH/drivers/char/drm/drm_bufs.c
===
--- BH.orig/drivers/char/drm/drm_bufs.c
+++ BH/drivers/char/drm/drm_bufs.c
@@ -136,6 +136,7 @@ static int drm_addmap_core(struct drm_de
return -EINVAL;
}
map-mtrr = -1;
+ printk(BLE %s a: map %p, handle %p\n, __func__, map, map-handle);
map-handle = NULL;
switch (map-type) {
@@ -183,6 +184,7 @@ static int drm_addmap_core(struct drm_de
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -ENOMEM;
}
+ printk(BLE %s b: map %p, handle %p\n, __func__, map, map-handle);
}
break;
@@ -201,6 +203,7 @@ static int drm_addmap_core(struct drm_de
return 0;
}
map-handle = vmalloc_user(map-size);
+ printk(BLE %s c: map %p, handle %p\n, __func__, map, map-handle);
DRM_DEBUG(%lu %d %p\n,
map-size, drm_order(map-size), map-handle);
if (!map-handle) {
@@ -211,6 +214,7 @@ static int drm_addmap_core(struct drm_de
if (map-flags _DRM_CONTAINS_LOCK) {
/* Prevent a 2nd X Server from creating a 2nd lock */
if (dev-lock.hw_lock != NULL) {
+ printk(BLE %s d: map %p, handle %p\n, __func__, map, map-handle);
vfree(map-handle);
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -EBUSY;
@@ -281,6 +285,7 @@ static int drm_addmap_core(struct drm_de
return -ENOMEM;
}
map-handle = dmah-vaddr;
+ printk(BLE %s f: map %p, handle %p\n, __func__, map, map-handle);
map-offset = (unsigned long)dmah-busaddr;
kfree(dmah);
break;
@@ -291,6 +296,7 @@ static int drm_addmap_core(struct drm_de
list = drm_alloc(sizeof(*list), DRM_MEM_MAPS);
if (!list) {
+ printk(BLE %s g: map %p, handle %p\n, __func__, map, map-handle);
if (map-type == _DRM_REGISTERS)
iounmap(map-handle);
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
@@ -308,6 +314,7 @@ static int drm_addmap_core(struct drm_de
map-offset;
ret = drm_map_handle(dev, list-hash, user_token, 0);
if (ret) {
+ printk(BLE %s h: map %p, handle %p\n, __func__, map, map-handle);
if (map-type == _DRM_REGISTERS)
iounmap(map-handle);
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
@@ -355,6 +362,7 @@ int drm_addmap_ioctl(struct drm_device *
return err;
/* avoid a warning on 64-bit, this casting isn't very nice, but the API
is set so
[Bug 9751] i915_wait_irq crash on G965, 2.6.19.2
http://bugs.freedesktop.org/show_bug.cgi?id=9751 --- Comment #1 from [EMAIL PROTECTED] 2007-12-15 18:29 PST --- A similar bug has been pasted to the Ubuntu forums: https://lists.ubuntu.com/archives/kernel-bugs/2006-July/018652.html I'm also seeing this issue on a Dell Inspiron 1420N running Ubuntu Gutsy, kernel is 2.6.22-14-generic. lspci -v says this about the video: VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA]) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
