I may have read your earlier questions as "will we do it", which I'm not able to answer. Questions about "is it possible ?", on the other hand, I *can* answer
AFAIK the code is either MIT/X11 or dual licensed, so that shouldn't be a problem. I guess it's possible that the kernel devs could band together and declare the API as "GPL only" but I don't think that is likely to happen.
We already have a good memory manager, so the most we would use from GEM is any API subset we needed to expose in order to let another kernel driver make use of a KMS-managed frame buffer. We would also need to expose the appropriate KMS API bits as you say.
I think the goal would be to use the existing framebuffer drivers; we could replace them as an alternative to exposing the GEM/KMS API bits but I don't think we would want to go that route.
The actual modesetting code would probably stay closed-source as it is today, not to protect the register info but to protect some of the proprietary software.
All that said, it's not clear whether implementing KMS in the fglrx driver is the right thing to do, or whether the endgame for professional graphics is more likely to move modesetting out of the X/DRI stack completely into a separate hypervisor. In that case we would probably just make the fglrx driver hypervisor-aware and hook modesetting that way rather than going with the current KMS approach.
For clarity, I still think KMS is absolutely the right direction for the open source drivers, and there's a good chance we will need to provide something similar in fglrx. I'm just not sure whether KMS would be the "next step" for fglrx.
AFAIK the code is either MIT/X11 or dual licensed, so that shouldn't be a problem. I guess it's possible that the kernel devs could band together and declare the API as "GPL only" but I don't think that is likely to happen.
We already have a good memory manager, so the most we would use from GEM is any API subset we needed to expose in order to let another kernel driver make use of a KMS-managed frame buffer. We would also need to expose the appropriate KMS API bits as you say.
I think the goal would be to use the existing framebuffer drivers; we could replace them as an alternative to exposing the GEM/KMS API bits but I don't think we would want to go that route.
The actual modesetting code would probably stay closed-source as it is today, not to protect the register info but to protect some of the proprietary software.
All that said, it's not clear whether implementing KMS in the fglrx driver is the right thing to do, or whether the endgame for professional graphics is more likely to move modesetting out of the X/DRI stack completely into a separate hypervisor. In that case we would probably just make the fglrx driver hypervisor-aware and hook modesetting that way rather than going with the current KMS approach.
For clarity, I still think KMS is absolutely the right direction for the open source drivers, and there's a good chance we will need to provide something similar in fglrx. I'm just not sure whether KMS would be the "next step" for fglrx.
Comment