Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: Luc Modularizes Mesa, DRI Drivers

  1. #11
    Join Date
    Jun 2008
    Posts
    162

    Default

    Quote Originally Posted by libv View Post
    So you think that my efforts to straighten out the X.org foundation are not very productive?
    ?

    I fail to understand. Did you mistake me with duby229? Or should I have prefaced my post with "CAUTION: IRONY" ?

  2. #12
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    Quote Originally Posted by miles View Post
    ?

    I fail to understand. Did you mistake me with duby229? Or should I have prefaced my post with "CAUTION: IRONY" ?
    Ok

    Well, this is one of those touchy subjects were i go on the defensive immediately, so sorry for not capturing what in other cases would've been a good laugh for me

  3. #13
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    Quote Originally Posted by markg85 View Post
    First; this is a very nice example where open source software is just awesome! Don't loke something change it.. sadly that is only true if you're a skilled programmer.

    @luc (libv)
    Why don't you simply fork xorg till they allow your structure to be THE structure to write drivers? You seem like someone that has the knowledge and will to do so and that will "fix" your issue of keeping your code working on xorg.. (if you fork, please enable ctrl+alt+bcksp by default again )

    Anyhow, awsesome job however it turns out.
    Well, forking is not my style and something like that does not succeed on its own, especially not for technical reasons. Forks are mostly only about politics and people trying to protect or enlarge their power-base outside of technical advancement.

    About not liking something, and/or not liking the general direction of things, and then coding up how they should be... I have done that many times before. And several of those have turned out to be real winners, even though the people who get proven wrong in such a case, are usually not very sportive about it. This means that credit is then not given where credit is due, and this is where the whole meritocracy thing breaks down, as the next time round, the same story has to be played all over again, in pretty much the same way, with a sizable waste of resources as a consequence.

    About ctrl-alt-bcksp... I miss that too (i know, it's only off per default). It's like the X stipple and the VGA text console. When you see the stipple, you know that your driver code is not horribly broken. When it is horribly broken, you might still have ctrl-alt-backspace, which then hopefully gives you the VGA console again. If you see the VGA console again, you get to play again... All 3 are happily tied together for a graphics driver developer

  4. #14
    Join Date
    Jun 2008
    Posts
    162

    Default

    Quote Originally Posted by libv View Post
    Ok

    Well, this is one of those touchy subjects were i go on the defensive immediately, so sorry for not capturing what in other cases would've been a good laugh for me
    That's ok, being an outsider anyway I do appreciate each and every one's work on Xorg, and I'm really happy to see developers like you working on improving the code

  5. #15
    Join Date
    Jan 2008
    Posts
    297

    Default

    Luc,

    For X server 1.9, the tentative plan is to merge the device-dependent drivers back into the X server.

    Your work here on Mesa seems to be doing the opposite.

    So, do you disagree with the move to merge the DDXs into the X server? If so, please explain.

    If not, how is the situation with DDX/X server sufficiently different from Mesa to warrant this move in the opposite direction?

  6. #16
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    Quote Originally Posted by mattst88 View Post
    Luc,

    For X server 1.9, the tentative plan is to merge the device-dependent drivers back into the X server.

    Your work here on Mesa seems to be doing the opposite.

    So, do you disagree with the move to merge the DDXs into the X server? If so, please explain.

    If not, how is the situation with DDX/X server sufficiently different from Mesa to warrant this move in the opposite direction?
    Moving drivers back into the X server is the single worst thing that people can do at this point.

    Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

    The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

    People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.

  7. #17
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default SDK capable mesa tree now available!

    at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

    I am still working on a README, and will make more noise once i have had some shut-eye.

    For the adventurous, here is the quick summary:
    * pick versions that are very close to your current mesa version (libGL needs to match)
    > ./autogen.sh [maybe want to add --prefix=/usr/]
    > make dri-sdk
    > make dri-sdk-install

    Then you can build, install and run your dri driver.

  8. #18
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    Quote Originally Posted by libv View Post
    at http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

    I am still working on a README, and will make more noise once i have had some shut-eye.

    For the adventurous, here is the quick summary:
    * pick versions that are very close to your current mesa version (libGL needs to match)
    > ./autogen.sh [maybe want to add --prefix=/usr/]
    > make dri-sdk
    > make dri-sdk-install

    Then you can build, install and run your dri driver.
    README: http://people.freedesktop.org/~libv/dri-sdk.txt

  9. #19
    Join Date
    Jul 2009
    Posts
    261

    Default

    Quote Originally Posted by libv View Post
    Well, forking is not my style and something like that does not succeed on its own, especially not for technical reasons. Forks are mostly only about politics and people trying to protect or enlarge their power-base outside of technical advancement.

    About not liking something, and/or not liking the general direction of things, and then coding up how they should be... I have done that many times before. And several of those have turned out to be real winners, even though the people who get proven wrong in such a case, are usually not very sportive about it. This means that credit is then not given where credit is due, and this is where the whole meritocracy thing breaks down, as the next time round, the same story has to be played all over again, in pretty much the same way, with a sizable waste of resources as a consequence.
    Tell me the story of radeonhd again? :P

    Quote Originally Posted by libv View Post
    About ctrl-alt-bcksp... I miss that too (i know, it's only off per default). It's like the X stipple and the VGA text console. When you see the stipple, you know that your driver code is not horribly broken. When it is horribly broken, you might still have ctrl-alt-backspace, which then hopefully gives you the VGA console again. If you see the VGA console again, you get to play again... All 3 are happily tied together for a graphics driver developer
    We figured that graphics drivers were probably going to be able to work out -retro, or have an alias or something. I admit it's not ideal though; we could do something like display the root weave in everything but RC/stable tarballs?

  10. #20
    Join Date
    Jul 2009
    Posts
    261

    Default

    Quote Originally Posted by libv View Post
    Moving drivers back into the X server is the single worst thing that people can do at this point.

    Ask yourself, what good does this move bring that isn't already fully provided for by the tinderbox?

    The graphics driver developers who want this just want to be lazy, and just want to be more free to break the APIs in a bad and untrackable way.

    People believe that the kernel model works for hardware as complicated and volatile as graphics hardware, but time will tell differently.
    'API' implies some vague sort of design. $(includedir)/xorg is many things, but not designed. The idea is to basically incrementally create useful APIs that everyone can use without too much pain. You should know this, having written a Screen(Pre)Init before ...

Posting Permissions

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