On 6/1/06, Dave Airlie <airlied@xxxxxxxxx> wrote:of course, but that doesn't mean it can't re-use X's code, they are the best drivers we have. you forget everytime that the kernel fbdev drivers aren't even close, I mean not by a long long way apart from maybe radeon.
I am aware that X has the best mode setting code and it would be foolish to ignore it.
9) there needs to be a way to control the mode on each head, merged fb should also work. Monitor hotplug should work. Video card hot plug should work. These should all work for console and the display servers.
Of course, have you got drivers for these written? this is mostly in the realms of the driver developer, the modesetting API is going to have to deal with all these concepts.
This needs to be considered in the design stage. For example, if both heads are mapped through a single device node they can't be independently controlled by two different user IDs. We need to make sure we leave the path open to building this.
I meant support for Korean, Chinese, etc. You can't draw some of the complex scripts without using something like Pango. Do we want to build a system where people can use console in their native language? You can use these languages from xterm but not console today. I have no strong opinion on this point other that I believe it should be discussed and input from non-English speakers should be considered. No one on this list has a problem with this area since we all speak English.
14) backwards compatible, an old X server should still run on a new kernel. I will allow for new options to be enabled at run-time so that this isn't possible, but just booting a kernel and starting X should work.
I'm not sure we want to continue supporting every X server released in the last 25 years. But we should definitely support any X server released in a 2.6 based kernel distribution. What are reasonable limits?
16) secure - no direct IO or MMIO access, modesetting is slow anyways having the kernel checking the mmio access won't make it much slower.
This needs some expansion. Secure is good, but it's not clear what you are requiring with this point.
For me security means reducing the privileged code to an absolute minimum and then inspecting it closely to make sure there are no holes. Everything that is passed in needs to be checked and regarded with suspicion. But you can go too far with the reduction, if you provide a generic IOCTL to poke an IO port with an arbitrary value you now have to verify that it is safe to pass in every possible value. Instead if the IOCTL implements a specific function that pokes the port with a single fixed value it is easier to say that it is secure.