Announcement

Collapse
No announcement yet.

Proposals To Split KMS & GPU Drivers, 2D Kernel API

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

  • phoronix
    started a topic Proposals To Split KMS & GPU Drivers, 2D Kernel API

    Proposals To Split KMS & GPU Drivers, 2D Kernel API

    Phoronix: Proposals To Split KMS & GPU Drivers, 2D Kernel API

    Following a "Kernel Display and Video API Consolidation" mini-summit held at the Emebedded Linux Conference (ELC 2012) last week, Linaro and other mobile/embedded Linux stakeholders have come up with several graphics-related action items for the Linux kernel. One of the proposals is to split KMS and GPU drivers in the kernel...

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

  • siride
    replied
    Originally posted by airlied View Post
    sorry I missed the bit where you paid me for the software you feel so entitled to.

    Dave.
    And I've, for years, missed the part where there's no longer an expectation that software should work.

    In any case, I mostly use Windows now. Both problems solved.

    Leave a comment:


  • Prescience500
    replied
    If the KMS drivers are separated from the graphics drivers, couldn't the same KMS driver be used by both the open source and the closed drivers? If so, Companies like AMD, NVIDIA, etc. might all provide KMS drivers so that the graphics driver devs don't have to. This would free up time and resources for additional graphics driver development. Wouldn't this be a great thing? (Assuming my the answer to the first question is a yes, of course.)

    Leave a comment:


  • airlied
    replied
    Originally posted by siride View Post
    Some people want to get work done and don't want to spend 45 minutes a day using two machines and SSH to debug someone else's broken code. The OS community has shown that it's unable to field a reasonable team of graphics driver developers, so now it's up to the users to do the work. That might fly among the hobbiests (I've done my share), but it's not really a good way to run a software project.
    sorry I missed the bit where you paid me for the software you feel so entitled to.

    Dave.

    Leave a comment:


  • siride
    replied
    Originally posted by asdx
    When you get a crash you should try to SSH into the affected machine and run dmesg, get all the logs you can and file a bug.

    But make sure you have sshd in the affected machine.
    Some people want to get work done and don't want to spend 45 minutes a day using two machines and SSH to debug someone else's broken code. The OS community has shown that it's unable to field a reasonable team of graphics driver developers, so now it's up to the users to do the work. That might fly among the hobbiests (I've done my share), but it's not really a good way to run a software project.

    Leave a comment:


  • b3nn0
    replied
    1: It crasehs before networking is even up
    2: I already reported a bug and included as much information as possible including a demonstration video. Nobody in the freedesktop bugzilla seems to care however.

    Leave a comment:


  • hal2k1
    replied
    Originally posted by faustop View Post
    Companies have stated in the past that they wouldn't be able to opensource their drivers even if they wanted because they contain code/technologies liscenced from other companies and not belonging to themselves.
    This is the precise reason why we do NOT want to run binary blobs from AMD or Nvidia.

    Originally posted by faustop View Post
    That is one of the reasons AMD started a new driver from scratch when they decided they needed an open source driver a few years back.
    Nitpick: AMD did not start a new driver, they merely published programming specs. Here they are:

    http://www.x.org/docs/AMD/

    The Radeon open source driver is code written from information (facts documented in the above programming spec) by community effort (including some input from AMD employees) and hosted at Xorg. This code belongs to the community, the community holds the copyright, not AMD. In this respect this open source driver is not like the Intel open source driver. The Intel open source driver is written by Intel, owned by Intel, the copyrights are held by Intel. The equivalent scenario is NOT the case for the Radeon open source driver, this driver does NOT belong to AMD/ATI.

    Hence, code/technologies liscenced from other companies have no impact at all on the Radeon open source driver.

    This is a very, very important point in the context outlined in the first statement from you quoted above.
    Last edited by hal2k1; 02-24-2012, 07:54 AM.

    Leave a comment:


  • faustop
    replied
    Originally posted by hal2k1 View Post
    The only way that one can have a KMS driver is to include it as a part of the kernel itself. Hence the module must be GPL licensed. Hence it canot be a closed source blob.
    Yes, but this opens the great possibility of companies like AMD and Nvidia modifying their binary blob driver to be only a GPU driver while using the same GPL KMS driver as the opensource drivers. This would be possible and desired because:
    • The KMS code could became more stable/mature, gainigng more users and developers
    • Companies would be able to keep their precious GPU code* closed, while sharing work with the community on the more basic mode setting code;


    * Companies have stated in the past that they wouldn't be able to opensource their drivers even if they wanted because they contain code/technologies liscenced from other companies and not belonging to themselves. That is one of the reasons AMD started a new driver from scratch when they decided they needed an open source driver a few years back.

    Leave a comment:


  • Nille
    replied
    And why are on my System i have kms as Modules? And why i see the first output not with my nativ resolution and why he switch after loading the modules?

    Leave a comment:


  • hal2k1
    replied
    Originally posted by b3nn0 View Post
    Would this also allow to implement KMS in closed source drivers?

    Anyway, I always wondered how it could be "impossible" to implement KMS in the proprietary drivers. Maybe someone can help me with that.

    Shouldn't it always be possible to implement KMS as a thin wrapper around a closed-source shared library? Why should it be impossible to implement this in closed source drivers? I really can't imagine a way how this is possible...
    (Note: I have never looked at KMS code or something like that. I tried to, but diddn't understand to much of it, as I'm not a driver developer).
    AFAIK, KMS is Kernel ModeSetting. The video mode is set when the kernel first loads and runs. Hence the KMS driver has to be an actual part of the kernel, it cannot be a loadable module which the kernel only loads later.

    Closed source drivers are bunary blobs which are wrapped in an open source wrapper and loaded after the kernel has started as a kernel loadable module. Too late for KMS.

    The only way that one can have a KMS driver is to include it as a part of the kernel itself. Hence the module must be GPL licensed. Hence it canot be a closed source blob.

    Leave a comment:

Working...
X