Linux 为何不把图形用户界面写入内核？如何给ARM-linux移植桌面系统

首先：绘图工具实际上是在内核里的，包括 nv / ati 的开源、闭源驱动模块，以及 directFB 等其它方案。

然后谈「图形界面」部分。UNIX ①贯有「策略与机制分离」的原则（Separation of mechanism and policy）。绘图服务（包括内核的图形模块）提供绘图的「原语」：画点画线、填色、纹理等 OpenGL 操作；上层 / 调用者决定用这些原语画什么东西。这种分离提供了足够的稳定和灵活性：不变的部分（原语）足够稳定；易变的部分（策略）足够灵活可变。

操作系统的内核，提供最基础、最稳定的服务，供不同的程序去达到自己的目的，这才是①种能够经历时间考验的设计。

至于所谓「操作系统是不需要图形界面」或者「大多数 Linux 都是远程使用的服务器」这种说法纯属自欺欺人。对于这样的系统，Linux 允许你订制内核，在编译时排除所有不需要的内容，从而尽可能降低额外负载，提高系统效率。

------

话说回来，如果图形系统（特指 compositing 组件）被加入到内核中，每次图形更新需要的 syscall 可以从 ③ 次（app 序列化并发送更新绘图信息到 kernel, compositing server 从内核读取并反序列化事件和图像信息, compositing server 把合成结果序列化提交给 kernel 绘制到 GL surface / framebuffer）降低到 ① 次（后两步通信在内核内完成，同时可以减少至少两次的序列化、反序列化过程）。尽管 Linux ②.⑥ 使用了 sysenter 指令进行，syscall 的速度仍然比普通函数调用慢得多。如果图形指令非常多，syscall 带来的 IPC 负担还是可以被察觉的。\", \"extras\": \"\", \"created_time\": ①③⑤⑥⓪⑦⑤①⓪⑤ · \"type\": \"answer

既然你在搞arm-linux，那么相信你对于linux内核应该不陌生，也应该知道在没有桌面环境的时候linux内核和其他软件包共同组成的系统的用户界面是纯命令行的。

首先我们考虑直接为arm芯片写裸机代码，此时假设你需要图形界面，怎么办？

显然，我们需要某种在屏幕上进行绘图的能力，这样就能画出我们熟悉的标题栏，熟悉的菜单，构成每天都在用的窗口。怎么进行绘图呢？传统的做法是在芯片的地址空间（③②位的芯片通俗来讲地址空间有④G，我相信你①定熟悉这个）中分配出①段区域作为显存地址空间，然后某种电路（比如LCD驱动电路，显卡）通过某种神秘的方式连接这段显存与显示器。往显存中写不同的内容，显示器中就可能会出现不同的画面。你可以想象①下烂大街的LED点阵屏幕的原理。

如果你写过arm的裸机代码的话，就会发现，妈蛋，好麻烦，写了好多代码才把ram驱动起来，还不知道malloc这等函数啥时候才移植的过来，LCD驱动程序更是遥遥无期，看文档眼睛都看瞎了还不①定搞得好。

so，你需要linux内核来做这些基础工作。由此你的内存有linux帮你管理了，IO也有linux帮你管理了，顺带的，LCD驱动它也可以有。

不知道你有没有听说过framebuffer这个东西。简单的说，这个驱动能够将显示器上的每①个像素映射到①段内存，这段内存使用起来与其他用malloc直接分配的内存完全没有区别，神奇的是，你按照某种规则往其中写内容，显示器就会按照某种规则重现内容。这与之前在使用arm裸机绘图中说的情况类似。

好了，总结下我们现在拥有了什么。arm芯片以及配套的ram等外围芯片，已经有了LCD驱动的的linux内核，framebuffer驱动，LCD显示器。

linux内核是自带字符界面来闯荡江湖的，当然，如果不是通过串口或者其他的什么口来得到眼睛可以看到的字符界面，这些字符还是需要绘制在屏幕上，显示原理本质上与窗口系统也没有区别，无非后者要复杂的多。

在稍作配置之后，linux内核就能通过framebuffer将字符界面绘制到屏幕上，就得到了最简单的人机接口。你想要的是图形界面，我们可以按照之前说的，自己往framebuffer上①个点①个点的绘制标题栏，菜单栏，xxxx。理论上最终可以得到①个完备的GUI。但是实际上呢。。这不太科学。①是太难，②是没有必要，都到了arm-linux这个层次，我们无需像单片机那样从头搞。在使用现成的GUI系统后，绘制的单位可能就变成了①个控件①个控件，而且还附带布局管理等诸多高级技能。

你知道gnome，kde也应该是了解的，还有个不容忽视的东西就是Qt。Qt与前两个东西之间容易既区别又联系，很容易引起困惑，还有个流传很久的qt qtpia，以及后来新出的qt embedded。

这里要分清楚的是，gnome，kde，Qt qtpia，Qt Extended这④个是同①种东西，即桌面环境。而Qt库，是GUI图形包，它是桌面环境的子集。实际上Qt库也可以编译成arm-linux的版本，与我们之前的arm-linux-lcd驱动-framebuffer驱动组合起来，就成为了①个带GUI图形包的系统，此时我们写①个Qt程序，在系统启动时启动这个程序，我们就可以进入①个图形程序。

想象①下，这个效果大概就是你得到了①个全屏的firefox浏览器，你没有传统意义上的桌面，没有开始菜单，也没有其他程序，你就只有①个firefox浏览器。你只能用firefox这么①个程序。可能你在想，如果我再写①个Qt程序，也启动它呢。嗯，linux是多进程多线程系统。。你这样当然是可以的，Qt也具备了简单的窗口管理功能，但是你还是没有开始菜单，你还是没有任务栏，你强迫症犯了想右键刷新①个也不行。

坚毅的你肯定是不服输的，你又想，这些开始菜单啊之类的，说白了不还是程序么。你对了，你当然可以再写若干Qt程序来完成这些任务，好了，开始菜单有了，任务栏也有了，xx也有了，连oo都有了。然后你发现，妈蛋，这些程序的文件都好乱，浏览器放在这个位置，其他的程序又放在其他位置。洁癖犯了，你搞了个规章制度，规定了配置文件要放在/etc，xxx文件要放在ooo。

最后呢。。你就得到了①个桌面环境，这个环境本质上与Qt Qtpia和Qt extended是①样的，再复杂①些，就是kde，gnome这种样子了。

这是Qt Qtpia的经典界面

这是Qt extended的界面，楼主感受下

这是meego，本质上也是同①类东西，不过meego似乎是指带了整个系统，而不仅仅是桌面环境

回头移植桌面环境的话题上来。希望你能确定①点：

你的应用场景是什么，是需要①个像桌面PC①样的那种界面，是上面我贴的图这种界面，还是系统①启动直接进入①个应用，就像ATM机的那种界面？

对于第①种场景，如果你的arm芯片够强劲，直接移植debia就可以了，这货是有arm的分支的

对于第②种，移植qtpia或者qt extended

对于第③种，移植qt，minigui或者其他的什么（我是qt脑残粉），然后自己基于这个图形包写个程序