Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: DRI3000 (DRI3) Begins To Take Shape Again

  1. #1
    Join Date
    Jan 2007
    Posts
    14,759

    Default DRI3000 (DRI3) Begins To Take Shape Again

    Phoronix: DRI3000 (DRI3) Begins To Take Shape Again

    Immediately following XDC2012 there was a lot of talk about "DRI3", but nothing materialized in time for the forthcoming X.Org Server 1.14 release. The DRI3 plans haven't died off but now Keith Packard is talking about this next Direct Rendering Infrastructure update as DRI3000...

    http://www.phoronix.com/vr.php?view=MTMwNjc

  2. #2
    Join Date
    Mar 2012
    Posts
    83

    Default Plan9 was right

    > DRI3 still revolves around using POSIX file descriptors for passing kernel objects between the X Server and the application.

    I wouldn't have thought that Plan9's concept are useful even on low level frameworks!

  3. #3
    Join Date
    Dec 2011
    Posts
    2,045

    Default

    Quote Originally Posted by renox View Post
    > DRI3 still revolves around using POSIX file descriptors for passing kernel objects between the X Server and the application.

    I wouldn't have thought that Plan9's concept are useful even on low level frameworks!
    "Everything is a file" is one of the defining features of Unix.

    Unix's successor Plan 9 took this concept into distributed computing with the 9P protocol.

  4. #4
    Join Date
    Dec 2011
    Posts
    2,045

    Default

    Interesting to see new work being done for X.org even though there is development going on for Wayland.

  5. #5
    Join Date
    Nov 2011
    Posts
    353

    Default

    Dri is used with wayland.

  6. #6
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,888

    Default

    Quote Originally Posted by garegin View Post
    Dri is used with wayland.
    Kernel-side infrastructure of it, maybe. But not the exact extensions, they can't. The extensions are X specific. Unless you're talking about the XWayland backend, but thats different.

  7. #7
    Join Date
    Nov 2011
    Posts
    353

    Default

    Quote Originally Posted by Ericg View Post
    Kernel-side infrastructure of it, maybe. But not the exact extensions, they can't. The extensions are X specific. Unless you're talking about the XWayland backend, but thats different.
    I hope supporting both x and wayland doesn't slow things down. Progress in already at a glacial pace.

  8. #8
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,888

    Default

    Quote Originally Posted by garegin View Post
    I hope supporting both x and wayland doesn't slow things down. Progress in already at a glacial pace.
    XWayland is just a shim-layer that gets created when you have an X Client that cant also be a Wayland Client. It creates an X server the exact size of the window in question and X is tricked into thinking its in charge when in reality Wayland is a puppeteer over head directing things to be how they want and how they SHOULD be in the Wayland world.

    Its actually a fairly elegant solution since X clients dont have to change at all and I dont think its in the way of anything in the Wayland world since there's no guarantees that an X Client will be up at any given time. Its basically just an optional code-path that only gets called if an X client somehow appears.


    EDIT: Or did you mean "Supporting" as in developer manpower? I doubt it... All the X devs are Wayland devs for the most part, they know Wayland is the future and that updating X is pretty much just a "Here's some work for us to better the community until KDE hits 5.0 and every Qt and KDE program becomes X/Wayland compatible" lol
    Last edited by Ericg; 02-20-2013 at 12:23 PM.

  9. #9
    Join Date
    Nov 2011
    Posts
    353

    Default

    Quote Originally Posted by Ericg View Post
    XWayland is just a shim-layer that gets created when you have an X Client that cant also be a Wayland Client. It creates an X server the exact size of the window in question and X is tricked into thinking its in charge when in reality Wayland is a puppeteer over head directing things to be how they want and how they SHOULD be in the Wayland world.

    Its actually a fairly elegant solution since X clients dont have to change at all and I dont think its in the way of anything in the Wayland world since there's no guarantees that an X Client will be up at any given time. Its basically just an optional code-path that only gets called if an X client somehow appears.


    EDIT: Or did you mean "Supporting" as in developer manpower? I doubt it... All the X devs are Wayland devs for the most part, they know Wayland is the future and that updating X is pretty much just a "Here's some work for us to better the community until KDE hits 5.0 and every Qt and KDE program becomes X/Wayland compatible" lol
    do you think distro can ship xwayland by the end of the year when it gets merged? kde 5 is a long way off.

  10. #10
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,888

    Default

    Quote Originally Posted by garegin View Post
    do you think distro can ship xwayland by the end of the year when it gets merged? kde 5 is a long way off.

    Hopefully XWayland will get merged into the next Xorg release, hopefully.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •