Re: How does XSetInputFocus() generate errors?
Wanna guess the worst offending x app I've seen? (B (BIt starts with "ja" ends with "va" ... (can you "swing" an answer to this) (B (B- Original Message - (BFrom: "Carsten Haitzler (The Rasterman)" <[EMAIL PROTECTED]> (BTo: <[EMAIL PROTECTED]> (BCc: <[EMAIL PROTECTED]> (BSent: Friday, December 17, 2004 6:11 PM (BSubject: Re: How does XSetInputFocus() generate errors? (B (B (B> On Fri, 17 Dec 2004 17:31:35 -0800 "Robert Currey" <[EMAIL PROTECTED]> (Bbabbled: (B> (B> > > the protocol level you will know just which calls these are. some of (Bthem: (B> > > XGetWindowAttributes, XSync, XQueryTree, XGetWindowProperty, (BXInternAtom, (B> > > XGetImage. (B> > (B> > This is TRUTH ... I had a "debate" one time with someone who claimed X (Bwas (B> > asyncronous ... for the protocol, that is true, but using Xlib and with (Bthe (B> > cases stated, it is NOT. XGetWindowAttributes is probably the nastiest (Bof (B> > the bunch (I've seen apps do XGetWindowAttributes/XSetWindowAttributes (B> > hundreds of times during startup and/or worse opening a window). (BXInternAtom (B> > and XGetWindowProperty are the other most common culprits. (B> (B> oh yeah. hell yeah. actually - writing wm's has made me acutely aware of (Ball of (B> this. i am going to the extent of trying to remove get property requests (B> entirely right now by first listing (a round trip unfortunately) then only (B> fetching the properties that exist (at that time) that i care about (as a (Bwm), (B> then relying on property change events to fetch any that get added later. (Bbut (B> even this sucks. this is where xcb rules the roost. it talks raw x (Bprotocol. i (B> can just send off my property fetch requests (and atom fetches at the (Bstart) all (B> nicely batched off and get them back later as asynchronous reply "events". (Bsince (B> the hole codebase is entirely event driven this works perfectly within the (B> existing coding model. BUt the issue here is programmers knowing all this (Band (B> spending the time to optimise through it are rare - most think in (B"get/reply" (B> scenarios where when the function returns the information has been fetched (Band (B> handed back to the app. it takes a bit of mind bending to start thinking (Bof your (B> entire app as being asynchronous - even to your display. xlib was written (Bwith i (B> guess the assumption that such mental gymnastics are often beyond a lot of (B> programmers and thus xlib hides it. i do say it is easier to do it that (Bway too (B> - until you realise the ugliness of the overhead behind it all and recoil (Bin (B> shock. :) (B> (B> > One common app would XGetImage the area under the cursor so it could do (Ba (B> > pretty "i beam" ... ugh (B> (B> as long as it queued the get for "idle time" (ie just before it goes back (Bto a (B> select() or a blocking wait for events etc.) making sure it didn't do it (Bfor (B> every single mouse motion event... this won't be THAT bad... well not on a (Blocal (B> machine (network badness will vary on nastiness of the network) :) a few (Bround (B> trips per event cycle isn't too bad as new events are buffered/batched and (Bthen (B> dealt with in a batch so the app is a bit jerkier but it "plays catch-up" (Bto the (B> input stream. unfortunately a lot of software does not do this. they do (Bwork for (B> every mouse motion or whatever event. if the expense of dealing with those (B> events is greater than the time between events... the app is in grave (Btrouble. (B> the problem here is... run the app on a slow/old machine and this scenario (Bis (B> MUCH more likely... now the app falls increasingly behind "realtime" (B(where the (B> user has their mouse now or what events have happened) and this is when (Bevilness (B> really shows its head and you notice how poorly programmed that client is. (B> (B> > Rob (B> > (B> > ___ (B> > Devel mailing list (B> > [EMAIL PROTECTED] (B> > http://XFree86.Org/mailman/listinfo/devel (B> > (B> (B> (B> -- (B> - Codito, ergo sum - "I code, therefore I am" -- (B> The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] (B> $BMg9%B?(B [EMAIL PROTECTED] (B> Tokyo, Japan ($BEl5~(B $BF|K\(B) (B> (B (B___ (BDevel mailing list ([EMAIL PROTECTED] (Bhttp://XFree86.Org/mailman/listinfo/devel
Re: How does XSetInputFocus() generate errors?
> it's not just a network that can be slow. if you are concerned about (Bperformance (B> with your x apps, mere context switching is an issue. if you do it often (Benough (B> (and sit, blocking and waiting for a reply). this asynchronous behavior is (B> highly desirable even for local communication. it allows x to take "system (B> overhead" and minimise it severely - by design. (B> (B> though this is where the fun comes... not all xlib calls are asynchronous. (Bsome (B> are synchronous. they sit and WAIT for a reply from x. generally it is (Badvised (B> to AVOID these calls when you can or minimise their use. if you understand (Bx at (B> the protocol level you will know just which calls these are. some of them: (B> XGetWindowAttributes, XSync, XQueryTree, XGetWindowProperty, XInternAtom, (B> XGetImage. (B (BThis is TRUTH ... I had a "debate" one time with someone who claimed X was (Basyncronous ... for the protocol, that is true, but using Xlib and with the (Bcases stated, it is NOT. XGetWindowAttributes is probably the nastiest of (Bthe bunch (I've seen apps do XGetWindowAttributes/XSetWindowAttributes (Bhundreds of times during startup and/or worse opening a window). XInternAtom (Band XGetWindowProperty are the other most common culprits. (B (BOne common app would XGetImage the area under the cursor so it could do a (Bpretty "i beam" ... ugh (B (BRob (B (B___ (BDevel mailing list ([EMAIL PROTECTED] (Bhttp://XFree86.Org/mailman/listinfo/devel
Re: finding all windows belonging to an application
Probably should also keep in mind that a single application (e.g. process) might appear to an Xserver as multiple Xclients. (I think the most common case would be a multi-thread QT app). I've seen this also occur for "modeless" dialogs where an app either forks or spins a thread to handle the modeless dialog. To the Xserver, it looks like an entirely new Xclient (new connection, new XID, etc), but the Xclient process (in a threaded case) is the same pid. Rob - Original Message - From: "Grant Wallace" <[EMAIL PROTECTED]> To: "Mark Vojkovich" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, November 09, 2004 1:58 PM Subject: Re: finding all windows belonging to an application > Yes, I see the pattern you mention in XID. Appears > that the most significant two bytes identify client > and the least sig two bytes identify window. This > should solve my problem. Thanks very much. > > Grant. > > --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: > > > > >All the resources allocated by a single client > > will have the > > same XID prefix. Look at the output of "xwininfo > > -children -root" > > and you'll see what I mean. What you probably want > > to do is search > > from the root and find the all the top-level windows > > with your > > client's prefix. > > > > > > Mark. > > > > > > On Mon, 8 Nov 2004, Grant Wallace wrote: > > > > > Hi, > > > I'm working on modifications to VNC server to > > share > > > individual applications. One thing I'm wondering > > about > > > is how do I find all windows which belong to the > > same > > > application. For instance I currently am able to > > share > > > the application's main window by using xwininfo > > and > > > getting the main windows ID number. Then I just > > > traverse the windows tree searching for that id. > > > However if the application later opens a dialog > > box or > > > a menu window I'd like to detect that while > > traversing > > > the windows tree and share it also. I haven't yet > > > found any field within the window data structure > > that > > > identifies which application a window belongs to. > > > What's the best way to find all these related > > windows > > > (related by application rather than window > > hierarchy)? > > > > > > Thanks, > > > Grant. > > > > > > > > > > > > > > > > > > __ > > > Do you Yahoo!? > > > Check out the new Yahoo! Front Page. > > > www.yahoo.com > > > > > > > > > ___ > > > Devel mailing list > > > [EMAIL PROTECTED] > > > http://XFree86.Org/mailman/listinfo/devel > > > > > > > > > > __ > Do you Yahoo!? > Check out the new Yahoo! Front Page. > www.yahoo.com > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Memory leaks when lots of graphical operations? [Qt/X11 3.1.1]
How are you determining "memory in use"?
does this also show "memory in use"?
#include
int main(int argc, char** argv)
{
int a = atoi(argv[1]);
int i;
int j = 0;
void* b[a];
printf("starting loops\n");
{
for (i=0; i
To: <[EMAIL PROTECTED]>
Sent: Monday, October 18, 2004 9:27 AM
Subject: RE: Memory leaks when lots of graphical operations? [Qt/X11 3.1.1]
> I tried a memory leak finder (e.g. LeakTracer) and... nothing! Well, there
are still some in my code and Qt but total amount of leak is about 25KB (and
it's not repetitive memory leak : memory leak is the same wether I send many
requests or not), while memory took 25MB!
>
> Any idea to known what is finally making memory use grow if it's not my
code or Qt? Another memory leak finder?
>
> Thanks in anticipation!
>
> Cheers,
>
> Sébastien
>
> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part
> de Mark Vojkovich
> Envoyé : vendredi 15 octobre 2004 19:44
> À : [EMAIL PROTECTED]
> Objet : RE: Memory leaks when lots of graphical operations? [Qt/X11
> 3.1.1]
>
>
> On Fri, 15 Oct 2004, [iso-8859-1] Sébastien ZINSIUS wrote:
>
> > the app's... I know it does not seem to be X server that has to be
blamed, but I'm convinced that my problem is linked to "graphical" side,
either in Qt or Xlib functions. I traced event creations and deletions (Qt
side ; as I have an external thread that stress GUI, I have to pass through
Qt custom events), and no events seem to be lost on the Qt side (all the
event destructors are called). On the other side, memory use is still
growing...
> >
> > Do you know if there was any major memory leak that has been found
recently or not in Xlib?
>
> There are no leaks in that stuff. You've got an app bug or Qt bug
> or something. I recall one app that requested alot of X events but never
> actually took them off of the queue so they just piled up in the client.
>
> >
> > Is there a way to trace X operations?
>
>There's no tracing feature in Xlib.
>
>
> Mark.
>
> >
> > Cheers,
> >
> > Sébastien
> >
> > -Message d'origine-
> > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part
> > de Mark Vojkovich
> > Envoyé : jeudi 14 octobre 2004 19:50
> > À : [EMAIL PROTECTED]
> > Objet : Re: Memory leaks when lots of graphical operations? [Qt/X11
> > 3.1.1]
> >
> >
> >It's the app's memory usage that climbs or the server's?
> >
> > Mark.
> >
> > On Thu, 14 Oct 2004, [iso-8859-1] Sébastien ZINSIUS wrote:
> >
> > > Hello!
> > >
> > > I'm currently developing a graphical application with Qt/X11 3.1.1.
This application does a lot of operations and I'm doing some robustness
tests... I have a test tool that can stimulate application and implies lot
of drawing. The target on which application has to run is a mobile computer
with a x86 compatible 133MHz CPU, 64 MB RAM and 256MB compactflash.
> > >
> > > My problem is that when frequency of update becomes to high, machine
seems not to be able to treat all the graphical updates (well, it's my
feeling...) and memory use (of application) climbs rapidely (according to
this frequency).
> > >
> > > I looked into Qt source code and tried to print some X dependant
informations, e.g. with XPending, and number of events that have to be dealt
by X server, seem to be the source of the problem.
> > >
> > > I tried this test on a faster machine (P4 2GHz 512MB) and problem
occurs also, but in very very strength conditions (2 thread running with a
1msec period and producing in each cycle about 100 operations).
> > >
> > > I thought that memory would be given back after the "stress period",
but I made the same test only on a 10 second period (stopping automatically
stressing thread), and memory seems to be lost for eternity... (no memory
use decrease followed)
> > >
> > > Do you have an idea why the memory use climbs? How could I solve this
problem?
> > >
> > > Thanks in anticipation!
> > >
> > > Cheers,
> > >
> > > Sébastien
> > >
> > > ___
> > > Devel mailing list
> > > [EMAIL PROTECTED]
> > > http://XFree86.Org/mailman/listinfo/devel
> > >
> >
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
> >
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
> >
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Memory leaks when lots of graphical operations? [Qt/X11 3.1.1]
> > Is there a way to trace X operations? > >There's no tracing feature in Xlib. > xmon? Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Memory leaks when lots of graphical operations? [Qt/X11 3.1.1]
I shoulda noted that my "simple" app all depends on the malloc in use by the
OS your on
for example (on an HP11.00) ... (and I changed the app to accentuate the
point)
bash-2.04$ cat test.c
#include
int main(int argc, char** argv)
{
int a = atoi(argv[1]);
int i;
int j = 0;
void* b[a];
printf("starting loops\n");
{
for (i=0; i
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 12:30 PM
Subject: Re: Memory leaks when lots of graphical operations? [Qt/X11 3.1.1]
> Not sure how your checking memory usage either ...
>
> Consider a simple app like ...
>
> int main(int argc, char** argv)
> {
> int i;
> void* b;
> for (i=0; i<100; i++)
> {
> b = malloc(100);
> free(b);
> }
> sleep(200);
> }
>
> will show memory in use during the sleep ... but this app doesn't leak.
>
> Rob
>
> - Original Message -
> From: "Mark Vojkovich" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, October 14, 2004 10:50 AM
> Subject: Re: Memory leaks when lots of graphical operations? [Qt/X11
3.1.1]
>
>
> >It's the app's memory usage that climbs or the server's?
> >
> > Mark.
> >
> > On Thu, 14 Oct 2004, [iso-8859-1] Sébastien ZINSIUS wrote:
> >
> > > Hello!
> > >
> > > I'm currently developing a graphical application with Qt/X11 3.1.1.
This
> application does a lot of operations and I'm doing some robustness
tests...
> I have a test tool that can stimulate application and implies lot of
> drawing. The target on which application has to run is a mobile computer
> with a x86 compatible 133MHz CPU, 64 MB RAM and 256MB compactflash.
> > >
> > > My problem is that when frequency of update becomes to high, machine
> seems not to be able to treat all the graphical updates (well, it's my
> feeling...) and memory use (of application) climbs rapidely (according to
> this frequency).
> > >
> > > I looked into Qt source code and tried to print some X dependant
> informations, e.g. with XPending, and number of events that have to be
dealt
> by X server, seem to be the source of the problem.
> > >
> > > I tried this test on a faster machine (P4 2GHz 512MB) and problem
occurs
> also, but in very very strength conditions (2 thread running with a 1msec
> period and producing in each cycle about 100 operations).
> > >
> > > I thought that memory would be given back after the "stress period",
but
> I made the same test only on a 10 second period (stopping automatically
> stressing thread), and memory seems to be lost for eternity... (no memory
> use decrease followed)
> > >
> > > Do you have an idea why the memory use climbs? How could I solve this
> problem?
> > >
> > > Thanks in anticipation!
> > >
> > > Cheers,
> > >
> > > Sébastien
> > >
> > > ___
> > > Devel mailing list
> > > [EMAIL PROTECTED]
> > > http://XFree86.Org/mailman/listinfo/devel
> > >
> >
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
> >
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Memory leaks when lots of graphical operations? [Qt/X11 3.1.1]
Not sure how your checking memory usage either ...
Consider a simple app like ...
int main(int argc, char** argv)
{
int i;
void* b;
for (i=0; i<100; i++)
{
b = malloc(100);
free(b);
}
sleep(200);
}
will show memory in use during the sleep ... but this app doesn't leak.
Rob
- Original Message -
From: "Mark Vojkovich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 14, 2004 10:50 AM
Subject: Re: Memory leaks when lots of graphical operations? [Qt/X11 3.1.1]
>It's the app's memory usage that climbs or the server's?
>
> Mark.
>
> On Thu, 14 Oct 2004, [iso-8859-1] Sébastien ZINSIUS wrote:
>
> > Hello!
> >
> > I'm currently developing a graphical application with Qt/X11 3.1.1. This
application does a lot of operations and I'm doing some robustness tests...
I have a test tool that can stimulate application and implies lot of
drawing. The target on which application has to run is a mobile computer
with a x86 compatible 133MHz CPU, 64 MB RAM and 256MB compactflash.
> >
> > My problem is that when frequency of update becomes to high, machine
seems not to be able to treat all the graphical updates (well, it's my
feeling...) and memory use (of application) climbs rapidely (according to
this frequency).
> >
> > I looked into Qt source code and tried to print some X dependant
informations, e.g. with XPending, and number of events that have to be dealt
by X server, seem to be the source of the problem.
> >
> > I tried this test on a faster machine (P4 2GHz 512MB) and problem occurs
also, but in very very strength conditions (2 thread running with a 1msec
period and producing in each cycle about 100 operations).
> >
> > I thought that memory would be given back after the "stress period", but
I made the same test only on a 10 second period (stopping automatically
stressing thread), and memory seems to be lost for eternity... (no memory
use decrease followed)
> >
> > Do you have an idea why the memory use climbs? How could I solve this
problem?
> >
> > Thanks in anticipation!
> >
> > Cheers,
> >
> > Sébastien
> >
> > ___
> > Devel mailing list
> > [EMAIL PROTECTED]
> > http://XFree86.Org/mailman/listinfo/devel
> >
>
> ___
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Licensing Spirit ...
I understand there is a history of a war about the Xfree licensing. I honestly am not try to bait or troll with this post, so please give some consideration to this post ... I'm trying to figure out what the "new" xfree licensing means to *developers* (hence the post in this venue). There seem to be three types of scenarios that a "developer" might fall in to. #1 ... You are a hardware vendor wanting to provide an X11 windowing system to your boxes. You write a ddx to your hardware. #2 ... You are a software vendor wanting to provide an X11 windowing system to a platform. You write a ddx to your platform. #3 ... You are a "solutions" provider, and want to provide an X11 windowing system as a part of your solution. You redistribute an existing X11 distribution as a part of your solution. Examples would be ... Case #1 includes cray, sun, hp, etc ... they have traditionally used the xorg base and write a ddx to their hardware. The contributions back to the "community" are at their choosing. This may also include a video card manufacturer who wants to provide a "driver" for their proprietary card. Case #2 includes PC Xserver vendors (e.g. Hummingbird, WRQ, etc) ... they again use the xorg base and write a ddx to their platform. Again their contributions back are at their choosing. Case #3 includes the "free" OS providers (aka RedHat, etc) ... they distribute a built version of an Xserver and associated utilities. So, can someone lay down what the "XFree" licensing means to these three classes of "developers"? The Xorg license is pretty clear in all three cases (e.g. do what you will, don't claim you invented it). >From what I can gather, much of the Xfree code also falls under the original MIT license (unless I'm mistaken and the Xorg folks relinguished their copyright to dix, mi, cfb, etc). Of course there is also much code in Xfree that is *not* a part of the Xorg tee (i.e. the xfree ddx tree). Then there is the "programs" included in both trees (xterm, xlogo, xdpyinfo, etc). And let's not forget the contribs (e.g. opengl from sgi with it's own license). I guess all I'm looking for is a "spirit" of the latest XFree86 license regarding the various components of Xfree86 (laywers and the courts will battle over the legaility of whatever license is written). Is this an accurate "spirit" then The "Xlib" (i.e xc/lib/*) is under "MIT" license (they hold copyright, so their license). The "Programs" (i.e xc/programs/xterm?xlogo?xinit etc) is under "MIT" license (they hold copyright, so their license). The "DIX" (i.e. xc.programs/Xserver/dix?mi?cfb?mfb?...) is under "MIT" license (they hold copyright, so their license). The "XFree86 DDX family" (i.e. xc/programs/Xserver/hw/xfree86) is under the XFree86 license (whatever form the copyright holder feels free to invoke). The "Xnest DDX" (i.e. xc/programs/Xserver/hw/xnest) is under whoever wrote it's license (i dunno, duncare, but someone) The "Contribs" (i.e. xc/contrib/*) are under the license of the "contributor" ... If that is accurate then ... Developer #1 above can then use the Xfree86 code distro under an MIT license (unless they utilize the xfree86 ddx code, and then they fall under that license). Utilizing "contribs" places them under the "contribs" license as well. The above would be the same for developer #2. (i.e under the license of the ddx code you base from, and the contribs you choose to use). Developer #3 is in a murky situation to me ... but then again sort of the same. Again, I am not trying to bait or troll here, I just want an understanding of the "spirit" of the license XFree86 has gone to, and how that applies to the various components of the tree. Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Emulation of Alt+Numpad+Digits behavior
I'm going to chime in ... > > X, on the other hand, is not supposed to be defining policy. Let's > > assume your solution was implemented. What would you expect to happen > > when you do Alt-227? What symbol would it be, and in what character > > set? Is it the same with a German keyboard layout? > > I do think that this goal is achievable, because the Alt-Numpad > functionality is so limited: all it does is to generate the same symbols > without regard to any codepage, keyboard mapping etc. And that's what > makes it useful im some cases (see below). And exactly because the > functionality is not supposed to be flexible at all, I think that it > doesn't necessarily conflict with the X paradigm. > To play nice, this should only need xkb file interpretation changes (changing the way the code works may get messy). I'm not that hip on how XKB maintains "state", but for Alt-gr type combos it is at least close. > Yes, with the german (or any other) keyboard Alt-0227 generates an "ã". > But beware: Alt-227 (without the leading 0) is different. This is > because MS added the four-digit mappings in Windows in order to maintain > compatibility with the three-digit ones from DOS. > > > Can we say unconditionally that no X application currently uses > > Alt-Numpad combinations? > > > > Or maybe I'm just scaring up issues where none exist. > > I don't think that one can safely assume that no application ever uses > Alt-Numpad combinations. > My experience says you can never safely assume anything about x apps :) > However, if those applications exist, they are > probably rather rare. So why do I want the Alt-Numpad feature anyway, > you may ask. The reason is simple: some specialized devices like > keyboards with integrated readers for Smartcards or keyboard-wedge style > barcode readers transmit their data via this mechanism. And their reason > to use it, is that it offers a channel which is guaranteed to be > transparent. i.e. unencumbered by keyboard mappings etc. > ummm ... the "to be transparent" is true for windows, but obviously not for unix or mac or ... This really smells like an input method ...so your app that needs to play with "readers for Smartcards or keyboard-wedge style barcode readers" would need to support the input method. Rob ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Job available for experienced XFree86 / DRI developers
fire estinguisher ready ... please let any flames die NOW - Original Message - From: "Elliott Mitchell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 10, 2004 1:08 PM Subject: Re: Job available for experienced XFree86 / DRI developers > >From: Suresh <[EMAIL PROTECTED]> > > Would you like to outsource this project to us , > > We are located in India, > > This also means tremendous savings in cost. > > Quite a number of studies have been rather dubious about such claims... > > The ones that do support such actions tend to be based on rather dubious > data. > > > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \ (| [EMAIL PROTECTED] PGP 8881EF59 |) / > \_ \ | _ -O #include O- _ | / _/ > \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
