关于图形部分的一点想法，欢迎大家和我讨论

kakuyou

有的文档里提到linux的内核是对console的输入提供抢先的，而X却不行，我想，这是因为consloe被编译到内核里而X是作为普通用户程序运行的缘故。
好像这两个东西各有一套图形驱动，code page，键盘映射，和鼠标驱动，当然Xfree86也可以使用console的driver。
我觉得现在之所以linux对最终用户是不友好的一个原因就是它不像windows有一个真正的图形核心子部件。我的意思不是说图形子部件是核心必须的，但应该也可以作为可选的编译选项，作为核心标准化的东西，就不用再有xfree86这么笨拙而吞噬资源的设计，只要实现一个X指令解释器就可以了，各种driver也可以统一到一种设计下。
我的这种想法另外还是基于以下的考虑，一个没有图形卡的机器实在想不出来鼠标，键盘等人工输入设备还有什么用，也就是说，显示设备和人工输入设备要么都有要摸都没有，所以kernel里有输入输出设备驱动和Xfree86也有输入输出设备驱动纯粹是个设计的失败。

Dragonfly

no idea about xfree86. i used it long long time ago and at that time i am very stupid. so ...

AndrewSiyer

有道理的，不过这样一来就会走M$的路了

Dragonfly

which road is not important, the best is to do best but not to be greedy.

超级用户

“xfree86这么笨拙而吞噬资源的设计”

哈哈，你把MIT做出来的西西骂了个爽。

这样设计的符合C/S模型。

_z_

可不可以这样设计：
对于本地用户登录后，可以把X连接到内核？？做成module？？

这想法是不是够stupid的？

Dragonfly

c/s model allow xserver support diskless workstation, remote desktop easier. but for local performance, it do has some problems.

i do not know the structure of x, so i haev no idea about whether can connect it to kernel or now.

kakuyou

>_<!   XFree86并不是MIT做的，X协议是MIT制定的，windows的消息机制应该是参照的X协议的设计（X协议的历史比windows api的历史长），两者的编程方法，包括API都非常像，本质上也是C/S结构。

XFree86慢的原因是因为以下因素
1。X本身设计上的因素
X的消息是不定长的，解释器要做额外的工作进行校验，解释。数据在客户端和服务器端是隔离的，即使运行在local也要进行流拷贝。相反windows的消息就全部是等长的，解释起来很简单。
2。Unx本身的问题
在做交互时，由于X是运行在普通用户模式下，即使一次简单的交互也不得不等待时间片。
3。Xfree86本身的问题
传说Xfree86的编程水平很一般，与IBM，SUN等商业产品相比相距较远，特别是一些硬件驱动上。

我的想法简单的说就是在内核级没有一个真正的图形子系统，那只能指望硬件来加速X了，sign

Dragonfly

kakuyou, u looks know so much.

memcpy and context switch are problems in current cpu. but i am not sure about xfree86 code skill. i am not a good programmer, so i dare not to evaluate other guy.

netdigger

微软的东西也并不是不好啊，只要是好的，哪怕拿过来用，也没有什么问题的。

Dragonfly

yes, but kernel is a complex place. i think kernel should be better before considering add graphic part.

ffxz

最近正在考虑这个问题，并慢慢写了一些代码，希望能够出一套比较完整的窗口系统。如果哪位感兴趣，可以一起交流交流。

以下是我的一些大致思路(on linux)，
前期完成的是一个小型窗口系统（及基本的绘图操作），包含了
(这个小型窗口系统，相当于X中的Server，采用多线程实现必要的事件处理)
- 底层硬件驱动。(VESA on linux，因为VESA比较通用，所以先用这个做Driver)
- 基本绘图操作
- 层管理、操作，每一个窗口都包含一个最基本的层，其他的控件在这个层上叠加
- 字体（文本）显示，位图显示，rect基本操作（绘制，复制）
- 基本窗口由：window和border组成
- 引入基本的wm theme，负责实现不同的窗口管理主题（仅仅是窗口，还并不是菜单、工具栏、按钮）；采用plug-in的方式动态载入（如果载入有错，很可能整个窗口崩溃，如果这个server完全在内核中，可能内核崩溃^-^）
- 消息驱动（未定。关于windows定长的消息格式，能否再多提供些信息？Thanks）
- 基本控件（button，menu，checkbox等）直接引入到小型窗口系统中（？）
- 输入法接口

以上大致是这个小型窗口系统的结构。但一些算法现在还不是太清楚，努力的thinking中……
第二步，添加client Applications的API，最有可能的是，引入整套Gtk+，把其中的GDK部分重新实现。这个时候，client和server之间的通信将是关键。
- 基本不可能再走X的老路线，用TCP socket or Unix socket方式。
- 如果这个小型图形系统完全放到内核中，做为一个module，那么这个module将提供额外的linux 系统调用，以支持两者的通信。
- 如果这个小型图形系统放在用户态，
     - 传统的socket方式
     - 仍然添加一个module来提供额外的通信机制。

等第二步完成时，它应该是一个和X11不兼容，但和Gtk+ API大部分兼容的窗口系统。

Others, please not look this as a full features window system, window system for embedded is better.

Dragonfly

interesting, maybe good for embedded linux.

but i have no idea on windows, ui part. i prefer to read i/o, fs part code.