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

Thread: Kernel Mode-Setting Push For Linux 2.6.29 Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    15,650

    Default Kernel Mode-Setting Push For Linux 2.6.29 Kernel

    Phoronix: Kernel Mode-Setting Push For Linux 2.6.29 Kernel

    David Airlie has just called upon Linus Torvalds to pull the kernel mode-setting framework and Intel KMS driver support into the Linux 2.6.29 kernel. If you're a faithful Phoronix reader this shouldn't come as a surprise since Intel, Red Hat, and others have been busy hacking away at kernel mode-setting to get it ready to merge. The core kernel mode-setting code will now be in the next mainline kernel release along with the Intel i915 KMS driver, but the kernel must be built with the CONFIG_DRM_I915_KMS option since KMS isn't yet enabled by default...

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

  2. #2
    Join Date
    Apr 2007
    Location
    Salvador - Bahia - Brazil
    Posts
    79

    Default

    What are the real odds of ATI pulling GEM-like support within the next three months?

    I'm just asking for a educated guess.

    Thanks for reading.
    Last edited by hobbes; 12-29-2008 at 12:21 PM. Reason: typo

  3. #3
    Join Date
    Nov 2007
    Location
    Die trolls, die!
    Posts
    525

    Default

    What is the schedule now?
    Do radeon developers add changes to GEM, so that even radeon cards runs with GEM quite well and not only intel devices?

    And if they do so, what is with radeonhd? Can they use the (extended/adjusted) GEM as well as radeon?

    Thanks.

  4. #4
    Join Date
    Oct 2008
    Posts
    3,246

    Default

    I'm also curious about radeonhd support - is KMS something that can be easily ported between the two? It seems like most of the differences between radeon and radeonhd are in the hardware initialization, which I assume is what would go into the kernel. Are there any plans to just use the same code in the kernel, and if so would radeonhd just go away or are there other significant differences?

  5. #5
    Join Date
    Jul 2007
    Posts
    405

    Default

    There aren't really substantial differences, so when kms becomes mainstream, radeonhd will likely fade away.

    As for GEM support, neither radeon nor radeonhd makes real use of it yet (the only real use in the Xorg driver is for UXA acceleration, which hasn't been implemented for anything except intel yet). I'm not sure of the status of GEM support in Mesa, although I believe it is used for Intel, at least.

  6. #6
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    Default

    Quote Originally Posted by hobbes View Post
    What are the real odds of ATI pulling GEM-like support within the next three months?

    I'm just asking for a educated guess.

    Thanks for reading.
    It is about 3 to 7.

  7. #7
    Join Date
    Dec 2008
    Location
    Austria
    Posts
    31

    Default

    ...CONFIG_DRM_I915_KMS option since KMS isn't yet enabled by default
    Well, nice to see, that kms+intel finally seems to be ready. I'm tracking development for a few weeks now and repositories have been very busy, which is great to see.

    Hardware: GMA X4500, GM45.
    Software:
    • kernel: master + airlie's drm-next
    • mesa, drm: master
    • xorg: master
    • video-intel: master


    I got UXA running, but using "i915 modeset=1" produces a black screen at start of GDM and forces me to do a SysRq reboot. I can nevertheless report that the freezes using Compiz are finally gone with UXA.

    Edit: Btw, I build video-intel with the kms-switch.
    Last edited by AliBaba; 12-30-2008 at 06:39 AM.

  8. #8
    Join Date
    Dec 2007
    Posts
    248

    Default

    Quote Originally Posted by hobbes View Post
    What are the real odds of ATI pulling GEM-like support within the next three months?
    It would be quite dissapointing if kms/gem for radeon didn't make it into 2.6.30 ...

    It's 3 months to get there but it's half year for a stable kernel with it... Some people don't want to use/compile RCs. And kernel is quite crucial part of the system so it does make sense to not use RCs.

  9. #9
    Join Date
    Dec 2008
    Location
    Austria
    Posts
    31

    Default

    Quote Originally Posted by val-gaav View Post
    And kernel is quite crucial part of the system so it does make sense to not use RCs.
    Not exactly, no.

    Every distribution I know lets you install several kernels side-by-side enabling you to fall back to a working configuration. I use 2.6.27, 2.6.28-rc* (and now 2.6.28) the Debian way (make-kpkg) and I can remove or add any kernel I build easily.

    There's by the way not even a reason to not use RCs at all if you are not affected by a _very_ serious bug (e1000 :-). The difference between a kernel with drm-next pulled by Linus or one where I merge Dave Airlie's branch myself (and maybe get all bugfixes before they land in Linus' kernel) does not exist, imho.


    My three cents, btw...

  10. #10
    Join Date
    Dec 2007
    Posts
    248

    Default

    The e1000 bug was quite serious. I think that example proves my point. Sure you can have a stable kernel and a RC on the same distro, but the stable one will not fix the hardware that RC broke.

    That said distros don't usually package kernel RCs, and not everyone wants to compile his kernel and repeat the process with every new RC (2 week time), and some users may not want to compile their own kernel at all

Posting Permissions

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