Announcement

Collapse
No announcement yet.

Ubuntu 10.04 May Backport More Kernel DRM

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

  • #21
    Originally posted by Kano View Post
    DRM is not the only interesting peace from .33 kernel. Samsung R780 laptops can only use wifi with .32, for the onboard marvell ethernet controller you need the sky2 driver of .33. So even with DRM backport U 10.04 will not support all generic hardware at the time of release - ethernet is usally really needed...
    Yeah, and those broken Wifi drivers in 2.6.31 and 2.6.32... because of change from ieee80211 to mac80211 stack which have fixes in 2.6.33.

    Comment


    • #22
      I would not call .33 an overall better kernel. I had issues even booting .33-rc8 on one of my systems. It just has some more interesting drivers. When you exchange the whole DRM stack it should not be that hard to do. The only problem i see is when you want to get security fixes in it. Then you have to track .32 AND .33 DRM. More likely that you will not get all. That's already now the case if you don't know it. U does not rebase after the first final of a kernel. They add extra SAUCE patches that often break stable relaese updates. So you can do serveral things: a) rebase on your own and fix the patches that are problematic, b) rebase and skip all problematic patches (that's what i did for 32-9 in Excalibur) or c) just leave the U source as it and hope all needed patches have been applied. Precompiled kernel do not interest me at all as i need some changes for extra hardware support, BFS and some extra backwards compatibility. Also U does not ship firewire headers which are required for complete external DVB updates (i.e. via dkms). I mentioned that a few times, but as it got not applied i got bored and only patched my kernel.

      Comment


      • #23
        what ever they choose will have to maintained for a long time. surely a close to vanilla kernel will make this easier.

        however greg kh has said that 2.6.32 will be a long term maintenance kernel (like 2.6.27). but that decision was based on the fact that big distros are planning to use it for big releases (eg ubuntu lucid).
        Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


        i thinks its a shame that closed source drivers might hold back new open source stuff getting to users.

        Comment


        • #24
          I don't get your point. Nv drivers already support .33 by default. ATI has more problems with xserver 1.7. For .33 you could patch it if needed.

          Comment


          • #25
            I think the real question here is going to be whether Lucid should be "the last UMS release" or "the first KMS release".

            If Lucid is going to focus on UMS (which AFAIK is *not the plan) then 2.6.32 should be OK, but if the plan is to go with KMS then pretty much all of the changes in 2.6.33 drm should be picked up, ie either a massive backport or pulling the whole drm.

            Support for UMS is starting to disappear from the drivers, which means that picking up new kernel drivers (or a *lot* of backporting) is going to be how new graphics hardware is enabled in the future -- and graphics hardware changes more quickly than most other devices.
            Test signature

            Comment


            • #26
              kms is suboptimal when you want to change from radeon to fglrx. I dont need kms anyway...

              Comment


              • #27
                Using KMS or UMS isn't a Problem at all. You can just disable it with a boot-parameter.

                Comment


                • #28
                  Or you compile the kernel default that way you want it

                  Comment


                  • #29
                    FWIW, I am running Lucid with the mainline kernel 2.6.33 , Radeon HD 3450

                    For KMS to work you need to get some firmware files manually, but even so, you get less performance than with UMS. Roughly speaking:

                    * Open source stack is 3 to 5 times slower than catalyst in karmic in 3D, and comparable in 2D.
                    * Open source stack with kernel 2.6.32 + UMS is very similar than 2.6.33-mainline + KMS
                    * Open source stack with kernel 2.6.32 + KMS is 25% faster.

                    Comment


                    • #30
                      Originally posted by mendieta View Post
                      FWIW, I am running Lucid with the mainline kernel 2.6.33 , Radeon HD 3450

                      For KMS to work you need to get some firmware files manually, but even so, you get less performance than with UMS. Roughly speaking:

                      * Open source stack is 3 to 5 times slower than catalyst in karmic in 3D, and comparable in 2D.
                      * Open source stack with kernel 2.6.32 + UMS is very similar than 2.6.33-mainline + KMS
                      * Open source stack with kernel 2.6.32 + KMS is 25% faster.
                      I am running Karmic with mainline kernel 2.6.32.8, Radeon HD 3650. And I upgrade all the package from xorg-edgers PPA. X server is 1.6.5, Mesa is 7.8-devel.

                      * Open source stack with kernel 2.6.32 + KMS works, but 3D acceleration is not workable. I start compiz, then the screen turns white.

                      * Open source with kernel 2.6.32 + UMS runs so faster than kernel 2.6.32.7 + KMS in Fedora 12. 3D is OK, But it is buggy.

                      Comment

                      Working...
                      X