Re: OpenGL-based framebuffer concepts

[Dave Airlie]

> >
> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/