Bug#412069: patch for beryl support
tags 412069 +wontfix thank you Trying to summarize: About Composite, upstream just got a commit saying Enable Composite by default now that it disables itself in the known bad cases. (and it has been said that fglrx disables the DRI when Composite is enabled.) About XAANoOffScreenPixmap, Michel said: The option is only needed to work around bugs in XAA. Because basically everything is a pixmap when windows are redirected (i.e. when a compositing manager is running), it effectively disables most 2D acceleration in that case and still a large portion of it without a compositing manager. So this option can't be enabled by default, because it hurts performance i all cases *except* when running a GLX compositing manager. About AddARGBGLXVisuals, there was no actual answer. It seems nVidia specific. Since xorg.conf would have to be edited to enable the nVidia driver, this option could be added at the same time. So I would personally not enable any of these options by default (hence tagging as wontfix). It is already very late in the release cycle, changing the default config now is too dangerous according to all the above. Regarding after Etch, the X server is already much newer in experimental, Composite will be enabled safely by upstream, the XAA problems might be fixed, EXA might work much better, ... no reason to enable any of these options now then. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Wed, Mar 28, 2007 at 09:23:20AM +0200, Brice Goglin wrote: tags 412069 +wontfix thank you Trying to summarize: [...] So I would personally not enable any of these options by default (hence tagging as wontfix). It is already very late in the release cycle, changing the default config now is too dangerous according to all the above. Ok. Can we add hooks to permit that unofficial beryl packages for etch add the missing bits in xorg.conf without breaking the debconf-based generation? See attached patch. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ diff -ur xorg-7.1.0.old/debian/local/dexconf xorg-7.1.0/debian/local/dexconf --- xorg-7.1.0.old/debian/local/dexconf 2007-02-13 11:02:09.0 +0100 +++ xorg-7.1.0/debian/local/dexconf 2007-03-28 10:40:00.0 +0200 @@ -351,6 +351,7 @@ if [ $DEVICE_USE_FBDEV = true ]; then printf \tOption\t\t\UseFBDev\\t\t\$DEVICE_USE_FBDEV\\n 4 fi +(shopt -s nullglob ; for i in /etc/X11/xserver.debconf.d/device/* ; do $i 4 ; done) printf EndSection\n 4 ### MONITOR @@ -428,6 +429,12 @@ EndSection SECTION +### Extensions +exec 4$DEXCONFTMPDIR/Extensions +echo Section \Extensions\ 4 +(shopt -s nullglob ; for i in /etc/X11/xserver.debconf.d/extensions/* ; do $i 4 ; done) +echo EndSection 4 + # Close file descriptor 4 before we delete temporary files exec 4- @@ -443,7 +450,7 @@ SPACER= for SECTION in Header Files Module InputDeviceKeyboard InputDeviceMouse \ - Device Monitor Screen ServerLayout DRI; do + Device Monitor Screen ServerLayout DRI Extensions; do if [ -e $DEXCONFTMPDIR/$SECTION ]; then eval $SPACER cat $DEXCONFTMPDIR/$SECTION $OUTFILE
Bug#412069: patch for beryl support
On Wed, Mar 28, 2007 at 10:41:32 +0200, Robert Millan [ackstorm] wrote: Ok. Can we add hooks to permit that unofficial beryl packages for etch add the missing bits in xorg.conf without breaking the debconf-based generation? See attached patch. Not going to happen for etch, sorry. Cheers, Julien signature.asc Description: Digital signature
Bug#412069: patch for beryl support
On Tue, Feb 27, 2007 at 06:26:45PM -0500, David Nusinow wrote: On Tue, Feb 27, 2007 at 11:33:12AM +0100, Robert Millan [ackstorm] wrote: On Tue, Feb 27, 2007 at 10:55:55AM +0100, Michel Dänzer wrote: My point is that if we don't figure that out satisfactorily in time, we could just enable the Composite extension, which sounds fairly safe, and seems to be enough for Intel cards. And Intel happens to be the card brand we have the best driver support for (compared to a RE'd driver for ATI and nothing for nVidia), so focusing on it makes sense to me. Yes, that should be mostly safe at this point. The only exception that comes to mind offhand is that fglrx disables the DRI when Composite is enabled. If we have to choose between optimizing for free drivers that work sanely (either intel or radeon) and non-free drivers that are partly broken, I think it's clear what is better. Ok with enabling Composite by default then? Yeah, I'm fine with that, although I think the better method is to enable it directly in the server by default. That sounds more like an upstream solution. IMHO, in Debian we should do it in the conffile because: - It's more transparent. User can tell this is enabled without going through the patchset. - It's easier to disable if it turns out to be a problem (performance?). -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Tue, Feb 27, 2007 at 06:25:51PM -0500, David Nusinow wrote: On Tue, Feb 27, 2007 at 10:26:09AM +0100, Robert Millan [ackstorm] wrote: On Mon, Feb 26, 2007 at 11:02:02PM -0500, David Nusinow wrote: I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. Than can we conditionalise it? We could add a question with priority 'normal' that most users won't see. Then in the post-etch era, the Beryl community can add a reconfigure xserver-xorg and enable beryl settings step in their how-tos. If we were to do that, I suppose we would prefer to have XAANoOffscreenPixmaps and AddARGBGLXVisuals as well. I'd be fine with that. You'll have to ask the translation team for permission on this one though. I've cc'ed Christian in case he's not reading this report. Can I assume that, since you agreed to Composite by default in the other sub-thread, we're only discussing XAANoOffscreenPixmaps and AddARGBGLXVisuals here ? -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Wed, 28 Feb 2007, Robert Millan [ackstorm] wrote: On Tue, Feb 27, 2007 at 06:26:45PM -0500, David Nusinow wrote: On Tue, Feb 27, 2007 at 11:33:12AM +0100, Robert Millan [ackstorm] wrote: On Tue, Feb 27, 2007 at 10:55:55AM +0100, Michel Dänzer wrote: My point is that if we don't figure that out satisfactorily in time, we could just enable the Composite extension, which sounds fairly safe, and seems to be enough for Intel cards. And Intel happens to be the card brand we have the best driver support for (compared to a RE'd driver for ATI and nothing for nVidia), so focusing on it makes sense to me. Yes, that should be mostly safe at this point. The only exception that comes to mind offhand is that fglrx disables the DRI when Composite is enabled. If we have to choose between optimizing for free drivers that work sanely (either intel or radeon) and non-free drivers that are partly broken, I think it's clear what is better. Ok with enabling Composite by default then? Yeah, I'm fine with that, although I think the better method is to enable it directly in the server by default. That sounds more like an upstream solution. IMHO, in Debian we should do it in the conffile because: - It's more transparent. User can tell this is enabled without going through the patchset. - It's easier to disable if it turns out to be a problem (performance?). See the patch below. Messing with xorg.conf is nasty, please do it like Ubuntu (and Fedora) has done since August and enable it in the server code. Users still can disable it with their config. --- xorg-server-1.2.0/os/utils.c.orig 2007-02-26 11:08:08.0 +0100 +++ xorg-server-1.2.0/os/utils.c2007-02-26 11:08:21.0 +0100 @@ -138,7 +138,7 @@ #ifdef COMPOSITE /* COMPOSITE is disabled by default for now until the * interface is stable */ - #define COMPOSITE_DEFAULT FALSE + #define COMPOSITE_DEFAULT TRUE _X_EXPORT Bool noCompositeExtension = !COMPOSITE_DEFAULT; #endif
Bug#412069: patch for beryl support
On Wed, 2007-02-28 at 11:45 +0200, Timo Aaltonen wrote: On Wed, 28 Feb 2007, Robert Millan [ackstorm] wrote: That sounds more like an upstream solution. IMHO, in Debian we should do it in the conffile because: - It's more transparent. User can tell this is enabled without going through the patchset. - It's easier to disable if it turns out to be a problem (performance?). I agree. See the patch below. Messing with xorg.conf is nasty, please do it like Ubuntu (and Fedora) has done since August and enable it in the server code. As Robert said, this really needs to be done upstream. It's getting tiresome that some distros ship patches such as this without pushing them upstream. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#412069: patch for beryl support
On Wed, Feb 28, 2007 at 10:39:13AM +0100, Robert Millan [ackstorm] wrote: On Tue, Feb 27, 2007 at 06:25:51PM -0500, David Nusinow wrote: On Tue, Feb 27, 2007 at 10:26:09AM +0100, Robert Millan [ackstorm] wrote: On Mon, Feb 26, 2007 at 11:02:02PM -0500, David Nusinow wrote: I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. Than can we conditionalise it? We could add a question with priority 'normal' that most users won't see. Then in the post-etch era, the Beryl community can add a reconfigure xserver-xorg and enable beryl settings step in their how-tos. If we were to do that, I suppose we would prefer to have XAANoOffscreenPixmaps and AddARGBGLXVisuals as well. I'd be fine with that. You'll have to ask the translation team for permission on this one though. I've cc'ed Christian in case he's not reading this report. Can I assume that, since you agreed to Composite by default in the other sub-thread, we're only discussing XAANoOffscreenPixmaps and AddARGBGLXVisuals here ? Exactly. I don't think composite needs a debconf question. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Mon, Feb 26, 2007 at 11:02:02PM -0500, David Nusinow wrote: I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. Than can we conditionalise it? We could add a question with priority 'normal' that most users won't see. Then in the post-etch era, the Beryl community can add a reconfigure xserver-xorg and enable beryl settings step in their how-tos. If we were to do that, I suppose we would prefer to have XAANoOffscreenPixmaps and AddARGBGLXVisuals as well. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Mon, 2007-02-26 at 13:12 +0100, Robert Millan [ackstorm] wrote: On Mon, Feb 26, 2007 at 12:39:45PM +0100, Xavier Bestel wrote: On Mon, 2007-02-26 at 11:44 +0100, Robert Millan [ackstorm] wrote: My intel card can do without either XAANoOffscreenPixmaps or AddARGBGLXVisuals. No difference can be found on first sight (and I tested most basic stuff: cube, skydome, etc). nVidia doesn't need AddARGBGLXVisuals, but it needs XAANoOffscreenPixmaps. The latter is weird, as TTBOMK the nvidia driver doesn't use XAA at all. I don't know about ATI. But ATI seems to be so badly screwed wrt Beryl that we shouldn't care much. Beryl works quite well on my ATI r300 using XAANoOffscreenPixmaps - well, excepted I can't resize windows and sometimes the whole thing just freezes. Yes, but as Brice said before we shouldn't enable these options unless we know what the drawbacks are. Maybe you can investigate about that? The option is only needed to work around bugs in XAA. Because basically everything is a pixmap when windows are redirected (i.e. when a compositing manager is running), it effectively disables most 2D acceleration in that case and still a large portion of it without a compositing manager. So this option can't be enabled by default, because it hurts performance in all cases *except* when running a GLX compositing manager. My point is that if we don't figure that out satisfactorily in time, we could just enable the Composite extension, which sounds fairly safe, and seems to be enough for Intel cards. And Intel happens to be the card brand we have the best driver support for (compared to a RE'd driver for ATI and nothing for nVidia), so focusing on it makes sense to me. Yes, that should be mostly safe at this point. The only exception that comes to mind offhand is that fglrx disables the DRI when Composite is enabled. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Bug#412069: patch for beryl support
On Tue, Feb 27, 2007 at 10:55:55AM +0100, Michel Dänzer wrote: My point is that if we don't figure that out satisfactorily in time, we could just enable the Composite extension, which sounds fairly safe, and seems to be enough for Intel cards. And Intel happens to be the card brand we have the best driver support for (compared to a RE'd driver for ATI and nothing for nVidia), so focusing on it makes sense to me. Yes, that should be mostly safe at this point. The only exception that comes to mind offhand is that fglrx disables the DRI when Composite is enabled. If we have to choose between optimizing for free drivers that work sanely (either intel or radeon) and non-free drivers that are partly broken, I think it's clear what is better. Ok with enabling Composite by default then? -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Tue, Feb 27, 2007 at 10:26:09AM +0100, Robert Millan [ackstorm] wrote: On Mon, Feb 26, 2007 at 11:02:02PM -0500, David Nusinow wrote: I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. Than can we conditionalise it? We could add a question with priority 'normal' that most users won't see. Then in the post-etch era, the Beryl community can add a reconfigure xserver-xorg and enable beryl settings step in their how-tos. If we were to do that, I suppose we would prefer to have XAANoOffscreenPixmaps and AddARGBGLXVisuals as well. I'd be fine with that. You'll have to ask the translation team for permission on this one though. I've cc'ed Christian in case he's not reading this report. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Tue, Feb 27, 2007 at 11:33:12AM +0100, Robert Millan [ackstorm] wrote: On Tue, Feb 27, 2007 at 10:55:55AM +0100, Michel Dänzer wrote: My point is that if we don't figure that out satisfactorily in time, we could just enable the Composite extension, which sounds fairly safe, and seems to be enough for Intel cards. And Intel happens to be the card brand we have the best driver support for (compared to a RE'd driver for ATI and nothing for nVidia), so focusing on it makes sense to me. Yes, that should be mostly safe at this point. The only exception that comes to mind offhand is that fglrx disables the DRI when Composite is enabled. If we have to choose between optimizing for free drivers that work sanely (either intel or radeon) and non-free drivers that are partly broken, I think it's clear what is better. Ok with enabling Composite by default then? Yeah, I'm fine with that, although I think the better method is to enable it directly in the server by default. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Mon, Feb 26, 2007 at 11:44:36AM +0100, Robert Millan [ackstorm] wrote: On Fri, Feb 23, 2007 at 10:25:56PM +0100, Robert Millan wrote: Oh, not really. Screw nVidia. Beryl is only for faithful followers of the one true Intel card brand. :-) So which lines are we going to add, if any? I can test which lines can Intel do without, but not till monday. My intel card can do without either XAANoOffscreenPixmaps or AddARGBGLXVisuals. No difference can be found on first sight (and I tested most basic stuff: cube, skydome, etc). nVidia doesn't need AddARGBGLXVisuals, but it needs XAANoOffscreenPixmaps. I don't know about ATI. But ATI seems to be so badly screwed wrt Beryl that we shouldn't care much. Given all this, can we at least enable the Composite part by default to make Intel cards work? Patch attached. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ diff -ur xorg-7.1.0.old/debian/local/dexconf xorg-7.1.0/debian/local/dexconf --- xorg-7.1.0.old/debian/local/dexconf 2007-02-13 11:02:09.0 +0100 +++ xorg-7.1.0/debian/local/dexconf 2007-02-23 12:07:45.0 +0100 @@ -428,6 +433,15 @@ EndSection SECTION +### Extensions +exec 4$DEXCONFTMPDIR/Extensions +cat 4 SECTION +Section Extensions + # needed for beryl + Option Composite Enable +EndSection +SECTION + # Close file descriptor 4 before we delete temporary files exec 4- @@ -443,7 +457,7 @@ SPACER= for SECTION in Header Files Module InputDeviceKeyboard InputDeviceMouse \ - Device Monitor Screen ServerLayout DRI; do + Device Monitor Screen ServerLayout DRI Extensions; do if [ -e $DEXCONFTMPDIR/$SECTION ]; then eval $SPACER cat $DEXCONFTMPDIR/$SECTION $OUTFILE
Bug#412069: patch for beryl support
On Fri, Feb 23, 2007 at 10:25:56PM +0100, Robert Millan wrote: Oh, not really. Screw nVidia. Beryl is only for faithful followers of the one true Intel card brand. :-) So which lines are we going to add, if any? I can test which lines can Intel do without, but not till monday. My intel card can do without either XAANoOffscreenPixmaps or AddARGBGLXVisuals. No difference can be found on first sight (and I tested most basic stuff: cube, skydome, etc). nVidia doesn't need AddARGBGLXVisuals, but it needs XAANoOffscreenPixmaps. I don't know about ATI. But ATI seems to be so badly screwed wrt Beryl that we shouldn't care much. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Mon, 2007-02-26 at 11:44 +0100, Robert Millan [ackstorm] wrote: My intel card can do without either XAANoOffscreenPixmaps or AddARGBGLXVisuals. No difference can be found on first sight (and I tested most basic stuff: cube, skydome, etc). nVidia doesn't need AddARGBGLXVisuals, but it needs XAANoOffscreenPixmaps. I don't know about ATI. But ATI seems to be so badly screwed wrt Beryl that we shouldn't care much. Beryl works quite well on my ATI r300 using XAANoOffscreenPixmaps - well, excepted I can't resize windows and sometimes the whole thing just freezes. Xav -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Mon, Feb 26, 2007 at 12:39:45PM +0100, Xavier Bestel wrote: On Mon, 2007-02-26 at 11:44 +0100, Robert Millan [ackstorm] wrote: My intel card can do without either XAANoOffscreenPixmaps or AddARGBGLXVisuals. No difference can be found on first sight (and I tested most basic stuff: cube, skydome, etc). nVidia doesn't need AddARGBGLXVisuals, but it needs XAANoOffscreenPixmaps. I don't know about ATI. But ATI seems to be so badly screwed wrt Beryl that we shouldn't care much. Beryl works quite well on my ATI r300 using XAANoOffscreenPixmaps - well, excepted I can't resize windows and sometimes the whole thing just freezes. Yes, but as Brice said before we shouldn't enable these options unless we know what the drawbacks are. Maybe you can investigate about that? My point is that if we don't figure that out satisfactorily in time, we could just enable the Composite extension, which sounds fairly safe, and seems to be enough for Intel cards. And Intel happens to be the card brand we have the best driver support for (compared to a RE'd driver for ATI and nothing for nVidia), so focusing on it makes sense to me. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Fri, Feb 23, 2007 at 12:18:06PM +0100, Robert Millan [ackstorm] wrote: Package: xserver-xorg Severity: wishlist Tags: patch I know it's too late for Beryl to make it into etch, but can we at least ship an xorg.conf that is frendly to Beryl ? With this patch, only installing the beryl packages will be enough to get it working with no further setup (provided that OpenGL is working fine). Also note that having these extra lines in your xorg.conf is harmless for non-Beryl users (at least it didn't produce any new warnings or errors in /var/log/Xorg.log for me), so I propose to add them unconditionaly. Please, can this make it into etch? This kind of eye-candy is _awesome_ to attract new users. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ diff -ur xorg-7.1.0.old/debian/local/dexconf xorg-7.1.0/debian/local/dexconf --- xorg-7.1.0.old/debian/local/dexconf 2007-02-13 11:02:09.0 +0100 +++ xorg-7.1.0/debian/local/dexconf 2007-02-23 12:07:45.0 +0100 @@ -351,6 +351,11 @@ if [ $DEVICE_USE_FBDEV = true ]; then printf \tOption\t\t\UseFBDev\\t\t\$DEVICE_USE_FBDEV\\n 4 fi +cat 4 SECTION + # needed for beryl + Option XAANoOffscreenPixmaps true + Option AddARGBGLXVisuals On These aren't generally necessary, and I don't believe it's a good idea to set them as default when they're not needed. The latter may be harmless, but I don't know enough about the former, since it only appears to be useful on some ati hardware. There's a reason why upstream hasn't enabled it by default in the driver. +SECTION printf EndSection\n 4 ### MONITOR @@ -428,6 +433,15 @@ EndSection SECTION +### Extensions +exec 4$DEXCONFTMPDIR/Extensions +cat 4 SECTION +Section Extensions + # needed for beryl + Option Composite Enable +EndSection +SECTION I haven't decided if enabling composite by default is a wise move yet. No one in Debian has done a real analysis as to what the downsides of such a decision are. While compiz and beryl may be very sexy, I don't want to break or degrade performance on systems not running them simply for the convenience of not having to modify xorg.conf. It's not out of the question, but I don't want to blindly enable options in our default settings for the bling of it. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
Package: xserver-xorg Severity: wishlist Tags: patch I know it's too late for Beryl to make it into etch, but can we at least ship an xorg.conf that is frendly to Beryl ? With this patch, only installing the beryl packages will be enough to get it working with no further setup (provided that OpenGL is working fine). Also note that having these extra lines in your xorg.conf is harmless for non-Beryl users (at least it didn't produce any new warnings or errors in /var/log/Xorg.log for me), so I propose to add them unconditionaly. Please, can this make it into etch? This kind of eye-candy is _awesome_ to attract new users. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ diff -ur xorg-7.1.0.old/debian/local/dexconf xorg-7.1.0/debian/local/dexconf --- xorg-7.1.0.old/debian/local/dexconf 2007-02-13 11:02:09.0 +0100 +++ xorg-7.1.0/debian/local/dexconf 2007-02-23 12:07:45.0 +0100 @@ -351,6 +351,11 @@ if [ $DEVICE_USE_FBDEV = true ]; then printf \tOption\t\t\UseFBDev\\t\t\$DEVICE_USE_FBDEV\\n 4 fi +cat 4 SECTION + # needed for beryl + Option XAANoOffscreenPixmaps true + Option AddARGBGLXVisuals On +SECTION printf EndSection\n 4 ### MONITOR @@ -428,6 +433,15 @@ EndSection SECTION +### Extensions +exec 4$DEXCONFTMPDIR/Extensions +cat 4 SECTION +Section Extensions + # needed for beryl + Option Composite Enable +EndSection +SECTION + # Close file descriptor 4 before we delete temporary files exec 4- @@ -443,7 +457,7 @@ SPACER= for SECTION in Header Files Module InputDeviceKeyboard InputDeviceMouse \ - Device Monitor Screen ServerLayout DRI; do + Device Monitor Screen ServerLayout DRI Extensions; do if [ -e $DEXCONFTMPDIR/$SECTION ]; then eval $SPACER cat $DEXCONFTMPDIR/$SECTION $OUTFILE
Bug#412069: patch for beryl support
Robert Millan [ackstorm] wrote: + Option AddARGBGLXVisuals On I thought this option was nVidia specific. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Fri, Feb 23, 2007 at 12:54:58PM +0100, Brice Goglin wrote: Robert Millan [ackstorm] wrote: + Option AddARGBGLXVisuals On I thought this option was nVidia specific. According to the wiki [1], it is optional if NVIDIA drivers are used. On my Intel chipset, this line didn't break anything. [1] http://wiki.beryl-project.org/wiki/Install_Beryl_on_Debian#Configure_xorg.conf -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
Robert Millan [ackstorm] wrote: On Fri, Feb 23, 2007 at 12:54:58PM +0100, Brice Goglin wrote: Robert Millan [ackstorm] wrote: + Option AddARGBGLXVisuals On I thought this option was nVidia specific. According to the wiki [1], it is optional if NVIDIA drivers are used. This comment is for XAANoOffscreenPixmaps. I could say ok to adding this option since I remember seeing improvement in Compiz when enabling it on my Radeon. But, I don't know what its drawbacks are. About being nVidia specific, I was talking about the other line, AddARGBGLXVisuals, I have no idea what this option does. On my Intel chipset, this line didn't break anything. So you think we should add nVidia crap to anybody's xorg.conf just because there are some users of these evil non-free drivers out there ? :) Anyway, as long as nobody explained the drawbacks of these options (and there are probably some, or they would be enabled by default), there is no way this is going to be enabled by default, sorry. It is important to keep the default config working on most boards, including the old ones that might not support Compiz/Beryl at all for some reason (for instance their video memory could not be large enough to store offscreenpixmaps?). Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
This comment is for XAANoOffscreenPixmaps. I could say ok to adding this option since I remember seeing improvement in Compiz when enabling it on my Radeon. But, I don't know what its drawbacks are. About being nVidia specific, I was talking about the other line, AddARGBGLXVisuals, I have no idea what this option does. Neither me, I just got them from the wiki. If you're concerned about yet-to-be-found drawbacks, we could make it optional via debconf then? On my Intel chipset, this line didn't break anything. So you think we should add nVidia crap to anybody's xorg.conf just because there are some users of these evil non-free drivers out there ? :) Oh, not really. Screw nVidia. Beryl is only for faithful followers of the one true Intel card brand. :-) So which lines are we going to add, if any? I can test which lines can Intel do without, but not till monday. Anyway, as long as nobody explained the drawbacks of these options (and there are probably some, or they would be enabled by default), there is no way this is going to be enabled by default, sorry. It is important to keep the default config working on most boards, including the old ones that might not support Compiz/Beryl at all for some reason (for instance their video memory could not be large enough to store offscreenpixmaps?). Want a patch to make a debconf option for this? -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412069: patch for beryl support
On Fri, Feb 23, 2007 at 10:25:56PM +0100, Robert Millan wrote: About being nVidia specific, I was talking about the other line, AddARGBGLXVisuals, I have no idea what this option does. Neither me, I just got them from the wiki. I just tried on an nVidia, and it turns out AddARGBGLXVisuals is the only option for which enabling/disabling doesn't seem to make any difference in beryl. As for the other two, Beryl can't do without them (in nVidia, that is). I'll test Intel tomorrow. As for ATI, let's say all my ATI cards are currently 2D junk. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
