No edit summary |
(added) |
||
| Line 15: | Line 15: | ||
=== Print interview === | === Print interview === | ||
* '''What is KMS? Can you give us a brief overview?''' </ | * '''What is KMS? Can you give us a brief overview?''' <br/> | ||
Sure. Kernel Mode Setting refers to the idea of moving low level display drivers into the kernel so that the kernel can set the display mode at boot. Traditionally, this has been reserved for the X server, which would set the display mode when it started up. However, having the X server do this causes problems in many cases, especially around areas like suspend/resume and with the development of new types of rendering mechanisms. The idea is to move this functionality into the kernel with an API that is accessible to the rendering engine so that the kernel will set the display mode at boot and the rendering engine can then interface with that to make any changes to the mode. It also now gives the kernel the ability to better manage memory for suspend/resume. This leaves the rendering mechanism to do what it was meant to do--render. | Sure. Kernel Mode Setting refers to the idea of moving low level display drivers into the kernel so that the kernel can set the display mode at boot. Traditionally, this has been reserved for the X server, which would set the display mode when it started up. However, having the X server do this causes problems in many cases, especially around areas like suspend/resume and with the development of new types of rendering mechanisms. The idea is to move this functionality into the kernel with an API that is accessible to the rendering engine so that the kernel will set the display mode at boot and the rendering engine can then interface with that to make any changes to the mode. It also now gives the kernel the ability to better manage memory for suspend/resume. This leaves the rendering mechanism to do what it was meant to do--render. | ||
* '''What are the benefits of this functionality and how will this improve the average users interaction with | * '''What are the benefits of this functionality and how will this improve the average users interaction with Fedora?''' <br/> | ||
There are a number of very important benefits to this functionality. The first one which most people will appreciate is probably the improved support for suspend/resume. Since the kernel is now in charge of managing that whole process, it should become much smoother. Users will also see much nicer boot screens using Plymouth now, due to the enhanced capabilities we can now tap due to intializing the display in the kernel. You will also notice alot if improvement in switching between VTs for the same reason. Lastly, anyone who cares about watching kernel oopses or panics (get it? this means you) will be able to have it printed out to the screen even under X. | |||
* This all stemmed out of work that started in Fedora 9. Can you give us a general overview of the path from then until now? | * '''You mentioned Plymouth. This all stemmed out of work that started in Fedora 9. Can you give us a general overview of the path from then until now?''' <br/> | ||
* This all came about very much as a result of coordinating with others upstream. Who were other people you worked with and how exciting was it working with them and the upstream in general? | |||
* There has been talk about creating a general panic screen now that its possible. Do you think we will ever have a blue screen of death on Fedora? | Absolutely. As you know we started working on Plymouth and sort of changing the way Fedora boots in general for Fedora 9. Alot of work at the time was done around improving the init scripts and that system and we also introduced Plymouth and kernel mode setting, which was only available for Intel based cards. For Fedora 10, we really wanted Plymouth to shine and an effort was spearheaded by Dave Airlie, to enabled this support by default for Intel cards and to extend it to include Radeon cards as well. Work has also been done by the Nouveau team to enable this for Nvidia cards as well. We have all been working together in the upstream, and those corporations which truly value open source have been contributing alot and that has been a tremendous help. So yes, we did start with Fedora 9, and once we saw that worked, we started pursuing it more aggressively and thats worked out well. | ||
* What are the plans for the future looking like? Is there a general roadmap you guys have? | |||
* What's the coolest functionality you think this could provide in the future? | * '''This all came about very much as a result of coordinating with others upstream. Who were other people you worked with and how exciting was it working with them and the upstream in general?''' <br/> | ||
* | |||
As I said before, those who value open source, such as Intel and ATi have been very helpful in committing code to the the upstream which helps up work on support for their hardware, and also have been very forthcoming with any help necessary. This is truly where open source shines, and we take advantage of this in Fedora every day. We are very deliberate to work with the upstream projects because not only does this make development for us easier, but it also ensures that this code and functionality will make its way to the greatest numbers of users who can benefit and contribute back to the open source circle. | |||
* '''There has been talk about creating a general panic screen now that its possible. Do you think we will ever have a blue screen of death on Fedora?''' <br/> | |||
I don't think so. Personally, I like the idea of a Red Screen of Death better. On the serious side, I mentioned before about printing kernel error messages to the screen even under X, so things like that become possible, but how thats implemented remains to be decided. | |||
* '''What are the plans for the future looking like? Is there a general roadmap you guys have?''' <br/> | |||
There are plans to continue working on this and to expand the number of cards which KMS will support--its a matter of getting the right drivers into the kernel. Also, alot of whats planned is expanding and solidying the API which the X server will interface with the kernel with and improved memory management. | |||
* '''What's the coolest functionality you think this could provide in the future?''' <br/> | |||
I think one day it will be possible for the kernel to set the display mode in such a way that it hypnotizes all those who watch the boot process and turns them into the slaves of the alien king Barabuton from N4561. So in short, Fedora in outer space. | |||
* '''What are you going to do after the F11 release is out? Go to DisneyWorld?''' <br/> | |||
Anything to get out of this bad weather! | |||
=== Audio interview === | === Audio interview === | ||
'''COMING SOON''' | |||
[[Category:Marketing]] [[Category:F11 in-depth features]] | [[Category:Marketing]] [[Category:F11 in-depth features]] | ||
Latest revision as of 13:49, 26 March 2009
| Date | Status report |
|---|---|
| 2009.03.26 | Updated print questions |
| Next action: Get answers to print questions, and set up for podcast. | |
Return to Category:F11 in-depth features page
Interviews
Print interview
- What is KMS? Can you give us a brief overview?
Sure. Kernel Mode Setting refers to the idea of moving low level display drivers into the kernel so that the kernel can set the display mode at boot. Traditionally, this has been reserved for the X server, which would set the display mode when it started up. However, having the X server do this causes problems in many cases, especially around areas like suspend/resume and with the development of new types of rendering mechanisms. The idea is to move this functionality into the kernel with an API that is accessible to the rendering engine so that the kernel will set the display mode at boot and the rendering engine can then interface with that to make any changes to the mode. It also now gives the kernel the ability to better manage memory for suspend/resume. This leaves the rendering mechanism to do what it was meant to do--render.
- What are the benefits of this functionality and how will this improve the average users interaction with Fedora?
There are a number of very important benefits to this functionality. The first one which most people will appreciate is probably the improved support for suspend/resume. Since the kernel is now in charge of managing that whole process, it should become much smoother. Users will also see much nicer boot screens using Plymouth now, due to the enhanced capabilities we can now tap due to intializing the display in the kernel. You will also notice alot if improvement in switching between VTs for the same reason. Lastly, anyone who cares about watching kernel oopses or panics (get it? this means you) will be able to have it printed out to the screen even under X.
- You mentioned Plymouth. This all stemmed out of work that started in Fedora 9. Can you give us a general overview of the path from then until now?
Absolutely. As you know we started working on Plymouth and sort of changing the way Fedora boots in general for Fedora 9. Alot of work at the time was done around improving the init scripts and that system and we also introduced Plymouth and kernel mode setting, which was only available for Intel based cards. For Fedora 10, we really wanted Plymouth to shine and an effort was spearheaded by Dave Airlie, to enabled this support by default for Intel cards and to extend it to include Radeon cards as well. Work has also been done by the Nouveau team to enable this for Nvidia cards as well. We have all been working together in the upstream, and those corporations which truly value open source have been contributing alot and that has been a tremendous help. So yes, we did start with Fedora 9, and once we saw that worked, we started pursuing it more aggressively and thats worked out well.
- This all came about very much as a result of coordinating with others upstream. Who were other people you worked with and how exciting was it working with them and the upstream in general?
As I said before, those who value open source, such as Intel and ATi have been very helpful in committing code to the the upstream which helps up work on support for their hardware, and also have been very forthcoming with any help necessary. This is truly where open source shines, and we take advantage of this in Fedora every day. We are very deliberate to work with the upstream projects because not only does this make development for us easier, but it also ensures that this code and functionality will make its way to the greatest numbers of users who can benefit and contribute back to the open source circle.
- There has been talk about creating a general panic screen now that its possible. Do you think we will ever have a blue screen of death on Fedora?
I don't think so. Personally, I like the idea of a Red Screen of Death better. On the serious side, I mentioned before about printing kernel error messages to the screen even under X, so things like that become possible, but how thats implemented remains to be decided.
- What are the plans for the future looking like? Is there a general roadmap you guys have?
There are plans to continue working on this and to expand the number of cards which KMS will support--its a matter of getting the right drivers into the kernel. Also, alot of whats planned is expanding and solidying the API which the X server will interface with the kernel with and improved memory management.
- What's the coolest functionality you think this could provide in the future?
I think one day it will be possible for the kernel to set the display mode in such a way that it hypnotizes all those who watch the boot process and turns them into the slaves of the alien king Barabuton from N4561. So in short, Fedora in outer space.
- What are you going to do after the F11 release is out? Go to DisneyWorld?
Anything to get out of this bad weather!
Audio interview
COMING SOON