Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
X GUI Software

DRI Comes to DirectFB 248

Posted by michael from the choices-are-better dept.
Pivot writes "To further heat up the discussion about the future of the graphical desktop on open source OSes: Now the DirectFB project works with DRI!. Screenshots are available. I guess what is lacking now is only XAA driver support, or native drivers for your favourite graphic card." We've mentioned DirectFB before.
This discussion has been archived. No new comments can be posted.

DRI Comes to DirectFB More

DRI Comes to DirectFB

Comments Filter:
  • It sounds like a great project but native driver support and linux, whoa back right up. For most consumer hardware that is far form a reality. Personally I have an ATI card so this is good for me but it may take quite a while to ad support for others. I can't wait to give it a try though should be exciting to see and work with because gui speed definently is lacking in the major desktops for linux which just slows down the programs that run on them.

    • NVIDIA not supported (Score:2, Interesting)

      by Anonymous Coward
      "The embedded-1-branch of Mesa is a port of DRI to the framebuffer device (fullscreen only, no input). Currently supported are ATI and Matrox (after porting the driver a few days ago)".

      Once again NVIDIA is not supported. NVIDIA wake up and release your specs and manuals under NDA to the developers. You are only hurting yourself by denying your product less acceptance in the open source world. And for the NVIDIA supports open source argument try moving between X versions and see how well your NVIDIA car

  • Here we go.... (Score:5, Insightful)

    by IamTheRealMike ( 537420 ) on Thursday May 01, 2003 @09:41AM (#5851974)
    I was wondering when this one would show up on Slashdot. A few thoughts:

    1) Today, DirectFB can do some things XFree cannot, but the reverse is also true. But, the XFree infrastructure could be (and will be) upgraded to do stuff like full use of hardware accelerations, proper save unders, alpha blended windows and so on. DirectFB cannot gain network transparency or code portability however.

    2) On the other hand, using DirectFB does not mean we lose network transparency. The X11 protocol won't disappear. If it had better hardware support, or was able to use the XFree drivers, I'd have no problem at all using this software. For apps that used GTK/Qt I'd always have the choice of network transparency when I needed it. Software written for DirectFB specifically probably isn't the sort of thing you'd want to run remotely anyway.

    3) Window transparency is overrated. Window double buffering is not.

    4) DirectFB still has a lot of questions to answer. AFAIK there is still not window management protocol for instance - X11 provides a lot of things most people don't think about, DirectFB would have to provide equivalents first.

    5) Half the comments in this thread about XFree will be misinformed ;)

    • Re:Here we go.... (Score:5, Insightful)

      by Yarn ( 75 ) on Thursday May 01, 2003 @10:07AM (#5852127) Homepage
      It's not designed as a windowing system, it's for embedded systems. I looked at using it for my PVR system, but I didn't like the API.

      I didn't use X because it provided a whole load of functionality I don't need (windows, input devices), and didn't have some things I did need (reliable access to the BES on the video output card).

      I do like X, it's great for my desktop, but it's not the only way of putting pixels on a screen, nor should it be.

    • Fresco (Score:3, Insightful)

      by p00ya ( 579445 )
      DirectFB still has a lot of questions to answer. AFAIK there is still not window management protocol for instance - X11 provides a lot of things most people don't think about, DirectFB would have to provide equivalents first.
      That's why I'd love to see fresco [fresco.org] enjoy some more support/activity/interest.

    • Re:Here we go.... (Score:5, Informative)

      by MartinG ( 52587 ) on Thursday May 01, 2003 @11:39AM (#5852864) Homepage Journal
      DirectFB cannot gain network transparency

      Not only can it gain network transparency, but it gains everything that X has functionally in the form of XDirectFB, a rootless X server that puts X compatability on a layer _above_ the windowing system. Many people believe this is where network transparency belongs rather than entangled within the windowing system.
      • ... puts X compatability on a layer _above_ the windowing system. Many people believe this is where network transparency belongs rather than entangled within the windowing system.

        Yup, this is my feeling exactly. I have no problem with X11. DirectFB is interesting because it allows us to have a much better design for our graphical subsystem (first and foremost, by using Linux kernel drivers). It does not replace X11 at all, just the driver base of XFree86.

        Can everybody please stop the X11 naysaying? D
      • Ah, no, I didn't make myself clear, sorry.

        DirectFB apps, that use the DirectFB API, are not network transparent, and probably never will be. DFBTerm for instance.

        The fact that most apps are capable of using the X protocol today, and that DirectFB implements a small X server, does not mean that apps which talk to DirectFB itself are network transparent.

    • The people who want DirectFB seem to be the same people who complain that they can't get a 648FR in Doom. "It's that damn networking transparency stuff in X! It's slowing me down!"

      Instead of throwing out X just to please a tiny segment of gamers, let's take a sensible approach. Win32 didn't become obsolete when DirectX showed up. In fact, they seem to work nicely together. Why can't the same thing happen in *NIX land? Why must it be one or the other? Have DirectFB tell X that it's going to use this region

  • Great 'article' about how to get a nice console (Score:5, Informative)

    by humming ( 24596 ) on Thursday May 01, 2003 @09:53AM (#5852052)
    It's tailored for gentoo, but most stuff applies to most distributions I guess. Not that I'm using them. ;)

    http://forums.gentoo.org/viewtopic.php?t=49036

    Then you can get consoles which look like this:
    http://www.alledora.co.uk/images/fb0.jpg
    o r
    http://www.bootsplash.org/silent-mode.jpg

    Files can be recived from
    http://www.bootsplash.org/

  • Obligatory regular expression (Score:5, Funny)

    by Znonymous Coward ( 615009 ) on Thursday May 01, 2003 @09:59AM (#5852081) Journal
    Screenshots are available.

    ~ s/are/were/

  • Dirty Rotten Imbiciles are going to work on a free and open project...glad to see punk music making the "crossover" with computers.... ...oh wait

  • So, what? (Score:2, Funny)

    by cdemon6 ( 443233 )
    Let's fork XFree, merge it magically with DireectFB and produce a lightweight X-windows brother...

    Then, let us call it DirectX. :)

  • Naive Question (Score:3, Interesting)

    by Godai ( 104143 ) * on Thursday May 01, 2003 @11:15AM (#5852665)

    I've noticed that a lot of the discussion on DirectFB is like all other X 'replacements' -- half the people talk about how great it will be because it will jettison the useless bloat in what they call outdated technology, while the other half rail about the loss of the network-transparency that they can't live without.

    Well, this may seem naive, but maybe both sides are right? I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20? Maybe? At the same time though, that one person is probably using it for somthing uber-useful, like eliminating 200 desktops in lieu of dummy terminals :)

    So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular? Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X) that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?

    I'm not saying this would be trivial, but surely it'd be worth the time and effort so that the 95% of users who don't want it can simply turn off network-transparency, and the 5% who do can plug it in without a lot of hassle.

    As I said, surely this is naive. So flame away.

    • "I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20?"

      Multiply that by 1 million and you'll get 1.000.000 in 20.000.000.
      Don't mark something down as "useless" bloat just because only what seems to be a minority in percentages use it.
      Even if only 1% use network transparency, if there are 500.000.000 computer users then there are still 5 million people who need network transparency!

    • Re:Naive Question (Score:4, Informative)

      by IamTheRealMike ( 537420 ) on Thursday May 01, 2003 @12:04PM (#5853084)
      So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular?

      Well, X is actually modular. It doesn't use the network subsystem when run locally.

      Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X)

      I've just been doing some Xlib programming (for wine). It's not that bad. Win32 is certainly a LOT harder and less intuitive. But very few people use Xlib directly anyway.

      that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?

      Yes, X provides exactly that, with the exception of alpha blended windows, but that's because more hacking is needed inside the XFree drivers architecture to make it work at acceptable speeds.

    • Re:Naive Question (Score:5, Insightful)

      by Paul Jakma ( 2677 ) on Thursday May 01, 2003 @12:25PM (#5853264) Homepage Journal
      First of X is not that bloated - have a look at TinyX (part of the XFree tree), its 868 kilobytes in size and is currently using about 5.9MB of RAM on my Ipaq (868KB for the exe, 2MB for libraries and just 2.6MB for data - and thats with a few apps open too).

      People who say X is bloated are either ignorant or liers.

      Also, X provides things which plain framebuffers do not which must /still/ be done somewhere if one wishes to actually have more than one app displaying to that framebuffer, ie arbitration. If you look at toolkits designed for plain fb's, eg QtEmbedded, they have a good bit of code in them to allow for arbitration between different apps for access to the framebuffer (and hey, now you need scheduling code too!). Iirc, there was an interview with one of the guys who was involved early on with the Berlin project, and he said that by time they had all the things needed to allow apps to work together on displays they werent far off the size of an X server anyway.

      Also, often when people blame X for bloat they're blaming the wrong thing. They see X taking up 80MB on their desktop and go "oh bloated" - but in all probability it is all your fancy graphical apps not cleaning up the pixmaps they create as they go along! Fix the apps!

      • X memory usage (Score:2, Informative)

        by Ender Ryan ( 79406 )
        The memory usage you see in X is actually the memory of your video card + X, often allocated in different ways causing `top' to display a huge amount of memory incorrectly.

        • indeed, i'm well aware of that, but you're missing something - X clients can ask the X server to create 'objects' usually pixmaps which persist for the lifetime of that X client connection. There are bad apps out there that forget to free objects, and just keep creating new ones, causing the X RAM usage to balloon. The app needs fixing.

          Shutting down the X client will cause the X server to free any objects it had. However, you probably will not see your RAM usage go down - as glibc /never/ shrinks the heap
    • Yet more morons are posting this fallacy.

      Think hard. Imagine how network transparency would be "added on" to an API that is designed to not be network transparent, for instance one that uses shared memory to read/write to the screen pixels.

      Answer: it is not possible. Network transparency requires design considerations in the API. Fortunately these requirements are exactly the same as are needed for all security and stability reasons so that crashing programs or hostile programs cannot take down the wind

      • It's not even worth wasting time.. 75% of Slashdot is filled with people who can't understand the conceptual design of the stuff they speak about. So basically, they don't even understand what you're saying. They like to think abstractly about problems which they know nothing about, hence, the above. As for the the "X is so bloated" comments that never seem to die, they usually come from people like the previously mentioned. Sadly they don't realize that it's akin to the "BSD is finally dead" type of commen
      • This is the only way to make "network transparency" a "plugin"

        Technically, "screen-scraper" systems like VNC also make transparency a plugin (as it's a feature that was considered by neither the designers of the GUI system, or individual applicatiosn).

        But of course, they pay a high price in lowered responsiveness.

  • X and networking (Score:5, Insightful)

    by ceswiedler ( 165311 ) * <chris@swiedler.org> on Thursday May 01, 2003 @11:59AM (#5853032)
    To prevent uninformed comments about X:

    X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

    X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

    X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER

    Look here [faqs.org] for an explanation of what Unix domain sockets are. They have nothing to do with networking and are the most efficient form of IPC on Linux. As a bonus, you can write code which uses either AF_UNIX sockets or AF_INET (TCP/IP) sockets seamlessly--but AF_UNIX sockets still have nothing to do with networking. Got it?
    • First, i know nothing of X. But I have a question: doesn't X still use the protocol over UNIX-domain sockets, which would still have to travel up and down the network stack?
      • Yes, X uses a protocol over the local sockets. That's inter-process communication. The X server runs as its own process, and that's a Good Thing.

        No, it does not ever touch the network stack. Really. I promise. You can run X locally on a kernel which doesn't even have networking compiled in. Unix sockets are like signals, shared memory, message queues, and other forms of inter-process communication. They simply use the same socket interface as TCP/IP sockets.
        • As someone who learned this painfully many years ago , you do need the networking stack compiled in. UNIX domain sockets depend on them.
    • The link you mention claims

      "As stated earlier, this FAQ deals only with AF_INET sockets."

      So it's not the best source for Unix domain sockets. However, Unix sockets ARE NETWORKING, from a software perspective. The same socket.h function calls are invoked for TCP/IP, or unix sockets (or even ipx, x25, and other stuff).

      are the most efficient form of IPC on Linux

      That's the crux of the common complaint. IPC = "interprocess communication". Some other prominent GUI systems don't require interprocess co
      • That's the crux of the common complaint. IPC = "interprocess communication". Some other prominent GUI systems don't require interprocess communication to update the screen, and can provide quicker response with less overhead. IPC will always be slower than system calls with no context switching.

        But the IPC overhead consumes less than 1/100th of 1 percent of the time it takes to draw a window or widget when running locally. Removing it would make no noticable difference. Even a benchmark would be hard p
        • But the IPC overhead consumes less than 1/100th of 1 percent of the time it takes to draw a window or widget when running locally.

          It's not the overhead of IPC that makes a difference when you're reaching for extreme speeds- it's the fact that there's another process involved at all. If the data magically transferred between processes instantly (as shared memory does, and Unix sockets virtually do), the user still won't get a response until the OS gives the other process a timeslice.

          The history of the W
      • OK, sorry, the FAQ wasn't the best link.

        Whether or not Unix sockets are networking depends on your definition of networking. Yes, they use the same interface as INET sockets. However, they're completely 100% limited to local-host communication. How can something be a networking component if it can't talk to another host?

        As I see it, Unix sockets are a form of inter-process communication which happens to act like inter-host communication. Which makes it easy to write code which communicates with either ano
        • AFAIK, Unix sockets are the fastest form of IPC.

          On Linux, Doors IPC [rampant.org] can be faster than Unix sockets (depending on how you benchmark). Sometimes even just pipes can be faster.

          Unix sockets are NOT the same as for example accessing a local drive through an NFS mount on the local server. That does indeed go through networking to the 127.0.0.1 address

          In that case, the majority of the slowdown comes not from the TCP/IP stack, but from overhead introduced by the nfs client and server processes (as they perf

      • Some other prominent GUI systems don't require interprocess communication to update the screen, and can provide quicker response with less overhead.

        Yeah, with either no security, or the kernel does all the work. Both often cause problems. Direct kernel calls for graphics primitives may not be a bad thing (in a way DRI allows this), but I think a separate process should manage windows, security and higher level functions. DRI also seems to break security. I have to block permissions of /dev/dri/ for any un

      • Re:X and networking (Score:3, Interesting)

        by Arandir ( 19206 )
        This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.

        I'm running KDE on a P4 1.4Ghz machine. My boss runs Win2k on a P4 1.5Ghz machine. I'm assuming that KDE performance is roughly comparable to Gnome performance.

        Anyway, my boss comes by and asks for some information. I bring it up by opening a Konqueror file manager window to an NFS mount, then opening
        • Anyway, my boss comes by and asks for some information. I bring it up by opening a Konqueror file manager window to an NFS mount, then opening the file in OpenOffice. He thanked me, then remarked how much snappier my desktop was than his. Huh? That was NFS plus OpenOffice, in case you didn't notice. Everyone on Slashdot tells me that X/KDE is slower than M$/Windows. They tell me so often that I was starting to believe it.

          That's really amazing. The complete opposite of my experience.

          I have an AMD Athlon
          • OpenOffice is slow, but not THAT slow. I suspect that you have a bad build or something.

            Anyway, I suspect it was "fast enough" in my story, because I already had an instance running. But it's still slower than MSOffice, which is why I was surprised my boss thought my desktop was snappier.

            I suspect that his impression came not from the speed of any individual action, but from the overall workflow.

      • Re:X and networking (Score:3, Interesting)

        by be-fan ( 61476 )
        Hmm, let's do a little survey:

        BeOS --- Known for being blazingly fast, if anything. It was pretty much a microkernel for god's sake. Used IPC for everything, including sending data to the app_server (the equivilent of X in its architecture).

        Windows --- All the NT kernel-based OSs use an IPC mechanism called LPC to communicate with the Win32 server and the GDI.

        OS X --- Not known for having a fast GUI, but the fact that it runs the GUI in a server (lightweight window process in OSX-speak) isn't the reason.
    • "X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER"

      Actually, your wrong. If you knew anything at all about how X works, you would realize this.

      The reason that X is slow locally is because 2D windowing isn't directly rendered like DRI 3D or DirectFB. In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering locally for everything, it will continue to be significantly slower t
      • A "direct rendering" method as you describe it is where the functionality to draw a specific graphic object is in the application (or in a library linked to the application) and all the system does is map video memory into the application's address space for that application to do bit by bit operations on. In a case like 3d rendering, where everything is a completely custom graphic, and the only predefined operation is transforming of a polygon description into a rastered image, which is done by a few very
      • The reason that X is slow locally is because 2D windowing isn't directly rendered

        Actually there were some folks who implemented direct rendering for 2D in X and guess what, it didn't make any difference! The problem is not direct rendering, it's the inefficiency of Xlib (e.g. requiring replies when it's not needed, etc).

        In XFree86, all communication is done via UNIX sockets. This is essentially a network protocol, and is just as slow as far as overhead is considered. Until XFree86 uses direct rendering
      • You do not know what you are talking about. Windows does not use "direct rendering" either. It would be WAY too slow and would make it impossible to use hardware acceleration.

        If this was a good idea we should also be writing files to disk by memory-mapping the disk into the application.

        The problem with X is bad Xlib design and their paranoid refusal to jettison parts of it because it might break some obscure program. Oddly enough X does not dictate the communication protocol, since you call XOpenDisplay

    • another myth that poeple need cleared up every fucking time is thus:

      THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT

      THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT

      THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT

      Got it? Good! Stop the nonsense regarding X! Stop trying to throw out the baby with the bathwater.

      Network transparency is used by a lot of people. Network transparency does not slow down X locally. Network transparency does not add considerable bloat.

      Blah blah bla

    • You seem like the guy to ask. Does X Windows use networking for the local server? ;-)

      They have nothing to do with networking and are the most efficient form of IPC on Linux.

      What are these epics thingies everyone keeps talking about. This guy told me shared memory or mmap can be faster for transfers of thingies like huge pictures. He even uses shared memory with the X thingie.

      AF_UNIX sockets still have nothing to do with networking.

      My psychic wants me to ask: What about NFS? Why did you link to a pag

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close