Announcement

Collapse
No announcement yet.

X.Org Project Has Five New Summer Projects

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Veerappan View Post
    *shrug* No clue why someone didn't pick up those projects.

    Well, I've been looking for a thesis topic for this fall/winter/spring, so if the h.264 gallium decoding isn't being worked on by then, I might have to see if it's feasible to do as a thesis project. I don't have much current video decoding knowledge, but I do have gallium-capable hardware, and the source for both is available for study.

    The timing just didn't work out for me to work on a SoC project, otherwise I'd have applied for one of these (The OpenGL 3.2 tracker would've been cool, but I don't know that I'd feel qualified for that one based on lack of GL knowledge).
    You do know that Xorg has an alternative program? EVoC - Endless Vacation of Code.


    So you can get paid to hack on this stuff at any time

    Comment


    • #12
      All these state trackers...

      I am wondering just how much Linux is going to totally PWN with Gallium/ATI and how the future landscape will look like. Minimalistic, modular, fast an feature rich.

      Fsck OpenCL! Just make a state tracker instead

      Comment


      • #13
        Originally posted by whizse View Post
        You do know that Xorg has an alternative program? EVoC - Endless Vacation of Code.


        So you can get paid to hack on this stuff at any time
        Actually, I wasn't aware of that program. Thanks for the link. Getting paid for it isn't a big deal for me (I've got a full-time programming job while working on my masters), but getting a Thesis out of it is.

        Comment


        • #14
          It seems to be a well kept secret, perhaps Phoronix could help pimp it a little bit?

          Comment


          • #15
            Hell I didn't even now that multi seat PNP-USB is missing in xorg,...how was it done now,what will change.Can someone elaborate on that.

            Comment


            • #16
              ..the Permedia 3/4 hardware comes as a bit surprising, if you even recognize the name.
              You bet. My first desktop had a Permedia 2 in a PCI slot. With only 4MiB of video RAM, it was pretty useless. I think it had a hardware MPEG2 decoder, though.

              Comment


              • #17
                If you are going to write a KMS interface for Permedia, why don't you select another card even easier to write drivers for? I'm thinking about the best supported 3D hardware in Linux ever: the 3dfx Voodoo.

                I worked with a venerable Voodoo3 3000 a lot of time, and it's a text case of how open specs and a truly free driver written by the community can help for a product survival.

                Back in time (1999), just before its downfall and NVIDIA adquisition, 3dfx went to store with the Voodoo3. It featured drivers for the OS there were then: Windows 98, Windows 2000 and a fantastic and never equalled Glide Mesa GL driver for Linux. That driver was truly miraclous. Descent 3 ran a lot better under Linux than under Windows then. And, for Windows 2000, things worked.

                NVIDIA bought 3dfx and killed off all support lines, and this, supposedly, was the death for all of us, Voodoo owners, because there were no drivers for Windows XP, and Microsoft drivers didn't accelerate 3D. Was it the end?

                From the darkest corners of fully documented, open source, and free support for Linux came a new driver, a backport of the free Linux driver to XP. With that new driver, repackaged as the 3DHQ driver, I could skip a generation of video cards and I was able to keep going with my Voodoo3.

                Let's pay an homage to the best supported ever video card under Linux. KMS it, instead of Permedia. It's worth it.

                Comment


                • #18
                  What is the multiseat plan exactly?

                  From the article I gather that the plan for multiseat is to provide more support for USB display devices.

                  That is nice, but as a sysadmin of a number of multiseat systems, I would like to see more support for audio, usb sticks and other usb devices (camera's, webcams, headsets, phones, mp3 players, wacom tablets etc.), and first and foremost a better way to configure which keyboard and mouse is coupled to which display.

                  For this to happen, a number of things need to happen:

                  * input devices: be able to assign a portion of the usb device tree to a users session. This way you can let all devices plugged in a certain usb hub (for instance the usb ports in a monitor) be owned by that user.
                  * audio: consolekit needs to be more complete and there needs to be a way to assign a certain audio device to a seat. The easiest way is to use USB headsets, and plug them into the hub that is configured as belonging to a seat. Again, you need to be able to assign a usb device subtree to a seat, and let the session owner all current devices in the subtree and all devices added in that subtree later.
                  * usb sticks and other devices: if plugged into the seat's hub, it will be added to the usb device tree and should automatically be owned by the user that has a session at that seat.

                  I can find almost no usable information on how consolekit actually works. It is hardly documented, it's design documents only look half finished. It is not yet finished itself, yet it is already a core part of the major distro's: ubuntu, fedora, suse.

                  I think consolekit, udev can be adapted to make the multiseat setup possible as described above, and I hope that is the idea of this summer of code project, but I'm not so sure.

                  Is there anyone who can shed some light on this issue? Maybe Lucas Ferreira can answer my question?

                  Comment


                  • #19
                    3DLabs getting bought by ATI... WTF? Phoronix changes the history...


                    3Dlabs was formed from a management buy-out of Dupont Pixel Systems in the UK in April 1994 and went public on Nasdaq in October 1996. 3Dlabs acquired Dynamic Pictures in July 1998 and the Intense3D division of Intergraph in July 2000 before being acquired by Creative Labs in June 2002. In February 2006, 3Dlabs announced that it would stop developing professional 3D graphic chips and focus on embedded and mobile media processors.

                    Also, they deserve a nice homage...

                    3Dlabs was an early pioneer in bringing 3D graphics to the PC. Its GLINT 300SX graphics processor was the industry's first single chip, 3D-capable graphics device that was shipped on graphics boards from multiple vendors. Gamma was the first single chip graphics geometry processor for the PC. Permedia was the first low-cost OpenGL accelerator chip. 3Dlabs was a member of the OpenGL Architecture Review Board and played an important role in the development of OpenGL 2.0 and ongoing evolution of the OpenGL API.
                    Maybe it makes sense if you read the following:

                    In November 2006, 3Dlabs announced its plans to spin out from Creative Labs and introduce a media processor capable of 720P HD Video for portable devices. This is the DMS-02, the first in the DMS range of products. 3Dlabs never spun completely out from Creative Labs, and was merged with a Creative product division and rebranded as ZiiLABS in January 2009.
                    Maybe their current products are based on former 3DLabs designs, like with PowerVR for example


                    Comment


                    • #20
                      I wasn't going to bother responding to this article or thread, but someone asked a question directly to me...

                      It's also exciting to see kernel mode-setting support being worked on for more hardware, but the Permedia 3/4 hardware comes as a bit surprising, if you even recognize the name. The Permedia 3 and Permedia 4 are products of 3Dlabs. These were low-end OpenGL-capable graphics cards that were offered by 3Dlabs prior to their acquisition by ATI. The 3Dlabs Permedia graphics cards that have been around for more than a decade are rightfully rare these days, but it's picking up kernel mode-setting support. The purpose of this GSoC project though is to document the KMS driver writing process rather than expecting this driver to have a useful life. Going with an older, simpler graphics processor should make it easier to implement a KMS driver over the course of a summer than a modern GPU that is much more advanced.
                      Beyond getting the part about 3DLabs being bought by ATI wrong, these cards were not low-end. Tell me what about a GVX420 (in 1999!) is low end? Its 128MB of RAM, its hardware T&L, or its two rasterizers?

                      Part of the project is for me to learn the internals of writing graphics drivers, this is the part I think we're missing.

                      And I'd like to see the driver have a useful life as well.

                      Originally posted by Alejandro Nova View Post
                      If you are going to write a KMS interface for Permedia, why don't you select another card even easier to write drivers for? I'm thinking about the best supported 3D hardware in Linux ever: the 3dfx Voodoo.
                      Best supported 3D hardware in Linux ever? The -voodoo DDX hasn't seen nontrivial changes in ages, and didn't they just kill the Mesa component because no one cared about it?

                      I don't know. The 3DLabs cards seem more interesting to me than Voodoos. Don't they only support up to 1024x768 at a decent color depth?

                      Comment

                      Working...
                      X