[Bug 6689] libGL warning: 3D driver claims to not support visual 0x4b
http://bugs.freedesktop.org/show_bug.cgi?id=6689 --- Comment #8 from [EMAIL PROTECTED] 2007-08-12 02:13 PST --- Created an attachment (id=11107) -- (http://bugs.freedesktop.org/attachment.cgi?id=11107action=view) disable-libGL-warning.diff braindead patch -- 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. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GL_CLAMP on D3D-only hardware
Alex Jackson wrote: Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. If feasible, I'd make it configurable via a .drirc option whether to map to GL_CLAMP_TO_EDGE or to GL_CLAMP_TO_BORDER, and make the former the default. This change should be made in both 965 and i830, and ideally in all the other drivers where the hardware natively supports both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER but not GL_CLAMP. Cursory Googling suggests that it's very common for other OpenGL implementations to map GL_CLAMP to GL_CLAMP_TO_EDGE (even if that's less conformant), and that consequently there're likely quite a few other OpenGL applications floating around in the wild that use GL_CLAMP when they mean GL_CLAMP_TO_EDGE. Indeed this show up every once in a while. A driconf option might be a good idea, but it doesn't solve the problem really for the hardware which indeed does support GL_CLAMP, unless you'd also introduce an option to make it non-conformant GL_CLAMP_TO_EDGE there too (which was suggested in the past). So the only real solution is to tell the app writers to fix their code. If you'd want to fix this in the driver without requiring user intervention, you'd need app detection (ugh). Roland - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6689] libGL warning: 3D driver claims to not support visual 0x4b
http://bugs.freedesktop.org/show_bug.cgi?id=6689 --- Comment #9 from [EMAIL PROTECTED] 2007-08-12 07:39 PST --- (In reply to comment #8) Created an attachment (id=11107) -- (http://bugs.freedesktop.org/attachment.cgi?id=11107action=view) [details] disable-libGL-warning.diff braindead patch Hmm. I don't think the id as such has any inherent meaning (so it could potentially change), I think though it's always the last mode. Maybe it would be better to filter the GLX_NON_CONFORMANT_CONFIG bit in the VisualRating instead, I don't think those are used anywhere else (and even if they were it would only suppress the warning if the driver can't support it anyway). -- 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. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Fwd: Re: GL_CLAMP on D3D-only hardware]
Forwarded Message From: James C Georgas [EMAIL PROTECTED] To: Roland Scheidegger [EMAIL PROTECTED] Subject: Re: GL_CLAMP on D3D-only hardware Date: Sun, 12 Aug 2007 12:30:51 -0400 On Sun, 2007-12-08 at 12:42 +0200, Roland Scheidegger wrote: Alex Jackson wrote: Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. If feasible, I'd make it configurable via a .drirc option whether to map to GL_CLAMP_TO_EDGE or to GL_CLAMP_TO_BORDER, and make the former the default. This change should be made in both 965 and i830, and ideally in all the other drivers where the hardware natively supports both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER but not GL_CLAMP. Cursory Googling suggests that it's very common for other OpenGL implementations to map GL_CLAMP to GL_CLAMP_TO_EDGE (even if that's less conformant), and that consequently there're likely quite a few other OpenGL applications floating around in the wild that use GL_CLAMP when they mean GL_CLAMP_TO_EDGE. Indeed this show up every once in a while. A driconf option might be a good idea, but it doesn't solve the problem really for the hardware which indeed does support GL_CLAMP, unless you'd also introduce an option to make it non-conformant GL_CLAMP_TO_EDGE there too (which was suggested in the past). So the only real solution is to tell the app writers to fix their code. If you'd want to fix this in the driver without requiring user intervention, you'd need app detection (ugh). Roland I think I've mentioned this before, WRT the radeon driver and some old loki games, like HG2. Since we can't fix the code in these kinds of apps, I think that a driconf option would be a good solution. It can default to the conforming behaviour, and be overridden on a per app basis. It's a non-intrusive solution which allows fine grained control. Besides, It's been ages singe I've been able to play HG2 without the annoying grid lines :) James - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: GL_CLAMP on D3D-only hardware]
James C Georgas wrote: Forwarded Message From: James C Georgas [EMAIL PROTECTED] To: Roland Scheidegger [EMAIL PROTECTED] Subject: Re: GL_CLAMP on D3D-only hardware Date: Sun, 12 Aug 2007 12:30:51 -0400 On Sun, 2007-12-08 at 12:42 +0200, Roland Scheidegger wrote: Alex Jackson wrote: Neither the i830 nor 965gm actually support GL_CLAMP natively (yay for d3d-only hardware). The different appearance is caused by the 965 driver mapping GL_CLAMP to GL_CLAMP_TO_BORDER while the i830 maps it to GL_CLAMP_TO_EDGE. The 965 driver has a comment saying that glconform prefers GL_CLAMP_TO_BORDER, while the i830 has a comment saying that the Windows GL driver uses GL_CLAMP_TO_EDGE. Several other drivers (savage, sis, unichrome) map GL_CLAMP to GL_CLAMP_TO_EDGE. What should I do now? 1) Fix the 965 driver to make GL_CLAMP work correctly (icky, and will be slower). 2) Use GL_CLAMP_TO_EDGE in the 965 driver. 3) Use GL_CLAMP_TO_BORDER in the i830 driver. 4) Nothing. If feasible, I'd make it configurable via a .drirc option whether to map to GL_CLAMP_TO_EDGE or to GL_CLAMP_TO_BORDER, and make the former the default. This change should be made in both 965 and i830, and ideally in all the other drivers where the hardware natively supports both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER but not GL_CLAMP. Cursory Googling suggests that it's very common for other OpenGL implementations to map GL_CLAMP to GL_CLAMP_TO_EDGE (even if that's less conformant), and that consequently there're likely quite a few other OpenGL applications floating around in the wild that use GL_CLAMP when they mean GL_CLAMP_TO_EDGE. Indeed this show up every once in a while. A driconf option might be a good idea, but it doesn't solve the problem really for the hardware which indeed does support GL_CLAMP, unless you'd also introduce an option to make it non-conformant GL_CLAMP_TO_EDGE there too (which was suggested in the past). So the only real solution is to tell the app writers to fix their code. If you'd want to fix this in the driver without requiring user intervention, you'd need app detection (ugh). Roland I think I've mentioned this before, WRT the radeon driver and some old loki games, like HG2. Since we can't fix the code in these kinds of apps, I think that a driconf option would be a good solution. It can default to the conforming behaviour, and be overridden on a per app basis. It's a non-intrusive solution which allows fine grained control. Yes, though it still requires user interaction to switch the behaviour - and few people actually seem to know about driconf, distros don't install it by default etc :-(. I don't think there were really any arguments against it, probably just noone bothered to actually implement it (which should be fairly trivial). As for the hw which can't do GL_CLAMP, I'm actually not sure if an option is really needed. Both possible behaviours (unless you'd want to implement correct behaviour somehow) look equally wrong to me, and just because a conformance test thinks one is more acceptable than the other doesn't really mean anything as both are violating the spec (and thus the conformance test should probably really say both aren't right). So why don't just change it to the behaviour which fixes some old broken apps. Roland - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
Hi, On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters [...] master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... -antrik- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: GL_CLAMP on D3D-only hardware]
On Sun, 2007-12-08 at 19:09 +0200, Roland Scheidegger wrote: Yes, though it still requires user interaction to switch the behaviour - and few people actually seem to know about driconf, distros don't install it by default etc :-(. I don't think there were really any arguments against it, probably just noone bothered to actually implement it (which should be fairly trivial). As for the hw which can't do GL_CLAMP, I'm actually not sure if an option is really needed. Both possible behaviours (unless you'd want to implement correct behaviour somehow) look equally wrong to me, and just because a conformance test thinks one is more acceptable than the other doesn't really mean anything as both are violating the spec (and thus the conformance test should probably really say both aren't right). So why don't just change it to the behaviour which fixes some old broken apps. Roland Assuming that you're right about both mappings being equally wrong, I'd say that argues in favour of a driconf option instead of picking one and hardcoding it. I'd want the implementation to be written to spec, regardless of what it breaks, and then if someone wants behaviour that violates the spec, they would have to explicitly request it. I suppose a driconf option with three choices: - spec - map to GL_CLAMP_TO_EDGE - map to GL_CLAMP_TO_BORDER would do the job. I suppose that for hardware that doesn't implement GL_CLAMP, that would mean coding a slow software fallback that renders to spec. As an aside, I'm looking at the 1.4 programming guide (4th ed.), on page 418, section Repeating and Clamping Textures, where it describes the tiling effects. I read it like this: GL_NEAREST == GL_CLAMP = GL_CLAMP_TO_EDGE GL_LINEAR == GL_CLAMP = GL_CLAMP_TO_BORDER Did I interpret it right? Oh yeah, I actually tried to implement a driconf option for this once, but I couldn't get enough of a grip on the code organization to figure out where to make the change. I suppose I could give it another shot. Can someone point me to the right place in the code? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6689] libGL warning: 3D driver claims to not support visual 0x4b
http://bugs.freedesktop.org/show_bug.cgi?id=6689 --- Comment #10 from [EMAIL PROTECTED] 2007-08-12 11:46 PST --- Thanks for the proposal. Unfortunately I can't say. I have exactly no idea of Mesa sources. Maybe you can provide an appropriate patch? -- 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. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GL_CLAMP on D3D-only hardware
On Sun, 2007-12-08 at 14:43 -0400, James C Georgas wrote: As an aside, I'm looking at the 1.4 programming guide (4th ed.), on page 418, section Repeating and Clamping Textures, where it describes the tiling effects. I read it like this: GL_NEAREST == GL_CLAMP = GL_CLAMP_TO_EDGE GL_LINEAR == GL_CLAMP = GL_CLAMP_TO_BORDER Did I interpret it right? I looked at the output of the texwrap test program in the mesa source, and it looks like my second assertion above is only true in the texture co-ordinate range [0,1]. Outside [0,1], GL_CLAMP differs from both GL_CLAMP_TO_EDGE and GL_CLAMP_TO_BORDER, but only when the filter method is GL_LINEAR. So I'll agree with you now that GL_CLAMP can't just be set to GL_CLAMP_TO_EDGE or GL_CLAMP_TO_BORDER, on hardware that doesn't implement GL_CLAMP, without breaking compliance to the spec. I still think a manual override in driconf is a good idea though. Even on hardware that does implement GL_CLAMP, it'd be handy for old binary progs that assume GL_CLAMP == GL_CLAMP_TO_EDGE. James /\V - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Fwd: Re: GL_CLAMP on D3D-only hardware]
James C Georgas wrote: On Sun, 2007-12-08 at 19:09 +0200, Roland Scheidegger wrote: Yes, though it still requires user interaction to switch the behaviour - and few people actually seem to know about driconf, distros don't install it by default etc :-(. I don't think there were really any arguments against it, probably just noone bothered to actually implement it (which should be fairly trivial). As for the hw which can't do GL_CLAMP, I'm actually not sure if an option is really needed. Both possible behaviours (unless you'd want to implement correct behaviour somehow) look equally wrong to me, and just because a conformance test thinks one is more acceptable than the other doesn't really mean anything as both are violating the spec (and thus the conformance test should probably really say both aren't right). So why don't just change it to the behaviour which fixes some old broken apps. Roland Assuming that you're right about both mappings being equally wrong, I'd say that argues in favour of a driconf option instead of picking one and hardcoding it. I'd want the implementation to be written to spec, regardless of what it breaks, and then if someone wants behaviour that violates the spec, they would have to explicitly request it. I suppose a driconf option with three choices: - spec - map to GL_CLAMP_TO_EDGE - map to GL_CLAMP_TO_BORDER would do the job. I suppose that for hardware that doesn't implement GL_CLAMP, that would mean coding a slow software fallback that renders to spec. Certainly for hw which does implement GL_CLAMP, we're not going to break that (by default). And I doubt someone is going to fix the drivers which don't do clamp properly, as for most uses swrast fallbacks are essentially considered useless (though on reasonably new hw it would be possible to do fixups in the pixel shader - but it's complicated, ugly, and drivers for other OS don't do it so you can't expect anyone to write code for that (unless you got some spare time?). So the suggestion to just use clamp_to_edge instead of clamp is simply because I'm not sure if apps exist which rely on gl_clamp which would work correctly if it's forced to clamp_to_border but not clamp_to_edge, so why not just set it to clamp_to_edge to get those broken apps fixed for free? As an aside, I'm looking at the 1.4 programming guide (4th ed.), on page 418, section Repeating and Clamping Textures, where it describes the tiling effects. I read it like this: GL_NEAREST == GL_CLAMP = GL_CLAMP_TO_EDGE GL_LINEAR == GL_CLAMP = GL_CLAMP_TO_BORDER Did I interpret it right? Oh yeah, I actually tried to implement a driconf option for this once, but I couldn't get enough of a grip on the code organization to figure out where to make the change. I suppose I could give it another shot. Can someone point me to the right place in the code? You're right for clamp being clamp_to_edge for nearest filtering, but it's not the same for linear, as clamp blends the border color with the texel edge color, whereas clamp_to_border does not. Maybe something like the attached (completely untested) patch should work? It looks a bit unclean, as I pushed the fixup code into core mesa, but it essentially really is a driver-independant option, so otherwise you just need to do the same thing for all drivers which want to support it (doing it in mesa means that an app querying the state of the wrap mode will always get back clamp_to_edge instead of clamp, but I highly doubt these broken apps are going to care...). Roland diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h b/src/mesa/drivers/dri/common/xmlpool/t_options.h index 4df1916..24fdfc8 100644 --- a/src/mesa/drivers/dri/common/xmlpool/t_options.h +++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h @@ -102,6 +102,11 @@ DRI_CONF_OPT_BEGIN(force_s3tc_enable,bool,def) \ DRI_CONF_DESC(en,gettext(Enable S3TC texture compression even if software support is not available)) \ DRI_CONF_OPT_END +#define DRI_CONF_FORCE_CLAMPTOEDGE(def) \ +DRI_CONF_OPT_BEGIN(force_clamptoedge,bool,def) \ +DRI_CONF_DESC(en,gettext(Use GL_CLAMP_TO_EDGE instead of GL_CLAMP to fix broken apps)) \ +DRI_CONF_OPT_END + #define DRI_CONF_COLOR_REDUCTION_ROUND 0 #define DRI_CONF_COLOR_REDUCTION_DITHER 1 #define DRI_CONF_COLOR_REDUCTION(def) \ diff --git a/src/mesa/drivers/dri/i915tex/intel_screen.c b/src/mesa/drivers/dri/i915tex/intel_screen.c diff --git a/src/mesa/drivers/dri/r200/r200_context.c b/src/mesa/drivers/dri/r200/r200_context.c index 5a17844..420ff81 100644 --- a/src/mesa/drivers/dri/r200/r200_context.c +++ b/src/mesa/drivers/dri/r200/r200_context.c @@ -382,6 +382,7 @@ GLboolean r200CreateContext( const __GLcontextModes *glVisual, i ); ctx-Const.MaxTextureMaxAnisotropy = 16.0; + ctx-Mesa_fixup_clamp = driQueryOptionb(rmesa-optionCache, force_clamptoedge); /* No wide AA points. */ diff --git
[Bug 6689] libGL warning: 3D driver claims to not support visual 0x4b
http://bugs.freedesktop.org/show_bug.cgi?id=6689 --- Comment #11 from [EMAIL PROTECTED] 2007-08-12 16:30 PST --- Created an attachment (id=2) -- (http://bugs.freedesktop.org/attachment.cgi?id=2action=view) patch for filtering warnings about non-conformant visuals What about this patch instead. Just filters warnings about unsupported non-conformant visuals instead of relying on the visual id. Not sure though it's a good solution neither... -- 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. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6689] libGL warning: 3D driver claims to not support visual 0x4b
http://bugs.freedesktop.org/show_bug.cgi?id=6689 --- Comment #12 from [EMAIL PROTECTED] 2007-08-12 18:08 PST --- Thanks. This is definitely a better patch. -- 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. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6689] libGL warning: 3D driver claims to not support visual 0x4b
http://bugs.freedesktop.org/show_bug.cgi?id=6689 --- Comment #13 from [EMAIL PROTECTED] 2007-08-12 18:12 PST --- Hmm. Shouldn't it be if (m-visualRating != GLX_NON_CONFORMANT_CONFIG) ^^ ? -- 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. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM enhancements document
On Sunday, August 12, 2007 8:50:12 am [EMAIL PROTECTED] wrote: Hi, On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters [...] master (big boss) - X server (got its framebuffer) - X application - sub GL window of this application (might want to have its framebuffer) - GL application (dri) client running X application (got its framebuffer which can used as a texture by the compositor, hello redirected direct rendering :)) - EGL program (got its framebuffer) - Console (got its framebuffer) - GL app offscreen rendering (no framebuffer for scanout) I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Graphics hardware is somewhat different in this regard due to the large userland component to the driver. It just doesn't make sense to have console setup and console switching -- which, on a monolithic system, is part of the kernel -- depend on a userspace daemon. This would be almost as bad as the current situation, where a userspace daemon called X server is doing all the management... Well, I'm not sure it's quite as bad as you make out. The kernel must still come up with *some* initial mode, though this may typically be whatever the bootloader gave us at handoff time. Once the kernel has started init, however, a userspace program (call it 'gfxmgr') can do full output probing (i.e. monitor mode detection, output-crtc mapping, and initial mode picking) taking better advantage of the hardware. The 'gfxmgr' program should be *much* smaller than the X server, since it will be doing far less--just output probing and access control, not full mode setting (the kernel will do this), protocol management, and client scheduling. Of course, most of this has yet to be prototyped, though most of the code is already written (in some cases several times over), lying around in various projects... Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1 of 5 ] /drivers/char ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson postfail at hushmail.com
--
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index 77bf4aa..53d233e 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -936,6 +936,12 @@ static acpi_status hpet_resources(struct
acpi_resource *res, void *data)
hdp-hd_phys_address = addr.minimum;
hdp-hd_address = ioremap(addr.minimum, addr.address_length);
+ if (!hdp-hd_address) {
+ printk(KERN_DEBUG %s: ioremap failed\n,
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG %s: 0x%lx is busy\n,
__FUNCTION__, hdp-hd_phys_address);
@@ -953,6 +959,12 @@ static acpi_status hpet_resources(struct
acpi_resource *res, void *data)
hdp-hd_address = ioremap(fixmem32-address,
HPET_RANGE_SIZE);
+ if (!hdp-hd_address) {
+ printk(KERN_DEBUG %s: ioremap failed\n,
+ __FUNCTION__);
+ return -ENOMEM;
+ }
+
if (hpet_is_known(hdp)) {
printk(KERN_DEBUG %s: 0x%lx is busy\n,
__FUNCTION__, hdp-hd_phys_address);
diff --git a/drivers/char/moxa.c b/drivers/char/moxa.c
index ed76f0a..094323d 100644
--- a/drivers/char/moxa.c
+++ b/drivers/char/moxa.c
@@ -447,6 +447,13 @@ static int __init moxa_init(void)
for (i = 0; i numBoards; i++) {
moxa_boards[i].basemem = ioremap(moxa_boards[i].baseAddr,
0x4000);
+ if (!moxa_boards[i].basemem) {
+ for (;i 0;i--)
+ if (moxa_boards[i].basemem)
+ iounmap(moxa_boards[i].basemem);
+
+ return -ENOMEM;
+ }
}
return retval;
diff --git a/drivers/char/sx.c b/drivers/char/sx.c
index 85a2328..30829ed 100644
--- a/drivers/char/sx.c
+++ b/drivers/char/sx.c
@@ -2627,6 +2627,12 @@ static void __devinit fix_sx_pci(struct
pci_dev *pdev, struct sx_board *board)
pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, hwbase);
hwbase = PCI_BASE_ADDRESS_MEM_MASK;
rebase = ioremap(hwbase, 0x80);
+ if (!rebase) {
+ printk(KERN_DEBUG
+ sx:ioremap fail, unable to perform cntrl reg fix\n);
+ return;
+ }
+
t = readl(rebase + CNTRL_REG_OFFSET);
if (t != CNTRL_REG_GOODVALUE) {
printk(KERN_DEBUG sx: performing cntrl reg fix: %08x -
diff --git a/drivers/char/vr41xx_giu.c b/drivers/char/vr41xx_giu.c
index e5ed091..2381162 100644
--- a/drivers/char/vr41xx_giu.c
+++ b/drivers/char/vr41xx_giu.c
@@ -639,8 +639,10 @@ static int __devinit giu_probe(struct
platform_device *dev)
}
irq = platform_get_irq(dev, 0);
- if (irq 0 || irq = NR_IRQS)
+ if (irq 0 || irq = NR_IRQS) {
+ iounmap(giu_base);
return -EBUSY;
+ }
return cascade_irq(irq, giu_get_irq);
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2 of 5 ] /drivers/char/agp ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson postfail at hushmail.com
--
diff --git a/drivers/char/agp/amd-k7-agp.c b/drivers/char/agp/amd-
k7-agp.c
index df0ddf1..ad946fd 100644
--- a/drivers/char/agp/amd-k7-agp.c
+++ b/drivers/char/agp/amd-k7-agp.c
@@ -223,7 +223,9 @@ static int amd_irongate_configure(void)
pci_read_config_dword(agp_bridge-dev, AMD_MMBASE, temp);
temp = (temp PCI_BASE_ADDRESS_MEM_MASK);
amd_irongate_private.registers = (volatile u8 __iomem *)
ioremap(temp, 4096);
-
+ if (!amd_irongate_private.registers)
+ return -ENOMEM;
+
/* Write out the address of the gatt table */
writel(agp_bridge-gatt_bus_addr,
amd_irongate_private.registers+AMD_ATTBASE);
readl(amd_irongate_private.registers+AMD_ATTBASE); /* PCI
Posting. */
diff --git a/drivers/char/agp/ati-agp.c b/drivers/char/agp/ati-agp.c
index da7513d..95200f8 100644
--- a/drivers/char/agp/ati-agp.c
+++ b/drivers/char/agp/ati-agp.c
@@ -213,6 +213,9 @@ static int ati_configure(void)
temp = (temp 0xf000);
ati_generic_private.registers = (volatile u8 __iomem *)
ioremap(temp, 4096);
+ if (!ati_generic_private.registers)
+ return -ENOMEM;
+
if (is_r200())
pci_write_config_dword(agp_bridge-dev, ATI_RS100_IG_AGPMODE,
0x2);
else
diff --git a/drivers/char/agp/hp-agp.c b/drivers/char/agp/hp-agp.c
index bcdb149..313a133 100644
--- a/drivers/char/agp/hp-agp.c
+++ b/drivers/char/agp/hp-agp.c
@@ -221,6 +221,7 @@ hp_zx1_lba_init (u64 hpa)
if (cap != PCI_CAP_ID_AGP) {
printk(KERN_ERR PFX Invalid capability ID 0x%02x at 0x%x\n,
cap, hp-lba_cap_offset);
+ iounmap(hp-lba_regs);
return -ENODEV;
}
diff --git a/drivers/char/agp/i460-agp.c b/drivers/char/agp/i460-
agp.c
index 53354bf..75d2aca 100644
--- a/drivers/char/agp/i460-agp.c
+++ b/drivers/char/agp/i460-agp.c
@@ -249,6 +249,10 @@ static int i460_create_gatt_table (struct
agp_bridge_data *bridge)
num_entries = A_SIZE_8(temp)-num_entries;
i460.gatt = ioremap(INTEL_I460_ATTBASE, PAGE_SIZE page_order);
+ if (!i460.gatt) {
+ printk(KERN_ERR PFX ioremap failed\n);
+ return -ENOMEM;
+ }
/* These are no good, the should be removed from the agp_bridge
strucure... */
agp_bridge-gatt_table_real = NULL;
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-
agp.c
index 294cdbf..ffa7cdf 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -930,8 +930,10 @@ static int intel_i915_create_gatt_table(struct
agp_bridge_data *bridge)
temp = 0xfff8;
intel_private.registers = ioremap(temp,128 * 4096);
- if (!intel_private.registers)
+ if (!intel_private.registers) {
+ iounmap(intel_private.gtt);
return -ENOMEM;
+ }
temp = readl(intel_private.registers+I810_PGETBL_CTL)
0xf000;
global_cache_flush(); /* FIXME: ? */
@@ -985,13 +987,15 @@ static int
intel_i965_create_gatt_table(struct agp_bridge_data *bridge)
temp = 0xfff0;
intel_private.gtt = ioremap((temp + (512 * 1024)) , 512 *
1024);
- if (!intel_private.gtt)
- return -ENOMEM;
+ if (!intel_private.gtt)
+ return -ENOMEM;
intel_private.registers = ioremap(temp,128 * 4096);
- if (!intel_private.registers)
- return -ENOMEM;
+ if (!intel_private.registers) {
+ iounmap(intel_private.gtt);
+ return -ENOMEM;
+ }
temp = readl(intel_private.registers+I810_PGETBL_CTL)
0xf000;
global_cache_flush(); /* FIXME: ? */
diff --git a/drivers/char/agp/nvidia-agp.c
b/drivers/char/agp/nvidia-agp.c
index 6cd7373..225ed2a 100644
--- a/drivers/char/agp/nvidia-agp.c
+++ b/drivers/char/agp/nvidia-agp.c
@@ -157,6 +157,9 @@ static int nvidia_configure(void)
nvidia_private.aperture =
(volatile u32 __iomem *) ioremap(apbase, 33 * PAGE_SIZE);
+ if (!nvidia_private.aperture)
+ return -ENOMEM;
+
return 0;
}
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3 of 5 ] /drivers/char/drm ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson postfail at hushmail.com
--
diff --git a/drivers/char/drm/drm_bufs.c
b/drivers/char/drm/drm_bufs.c
index 923174c..448488b 100644
--- a/drivers/char/drm/drm_bufs.c
+++ b/drivers/char/drm/drm_bufs.c
@@ -177,8 +177,13 @@ static int drm_addmap_core(struct drm_device *
dev, unsigned int offset,
MTRR_TYPE_WRCOMB, 1);
}
}
- if (map-type == _DRM_REGISTERS)
+ if (map-type == _DRM_REGISTERS) {
map-handle = ioremap(map-offset, map-size);
+ if (!map-handle) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -ENOMEM;
+ }
+ }
break;
case _DRM_SHM:
list = drm_find_matching_map(dev, map);
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4 of 5 ] /drivers/char/rio ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson postfail at hushmail.com
--
diff --git a/drivers/char/rio/rio_linux.c
b/drivers/char/rio/rio_linux.c
index 0ce9667..fdaf44f 100644
--- a/drivers/char/rio/rio_linux.c
+++ b/drivers/char/rio/rio_linux.c
@@ -924,6 +924,11 @@ static void fix_rio_pci(struct pci_dev *pdev)
hwbase = pci_resource_start(pdev, 0);
rebase = ioremap(hwbase, 0x80);
+ if (!rebase) {
+ printk(KERN_DEBUG rio: unable to perform cntrl reg fix as
ioremap call failed\n);
+ return;
+ }
+
t = readl(rebase + CNTRL_REG_OFFSET);
if (t != CNTRL_REG_GOODVALUE) {
printk(KERN_DEBUG rio: performing cntrl reg fix: %08x -
%08x\n, t, CNTRL_REG_GOODVALUE);
@@ -996,6 +1001,11 @@ static int __init rio_init(void)
if (((1 hp-Ivec) rio_irqmask) == 0)
hp-Ivec = 0;
hp-Caddr = ioremap(p-RIOHosts[p-RIONumHosts].PaddrP,
RIO_WINDOW_LEN);
+ if (!hp-Caddr) {
+ printk(KERN_ERR RIO: Unable to ioremap.\n);
+ return -ENOMEM;
+ }
+
hp-CardP = (struct DpRam __iomem *) hp-Caddr;
hp-Type = RIO_PCI;
hp-Copy = rio_copy_to_card;
@@ -1049,6 +1059,10 @@ static int __init rio_init(void)
hp-Ivec = 0;
hp-Ivec |= 0x8000; /* Mark as non-sharable */
hp-Caddr = ioremap(p-RIOHosts[p-RIONumHosts].PaddrP,
RIO_WINDOW_LEN);
+ if (!hp-Caddr) {
+ printk(KERN_ERR RIO: Unable to ioremap.\n);
+ return -ENOMEM;
+ }
hp-CardP = (struct DpRam __iomem *) hp-Caddr;
hp-Type = RIO_PCI;
hp-Copy = rio_copy_to_card;
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 5 of 5 ] /drivers/char/watchdog ioremap balancing/ returncode check
patchset against 2.6.23-rc2 and this set is an audit of
/drivers/char/a*
through drivers/char .
this corrects missing ioremap return checks and balancing on
iounmap calls..
Signed-off-by: Scott Thompson postfail at hushmail.com
--
diff --git a/drivers/char/watchdog/iTCO_wdt.c
b/drivers/char/watchdog/iTCO_wdt.c
index cd5a565..81c5901 100644
--- a/drivers/char/watchdog/iTCO_wdt.c
+++ b/drivers/char/watchdog/iTCO_wdt.c
@@ -621,6 +621,12 @@ static int iTCO_wdt_init(struct pci_dev *pdev,
const struct pci_device_id *ent,
pci_read_config_dword(pdev, 0xf0, base_address);
RCBA = base_address 0xc000;
iTCO_wdt_private.gcs = ioremap((RCBA + 0x3410),4);
+ if (!iTCO_wdt_private.gcs) {
+ printk(KERN_ERR PFX failed to ioremap\n);
+ ret = -ENOMEM;
+ goto out;
+ }
+
}
/* Check chipset's NO_REBOOT bit */
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
