Messages in this thread | | | Date | Fri, 2 Jun 2006 12:45:54 +1000 | From | "Dave Airlie" <> | Subject | Re: OpenGL-based framebuffer concepts |
| |
> > > > not really necessary.. nor should it be... fbset works, something like > > it would be good enough.. > > 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.
Sorry misinterpreted, a userspace console would be possible now, if someone implements it we can use it, but I'm not sure a freetype accelrated console is necessary for us to do everything else.
> > 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?
Yes at least a 2.6 distro based X should always work, I'm sure 2.4 DRM doesn't work with new X in a lot of cases anyways as no-one tested it at the time and it just got broken...
> > 15) re-use as much of the X drivers as possible, otherwise it will KGI. > > I would broaden this to use the best code where ever it is found. Of > course X is a major source.
I'm not considering using knowledge from X drivers, I'm considering using the X drivers, I don't personally care about things like X's over use of typedefs and that sort of stuff, that is what I term semantic, people who work on X drivers know X drivers, and writing the drivers is the biggest part of any graphic systems.
> > 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.
I'm talking the recent secure thread that came from OpenBSD, we should have no unchecked access to the I/O ports from userspace, even for root or special graphics processes, MMIO needs to be mapped R/O to userspace and accessed via either real DMA or pseudo-DMA mechanism in the kernel. I don't think putting modesetting into the kernel is sufficent to fix all needed uses for MMIO so I'd rather add a checking mechanism ala what the DRM does now.
Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |