Re: OpenGL-based framebuffer concepts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux