On Mon, 22 Sep 2003, Ian Romanick wrote:
> >The fact that there may be different best implementations
> > with various kernels only further supports that XFree86 should
> > export a xf86Yield() function which "does the right thing" on
> > that platform. For Linux <= 2.4 that appears to be sc
Around 21 o'clock on Sep 22, Ivan Pascal wrote:
> Also I added a flag for timers TimerNeedsCheckInput. The timers without this
> flag are processed before the select all others are delaied until the second
> timers check. (The second check doesn't distinguish those timers.)
I think that's overk
On Tue, 23 Sep 2003, Nathan Hand wrote:
> On Tue, 2003-09-23 at 07:55, Mark Vojkovich wrote:
> > On Tue, 23 Sep 2003, Nathan Hand wrote:
> >
> > > On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote:
> > > > Can we export to the drivers some function that yields the CPU?
> > > > Currently alot of
Nathan Hand wrote:
On Tue, 2003-09-23 at 07:55, Mark Vojkovich wrote:
On Tue, 23 Sep 2003, Nathan Hand wrote:
On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usl
Mark Vojkovich wrote:
On Mon, 22 Sep 2003, Ian Romanick wrote:
Mark Vojkovich wrote:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usleep(0) is not good for this because it's jiffy based and usually
never retur
On Tue, 2003-09-23 at 07:55, Mark Vojkovich wrote:
> On Tue, 23 Sep 2003, Nathan Hand wrote:
>
> > On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote:
> > > Can we export to the drivers some function that yields the CPU?
> > > Currently alot of drivers burn the CPU waiting for fifos, etc...
> > >
On Tue, 23 Sep 2003, Nathan Hand wrote:
> On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote:
> > Can we export to the drivers some function that yields the CPU?
> > Currently alot of drivers burn the CPU waiting for fifos, etc...
> > usleep(0) is not good for this because it's jiffy based and us
On Mon, 22 Sep 2003, Ian Romanick wrote:
> Mark Vojkovich wrote:
>
> > Can we export to the drivers some function that yields the CPU?
> > Currently alot of drivers burn the CPU waiting for fifos, etc...
> > usleep(0) is not good for this because it's jiffy based and usually
> > never returns i
I was thinking a very useful function in line with everything else Xmu
provides would be an
XmuPrintEvent(XEvent *ev, FILE *stream);
which would print information about the event to stream in the same
format as xev. I was able to liberate the code for the core protocols
from xev and the code to
On Tue, 2003-09-23 at 05:58, Mark Vojkovich wrote:
> Can we export to the drivers some function that yields the CPU?
> Currently alot of drivers burn the CPU waiting for fifos, etc...
> usleep(0) is not good for this because it's jiffy based and usually
> never returns in less than 10 msec which
Ian Romanick wrote (in a message from Monday 22)
> Mark Vojkovich wrote:
>
> > Can we export to the drivers some function that yields the CPU?
> > Currently alot of drivers burn the CPU waiting for fifos, etc...
> > usleep(0) is not good for this because it's jiffy based and usually
> > ne
Mark Vojkovich wrote:
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usleep(0) is not good for this because it's jiffy based and usually
never returns in less than 10 msec which has the effect of making
interactivi
On Mon, Sep 22, 2003 at 09:27:53PM +0700, Ivan Pascal wrote:
>
>I made new version of the patch.
>The issue Keith pointed is fixed.
>
>Also I added a flag for timers TimerNeedsCheckInput. The timers without this
>flag are processed before the select all others are delaied until the second
>timers
David Dawes wrote:
> In five minutes I can come up with a dumb script that extracts the same
> information from imake. Proof of concept attached. Works for Xv,
> Xxf86misc, etc.
Now dump the info into a .pc file so that it can be used with pkg-config.
The point was not the method of my patch (I
On Mon, Sep 22, 2003 at 10:03:58AM -0400, Owen Taylor wrote:
>On Sun, 2003-09-21 at 22:38, David Dawes wrote:
>> On Sun, Sep 21, 2003 at 09:06:43PM -0500, Warren Turkal wrote:
>> >David Dawes wrote:
>> >> I think you have your perspective backwards. Autotools is supposed to
>> >> handle system dif
Can we export to the drivers some function that yields the CPU?
Currently alot of drivers burn the CPU waiting for fifos, etc...
usleep(0) is not good for this because it's jiffy based and usually
never returns in less than 10 msec which has the effect of making
interactivity worse instead of bet
Keith Packard writes:
> Around 21 o'clock on Sep 21, Egbert Eich wrote:
>
> > That was my suggestion. But I'm afraid xkb doesn't work like that.
> > Not xkb checks for pending input the ddx layer does in a wakeup
> > handler that does so and passes information on to xkb.
> > The timeout ha
is there some x3.3.6 to x4.x.x porting guide around?
-Alex.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Hi,
I recently bought an old laptop with a Compaq AVGA video chipset, and I did not find
any support for it under xfree86-4.3.0, but there is an AVGA driver for xfree86-3.3.6.
I am thinking about porting it to 4.x. Is there any work already underway with the
AVGA driver for 4.x or do I need to
On Mon, 22 Sep 2003, Mike A. Harris wrote:
> We move the XFree86 supplied .pc files into /usr/lib/pkgconfig/
> where the default pkgconfig configuration can find them. A
> better fix would be either making XFree86 install them into
> /usr/lib/pkg-config by default, or making the default
> con
I made new version of the patch.
The issue Keith pointed is fixed.
Also I added a flag for timers TimerNeedsCheckInput. The timers without this
flag are processed before the select all others are delaied until the second
timers check. (The second check doesn't distinguish those timers.)
Also I
> Around 20 o'clock on Sep 20, Ivan Pascal wrote:
>
> > The solution is obvious. WaitForSomething should not run any callbacks before
> > the Select but just check timers and if there are expired timers call select
> > with a zero timeout.
>
> One more issue I thought of this morning -- the patc
On Sun, 2003-09-21 at 22:38, David Dawes wrote:
> On Sun, Sep 21, 2003 at 09:06:43PM -0500, Warren Turkal wrote:
> >David Dawes wrote:
> >> I think you have your perspective backwards. Autotools is supposed to
> >> handle system differences for the software package, not impose
> >> requirements
>
Hello,
Egbert Eich wrote:
> > One use for timeouts is to handle external network events, such as font
> > server reconnect or XDMCP messages. In those cases, the timeout routine
> > can modify which sockets will be needed in the select mask, hence the
> > desire for the timeout routine t
wjd wrote:
> I want to build a program which is related with X release number(3.x or 4.x),
That would be the XFree86 version. The X version is of the form X11R6.6.
(I don't think either is easily available in a header file though, but
they are available in Imakefiles via definitions in the
On Fri, 19 Sep 2003, David Dawes wrote:
>>> That some libs have pkg-config support shouldn't be seen as indicative
>>> of anything in particular. All of them are distributed separately
>>> by their primary author, which isn't true of the other libs in the
>>> XFree86 source tree. It's likely tha
I can not find a function that brings a windows from another application in the
foreground ( i already have the window struct of that window). I tried using
RaiseWindow , ResizeWindow, ConfigureWindow with no results. Any ideas?
Thanks
___
Hi All,
I want to build a program which is related with X release number(3.x or
4.x),do any head file define X release number on linux os(i uses redhat)?
Thanks
wjd
[EMAIL PROTECTED]
2003-09-22
__
28 matches
Mail list logo
