Re: Audio in X11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 11 Sep 2003 05:39 am, Warren Turkal wrote: Fred Heitkamp wrote: I was wondering. Was there ever an effort to make a network independent audio extension for X11? (forgive my terminology if it's wrong.) For example, if I am logged on from a remote terminal and want to play an MP3 from the distant machine on the remote terminal, is this possible? Sorry if this is a FAQ, but I didn't see one while googling. Arts is supposedly network transparent. OK: MAS, Arts, Jack, Enlightenment Sound Daemon. Is there a master architecture for how this fits together? How do we get to a universal solution? What's missing and what'd duplicated? Brad -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/bVJjW6pHgIdAuOMRAt6KAJ0WMBY9TqZEGKn8z7ZP+oLevMLCcgCghR9l yrHOV9/k5VTbuhelGZhhluc= =Aou7 -END PGP SIGNATURE- ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: C version of ucs2any.pl
David Dawes writes: BTW, how are things like host vs target imake binaries handled when cross-compiling? Currently in most cases the installed versions are used. Only imake is compiled as HostProgramTarget(). I don't recall if a target version is ever built and installed. This should definitely be tested and fixed. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 developer
i want to be a XFree86 developer bu how -- __ http://www.india.com Now with POP3/SMTP access for only US$14.95/yr Powered by Outblaze ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 developer
Chaitanya Chaitanya wrote (in a message from Sunday 21) i want to be a XFree86 developer But how ? You should start by checking the mailing list archives... This question was asked exactly one week ago. Egbert Eich answered: Please check out this: http://www.xfree86.org/developer.html You can also find some info at http://xfree86.linuxwiki.org where I've started adding some development pages. And here was my answer: There are many ways to participate, depending on your level of knowledge about X in general, the XFree86 server and other related topics. You can contribute by developing code, testing existing code and providing feedback, by writing documentation, and probably other means that I don't have in mind right now. As a starting point, if you don't already have a precise idea of the area on which you'd like to help, you can browse the bugzilla database (http://bugs.xfree86.org/) and look for problems not yet solved for which you may be able to submit a solution. There have also been wish lists of new features posted (among other) to the [EMAIL PROTECTED] list; check the archives. The [EMAIL PROTECTED] list is aimed to be link between developpers (in the wide sense of the term, including documentation). If you have code to submit, use the bugzilla to submit it. The team of developpers with commit access will look at it and commit it into the XFree86 repository if it's worth. Documentation enhancements are very welcome too and can be submitted through bugzilla too. Commit access is proposed after some time to people who are regularly submitting code that gets included and/or who are working on an area of the XFree86 code not already well covered by existing commiters. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
Keith Packard writes: 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. Also the code before the select checks screensaver and DPMS timeouts. 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 to execute before the select (and various BlockHandler) routines are invoked. When the timeout routine fires only after select returns, the server will go through a complete scheduling interval before the BlockHandler is invoked. So what would be the way out? I suppose one could use a wakeup handler instead. This however would only work if the wakeup handler for keyboard input was called before the xkb timer handler. The latencies of other handlers that are called before the xkb handler could also cause the timer to expire with the key release unnoticed. The only way to ensure that a possible release event is detected is to read the keyboard in the xkb callback handler to check for pending release events. However I'm afraid xkb simply doesn't work that way. Another solution may be a a SIGIO driven keyboard input. Also the code before the select checks screensaver and DPMS timeouts. I don't see reason why those timeouts are processed separately from timers and don't use timers facility. ScreenSavers used to be the only timeout and were coded before the general timeout mechanism was added; DPMS was kludged in on top of that mechanism. When the general timeout mechanism was added, the screen saver/DPMS code should have been migrated over. Yes, Ivan's patch fixed that. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
David, David Dawes wrote: On Sun, Sep 21, 2003 at 12:13:10AM -0400, Harold L Hunt II wrote: The only suggestion I have is that the function prototypes in include/os.h should follow the conventions of all other prototypes in os.h, using #if NeedFunctionPrototypes: extern void SetScreenSaverTimer( #if NeedFunctionPrototypes void #endif ); #ifdef DPMSExtension extern void SetDPMSTimers( #if NeedFunctionPrototypes void #endif ); #endif Actually, we're going the other way and on the trunk all of the NeedFunctionPrototypes references have been removed in os.h. I missed that. Sorry for the noise. Thanks for taking the time to debug this properly... I hope that there Yes! Hopefully the screen saver/DPMS cleanup will reduce the likelihood of further subtle bugs that have plagued that code for a while. Cleanup is good. Harold ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Wrong order of a timeouts processing in WaitForSomething.
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 handling would have to be moved from xkb to ddx. The XKB code could call ProcessInputEvents just above the check for a pending repeat key; that would ensure that any input queued either in the X server or the kernel would get processed before repeat status was checked. I agree, but I don't think there is a restriction on the amount of processing done before the events are queued. Therefore events could be processed far enough to know if a pending timer for a repeat should be canelled. But then this would require more extensive changes in xkb. The server really can't process events even this far -- detecting which keysyms are associated with each key requires accessing keymap tables which may be manipulated by clients outside of the signal handler. It's far easier to restrict SIGIO processing to event queuing -- that requires no global server state aside from the event queue itself. I think that's what Ivan's patch does: The only place where timers are called is after the select and the WakeupHandlers. The timers are invoked just before the test for queued input; moving the queued input test above that should eliminate cases where key events are queued with SIGIO and then not processed before the timer function is invoked. In any case, the current spot isn't sufficient as the timers will never be executed if the server is constantly receiving application input, so at least that needs to be fixed. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
elsa gloria synergy specs
I'm interested in getting the tv-out on a Elsa Gloria Synergy to work. In various places I see mention that the glint server and/or its predecessor 3Dlabs server got help in the form of good documentation from Elsa. So I'm wondering, where can I find that documentation, or where can I find the people who worked on this server, who might be able to help me track it down. Thanks, Dave Cottingham ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
