Re: [compiz] GL_MAX_TEXTURE_SIZE and dual-screens
Le dimanche 02 décembre 2007 à 01:38 +0100, Dennis Kasprzyk a écrit :
> Am Samstag, 1. Dezember 2007 12:10:51 schrieb Xavier Bestel:
> > Hi,
> >
> > I'm running compiz on a r300, dual-screens setup. The r300 driver has a
> > GL_MAX_TEXTURE_SIZE = 2048 limit, and it shows: the nautilus backdrop
> > window doesn't cover both screens.
> >
> > Is there a mean to let compiz sort of "split" the nautilus window to
> > stay within the 2048 limit on each screen ?
> >
>
> I've posted a patch to this mailing list a while ago ("WARNING ONLY A PROOF
> OF
> CONCEPT: copy texturing to fix maximum texture size restrictions") that was
> using copy to texture to fix this problem. But compiz will need some internal
> changes to allow an implementation of such system in a clean way.
>
> I'm sorry, but you will have to wait.
Ok. Do you have any idea when this could happen ?
Thanks,
Xav
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] SuSE 10.3 New 711 Driver - Fatal: GLX_EXT_texture_from_pixmap is missing
Guys, Since loading xorg 7.3 I have not been able to get compiz working on my Toshiba Satellite laptop with the ATI mobility radeon 9700 card. I was hoping that the new driver would work, but unfortunately I still receive fatal errors when trying to start compiz. Here is the error: 20:27 rankin-p35a~> compiz --replace --sm-disable --ignore-desktop-hints ccp --indirect-rendering --no-libgl-fallback emerald --replace compiz (core) - Fatal: GLX_EXT_texture_from_pixmap is missing compiz (core) - Error: Failed to manage screen: 0 compiz (core) - Fatal: No manageable screens found on display :0.0 Does anybody have any thoughts on this problem, or what I could try to attempt to get compiz back? I have made the required library adjustments, but still no luck: 20:37 rankin-p35a~> l /usr/lib/libGL.so* lrwxrwxrwx 1 root root 10 2007-11-09 16:19 /usr/lib/libGL.so -> libGL.so.1* lrwxrwxrwx 1 root root 12 2007-11-14 10:06 /usr/lib/libGL.so.1 -> libGL.so.1.2* lrwxrwxrwx 1 root root 27 2007-12-02 20:05 /usr/lib/libGL.so.1.2 -> /usr/X11R6/lib/libGL.so.1.2* -rwxr-xr-x 1 root root 391344 2007-09-21 20:34 /usr/lib/libGL.so.1.2.sav* 20:38 rankin-p35a~> l /usr/lib/libIn* -rwxr-xr-x 1 root root 440676 2007-09-21 20:34 /usr/lib/libIndirectGL.so.1.2* lrwxrwxrwx 1 root root 20 2007-11-09 16:19 /usr/lib/libIndirectGL.so.1.sav -> libIndirectGL.so.1.2* Any help will be greatly appreciated. -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] GL_MAX_TEXTURE_SIZE and dual-screens
Hi Dennis,
I'm not terribly active on this list but I posted the exact same
request several months ago.
Lots of users out there could benefit from this being implemented,
especially people with these old-ish ATI cards.
And to Xavier,
A bit of googling led me to find the patch at
http://lists.freedesktop.org/archives/compiz/2007-May/002165.html
but I was unable to apply it (couldn't find the right locations for
the diffs.) I have to admit I gave up.
I've since upgraded to a Nvidia 8800GTS, the r300 isn't fast enough
for modern games.
It's got support for at least 4096x4096 textures.
It's an expensive solution, but might I suggest upgrading to a newer
ATI or Nvidia card?
I'm no expert but I hope even budget cards can do 4096x4096 textures.
Cheers
Chris.
On Dec 3, 2007 2:51 AM, Xavier Bestel <[EMAIL PROTECTED]> wrote:
> Le dimanche 02 décembre 2007 à 01:38 +0100, Dennis Kasprzyk a écrit :
> > Am Samstag, 1. Dezember 2007 12:10:51 schrieb Xavier Bestel:
> > > Hi,
> > >
> > > I'm running compiz on a r300, dual-screens setup. The r300 driver has a
> > > GL_MAX_TEXTURE_SIZE = 2048 limit, and it shows: the nautilus backdrop
> > > window doesn't cover both screens.
> > >
> > > Is there a mean to let compiz sort of "split" the nautilus window to
> > > stay within the 2048 limit on each screen ?
> > >
> >
> > I've posted a patch to this mailing list a while ago ("WARNING ONLY A PROOF
> > OF
> > CONCEPT: copy texturing to fix maximum texture size restrictions") that was
> > using copy to texture to fix this problem. But compiz will need some
> > internal
> > changes to allow an implementation of such system in a clean way.
> >
> > I'm sorry, but you will have to wait.
>
> Ok. Do you have any idea when this could happen ?
>
> Thanks,
> Xav
>
>
>
> ___
> compiz mailing list
> compiz@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>
>
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] GL_MAX_TEXTURE_SIZE and dual-screens
Hi Chris, Le lundi 03 décembre 2007 à 16:25 +1100, Chris Adams a écrit : > A bit of googling led me to find the patch at > http://lists.freedesktop.org/archives/compiz/2007-May/002165.html > but I was unable to apply it (couldn't find the right locations for > the diffs.) I have to admit I gave up. > > I've since upgraded to a Nvidia 8800GTS, the r300 isn't fast enough > for modern games. > It's got support for at least 4096x4096 textures. > > It's an expensive solution, but might I suggest upgrading to a newer > ATI or Nvidia card? > I'm no expert but I hope even budget cards can do 4096x4096 textures. All decent cards nowadays are PCI-E, so that would mean changing the whole machine. I intend to do that as soon as there are free 3d drivers for a good card (any brand). In the remaining time, I'm just waiting. Thanks, Xav ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] object framework design
I'm going to start today by posting the first two, out of a series of four documents describing the work done in the object-framework branch. This post is just a heads-up but I'd also like to make sure people understand that what's described in these docs and what's in the object-framework branch is not set in stone in any way. It's a proposal based on my experience with the current compiz code-base and the research I've done lately for how we can move to what I think is a much more appropriate architecture. Feedback is much appreciated. I'm confident that with the object-framework branch work as base, together we can implement a system that is hugely superior to what we currently have. Thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] object framework design, part I: OBJECT MODEL
OBJECT MODEL A hierarchical object model is used. Every object has a name and a parent reference, which together provide an object path from each ancestors to the object itself. It's a single inheritance object system. However, each object can implement any number of interfaces. All methods and members belong to some interface. Interfaces that are not part of the object type can be added and removed dynamically during an object instance's lifetime. LIFO (Last In First Out) order applies, though. The system contains built-in support for introspection, hence also safe invocation of object methods (member functions). Object types are not much more than names without an object tree. An object tree and a parent node is required to instantiate and insert an object of any other type than the root type. Only one object of the root type can exist in an object tree. This means that an object type can optionally be present in only a part of the complete object tree. To ensure that different modules, unaware of each other, can access, extend and manipulate an object tree in an robust, easily predictable and safe manner, object tree processing is done in a very well defined way. These three rules apply for all modules: 1. Member functions should never try to access objects outside its own sub-tree. 2. Member functions should never invoke member functions in any of its ancestors. 3. Member functions should never try to access members or children provided by interfaces that are part of derived types or loaded after the member functions own interface. A module that doesn't comply with these rules is considered broken. However, the object system has been carefully designed so that writing code that break any of these rules is hard, if not impossible in most cases, so developers rarely need to worry about it. >From this description, it might sound similar to some other existing object systems that could be reused instead of creating this new system. However, there's a lot of important details that make the extremely extensible system that we need in compiz efficient, robust and easy to maintain. This system also takes into account that most compiz modules will be of a hierarchical nature and very performance sensitive as most non-performance sensitive code will preferably be moved to a separate process. More about these details in following posts. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] object framework design, part II: COMMUNICATION
COMMUNICATION Method Invocation The most common form of communication between an object and one of its descendants is done by invoking one of the descendant's member functions. Values can be passed to the descendant using function arguments and values can be passed back to the ancestor using the return value of the member function or one of its arguments. It's a regular function call, hence also very efficient. As member functions can't access members or children provided by interfaces that are part of derived types or loaded after the member functions own interface, some other form of communication interface is required as well. Signals Signals are basically just member functions for which invocation can be connected to a member function of one of its descendants. It's also possible to connect invocation to a member function of the object itself but the function must then be part the interface with signal, a base-type interface or one of the interfaces that became available before the interface with signal. A member function can only be connected to member functions with a matching prototype. Computational time to emit a signal is linear to the number of connected member functions, so in theory just as an efficient form of communication as method invocation. A unique handle is created for every function that is connected to a signal. This handle can be used to break the connection. However, this rarely needs to be done thanks to the hierarchical object model used, which allow signal connections to be broken automatically as interfaces and objects are removed from the object tree. Method invocation and the signals mechanism described here are both forms of communication that needs to be initiated by an ancestor object. Signed signals It's quite common that you want processing done in a descendant's member function to trigger invocation of an ancestor member function. Signed signals allow this form of communication. Signed signals are simply signals for which a signature has been provided. Just like a signature can be provided for a member function so it can be introspected and invoked safely. Signed signals are emitted and can be connected to just like all other signals. However, a chunk of data that describe the signal is also created and stored in a queue within the object tree's root node each time a signed signal is emitted. This queue is processed asynchronously from the main loop. During processing of a queued signal, the signal named "signal" which is part of the interface also named "signal" implemented by the base object type is invoked for the object that emitted the original signed signal and all of its ancestors. The data describing the signed signal is passed as an argument to the "signal" signal. So by connecting to an objects "signal" signal, it's possible to monitor an invoke appropriate member functions for each signed signal emitted by the object and all its descendants. Inter-Process Communication The object system itself is designed to promote creation of interfaces that are well suited for IPC. The communication interfaces provided within the object system makes it easy for modules with access to an object tree or part of an object tree to safely invoke any member function with a signature as a response to some IO event and send notifications to interested destinations when any signed signal has been emitted. --- -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] SuSE 10.3 New 711 Driver - Fatal: GLX_EXT_texture_from_pixmap is missing
On Dec 3, 2007 8:09 AM, David C. Rankin <[EMAIL PROTECTED]> wrote: > Guys, > > Since loading xorg 7.3 I have not been able to get compiz working on > my > Toshiba Satellite laptop with the ATI mobility radeon 9700 card. I was > hoping that the new driver would work, but unfortunately I still receive > fatal errors when trying to start compiz. Here is the error: Use 7.2 unless there are some features in 7.3 you cannot live without. > > > Does anybody have any thoughts on this problem, or what I could try to > attempt to get compiz back? I have made the required library > adjustments, but still no luck: You do not have to change any library paths. See http://dev.compiz-fusion.org/~cyberorg/2007/11/23/ati-84337-11-on-opensuse-howto/ Ciao -J ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] object framework design
So far it sounds like the objects, interfaces, methods and signals map very easily to dbus. Did you design the object system with that in mind? To easily integrate compiz and dbus? tom ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
