[2.6 patch] make drm_minors_cleanup() static
This patch makes the needlessly global drm_minors_cleanup() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
33cfc2c40ea8449f0e36af7107778a2bdaffae19 diff --git
a/drivers/char/drm/drm_drv.c b/drivers/char/drm/drm_drv.c
index fc54140..7166a55 100644
--- a/drivers/char/drm/drm_drv.c
+++ b/drivers/char/drm/drm_drv.c
@@ -318,7 +318,7 @@ static void drm_cleanup(struct drm_device * dev)
DRM_ERROR(Cannot unload module\n);
}
-int drm_minors_cleanup(int id, void *ptr, void *data)
+static int drm_minors_cleanup(int id, void *ptr, void *data)
{
struct drm_minor *minor = ptr;
struct drm_device *dev;
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10501] Screen is corrupted running compiz
http://bugs.freedesktop.org/show_bug.cgi?id=10501 --- Comment #10 from Michel Dänzer [EMAIL PROTECTED] 2008-04-29 00:31:35 PST --- Created an attachment (id=16230) -- (http://bugs.freedesktop.org/attachment.cgi?id=16230) Mesa patch Does this patch remove the need for drirc? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
BSD libdrm Update
I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and atomics. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10501] Screen is corrupted running compiz
http://bugs.freedesktop.org/show_bug.cgi?id=10501 --- Comment #11 from Thomas Champagne [EMAIL PROTECTED] 2008-04-29 04:45:46 PST --- Does this patch remove the need for drirc? Ok Michel, I try to test this patch. But I don't know if I will succeed it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM Modesetting fbset tool?
I've started playing with the modesetting branch of DRM and managed to get it to work on my GMA 965 based laptop (after working out I needed to pass modeset=1 as a parameter to the i915 module). On my laptop, I get /dev/fb0 /dev/fb1, with /dev/fb0 connected to my laptop screen (LVDS?) and fb1 connected to VGA out. I can successfully run Qt/Embedded on fb1 (using the normal fbdev interface... not started writing drm modesetting code yet). What would be nice is to have a tool like fbset which not only sets the mode, but also chooses which crtc (correct terminology?) is connected to which framebuffer. On the OMAP framebuffer, this can be controlled through a sysfs interface. However, my understanding is that the i915 driver provides a linuxfb emulation driver it registers with the kernel during probe? The fbcon then binds to the (first) fbdev device? So the tool would in fact just configure i915's linuxfb emulation and not be very useful or portable. Have I understood things correctly? I'm getting a bit confused about how things should look inside the kernel (This is mainly because I'm having a hard time working out how consoles, virtual terminals vt-switching fit together... but I'm picking it up bit-by-bit). It seems to me that a completely new console driver needs to be written which uses the drm modesetting interface, rather than the fbdev interface? So the tool to set modes change crtcs would only talk to the console driver. User-space applications like X Qt/Embedded seem pretty strait-forward. They just use mode setting functions in libdrm. I.e. They provide their own way of configuring which output goes to which crtc. What about vt-switches? Will an application still be responsible for re-drawing itself after a vt-switch? Or will vt-switches now become completely transparent to userspace applications? Please let me know what I've got wrong. Eventually, I'd quite like to have a go at writing some in-kernel stuff using the drm. If there's any boring low-hanging fruit I could start to learn on, let me know (like an fbset-like utility). Cheers, Tom - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10501] Screen is corrupted running compiz
http://bugs.freedesktop.org/show_bug.cgi?id=10501 --- Comment #12 from Thomas Champagne [EMAIL PROTECTED] 2008-04-29 08:22:03 PST --- I'v just tested the Michel's patch and it works for the r200 driver. Thanks for this patch Thomas -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM Modesetting fbset tool?
On Tue, 29 Apr 2008 15:08:12 +0200 Tom Cooksey [EMAIL PROTECTED] wrote: I've started playing with the modesetting branch of DRM and managed to get it to work on my GMA 965 based laptop (after working out I needed to pass modeset=1 as a parameter to the i915 module). On my laptop, I get /dev/fb0 /dev/fb1, with /dev/fb0 connected to my laptop screen (LVDS?) and fb1 connected to VGA out. I can successfully run Qt/Embedded on fb1 (using the normal fbdev interface... not started writing drm modesetting code yet). What would be nice is to have a tool like fbset which not only sets the mode, but also chooses which crtc (correct terminology?) is connected to which framebuffer. On the OMAP framebuffer, this can be controlled through a sysfs interface. However, my understanding is that the i915 driver provides a linuxfb emulation driver it registers with the kernel during probe? The fbcon then binds to the (first) fbdev device? So the tool would in fact just configure i915's linuxfb emulation and not be very useful or portable. Have I understood things correctly? I'm getting a bit confused about how things should look inside the kernel (This is mainly because I'm having a hard time working out how consoles, virtual terminals vt-switching fit together... but I'm picking it up bit-by-bit). It seems to me that a completely new console driver needs to be written which uses the drm modesetting interface, rather than the fbdev interface? So the tool to set modes change crtcs would only talk to the console driver. User-space applications like X Qt/Embedded seem pretty strait-forward. They just use mode setting functions in libdrm. I.e. They provide their own way of configuring which output goes to which crtc. What about vt-switches? Will an application still be responsible for re-drawing itself after a vt-switch? Or will vt-switches now become completely transparent to userspace applications? Please let me know what I've got wrong. Eventually, I'd quite like to have a go at writing some in-kernel stuff using the drm. If there's any boring low-hanging fruit I could start to learn on, let me know (like an fbset-like utility). Cheers, Tom Modesetting API is not set in rock and i believe their is plan to make some modifications to it. My last understanding (as things move quickly in this area this might be as outdated as stone age) is that the drm rework (DRM multi-master things) will significantly impact this modesetting things. IIRC we want to have a master in charge of ack mode request or giving permission to other program to change mode. Such master would be in charge of vt switch. Their is also many plan on widering the kernel object usage in this DRM2 so we can take advantage of linux object framework (like filesystem stuff). For console we had the idea of building a full userspace console things instead of having this whole things in the kernel. Which would mean to write some userspace program using the modesetting API and providing the console. I believe there is several advantages (i talk about drawbacks latter) for instance you can do a fency console, or have multiple console at the same time by dividing screen, or have efficient multi-seat console with nice screen input association. Well many things worth having for the XXI century where car flies and robots wash the house and do the laundry. Main drawback i see, is for rescue case, ie we likely need to keep a minimal console in kernel as in rescue we can't rely on userspace to be their or operational. Their is likely others drawback but none of importance come to my mind. Anyway i believe such things need to be discused on lkml but as the API and things like multi-master, DRM2, ... are not yet worked out i believe its a bit too early to bring this topic on lkml (given that this might proove to lead to some nice flamewar :() Still you might be interested in writing a proof of concept user space console. Adapting it to API change won't be that hard. Cheers, Jerome Glisse - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BSD libdrm
On Mon, 28 Apr 2008 08:26:41 -0700 vehemens [EMAIL PROTECTED] wrote: I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and locks. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? What are your aims ? As far as i know BSD/drm does not have memory manager support thus modesetting is not operational on BSD as it needs the memory manager. libdrm so far is a pretty small layer on top of kernel interface to make userspace life easier. For testing current BSD functionalities i believe a working 3D acceleration under X is the best use case given that DRM is primilary designed and written for this usage. Cheers, Jerome Glisse - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10501] Screen is corrupted running compiz
http://bugs.freedesktop.org/show_bug.cgi?id=10501 Michel Dänzer [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Michel Dänzer [EMAIL PROTECTED] 2008-04-29 10:08:51 PST --- Patch pushed to the Mesa Git master and 7.0 branches. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15730] Blinking textures in ray mesa demo
http://bugs.freedesktop.org/show_bug.cgi?id=15730 Roland Scheidegger [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Roland Scheidegger [EMAIL PROTECTED] 2008-04-29 13:25:12 PST --- Your analysis looks right. I think it's not a problem for tcl because it does the dma flush anyway for each primitive. In any case, I've pushed your suggested fix (though I've moved it up one function as it could be problematic there too). I don't think there should be any performance issue with this, since if there are _any_ state changes R200_NEWPRIM (and hence the dma flush) would be called anyway - only in case of all state being equal would it make a difference, but this probably shouldn't happen too often (it should only happen if an app sets some state, then reverting the state to the previous value without drawing anything in-between, or setting irrelevant state). The alternative would be to use some interim values, then checking those against the rmesa-state.x values to decide if the R200_NEWPRIM is needed before setting the rmesa-state.x values, but it doesn't seem worth the trouble (the state handling is probably no longer really optimally efficient anyway). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15193] mesa xdemo 'glthreads' draw nothing
http://bugs.freedesktop.org/show_bug.cgi?id=15193 Colin.Joe [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Colin.Joe [EMAIL PROTECTED] 2008-04-29 19:17:43 PST --- Using the master tip , this bug can't be reproduced again. verified . -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15193] mesa xdemo 'glthreads' draw nothing
http://bugs.freedesktop.org/show_bug.cgi?id=15193 Colin.Joe [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BSD libdrm
On Tuesday 29 April 2008 08:35:36 am Jerome Glisse wrote: On Mon, 28 Apr 2008 08:26:41 -0700 vehemens [EMAIL PROTECTED] wrote: I'm currently working on updating the bsd libdrm for use with my freebsd system. To reduce the work involved, I'm using some code from the linux kernel for lists and locks. This also greatly reduces the amount of unique code required. Unfortunately I only have radeon rv370 and intel i810 class hardware so my testing capability is somewhat limited. My thoughts are that i9i5 flavor hardware may be the best way to to check out the code. Another option is to stick with radeon and to switch over to the mode-setting branch at some point. So does anyone have any ideas on what would be the best testing approach? What are your aims ? As far as i know BSD/drm does not have memory manager support thus modesetting is not operational on BSD as it needs the memory manager. libdrm so far is a pretty small layer on top of kernel interface to make userspace life easier. For testing current BSD functionalities i believe a working 3D acceleration under X is the best use case given that DRM is primilary designed and written for this usage. The primary goal is to update the BSD drm code with the recent linux changes including linux drm memory management code. I haven't seen anything in the code that would prevent this from occurring, but I'm new at this. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
