Slashdot Mirror

If you don't know what Linux is about, then you are WEABOO about how you missed the boat and are blaming a transparent minute kernel as compared with all the non-Linux software that makes it what it is.

Linux is nothing more than thread, and all the programs are nothing more than fabric. If you have no ability as a system administrator to bring it all together tailored to another's or your needs then you simply are in the wrong business and can't see past the diagrams to tailor it all together.

GNU/Linux doesn't need to be, as all my uses have been pushing the limits of embedded consoles for public uses. There are many non-distributable components that are superior than what you get out of the box for desktops. Consider documented off-standards that optimize for better usage, like something composed through a component from DirectFB with WINE. That wasn't too hard. What else do you want to be optimized with almost no need for administration? With a couple mount-points, that simple sandbox can extend to a full-fledged desktop or development console simply because of the versatility of the filesystem.

Don't let it bother you. I've abandoned Linux before because I didn't know what it was good for, and then when I couldn't do something where I needed I walked back to Linux thankfully. Of'course, I made some donations because after-all Linux is composed by others like you and I that just need something to be done and can trade someone else with functionality into a cost-free pool. Keep the corporations out and we are fine. The more moochers we get into GNU/Linux will assure it's development trend will continue and popularity will rise. BSD's shoot theirselves in the foot is why they don't catch-on.

Look for a distribution of Linux in a small form factor and based on DirectFB.

Take a look into SaWMan ( http://directfb.org/index.php?path=Platform%2FSaWMan ) to see if it will work for you.

There's so much Open Source application footprint that re-implements simulated system calls in application space if it's ever displaced from system.

It all works, and lets you move to other consoles by taking the Display environment of the host system to Xmove it to where you want to work from.

Or they could use DirectFB instead of X.org or any other X11 server : http://www.directfb.org/.

What's so wrong with using X11 anyway ?

Google has recently been active in directfb.

http://directfb.org/index.php?path=Projects%2F%2B%2BDFB

++DFB

++DFB is an advanced version of DFB++

It's an incompatible fork with fundamental changes.

Applications no longer deal with interface pointers. The classes wrapping around interfaces are used a container for an interface pointer, providing garbage collection the "direct" way 8-)

Good grief.

Google has recently been active in directfb.

http://directfb.org/index.php?path=Projects%2F%2B%2BDFB

++DFB

++DFB is an advanced version of DFB++

It's an incompatible fork with fundamental changes.

Applications no longer deal with interface pointers. The classes wrapping around interfaces are used a container for an interface pointer, providing garbage collection the "direct" way 8-)

Good grief.

Google has recently been active in directfb.

It is much more effective to have Linux on a bios, and allow it directly throttle system settings on demand. Back when hardware IO was on a proprietary bridge, eventually an assembly procedure module will be universal to any operating system for the kernel to interact its procedures. Instant bootup in Linux or even *gasp* Microsoft Windows would be similar to how Apple has closely integreated their software to BIOS. Instant-On will be just that. In terms of Linux, memtest86 or whatever it's called, would make a fair footprint rather than the default sissy hardware check that is performed; imagine a hardware check done in Linux to test the reliability of hardware while it is actively running! Imagine firmware upgrades that take effect while still running the OS, and with compatibility backdoors to prevent hardware hangups so they could be reset into a compatibility mode to try again for full function non-default!

As for me, I wouldn't mind seeing Linux kernel integrated with a complete DirectFB with minimal X Server, all on BIOS in immediate power-on mode.

People may wish to have a look at DirectFB: directfb.org

xorg.conf needs to go away

I personally find xorg.conf easier to configure. However, it is being replaced by HAL.

Frankly, I don't need to be able to connect remotely to my xorg server, and most people don't need to either

So you want to remove the server from the server? I wonder how much code you would lose by telling X to ignore the network. Personally, I use this functionality all the time. However, if you only have a single computer that you never need to access remotely, at least at the GUI level, I can see the desire to remove the feature.

Xorg should auto-failback to a VGA/VESA mode like Windows.

I found this approach interesting: http://archives.seul.org/or/cvs/Sep-2007/msg00180.html If X fails on the first server layout, have it fall back to the second.

Xorg needs to step into the 21st century when it comes to multi-monitors and multi-GPUs

I admit that I haven't used X in a multi-GPU setup. However, xrandr seems to work fine with multiple monitors. I use KDE's KRandRTray all the time with dual-monitor setups, projectors, and televisions.

A real basic X windowing environment would benefit most users

Have you considered KDrive or XDirectFB?

The whole argument for FOSS 3D video card drivers is just silly in my opinion.

It makes excellent sense if your whole world is not limited to X.org. There are lots of other platforms that can benefit from Open drivers.

I had the same networking issue (with andLinux, another coLinux "distro") and am not sure I will be able to fix it given the level of paranoia of my company's IT department.

I wonder if one way of fixing this issue would be to use DirectFB instead of Xming (an X server)...

I would really like to have a graphics system that is simple enough that I (with only a 4-year degree in computer science) can understand, and which we're using because it's the best design we can come up with, not because it's the only free windowing system we could find in 1984.

DirectFB?

For the EPIA-MII VIA supply a "fastboot" BIOS, there are seperate BIOS images depending on what device you want to boot off. Using their BIOS along with a compact flash->IDE adapter and a little kernel optimisation you can have a command prompt in around 4 seconds from power on. My aim was to have the system in a gui (using DirectFB) in under 10 seconds but at present I'm looking at around 6-7.

The system was using grub, a custom built kernel and Busybox.

- The X Windows foundation
- The lack of a diverse array of superfriendly, fast end-user applications and games that you can buy for Linux off-the-shelf at OfficeMax, Staples and OfficeDepot
- The X Windows foundation
- The lack of more closely integrated OpenGL with both the window manager and the graphics card driver
- The X Windows foundation


And, oh, did I mention "The X Windows foundation?"

Face it, in order for Linux to become the next Desktop "phenomenon," it can't do just as well as Microsoft XP/Vista, it must be notably BETTER. However, it will never be as long as it is tied to X. X is great when you want graphics over a network, but it will always be mediocre used for a desktop. A successful Linux desktop must be next generation, not last generation.

You want success in the Linux Desktop? Save X for the "Remote Desktop" features when you want to login over a network, and get behind building a high-performance bleeding edge desktop built on something more like DirectFB. A successful Linux Desktop GUI has to really push the envelope, and it just ain't doin' that right now.

Sure, X can be enhanced with "work around" features to bypass TCP/IP when the client and server are both in the same box, but not without performance cost compared to something like an XBox or a Playstation II, which is the kind of GUI performance you need to at least appear to be "next generation" in comparison with XP/Vista...

I actually spent a couple of years using Linux as my primary desktop at home but I don't anymore, as I ended up dual booting into W2K and then ended up spending all of my time in W2K running the apps and even developing some OpenGL programs, because the performance was so much better. As much as I hate Microsoft, even W2K beats out KDE and Gnome on the two factors that are the most important-- graphic application availability, and performance. You can't get the former instantly, that's sure, but you can't get it AT ALL unless you've got the latter...

Oh, and BTW-- I have been using Vista lately, IMHO it really IS just a warmed over XP. They added UAC (privilege tokens), added a few other security elements here and there, changed the interface graphics a bit, and moved things around and reorganized the menus so it looks different (such as moving search to inside start menu), but otherwise it seems just about the same. The new IE interface seems worse, and the new Windows Explorer interface is horrible.

As soon as Linux looks as shiny as MacOSX, this will change. Yet the question is, can Linux eventually reach this point. For that Linux (better said the Linux desktop) first has to solve the "top inhibitors of the Linux desktop adoption" (see http://www.osdl.org/dtl/DTL_Survey_Report_Nov2005. pdf). Any GUI software has to use DirectFB/Cairo (see http://www.directfb.org/) as it graphic engine so it looks as shiny. And applications have to follow the wyoGuide guidelines (see http://wyoguide.sf.net/) so they have an equal usable look&feel. If these requirements are fulfilled Linux will completely replace MacOSX.

O. Wyss

You should have a look at the current version of GNOME, which uses even less memory than the development versions of KDE (soon to be KDE4). Also, the latest version of GTK+ includes the DirectFB port, which allows GTK+ applications to run without X11.

All you have to do is get a full-featured window manager and graphics/GUI API going using something really fast (which means something that DOESN'T use streams-hamstrung protocols like X11 does, such as DirectFB) to handle the graphics, and KDE and Gnome will start gathering the dust they so richly deserve.

If Google were to do this, the Linux desktop would most definately be in business.

If you have an Intel gfx chip a framebuffer driver does exist:

http://mail.directfb.org/pipermail/directfb-dev/20 05-July/000457.html

It's much easier to write a microkernel since you simply offload all the needed code to build for a complete system and possibly just forget to implement all the offloaded code. Who is using a shell only system these days even just for operating system classes? It's too easy to implement a microkernel without a GUI possiblity. It leave the taste of "not being able" to implement a GUI. At least as long as there isn't a GUI driver, there is _no_ prove!

I'd really like to see a microkernel with a framebuffer driver, something like DirectFB http://www.directfb.org/.

Does Minix have a framebuffer like Linux? Then it would be possible to implement DirectFB http://www.directfb.org/ on top of it. This would give me more reason to renew my wyoDesktop http://wyodesktop.sf.net/ project.

(posting from a proxy because my Slashdot posting record incurred lurker moderation from some hateful users.)

DirectFB is a good offer compared to all others. Linux graphics is not a bloody mess; there is a large choice of graphics rendering targets and each one has its quirks.

DirectFB is an example of how ease and simplicity to build software for a use should be. If you want a graphics target specifically refined for Linux, then consider DirectFB. On that project page, there are similar hosted projects that bring it all together for a complete alternative and replacement for other X servers and bindings for tool-kits of greater popularity, as well as retaining compatibility. The graphics hardware support on DirectFB is limited to companies willing to document the hardware; thus, Matrox, 3Dfx, and ATI, Trident, some nVidia, and a couple others have optimized accelerated framebuffer support. Then to top it off, there is a related project that binds DRI accelerated openGL into the framebuffer without a X server, DirectFBGL (currently available only for Matrox hardware, but soon for ATI). Then aside from accelerated openGL of DRI in an accelerated framebuffer, there is a rootless X server package called XDirectFB.

It's GPL, it was at FOSDEM, and it is specific for Linux. Anyone willing to bite on this software will avoid the large, complex, picky, software projects and the competitors known to be successors, and protests of existant alternatives thatslowly become worse than the cause of the move; allthewhile retaining compatibility.

(posting from a proxy because my Slashdot posting record incurred lurker moderation from some hateful users.)

DirectFB is a good offer compared to all others. Linux graphics is not a bloody mess; there is a large choice of graphics rendering targets and each one has its quirks.

DirectFB is an example of how ease and simplicity to build software for a use should be. If you want a graphics target specifically refined for Linux, then consider DirectFB. On that project page, there are similar hosted projects that bring it all together for a complete alternative and replacement for other X servers and bindings for tool-kits of greater popularity, as well as retaining compatibility. The graphics hardware support on DirectFB is limited to companies willing to document the hardware; thus, Matrox, 3Dfx, and ATI, Trident, some nVidia, and a couple others have optimized accelerated framebuffer support. Then to top it off, there is a related project that binds DRI accelerated openGL into the framebuffer without a X server, DirectFBGL (currently available only for Matrox hardware, but soon for ATI). Then aside from accelerated openGL of DRI in an accelerated framebuffer, there is a rootless X server package called XDirectFB.

It's GPL, it was at FOSDEM, and it is specific for Linux. Anyone willing to bite on this software will avoid the large, complex, picky, software projects and the competitors known to be successors, and protests of existant alternatives thatslowly become worse than the cause of the move; allthewhile retaining compatibility.

(posting from a proxy because my Slashdot posting record incurred lurker moderation from some hateful users.)

DirectFB is a good offer compared to all others. Linux graphics is not a bloody mess; there is a large choice of graphics rendering targets and each one has its quirks.

DirectFB is an example of how ease and simplicity to build software for a use should be. If you want a graphics target specifically refined for Linux, then consider DirectFB. On that project page, there are similar hosted projects that bring it all together for a complete alternative and replacement for other X servers and bindings for tool-kits of greater popularity, as well as retaining compatibility. The graphics hardware support on DirectFB is limited to companies willing to document the hardware; thus, Matrox, 3Dfx, and ATI, Trident, some nVidia, and a couple others have optimized accelerated framebuffer support. Then to top it off, there is a related project that binds DRI accelerated openGL into the framebuffer without a X server, DirectFBGL (currently available only for Matrox hardware, but soon for ATI). Then aside from accelerated openGL of DRI in an accelerated framebuffer, there is a rootless X server package called XDirectFB.

It's GPL, it was at FOSDEM, and it is specific for Linux. Anyone willing to bite on this software will avoid the large, complex, picky, software projects and the competitors known to be successors, and protests of existant alternatives thatslowly become worse than the cause of the move; allthewhile retaining compatibility.

(posting from a proxy because my Slashdot posting record incurred lurker moderation from some hateful users.)

DirectFB is a good offer compared to all others. Linux graphics is not a bloody mess; there is a large choice of graphics rendering targets and each one has its quirks.

DirectFB is an example of how ease and simplicity to build software for a use should be. If you want a graphics target specifically refined for Linux, then consider DirectFB. On that project page, there are similar hosted projects that bring it all together for a complete alternative and replacement for other X servers and bindings for tool-kits of greater popularity, as well as retaining compatibility. The graphics hardware support on DirectFB is limited to companies willing to document the hardware; thus, Matrox, 3Dfx, and ATI, Trident, some nVidia, and a couple others have optimized accelerated framebuffer support. Then to top it off, there is a related project that binds DRI accelerated openGL into the framebuffer without a X server, DirectFBGL (currently available only for Matrox hardware, but soon for ATI). Then aside from accelerated openGL of DRI in an accelerated framebuffer, there is a rootless X server package called XDirectFB.

It's GPL, it was at FOSDEM, and it is specific for Linux. Anyone willing to bite on this software will avoid the large, complex, picky, software projects and the competitors known to be successors, and protests of existant alternatives thatslowly become worse than the cause of the move; allthewhile retaining compatibility.

(posting from a proxy because my Slashdot posting record incurred lurker moderation from some hateful users.)

DirectFB is a good offer compared to all others. Linux graphics is not a bloody mess; there is a large choice of graphics rendering targets and each one has its quirks.

DirectFB is an example of how ease and simplicity to build software for a use should be. If you want a graphics target specifically refined for Linux, then consider DirectFB. On that project page, there are similar hosted projects that bring it all together for a complete alternative and replacement for other X servers and bindings for tool-kits of greater popularity, as well as retaining compatibility. The graphics hardware support on DirectFB is limited to companies willing to document the hardware; thus, Matrox, 3Dfx, and ATI, Trident, some nVidia, and a couple others have optimized accelerated framebuffer support. Then to top it off, there is a related project that binds DRI accelerated openGL into the framebuffer without a X server, DirectFBGL (currently available only for Matrox hardware, but soon for ATI). Then aside from accelerated openGL of DRI in an accelerated framebuffer, there is a rootless X server package called XDirectFB.

It's GPL, it was at FOSDEM, and it is specific for Linux. Anyone willing to bite on this software will avoid the large, complex, picky, software projects and the competitors known to be successors, and protests of existant alternatives thatslowly become worse than the cause of the move; allthewhile retaining compatibility.

I'm still waiting for a reasonable alternative to the underlying X server that isn't completely unheard of in 90% of the OSS world.

I'm not sure what you mean here, do you want a different implementation of the X protocol? If so, why not try Freedesktop.org's experimental XServer? It's quite a nice fast modular server. Are you looking for something other than X11 protocol? Then why not try DirectFB? DirectFB doesn't have enough supported applications for you? Why not try Quartz, which I imagine at least 90% of the OSS world as heard of. I don't really see a lack of options there.

Jedidiah.

No no no... to do those fun graphical things they don't load an X server! They simply use the linux console in frame buffer mode.

This is why the resolution change (even if the res is the same) is necessary. This will likely never be changed. The X server then loads up, and puts the graphics card in its desired hardware accelerated mode (as opposed to the vesa frame buffer mode).

One solution to this would be to run DirectFB, and their hardware accelerated frame buffer x server! (apprently they even have 3d accel working on some cards, plus true transparency etc). However this is less than desirable.

If you're interested in learning more about frame buffer console check out the SVGALib project... or cruise the source code to say... mplayer, AdvanceMAME, elinks, or any other project that makes use of the frame buffer for some advanced applications.

In case you're wondering, you can actually play movies in a linux console (without any flavor of X running) with mplayer! Make sure you compile it with the right options though.

That's what Directfb is for...

Rich,

If I had a nickel for how many times I need to admonish others that I am not trolling, I would donate all those nickels to X.org.

First, KDE needs Xlib to connect to an X Server. KDE has graphics paths to Microsoft's GDI as well as X11. KDE doesn't have a rendering path directly to anythin outside of Microsoft's GDI. What I was trying to say is that KDE (and the same to be said for Gnome) is limited on Linux environments by the X Server. What you and I will slowly see is a reversal of technologies by the dominant *Desktop environments to establish a local API to access the canvas (think graphics hardware) directly and not needing to move through Xlib on the network datalink.

The methodology that I am aware has already discussed this has been readily available in the Linux kernel as the "framebuffer" graphics modules and an alternative linux-only implementation known as DirectFB. At the DirectFB project's homepage, there are many sub-projects. DirectFB is the framebuffer drivers where currently GNOME and generaly anything using the GTK+-2.x (and GTK+-1.x Iirc) can use a framebuffer with a driver-based unnetworked window-managing system with window transparancy; ie everything KDE and Gnome Desktop desire without needing to move through Xlib in the final packet session output to the X Server. It is all done without the X Server. Further into the DirectFB project website you will find a X Server that *runs* on the framebuffer; tricky thinking, that I suggest to you that this X Server is interfacing its windowing environment regulated by the DirectFB's natively-encoded window manager; XDirectFB. As much as I dislike linking and using enterntainment software to discuss the innovation in DirectFB's many subprojects; I do reveal to you that there is even the project DirecFBGL demonstrating using the Direct Rendering Infrastructure without a X Server and in the Framebuffer provided by DirectFB. Quake3, accelerated, in a Framebuffer, I apologise for only having posted an example of entertainment.

K NX is the prequel to DirectFB; NX server tries to keep X11 and KDE tightly bonded because KDE has no rendering path through anything but a X Server and Microsoft GDI. I need not say more.

Despite you labeling me as a troll, I forgive you. I've made mistakes, and one of them was not to secure "SlashdotTroll" from the hands of debilitating users to post pornography and slander.

HTH,
-SlashdotTroll

Rich,

If I had a nickel for how many times I need to admonish others that I am not trolling, I would donate all those nickels to X.org.

First, KDE needs Xlib to connect to an X Server. KDE has graphics paths to Microsoft's GDI as well as X11. KDE doesn't have a rendering path directly to anythin outside of Microsoft's GDI. What I was trying to say is that KDE (and the same to be said for Gnome) is limited on Linux environments by the X Server. What you and I will slowly see is a reversal of technologies by the dominant *Desktop environments to establish a local API to access the canvas (think graphics hardware) directly and not needing to move through Xlib on the network datalink.

The methodology that I am aware has already discussed this has been readily available in the Linux kernel as the "framebuffer" graphics modules and an alternative linux-only implementation known as DirectFB. At the DirectFB project's homepage, there are many sub-projects. DirectFB is the framebuffer drivers where currently GNOME and generaly anything using the GTK+-2.x (and GTK+-1.x Iirc) can use a framebuffer with a driver-based unnetworked window-managing system with window transparancy; ie everything KDE and Gnome Desktop desire without needing to move through Xlib in the final packet session output to the X Server. It is all done without the X Server. Further into the DirectFB project website you will find a X Server that *runs* on the framebuffer; tricky thinking, that I suggest to you that this X Server is interfacing its windowing environment regulated by the DirectFB's natively-encoded window manager; XDirectFB. As much as I dislike linking and using enterntainment software to discuss the innovation in DirectFB's many subprojects; I do reveal to you that there is even the project DirecFBGL demonstrating using the Direct Rendering Infrastructure without a X Server and in the Framebuffer provided by DirectFB. Quake3, accelerated, in a Framebuffer, I apologise for only having posted an example of entertainment.

K NX is the prequel to DirectFB; NX server tries to keep X11 and KDE tightly bonded because KDE has no rendering path through anything but a X Server and Microsoft GDI. I need not say more.

Despite you labeling me as a troll, I forgive you. I've made mistakes, and one of them was not to secure "SlashdotTroll" from the hands of debilitating users to post pornography and slander.

HTH,
-SlashdotTroll

Rich,

If I had a nickel for how many times I need to admonish others that I am not trolling, I would donate all those nickels to X.org.

First, KDE needs Xlib to connect to an X Server. KDE has graphics paths to Microsoft's GDI as well as X11. KDE doesn't have a rendering path directly to anythin outside of Microsoft's GDI. What I was trying to say is that KDE (and the same to be said for Gnome) is limited on Linux environments by the X Server. What you and I will slowly see is a reversal of technologies by the dominant *Desktop environments to establish a local API to access the canvas (think graphics hardware) directly and not needing to move through Xlib on the network datalink.

The methodology that I am aware has already discussed this has been readily available in the Linux kernel as the "framebuffer" graphics modules and an alternative linux-only implementation known as DirectFB. At the DirectFB project's homepage, there are many sub-projects. DirectFB is the framebuffer drivers where currently GNOME and generaly anything using the GTK+-2.x (and GTK+-1.x Iirc) can use a framebuffer with a driver-based unnetworked window-managing system with window transparancy; ie everything KDE and Gnome Desktop desire without needing to move through Xlib in the final packet session output to the X Server. It is all done without the X Server. Further into the DirectFB project website you will find a X Server that *runs* on the framebuffer; tricky thinking, that I suggest to you that this X Server is interfacing its windowing environment regulated by the DirectFB's natively-encoded window manager; XDirectFB. As much as I dislike linking and using enterntainment software to discuss the innovation in DirectFB's many subprojects; I do reveal to you that there is even the project DirecFBGL demonstrating using the Direct Rendering Infrastructure without a X Server and in the Framebuffer provided by DirectFB. Quake3, accelerated, in a Framebuffer, I apologise for only having posted an example of entertainment.

K NX is the prequel to DirectFB; NX server tries to keep X11 and KDE tightly bonded because KDE has no rendering path through anything but a X Server and Microsoft GDI. I need not say more.

Despite you labeling me as a troll, I forgive you. I've made mistakes, and one of them was not to secure "SlashdotTroll" from the hands of debilitating users to post pornography and slander.

HTH,
-SlashdotTroll

Rich,

If I had a nickel for how many times I need to admonish others that I am not trolling, I would donate all those nickels to X.org.

First, KDE needs Xlib to connect to an X Server. KDE has graphics paths to Microsoft's GDI as well as X11. KDE doesn't have a rendering path directly to anythin outside of Microsoft's GDI. What I was trying to say is that KDE (and the same to be said for Gnome) is limited on Linux environments by the X Server. What you and I will slowly see is a reversal of technologies by the dominant *Desktop environments to establish a local API to access the canvas (think graphics hardware) directly and not needing to move through Xlib on the network datalink.

The methodology that I am aware has already discussed this has been readily available in the Linux kernel as the "framebuffer" graphics modules and an alternative linux-only implementation known as DirectFB. At the DirectFB project's homepage, there are many sub-projects. DirectFB is the framebuffer drivers where currently GNOME and generaly anything using the GTK+-2.x (and GTK+-1.x Iirc) can use a framebuffer with a driver-based unnetworked window-managing system with window transparancy; ie everything KDE and Gnome Desktop desire without needing to move through Xlib in the final packet session output to the X Server. It is all done without the X Server. Further into the DirectFB project website you will find a X Server that *runs* on the framebuffer; tricky thinking, that I suggest to you that this X Server is interfacing its windowing environment regulated by the DirectFB's natively-encoded window manager; XDirectFB. As much as I dislike linking and using enterntainment software to discuss the innovation in DirectFB's many subprojects; I do reveal to you that there is even the project DirecFBGL demonstrating using the Direct Rendering Infrastructure without a X Server and in the Framebuffer provided by DirectFB. Quake3, accelerated, in a Framebuffer, I apologise for only having posted an example of entertainment.

K NX is the prequel to DirectFB; NX server tries to keep X11 and KDE tightly bonded because KDE has no rendering path through anything but a X Server and Microsoft GDI. I need not say more.

Despite you labeling me as a troll, I forgive you. I've made mistakes, and one of them was not to secure "SlashdotTroll" from the hands of debilitating users to post pornography and slander.

HTH,
-SlashdotTroll

I bought my Indrema when it was first advertised at the convention. At the time, they demo'd it as playing teh Linux version of Quake 3 Arena and they described the system as being a Simple Direct-media Layer box with Framebuffer and accelerated openGL. They never said how, but I imagine a better solution would be possible with the DirectFB's framebuffer and DirectFBGL accelerated OpenGL (without X Server w00t)

What are you waiting for? Didn't you know the Indrema already arrived on the market? I bought mine. After dissasembling it, I discovered it is based on a DEC 21164 ev57 Alpha!

Best console I have ever owned...and its dying!

I bought my Indrema when it was first advertised at the convention. At the time, they demo'd it as playing teh Linux version of Quake 3 Arena and they described the system as being a Simple Direct-media Layer box with Framebuffer and accelerated openGL. They never said how, but I imagine a better solution would be possible with the DirectFB's framebuffer and DirectFBGL accelerated OpenGL (without X Server w00t)

What are you waiting for? Didn't you know the Indrema already arrived on the market? I bought mine. After dissasembling it, I discovered it is based on a DEC 21164 ev57 Alpha!

Best console I have ever owned...and its dying!

I bought my Indrema when it was first advertised at the convention. At the time, they demo'd it as playing teh Linux version of Quake 3 Arena and they described the system as being a Simple Direct-media Layer box with Framebuffer and accelerated openGL. They never said how, but I imagine a better solution would be possible with the DirectFB's framebuffer and DirectFBGL accelerated OpenGL (without X Server w00t)

What are you waiting for? Didn't you know the Indrema already arrived on the market? I bought mine. After dissasembling it, I discovered it is based on a DEC 21164 ev57 Alpha!

Best console I have ever owned...and its dying!

However, I'd suggest talking to various people in the industry first - people tend to get lots of misinformation that sounds correct but actually isn't by reading random stuff on the web (and slashdot). See the remarks about Office preloading above - doesn't happen.

So the design of X it turns out isn't actually a serious bottleneck on performance. If you do profiling runs and such, you find that having everything co-ordinated by the X server isn't a serious speed problem and that much larger issues are things like having to read from the fb to do XRENDER blending (or was last time I checked).

Basically, before going "wow yeah, right on!" I suggest you do a lot of research into the design of past and present windowing systems - what sounds intuitively right often isn't.

Just here to let you know, this 4-user setup defined in this forum's topic is using four nVidia TNT2 graphics accelerators! These are better than GeForce graphics accelerators for driver-related reasons. Way back in the maturation of XFree86, with version 3.3.6, it is possible then and a throughout the 3.x XFree86 branch to configure XFree86Config to "Load """ Utah-GLX's nvidia driver to attain hardware-accelerated openGL. This is a completly different driver approach than DRI's openGL SAL. Utah-GLX provides X Server modules rather than its various competitors providing a /usr/lib/libGL.so.* and any non-standard patch cludged into the X Server. DRI project's openGL acceleration architecture at the moment may also allow mutliple local X Servers, albeit that of the various non-XFree86 such as the capable technology at DirectFB project (which allows accelerated openGL without a X Server; directly using the DRI without an X Server).

Backtracking to Utah-GLX's driver (project page here, this will allow many complex openGL-phile programs to run at the same time given its architecture. I, however, doubt that older XFree86 3.3.6 will scale to this feat; I simply don't know. Yet, the Utah-GLX driver system has been ported to XFree86-4.x; it is a openGL GLX driver package in the form of dynamically loaded X Server modules/extensions and can be manipulated into and without the X Server without having to restart the X Server. It's somwhat parallel to the DRI driver, to provide an alternative, but it is not being maintaned anymore; Utah-GLX is dead and someone needs to commandeer!

I am using three Athlon Thunderbid 700MHz computers with a total 9 nVidia TNT2 adaptors total (three per computer), S-Video composite output to NTSC televisions, and quad-bonded 100BaseTX ZNYX LAN adaptors for verry low-latency threaded shared openGL rendering; I use as Chromium 3D videowalls, by using XFree86 4.3 and Utah-GLX's nVidia openGLX driver.

And yes, Quake3 looks hot!

There's also GTK+ for DirectFB, which is aimed at the embedded crowd.

Directfb project has had proper translucent windows for an age.

Do you happend to know what's the status for the IGP adapters? (I have an IGP345, chipset R250 if I recall correctly)

So far I can get 2D acceleration, but not 3D, I've found some links (ATI IGP 320, Linux on a Compaq Presario 900US to name a few) but DRI is disabled (I use debian sid, and the dri-trunk-sid packages by the way)

I can't get a working radeon framebuffer, all i get is a garbled screen mode and I can't seem to fix it (I've even installed a kernel patch)

All I'd want is a working 3D acceleration, the framebuffer is not important to me.

In fact, even getting DirectFB working on a Gentoo system was amazingly easy as long as your kernel Frame Buffer is working. I got it up and running with GDM and Gnome without any major bumps.

If you look at the XDirectFB screenshots you can see what it looks like using the DirectFB X-server :-) The server has the ability to make windows transparent/opaque by degree as focus is lost/gained or hidden/shown. Very nice :-)

If this gets the go-ahead (and if it's open source), it'll be even nicer. The DirectFB X-server is still a standard 2-D environment, with all that entails. I can't see much use for attaching sticky notes to the "backs" of windows, but I'm sure someone will come up with one :-)

Simon

DirectFB.

Yay DirectFB!

From the looks of the screen shots on their web page these projects seem like an interesting alternative that can potentially put the Linux desktop at a stage not achievable via X alone - A true alpha blended desktop!!!... haven't tried it out cuz the driver support seems lacking... is there any way to port drivers from X into this project without causing all sorts of license problems?

No. I think "rootless" in the context of the parent implies no root container window within which each X window appears. Cygwin/XFree86 works this way, all the apps are contained within one big container window. In contrast, Apple's X Server that runs on top of OS X and the X Server in DirectFB does not do this. Each X window is mapped to a top-level window in the host windowing system, managed by the host windowing system rather than an X Windowing System Window Manager (so borders and universal window controls like 'Close' and 'Iconify' look the same as the host windowing system, and the individual X windows appear in the window list / taskbar / dock of the host windowing system).

GTK on the framebuffer is quite nice. Aside from the nice transparency effects in the screenshots, it's really quick. Hopefully we'll see a LiveCD come along soon with GTK on DirectFB so people can evaluate it without jumping through a great many hurdles. I bet a great many GNU/Linux/BSD users don't need or even know about the many features of X11 like network transparency, let alone use them.

I like to think DirectFB is to X11 as Hurd is to Linux. ( in design - not availability :) I could be wrong about that, but it seems to be more modular, and lightweight.

With that said, congrats to freedesktop.org. They are becoming more and more valuable to our little community every day it seems.

If IBM wants to get this trough it needs to do a couple of things:
1. Take X11 and throw it out of the window. Build a FB acceled interface and make Qt/GTK use it. There already are some viable projects like DirectFB so IBM can simply inject some cash into it and strongarm the HW makers into more collaborative driver efforts.
2. Offer X11 as an add on like Apple; it's too useful for interoperability and compat but keeping it as a modified & bloated primary interface would make it too complicated for developers. Building a least-resistance clear cut route for them... they're lazy!
3. Buy Qt... LGPL it or offer it at dirt cheap prices... all specialist SW I've seen on WIN/UNIX is linked against Qt, wouldn't that be a better solution to wine (still interop but no OS/2 "might as well jmust go Windows right?")
4. Wait...
5. Give the finger to M$... >-]

Looks like DirectFBGL is 16 months old, although XDirectFB has a v1.0rc5 that's only 6 months old. I can't tell how you'd "make install" the two together, and whether existing apps would "just work", but someone else seems to be working on it.

Looks like DirectFBGL is 16 months old, although XDirectFB has a v1.0rc5 that's only 6 months old. I can't tell how you'd "make install" the two together, and whether existing apps would "just work", but someone else seems to be working on it.