Slashdot Mirror
First Xouvert Milestone Released
An anonymous reader writes "
The first milestone of xouvert, the X-server replacement has been released. Xouvert includes MAS giving the X server its very own sound server. Nice. :) Also, just noticed that enlightenment quietly released an update to the 0.16 series.
" (Here's a link to the Xouvert download page.)
For the non-french speaking under you: Xouvert means "X open".
This is an X server, not YAWM.
Uhm, there are actually not that many X servers. It's not like windowmanagers or anything like that. Besides , the goal of Xouvert is to get their changes back to XFree
Well to quote:
<quote>
Eugenia (IP: ---.osnews.com) - Posted on 2003-12-09 01:21:59
Xouvert: XFree86 fork with some code cleanups and addition of patches that the xfree86 guys were snobbing.
freedesktop.org's X: Re-write of the core of their server (not a fork), rewrite of some of the extenstions, while reusing some xfree86 code mostly for some other extensions and drivers, but overall a new thing.
Xouvert would be interesting to serve as the "middle man" towards the migration to fdo's X.
</quote>
So yes you'r right. I read on freedesktop.orgs site, or maybe it wasnt, and maybe it was old, but the server only needed less than 800k To run or it was of that size. Their server so far requires a compile for you to configure it as there are no configuration files. That alone i feel would cut out some bloat. The freedesktop.org promises a lot more i believe where as this one we're talking about just imporves on the current X server. But, any improvments are welcome ones.
Thanx for the text Eugenia
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
I know you're trolling, I just find your post humerous. You know that the people running Xouvert are kind-of "GTK fanboys" (sic), right? Check the projects some of them have worked (and still work) on. The only way to make sure one can use the GUI toolkit one wants to is to leave it out of the X server (not that there's an easy way to integrate it yet and not that there would be much of an advantage in doing so). Realize that encouraging a server to merge a GUI toolkit could always backfire.
At least GTK is planning to switch to it, I guess QT as well.
Already in progress at Freedesktop.org, thanks to the awesome Keith Packard. There's Cairo for vector graphics rendering and some unnamed project for double buffered/transparent/warpable windows (and yes there are screenshots, click the link!). Freedesktop.org is rapidly becoming host to many projects that are innovating in the Linux desktop arena. Check out some of the other software hosted there. Of particular interest (to me at least) is D-BUS combined with HAL.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
As said before this guy appears *not* to be a Dev on the Xouvert project.
Have a read through some of his previous posts on other topics.
Thanks.
Ripping an new rectum in the fabric of spacetime.
I've seen MAS demoed on a couple of shows already and I did like what I saw. They are aiming for professional quality sound delivery with extremly low latencies which definitly is a good thing. MAS of course is network transparent of course, but the network is just another input-/output device to MAS (like a soundcard), you don't have to use it for local playback. It is a handy feature though: You can pipe your sound to an effects mashine for processing, something that might come in handy in a professional environment.
Regards, Tobias
Oh dear. It can change resolutions on the fly; it's called the XRandR extension and has been in XFree86 for a while now.
Secondly, users don't need to know their refresh rates. Almost all major distros include an X setup tool, and even "X -configure" does a decent job.
Try to get out more, instead of repeating lies on Slashdot. It's not healthy.
Check your facts before blurting out. QT is available under the Gnu Public Licence!
e .h tml
http://www.trolltech.com/products/qt/freelicens
I think the following should settle your fears.
//end direct quote from site.
From their site
"Many of the visually impaired have finely tuned auditory sensibilities, allowing them to react quickly to sound. From its beginning, MAS was designed to handle timing issues exceedingly well. It was optimized to provide tight synchronization of multiple media streams. More importantly, for users dependent on audio cues, it is designed to stop some functions and start others quickly. For example, a user, hearing the opening syllables of a menu option, can either select it or move to another option without waiting for a complete articulation of the option. MAS's original accessibility requirements, developed with leading accessibility authorities, included:
* Ability to stop utterances quickly
* Controllable low latency
* Format independent media handling
* High audio quality
* Multiplexing--with priorities
* Small memory footprint
* Synchronization of multiple media stream
"MAS enables low-latency Internet conferencing and telephony. Automatic bandwidth measurements and MAS's dynamically-switchable CODECs insure that the conference quality scales from 56K modems to T1 lines".
"MAS integrates with a compatible X11 server on your desktop. It processes graphic information locally, alleviating the need for network transmission of uncompressed graphical content. Graphic events are easily synchronized with audio events for professional-quality multimedia and accessibility-enabled applications."
"MAS handles network-distributed media processing and intricate format configuration tasks. It continually measures system performance and adjusts its actions depending on the available system resources. The longer it runs, the better it knows your system".
Obviously this has been designed for performance/scalability.Of course the real trial is actually running it for yourself but give it a chance before you write it off.
You know, you are right. And it's by design. And it's well known. I remember several years ago CmdrTaco posting an article to discuss just that particular topic. IIRC, if you put in a comment as an AC, then you can't moderate comments attached to that article you posted against, just as if you had posted from your normal account.
/does/ get logged, you know). There is rarely any true anonymity in this world. It's not a bad thing, unless you are doing something wrong...
It's all well known about, and well documented. The idea of the AC account is that nobody knows who you are, but admin can always find out things anyway (stuff
you're either trolling to start the old religious wars which are hardly necessary; or you haven't used X in about the last 5 years or so.
my experiance lately has been that X id's cards and monitors better the firstime than windows does. [Cntrl]+[alt]+[+} or [cntrl]+[alt]+[-] changes screen resolution on the fly just find on any X you happen to run; in fact when windoser see me do this in Linux, they get envious
Apocalypse Cancelled, Sorry, No Ticket Refunds
I believe your right, It works *abobe* ALSA. ALSA will do the hardware bits while the MAS will back into it, or if your XWindow is running on OSX, back into the Darwin equivelent, or Windows, back into ActiveDirectX.NET(?)
Im not certain, can someone verify?
Well, you could have read the Xouvert FAQ before posting to educate yourself on what they actually plan on improving. That way, you wound't sound like you have no idea what you are talking about. Anyway, from the FAQ:
2.5) So why is X so slow on my machine if not for network transparency?
Yes, XFree86 /can/ be slow, especially on uniprocessor machines, but network transparency is NOT at fault. More common culprits appear to be toolkits, video drivers, and font rendering/render. Render really needs to DMA driven. Right now it pulls bits from the framebuffer using the CPU which with PCI is abysmally slow.
Sir, may I suggest you RTFA? Xouvert is a fork of XFree86. The current release is basically exactly the same as the current release of XFree86, but with a handful of extras. Since they are the same thing with different names, I suspect they may just be compatible.
"Changing resolution on the fly springs to mind as one thing it cant do"
Thats strange , because I've been able to do ctrl-alt-+ and ctrl-alt-minus to change the resolution ever since linux 1.2 days...
informative, sure. but... you fail to mention that this feature requires support of the window _managers_ to be able to use this feature. to use this in kde you're gonna need 3.2 which is still in beta. i'm not quite as familiar with other window managers, but last i looked into this, there weren't ANY that let you resize your desktop on the fly similiar to right clicking on the desktop, thenchoosing "resolutions", then selecting something different than the one you're using, and giving you and option to try out the new one.
IIRC, xrandr has been in xfree since the 4.3 series, which i suppose you could consider "a while now". this version of the server which was released 27 Feb of 2003. are the wm's slow to implement this feature? this is a feature Microsoft has had for 8 years now.
while XFree86 _is_ nice, it seems very cumbersome to change. there's probably a small list of feature requests from the user community out there, and they're not getting implemented.
when you tell the truth, be sure to give the whole story.
and with xrandr it now does it when a program asks for it (like say a game) and the novice/newbie can do it tru a menu. oh and does your desktop (gnome/kde) detect the change when you use the keyboard combos or does it just keep the old size and let you slide about by pushing the mouse against the edges? again xrandr will tell any enabled program that changes have been made so it can fit better...
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
That's chaning the sixe of the screen, not the desktop. It's a big differeence.
TODO: Something witty here...
The visual stuff is there for (eg.) = 8 bit displays where apps really do need to have exact control over colormaps. No longer useful on the desktop, but very handy for embeded or PDA developers.
I've seen this post so many times about how much X or XFree sucks. Please enlighten me because I seem to be living in an alternate dimension. Right now at my house, I have a large dual-Athlon basement machine running headless. My main X term upstairs is a $40 used PII with a good graphics card and no hard drive. I cannot perceive a performance difference between this machine with applications, scrolling, switching desktops, etc, with the 2GHz P4 running WinXP at work. I can play fullscreen NTSC quality videos over the network. Everything but page-flipping games run flawlessly, and I'm sure cheap gigabit would solve even that problem.
In the living room I have a 1GHz Athlon game box that runs all sorts of games and emus at 60 frames per second fullscreen with no problem.
My wife runs a PII system with a good Matrox card and other than slow load times for some apps, the graphics performance (scrolling, menuing, maximizing, etc) is superb.
Where is the horrible performance? Windows is supposed to be so much better, but I have yet to see a window that didn't shear when "Show Contents when moving/resizing" was turned on. That's why I turn it off and use the outline. And, by the way, no matter how fast your graphics updates are, you will always get shearing on a CRT, unless you blast your updates while the electron gun is returning to the top corner. I imagine that would add a great deal of complexity to the windowing system, which is probably why it hasn't been done on either platform, just so a tiny part of daily work will "look better".
I just wonder what I've been doing right with these systems (all running XFree), especially since I'm pretty picky about graphics performance.
Up until about 3 years ago I was using TWM. Then I switched over to Blackbox. It's light and fast, with very little eye-candy. A great, fast, and no frills WM in less than 300KB (263KB Solaris/SPARC, 288KB Solaris/i386).
Maybe I'm just not with the times. Besides my Mac, the two machines I have are a P3 600 w/ a Rage 128 Ultra w/ a paltry 16MB VRAM running Slack 9.1 and a P2 400 w/ a Mach64 w/ a whopping 4MB VRAM running NeXTStep 3.3. Neither of which would be suitable for the next generation desktop.
To each his (or her) own, I suppose. I'll stick with the plain and simple.
I'm pleasantly surprised to see that Xouvert is using the Arch revision control system.
Does anyone know if you have to create individual UNIX user accounts for Arch users as you do with CVS? I've always hated that about CVS.
Right, I've got an Agenda also, but that's not what the parent poster is talking about.
What he's saying is that the source code distribution for XFree86 is way too big. Rather than separate the libraries, X server, applications, and everything else into separate tarballs, they release the entire source tree at once.
Freedesktop is working on splitting the X server out as its own separate release.
Actually, this is isn't correct -- having spent too many years programming video games in the 80s-90s, I'll have a shot at explaining...
You fix the problem of onscreen redraw glitches simply by using double (or triple) buffering - all updates are then drawn to an off-screen back-buffer instead of to the visible surface, and once the back-buffer update is complete you wait until the next vsync (when the CRT is in an offscreen period) and 'flip' the visible surface out, bringing the newly drawn one into view.
Double buffering is simpler to code than triple buffering, but any system implementing either of these will still have a pretty simple API to call, and both will be similar (if not identical if you plan correctly) -- the tricky stuff all happens 'behind the scenes', usually implemented with a combination of interrupts, threads and code to handle 'surface locking'.
The 'cost' of using double buffering is: you need video memory for both a primary and a secondary surface, you have to write a small piece of (fairly technical) code -- and when you call flipSurfaces() no code can access a visible surface to draw upon until the 'flip' has actually taken place (the next VBlank interrupt), which will likely mean waiting code... tidy screen redraws, but stalling code. :(
If you have enough video memory, you can get around this 'waiting' problem by using triple buffering. It's a bit trickier to implement, and requires three times more memory than an unbuffered display - but you avoid the problem of having a locked back buffer (waiting to become the primary surface) by having the extra (and therefore always 'unlocked') surface ready to return when any code calls getBackBuffer().
When flipping screens (during the CRT gun's offscreen period), the new buffer can be made visible by either copying it to the front buffer (maybe using blt h/w, if available), or by changing some kind of magic memory pointer in the video hardware.
So stopping tearing can in fact be done fairly easily -- a heck of a lot of video games use a double or triple buffering, and have done since at least the early eighties. I don't think any of the PC Windowed-style OSes use this technique yet (...but I don't have a Mac, and with all that transparency and other eye candy I sure hope that they're drawing to an offscreen surface!)
(Sorry for the almost off topic ramble, but I had to satisfy my innermost geek)
That's what's bad about OpenSource. Everyone wants to do the 'kewl' stuff an no one wants to do the grind that many of these projects need. I'm sorry but a hell of a lot of Open Source software just isn't carried out professionally. Yes you can leap in and add all sorts of cool and froody stuff but the boring bits like quality control, documentation etc gets left behind. Where are the code reviews, test suites and the like? It still has the feeling of bedroom hacker development. If I ran my development team like some of these projects are run I would be severely slapped!
I think you should take a look at some of these projects a little more seriously. I'm somewhat involved with the venerable Audacity project, and there isn't any of this "bedroom hacker development" there. Sure, we're all doing it in our free time. But the code does get regular reviews, there is a focus on squashing bugs and making the software more reliable, and each version isn't just a collection of "kewl" features. It's always better software, all the way around. Eric Raymond even cited Audacity as a leader in Open Source UI design.
My experience with audacity is actually representative of my experience with every Free Software project I've gotten involved with. Granted, I've backed out of some for various reasons because it was obvious the projects didn't suit me, but that doesn't mean I haven't seen anything but professionalism. If anything, I've seen more professionalism among Free Software developers than I ever saw in the proprietary software world!
I have a Linux PDA. I'm still using the software it came with despite trying open source alternatives every couple of months or so. Why? Because some functionality is missing because it's not kewl. The documentation is crap. It's as buggy as hell At least with the comercial variant time was taken to clean it up. Yes it may be technologically behind but it's reliable.
Considering how new the PDA market is, and the barrier to entry for developing on PDAs, it's not surprising that PDA software is lagging right now. If you're such a hot programmer, and if you're so interested in making it better, why don't you put your money where your mouth is? Get in there and start coding yourself! Or better yet, take the crap documentation and provide some good documentation. Take the lead, if you're so interested in seeing it taken, and implement that "not-kewl functionality". Fix the bugs. Show everyone what you thing should be happening.
I suspect that the journey would be far more informational than the destination.
Like what I said? You might like my music
Actually you have the terminology backwards.
The ctrl+/- changes the video resolution (the monitor gets a different number of pixels). It does not change the virtual screen (the area that programs think is visible).
Making a way to change the virtual screen, not the video resolution, is what is wanted, and is currently missing.
I am rather annoyed that RandR is so complex. Why couldn't they just send a ConfigureNotify event to the root window? I would think most window managers could be easily rewritten to use that, instead of inventing a whole new protocol. In addition it would be nice if attempts to resize the root window caused the X server to pick the nearest resolution and switch to that. See, it can all be done without adding to the interface!.