Zed 目前支持 zedrem 和 zedd 这两种远程编辑方式，下面分别介绍一下另，另外也说明了如何使用 Zed 自带的 Web Server。

zedrem 远程编辑

zedrem 是用 Go 语言编写的工具，按照 Zed 官网的介绍一条命令就可以安装成功，默认情况下在 VPS 上运行 zedrem 命令之后会自动连接 Zed 服务器注册并返回远程编辑地址，Chrome 应用后续的列举文件、打开文件、保存等操作都会通过 Zed 服务器进行中转，这样可以直接绕过防火墙之类的限制。

zedrem 的使用也非常简单，在 VPS 上运行 zedrem 跟上需要编辑的目录路径（不加目录参数则是直接编辑当前目录）：

root@zoserver:~# ./zedrem wiki-dir
In the Zed application copy and paste following URL to edit:

https://remote.zedapp.org:443/fs/c1e91639eede09e0be43a4cf3f22d036

Press Ctrl-c to quit.

看到上面 zedrem 命令给出的地址之后，就可以在 Zed App 的 选择项目 界面中选 Remote Folder，在出来的 Open Zedrem Folder 界面中直接输入上面的地址并点击 Open 就可以远程编辑 VPS 上的目录了。

如果你对 zedrem 默认通过 Zed 服务器进行中转的工作机制不放心的话，也可以让 Zed Chrome 应用与 VPS 服务器直接连接，首先在 VPS 上让 zedrem 作为转发服务器运行：

root@zoserver:~# ./zedrem --server
Zedrem server now running on ws://0.0.0.0:7337

然后另开一个终端再运行 zedrem 命令并增加 -u 参数指定转发服务器地址，这里可以直接填 VPS 服务器的 IP 地址或者域名：

root@zoserver:~# ./zedrem -u ws://xxx.xxx.xxx.xxx:7337 wiki-dir
In the Zed application copy and paste following URL to edit:

http://xxx.xxx.xxx.xxx:7337/fs/7d6f781a002875f0a9fb57e095f3ddec

Press Ctrl-c to quit.

刚才运行 zedrem 转发服务器的终端上也会显示新的客户端已经连接：

Client 7d6f781a002875f0a9fb57e095f3ddec connected

同样 Zed Chrome 应用也只需要输入上面 zedrem 命令给出的地址就可以进行远程编辑操作了，实际使用中也可以直接把 zedrem 的转发服务器模式放在后台运行的。

当然如果你的 Chromebook 和 VPS 的连接速度比较慢（比如在移动宽带网络下连接我的美国 VPS 可能就会比较慢），也可以在别的主机（例如使用另一台香港 VPS）上运行 zedrem 的转发服务器，并通过 -u 参数指定通过新的主机进行转发，这样也可以加快远程编辑的响应速度。

zedd 远程编辑

VPS 上安装 zedd

一般使用 zedrem 就能满足普通用户的基本远程编辑需求了，但如果你想实现远程编辑文件之后运行特定的命令等高级的需求（例如我修改的 MDwiki 系统在新增 Wiki 项目之后需要运行命令生成刷新 Wiki 目录文件），zedrem 对这种情况就无能无力了。

不过还好 Zed 也为我们提供了 Zedd 后台程序，Zedd 支持远程执行命令，而且导出远程文件系统的方式也更加高效，Zedd 远程目录也可以在 Chrome 应用的历史项目中直接显示，比较适合 Chromebook 用户。

Zedd 程序是用 Node.js 编写的，安装步骤相对 zedrem 会稍微复杂一点，其详细说明也可以参考 Zed 官方网站，首先 VPS 上需要安装 Node.js 环境，我的 VPS 使用的是 Debian 7 系统，可以通过下面的命令安装（假设你有 VPS 的 root 访问权限，同时也会自动安装必需的 Node.js 的 npm 包管理工具）：

root@zoserver:~# curl -sL https://deb.nodesource.com/setup_4.x | bash -
root@zoserver:~# apt-get install -y nodejs

安装完成之后就可以通过 npm 命令安装 Zedd 程序：

root@zoserver:~# npm install -g zedd

使用 zedd

Zedd 安装好之后可以先看看其运行帮助信息：

root@zoserver:~# zedd --help
Zedd is the Zed daemon used to edit files either locally or remotely using Zed.
Options can be passed in either as environment variables, JSON config in
~/.zeddrc or as command line arguments prefixed with '--':

   user:       username to use for authentication (default: none)
   pass:       password to use for authentication (default: none)
   remote:     bind to 0.0.0.0, requires auth, and disables
               enable-run by default
   port:       port to bind to (default: 7337)
   root:       root directory to expose (default: $HOME)
   enable-run: enable running of external programs in remote mode
   tls-key:    path to TLS key file (enables https)
   tls-cert:   path to TLS certificate file (enables https)

默认如果运行 zedd 程序不加任何参数会导出用户的主目录，而且默认也只有 localhost 本地才能访问，导出地址为：

http://127.0.0.1:7337/

当然对于我们要在 Chromebook 上远程编辑 VPS 上的文件就不能这么做了，根据情况可以在 VPS 服务器上运行 zedd 程序时：

• 增加 --remote 参数可以支持外部连接；
• 增加 --root 参数指定导出的根目录（默认为 $HOME 用户主目录）；
• 增加 --enable-run 参数可以允许执行外部命令；
• 另外可以指定 --user 和 --pass 参数配置访问的用户名和密码。

提示

为了 VPS 上文件的安全性考虑，如果你有可用的 SSL 证书的话建议使用 --tls-key 和 --tls-cert 参数，这样可以使用 https 模式替代默认的 http 模式。

例如我的 VPS 上可以这样运行 zedd 程序：

root@zoserver:~# zedd --remote --enable-run --root wiki-dir --user zeduser --pass zedpass
Zedd is now listening on http://0.0.0.0:7337
Exposed filesystem : /home/root/wiki-dir
Mode               : remote (externally accessible)
Command execution  : enabled
Authentication     : enabled

Chromebook 上要使用 Zedd 远程文件夹也比较简单，在选择项目界面中点击 Zedd Folder 进入 Open Zedd Folder 界面，该界面中就可以输入远程 Zedd 导出地址和用户名、密码：

确认之后点击 Connect 按钮连接正常的话就可以看到远程的目录树，接着就可以任意选择下面的子目录进行编辑了。

zedd 的外部命令支持

对于打开的远程 Zedd 文件夹，Zed Chrome 应用是支持运行外部命令的，首先使用 Zed 命令快捷键（默认为 Ctrl-Shift-.，我的 Chromebook 上改成了 Ctrl-Shift-C）或者点击 Tools -> Run Command 菜单项，在弹出的 Enter command 中输入 external，Zed 会自动搜索，默认匹配到的两个就是远程执行外部命令用的：

一般使用第一个 Tools:External:Insert Command Output 命令，选择该命令会让你输入需要在 VPS 主机上执行的命令及参数，并将远程命令的执行结果插入到当前所打开文件的光标位置。

如果你想要执行的命令有输出又担心影响正在打开的文件（Zed 是编辑区内容有改动就实时保存的），那可以直接打开 Zed 保留的 zed::start 只读文件并执行 Insert Command Output 操作，这样既可以看到远程命令的输出结果又不会改动其它文件的内容。

例如我打开远程 MDwiki 目录之后进行编辑之后需要进行刷新 Wiki 目录文件的操作，这就需要执行我写的 generate-index.sh 脚本。我就可以切换到 zed::start 文件并执行 generate-index.sh 远程命令并查看输出结果。当然如果你不关心输出结果，也可以不管当前打开的是什么文件，直接执行命令并附加 >/dev/null 以忽略输出：

这样配置之后我就能实现不经远程登录或同步 VPS 就能直接远程编辑 MDwiki 知识库的需求了，而且编辑完成之后直接在 Chromebook 上执行外部命令就能更新 Wiki 目录。

使用 Zed 自带 Web Server

由于我的 VPS 上的 MDwiki 目录同时也开启了 BTSync 同步，需要时也可以将远程的 Wiki 目录同步到本地，同步到 Chromebook 之后也可以使用 Zed 自带的 Web Server 功能本地查看 MDwiki 知识库。

Zed 打开 MDwiki 目录之后同样使用命令快捷键运行命令，输入 static server 进行搜索，就会匹配 Zed 自带 Web Server 的几个命令：

• Tools:Static Server:Stop
• Tools:Static Server:Start
• Tools:Static Server:Generate Full Site

选择第二个 Tools:Static Server:Start 命令启动 Zed 自带静态 Web Server，Zed 会自动打开新 Chrome 标签页显示 MDwiki 知识库，如果当前打开的项目目录下没有 index.html 或者 default.html 等文件则会自动显示文件列表。不再需要查看 Wiki 知识库时选择 Tools:Static Server:Stop 命令停止 Web Server 即可。

不过我在使用 Zed 自带 Web Server 时发现其存在不支持中文等非 ANSI 路径名以及包含特殊符号的文件名的问题，默认的文件列表页显示中文文件名同样不正确，因此我检出了 Zed 官方的 staticserver 包进行了修正，并在 GitHub 上新创建了一个仓库：

https://github.com/zohead/staticserver

测试完成之后我也为官方 staticserver 仓库创建了新的 Pull Request，只是目前还没有得到回应。

有使用 Zed 自带 Web Server 需求的朋友可以检出上面我的 staticserver 代码，并替换到 Zed Chrome 应用的 staticserver 包路径：

~/Extensions/pfmjnmeipppmcebplngmhfkleiinphhp/1.1.0_0/config/packages/gh/zedapp/staticserver

替换之后重新启动 Zed 应用再运行启动 Web Server 的命令应该就可以解决不能正常访问中文路径的问题了。

对于很多 Chromebook 用户来说，缺少比较好用的本地编辑器是一个比较普遍的困扰，特别是我这样的程序员用户对于编辑器的要求就更多一些了。有一些同学是直接通过 crouton 安装 Sublime Text、GitHub Atom 等编辑器或者各种 IDE 软件来解决。

之前我介绍过 Caret 这款 Chrome 应用商店里的文本编辑器 App，如果只是用来编辑纯文本之类的文件那 Caret 是能胜任的，如果你需要额外的一些扩展功能，那只能另寻他法了。我还尝试过第三方开发者移植的 Chrome 版 Adobe Brackets 编辑器（和 Atom 有点类似），不过使用起来还是存在各种问题就作罢了。

还好后来我还是在 Chrome 商店里找到了今天要介绍的 Zed 编辑器，Zed 的使用方式和 Sublime Text 比较类似，其主要功能可以参考官网：

http://zedapp.org/

Zed 编辑器其实是有 Chrome App 版本和 Windows、Mac、Linux 等系统下的 Standalone 版本的，Standalone 版本的功能比 Chrome App 版本要更多（例如可以直接运行本地命令等）。

对于 Chromebook 用户来说虽然默认只能用功能相对少的 Chrome App 版本，但相应的也能得到 Chrome 版本的带来的好处：

• 一处安装多处直接运行；
• 自动通过 Google Drive 同步 Zed Chrome App 配置；
• Zed Chrome App 默认自动从 Chrome 商店更新。

而且开发者考虑到日益增长的 Chromebook 用户的需求目前也在不断更新 Chrome App 版本，我们可以从 Chrome 商店 直接安装。

初步使用

Zed 编辑器启动时会提示你使用哪种界面风格，默认是不带目录树甚至隐藏了菜单栏的风格，打开编辑器会显示选择项目界面：

点击“Local Folder” 或者“Local File(s)”就可以打开本地的文件夹或文件编辑了，“Zedd Folder”和“Remote Folder”是两种直接编辑远程文件的方式后面单独再做介绍，另外 Zed 还直接支持打开 GitHub 版本库和 Dropbox 这点也比较方便。

打开具体的文件会直接显示文件内容，第一次打开某个项目文件夹的话则默认显示只读的 zed::start 内置使用介绍文件以帮助用户熟悉编辑器的各种快捷键之类的。

Zed 的文件编辑和 Sublime Text 这种类似是直接实时保存用户输入的结果，不需要单独的关闭保存操作。

通常的文件操作可以使用键盘快捷键或者 File 菜单完成：

• Ctrl-N 键新建文件；
• Ctrl-E 键打开文件；
• Alt-T 键显示目录树；
• F5 键刷新文件夹中的文件列表。

新建文件或者打开文件时会显示命令窗口，输入不存在的文件名就可以实现新建文件（当然也就可以直接在命令窗口中输入子目录路径）。

如果你在编辑的过程中需要打开另一个项目文件夹或者文件，那可以按 Ctrl-Shift-o 键显示最开始的选择项目界面，这样就不用重启 Zed App 了。

Zed 配置文件

这里先说 Zed 的配置文件是因为最常用的调出 Zed 命令窗口的默认快捷键 Ctrl-. 或 Ctrl-Shift-. 在 Chromebook 上是不起作用的，当然你也可以鼠标点击 Tools 菜单下的 Run Command 菜单项来实现，不过为了使用方便，我们还是先修改 Zed 配置文件来定制命令快捷键。

打开 Zed 编辑器开始显示的选择项目界面里可以看到 Configuration 项，使用此项就可以打开 Zed 自带的配置项目目录，默认第一次打开还是会显示 zed::start 文件，使用 Ctrl-E 快捷键或者打开菜单选择 user.json 文件进行编辑，这个就是 Zed 的用户配置文件。

默认的 user.json 用户配置文件可能是这样的（仅供参考）：

{
    imports: [
        "/default.json"
    ],
    preferences: {},
    modes: {},
    keys: {},
    commands: {},
    handlers: {},
    themes: {},
    packages: [    ]
}

我们可以在 keys 中新增一项来修改默认的运行命令快捷键：

    keys: {
        "Command:Enter Command": {
            win: "Ctrl-Shift-C"
        }
    },

例如改成上面的内容就可以使用 Ctrl-Shift-C 键调出运行 Zed 命令的窗口了。

当然对于修改主题之类的常用配置，你可以使用 Ctrl-, 快捷键或者 Configuration - Preferences 菜单项进行图形化的配置，这样也更加方便。

Zed 命令

Zed 命令的使用方式也是和 Sublime Text 比较相似，经过上面的步骤修改命令快捷键之后就可以体验 Zed 的各项命令了，Zed 的命令窗口支持模糊查找识别的功能。

Zed 相对 Chrome 商店里其它各种编辑器的一大优势就是其支持 Zed Package Manager（简称 ZPM）包管理特性，第三方开发者可以根据需要为 Zed 开发各种扩展功能包，ZPM 的介绍可以参考 Zed 官网文章，常用 ZPM 包在这里：

https://github.com/zedapp/zed/wiki/Packages

按快捷键调出运行命令的窗口后，输入 install 就可以看到默认匹配的安装 ZPM 包命令：

同样输入 installed 就可以看到默认匹配的列出已安装的 ZPM 包命令，还是比较方便的。

Markdown 编辑与预览

Zed 虽然不像 Sublime Text 那样支持多标签页功能，但也可以在一个 Zed 窗口中显示最多 3 个编辑窗口，通过快捷键可以切换：

• Ctrl-2 将窗口分割为两个编辑窗口；
• Ctrl-3 将窗口分割为三个编辑窗口（最好高分屏才这么干哈）；
• Ctrl-1 恢复为单编辑窗口；
• Ctrl-0 在多个编辑窗口之间切换焦点。

Zed 自带 Markdown 预览功能，如果编辑的是 Markdown 文件则可以通过 Ctrl-P 快捷键显示预览窗口，开启预览之后还可以多次使用 Ctrl-P 快捷键切换源 Markdown 文件编辑窗口和预览窗口的大小，当然也可以按 Ctrl-1 键关闭预览窗口。

我使用的 Wiki 系统 中的 Markdown 文件预览效果如下：

你可能从上面的截图可以看出 Zed 的 Markdown 预览功能似乎效果一般，这是因为 Zed 自带的 Markdown 预览模块对 GitHub 格式的 Markdown 文件的支持是不太好的。

不过还好已经有人为 Zed 写了一个支持 GitHub Flavored Markdown 的 ZPM 包，其项目地址如下：

https://github.com/akoenig/zed-gfm-preview

按照该项目主页的介绍，调出运行命令窗口，选择 Tools:Zpm:Installed Packages 命令准备安装新的 ZPM 包，包地址中输入 gh:akoenig/zed-gfm-preview 就可以完成安装。

安装完成之后编辑 Markdown 文件时可以通过 GitHub:Markdown:Preview 命令使用 zed-gfm-preview 方式来预览 Markdown，当然还是建议修改 Zed 用户配置文件直接将 zed-gfm-preview 配置为 Zed 默认的 Markdown 预览方式：

modes: {
    markdown: {
        handlers: {
            preview: [
                "!Tools:Preview",
                "GitHub:Markdown:Preview"
            ]
        }
    }
}

这样还是可以按默认的 Ctrl-P 快捷键直接预览 Markdown 文件：

可以看到效果也比 Zed 自带的实现好多了哦，代码块的显示也正确了。

后记

本文只是对 Zed 编辑器的初步介绍，另外一些 Zed 自带的比较好用的远程编辑文件、自带 Web 服务器等特性后面有空再来写了，大家也可以研究折腾甚至开发自己的 ZPM 包哦。文章中有任何问题还请提出指正，火热的六月仍然祝大家玩的开心呢 ^_^。

我目前使用的 360 云盘虽然有 Android 和 Windows 下的在线视频播放客户端，但是 Web 端的视频播放功能相对还是弱了一点，云盘里基本上只有标准 H.264 编码的 mp4 格式的视频才能直接用 Chromebook 进行在线播放。

这里还是提一下 360 云盘 Web 版的一个优点就是标准 H.264 编码的 mp4 格式视频竟然还是以 html5 方式直接播放的。

其它诸如 avi、wmv、mkv、rmvb 等很常见的视频文件都不能直接在线播放，点击时会直接提示用户下载视频到本地。

解释

Chrome 浏览器默认只支持播放 H.264 和 WebM 编码的视频,而且 Chrome 45 以上的版本已经不支持不太安全的 NPAPI 形式的插件了（对于 Chromebook 这种终端使用 NPAPI 插件也不现实哦）。

考虑到 360 云盘的 Android App 目前看起来通过 Chrome ARC 环境也不能正常运行，因此我就稍微花了几天时间写了一个针对 360 云盘的视频播放助手 Chrome 扩展，建议直接从 Chrome 应用商店中安装本扩展：

https://chrome.google.com/webstore/detail/klomjfcgakppceibbbgkbdklmhiiidkl

本播放助手扩展主要对 360 云盘的 Web 版做了一些改进：

• 360 云盘的文件列表界面中点击非 mp4(webm) 的视频文件也可以弹出视频播放网页；
• 视频分类界面中点击视频文件也能达到同样的效果；
• 视频播放网页上方增加播放助手图标，并显示 [转码视频] 和 [原画视频] 链接，点击可以直接播放，右键也可以复制视频链接地址到其它播放器中播放。

特别需要说明的是虽然 Chrome 浏览器本身只支持播放 H.264 和 WebM 编码的视频,不过还好国外的 Video Experts Group 推出了适用于 Chrome 浏览器的 NaCl（PNaCl） 形式的视频播放插件 VXG Media Player Plug-in，此插件可以提升 Chrome 浏览器的视频播放能力，而且相比 NPAPI 插件也更加安全。

有关 VXG Media Player 视频播放器插件的详细介绍可以参考其官网：

http://www.videoexpertsgroup.com/chrome-media-player-plug-in/

VXG Media Player 插件的基本特性包括：

• 支持 RTSP, RTP, UDP, RTMP, MMS， HLS 等各种常见的媒体协议；
• 支持 H.264, MPEG-4, MPEG-2 等众多的视频编码；
• 支持 AAC, PCM, G711, MP3 等音频编码格式；
• 视频解码支持硬件加速；
• 由于是 NaCl（PNaCl） 形式的插件，在不同硬件平台上兼容性比较好。

安装 VXG Media Player 插件并经过基本测试之后发现该插件虽然也有一些问题，但也算能满足 Chromebook 上网页直接播放视频的需求了。因此经过研究 VXG Media Player 插件的 API 之后决定在我的云盘播放助手扩展中使用此插件以实现更加全面的视频播放支持，最终的使用方式就是：

• mp4(webm) 视频：
  直接使用 360 云盘自带的 html5 视频播放功能，效果最好；
• avi、wmv、mkv、rmvb 等视频：
  调用 VXG Media Player 插件接口让这些格式的视频也能在云盘视频播放界面中直接播放。

安装 VXG Media Player 插件请移步 Chrome 商店：

https://chrome.google.com/webstore/detail/hncknjnnbahamgpjoafdebabmoamcnni

这里贴上我的云盘播放助手扩展运行效果截图：

从上面的截图可以看到本扩展在 360 云盘播放界面增加的图标和两个链接，本扩展不会修改云盘播放界面上的默认播放效果（不管是使用 html5 视频播放或者 360 云盘的 Flash 视频播放器），只有点击增加的链接之后才会切换播放方式。

提示

对于 mp4(webm) 格式的视频文件，由于 360 云盘已经支持比较好的 html5 视频播放效果，本扩展就没有提供使用 VXG Media Player 插件进行播放的功能。

上面截图展示的就是点击 [转码视频] 链接之后使用 VXG Media Player 插件播放 mkv 视频的效果；当然你也可以在增加的 [转码视频] 和 [原画视频] 链接上点右键复制视频地址在其它播放器中播放（强烈建议 Chromebook 用户安装 Chrome 商店中的 VLC 播放器应用）。

如果你的 Chrome 浏览器没有安装 VXG Media Player 插件，那么在点击 [转码视频] 和 [原画视频] 链接时会自动提示你转到 Chrome 商店安装该媒体播放器插件：

当然还是要说下本云盘播放助手扩展目前存在的问题：

• VXG Media Player 插件的控制条暂时不支持拖动、快放、慢放、暂停操作，看起来是有些不足，视频插件更新之后应该会有改善；
• mkv 等格式的高清视频效果没有外部 VLC 播放器的效果好；
• 360 云盘自动转码的 m3u8 HLS 视频某些情况下会出现播放速度过快的问题，还是 VXG Media Player 插件的锅，只能等后续更新了；
• 从上面的截图可以看到播放时会显示 VXG Media Player 插件的 logo 和评估版本的提醒，这个由于是个人使用也不好去掉咯。

因此如果你发现 VXG Media Player 插件的播放效果不给力，也大可以使用其它播放器播放，本扩展并没有捆绑依赖 VXG Media Player 插件。

本扩展的源代码已经发布到 GitHub 上：

https://github.com/zohead/cloud-disk-player-helper

如果你在使用云盘播放助手扩展的过程中发现任何问题，欢迎在本扩展的 Chrome 商店页面、GitHub 项目支持页面、本博客文章下提交 issue 或者留言，最后祝玩的开心～～～

crouton 是一个通用的在 Chrome OS 系统里以 chroot 方式运行普通 Linux 系统的环境，这里我就不做介绍了，由于要测试一下我之前修改的 PPTV Kodi（XBMC） 插件，直接通过 crouton 启动 Ubuntu 14.04 trusty 系统，跟往常一样打开 Kodi 却发现没有任何反应。系统没有直接给出任何报错信息，通过命令可以看到 kodi.bin 进程在运行但一直没有看到 Kodi 媒体系统界面，查看 Kodi 的日志文件 ~/.kodi/temp/kodi.log 也看不到有用的错误信息。

接下来发现更加奇怪的是似乎 crouton 系统里所有和音频相关的程序都是启动了没有任何反应，包含 XFCE 自带的 Audio Mixer，例如我之前用的好好的 SuperTux 2 小游戏（一款类似超级马里奥的 Linux 游戏）也运行不了，通过给 SuperTux 2 启动命令加调试输出的参数可以看到：

(trusty)zzm@localhost:~$ supertux2 --verbose
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:236 PhysfsWriteDir: /home/zzm/.supertux2
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:237 PhysfsSearchPath:
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:241   /home/zzm/.supertux2
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:241   /usr/share/games/supertux2
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'config' finished after 0.001 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'tinygettext' finished after 0.094 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'controller' finished after 0.001 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'commandline' finished after 0 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:61 no support for late swap tearing vsync: No OpenGL context has been made current
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:64 no support for vsync: No OpenGL context has been made current
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:132 Using GLEW 1.10.0
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:133 GLEW_ARB_texture_non_power_of_two: 1
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:291 window  Window: Size(1280, 712) Fullscreen: Size(0, 0)@0 Area: Size(0, 0)
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'video' finished after 0.074 seconds

从上面的输出可以看到 SuperTux 已经可以正确加载视频组件了，但似乎到了音频时就直接卡住没反应了，这时我想起看看 crouton 系统的 PulseAudio 音频功能是否工作正常：

(trusty)zzm@localhost:~$ ps ax | grep pulseaudio
 2034 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
11585 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
11944 pts/2    Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
11991 pts/2    Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
12055 pts/2    Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
13094 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
13301 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
13388 pts/2    S+     0:00 grep --color=auto pulseaudio
27624 ?        S      0:00 /usr/bin/pulseaudio --start --log-target=syslog
27630 ?        S      0:00 /bin/sh /usr/bin/start-pulseaudio-x11
27640 ?        Ss     0:00 /usr/bin/pulseaudio --start --log-target=syslog
27641 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
27645 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog

这下才发现 Ubuntu 的 PulseAudio 音频服务已经不正常了，系统里已经启动了多个 pulseaudio 进程，但都是直接卡住无法退出的状态，我们可以看看系统日志的输出：

2016-03-26T00:44:51.253228+08:00 ERR pulseaudio[13959]: cras_client: Unknown server_state version.
2016-03-26T00:47:17.599107+08:00 ERR pulseaudio[14281]: cras_client: Unknown server_state version.

看到 cras_client 就明白了这个是之前大概了解过的 Chrome OS 音频客户端，看看 crouton 官方 Wiki 里关于音频系统的说明：

https://github.com/dnschneid/crouton/wiki/Audio

开始就说的是 crouton 系统里音频工作机制：

Audio in crouton should work out of the box, with sound control synchronized between Chrome OS and crouton. By default, audio is forwarded to Chromium OS Audio Server (CRAS), and you will be able to play audio from both Chromium OS and crouton at the same time, without problem.

也就是 crouton 系统里的音频是以 ALSA 插件方式直接通过 Chrome OS 自带的 CRAS (Chromium OS audio server) 服务器实现的，这样存在的问题就是 Chrome OS 主系统自动升级之后可能和 crouton 里已经安装的 CRAS 插件不兼容了，这样 PulseAudio 音频服务就会启动失败。

解决方法也就简单了，用最新的 crouton 脚本更新一下已经安装的 Linux 系统一般就能搞定了（请自行把下面的 trusty 换成你安装的 crouton 系统名称）：

chronos@localhost ~/Downloads $ sudo sh ./crouton -n trusty -u

提示

鉴于国内不少 Chromebook 用户没有路由器直接翻墙的条件，而 crouton 系统里又是不能直接使用 Chrome OS 的代理的，这样很多用户会在 crouton 脚本从 chromium.googlesource.com 网站下载音频程序这一步遇到被墙阻挡而更新失败的问题。

这里我安利一下我修改过的 crouton 脚本，和官方脚本的唯一区别就是通过 HTTP（HTTPS） 代理从 chromium.googlesource.com 网站下载音频程序，我已经放到 Gist 上，需要的朋友可以从此 Gist 链接 下载。

更新成功之后会看到 crouton 其实已经在输出信息的最后对这个问题做了说明,只能怪自己当初安装 crouton 系统的时候就没注意到这点了 -_-#：

Audio from the chroot will now be forwarded to CRAS (Chromium OS audio server),
through an ALSA plugin.

Future Chromium OS upgrades may break compatibility with the installed version
of CRAS. Should this happen, simply update your chroot.

另外需要说明的是如果你的 crouton 系统里安装了不止一个图形系统 target （例如我同时安装了 xorg 和 xiwi 这两个 target，默认的 xorg 是为了更好的性能，xiwi 则是为了可以直接在 Chrome OS 系统里以窗口形式运行 Linux 图形程序），那么 crouton 系统自动更新之后默认的图形系统可能会被改回来，这是你只要修改对应 crouton 系统的 xmethod 配置文件 （例如我的是： /usr/local/chroots/trusty/etc/crouton/xmethod） 就可以重新配置默认的图形系统了。

Chromebook 的触控板由于比较特殊之前很多网友安装的 Ubuntu 系统里经常也用不了，这里我以 Dell Chromebook 11 为例子对 Remix OS PC 版内核模块做一些修改可以实现 Remix OS 下基本的触控功能，对于在 Chromebook 上单独安装的 Linux 系统下想使用触控板的用户也能做一个参考。

下面的篇幅有很大一部分是对 Remix OS 不能使用 Chromebook 触控板的原因分析，不想了解技术细节的话可以直接拖到最后「修改 Remix OS 系统文件」部分下载并使用我修改编译出来的适合 Remix OS 的内核模块哦。

编写这篇文章时我使用的是 Remix OS PC 版 2016-02-01 alpha 版本，对应 Android x86 5.1.1 版本，Linux kernel 版本 4.0.9；
我使用的 Chrome OS 版本是 48.0.2564.116 正式版，Linux kernel 版本 3.8.11。

触控板问题分析

首先确认能正常工作的 Chrome OS 下的 Chromebook 触控板相关信息，看看 Linux 输入设备中的触控板设备：

I: Bus=0018 Vendor=0000 Product=0000 Version=0001
N: Name="Cypress APA Trackpad (cyapa)"
P: Phys=i2c-9-0067/input0
S: Sysfs=/devices/pci0000:00/0000:00:15.1/i2c-9/9-0067/input/input7
U: Uniq=
H: Handlers=event7 
B: PROP=5
B: EV=b
B: KEY=e520 10000 0 0 0 0
B: ABS=660800001000003

可以看到 Dell Chromebook 11 上的触控板其实用的是 Cypress 家的 APA I2C 输入设备，Chrome OS 上对应 i2c-9 适配器，I2C 地址是 67，对应的 I2C 输入设备驱动为 cyapa。

提示

其它也有不少三星、HP 之类的 Chromebook 设备用的是 I2C 触控板，但不一定是同一厂商的，有的是使用 ELAN 等 I2C 触控板；
另外具体机器上 I2C 地址是固定的，i2c-9 适配器则是 Linux kernel 自动生成的并不固定。

接下来看看 I2C 适配器实际对应的设备位置和名称：

chronos@localhost ~ $ cd /sys/class/i2c-adapter/
chronos@localhost /sys/class/i2c-adapter $ ls -dl *
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-0 -> ../../devices/pci0000:00/0000:00:02.0/i2c-0
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-1 -> ../../devices/pci0000:00/0000:00:02.0/i2c-1
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-10 -> ../../devices/pci0000:00/0000:00:15.2/i2c-10
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-2 -> ../../devices/pci0000:00/0000:00:02.0/i2c-2
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-3 -> ../../devices/pci0000:00/0000:00:02.0/i2c-3
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-4 -> ../../devices/pci0000:00/0000:00:02.0/i2c-4
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-5 -> ../../devices/pci0000:00/0000:00:02.0/i2c-5
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-6 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/i2c-6
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-7 -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/i2c-7
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-8 -> ../../devices/pci0000:00/0000:00:1f.3/i2c-8
lrwxrwxrwx 1 root root 0 Mar  1 22:38 i2c-9 -> ../../devices/pci0000:00/0000:00:15.1/i2c-9
chronos@localhost /sys/class/i2c-adapter $ cat i2c-*/name
i915 gmbus ssc
i2c-designware-pci-1
i915 gmbus vga
i915 gmbus panel
i915 gmbus dpc
i915 gmbus dpb
i915 gmbus dpd
DPDDC-A
DPDDC-B
SMBus I801 adapter at 0400
i2c-designware-pci-0

可以看到触控板的 I2C 适配器 i2c-9 在 PCI 设备 0000:00:15.1 上，名称为：i2c-designware-pci-0，另外系统里还有 i2c-10 适配器在 0000:00:15.2 上，名称为：i2c-designware-pci-1，这两个适配器对应的 I2C 总线驱动是：i2c-designware-pci。

下面就可以在 Chromebook 上启动 Remix OS 确认其内核下 I2C 设备信息是否正确：

chronos@localhost ~ $ cd /sys/class/i2c-adapter/
root@remix_cn_x86_64:/sys/class/i2c-adapter # ls -dl *
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-0 -> ../../devices/pci0000:00/0000:00:02.0/i2c-0
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-1 -> ../../devices/pci0000:00/0000:00:02.0/i2c-1
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-10 -> ../../devices/pci0000:00/0000:00:1f.3/i2c-10
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-2 -> ../../devices/pci0000:00/0000:00:02.0/i2c-2
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-3 -> ../../devices/pci0000:00/0000:00:02.0/i2c-3
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-4 -> ../../devices/pci0000:00/0000:00:02.0/i2c-4
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-5 -> ../../devices/pci0000:00/0000:00:02.0/i2c-5
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-6 -> ../../devices/pci0000:00/0000:00:02.0/i2c-6
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-7 -> ../../devices/pci0000:00/0000:00:02.0/i2c-7
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-8 -> ../../devices/pci0000:00/0000:00:15.1/i2c-8
lrwxrwxrwx root     root              2016-03-01 00:24 i2c-9 -> ../../devices/pci0000:00/0000:00:15.2/i2c-9
root@remix_cn_x86_64:/sys/class/i2c-adapter # cat i2c-*/name
i915 gmbus ssc
i915 gmbus vga
SMBus I801 adapter at 0400
i915 gmbus panel
i915 gmbus dpc
i915 gmbus dpb
i915 gmbus dpd
DPDDC-A
DPDDC-B
i2c-designware-pci
i2c-designware-pci

这样可以发现 Remix OS 内核下两个 I2C 适配器为 i2c-8 和 i2c-9，虽然 i2c-8 是触控板设备但是使用起来应该是没有影响的，I2C 总线驱动也是正确的，但适配器名称都是一样的 i2c-designware-pci。

同时进一步确认之后发现 Remix OS 内核下虽然没有 Chrome OS 里直接使用的 cyapa 驱动，但其默认集成了新的 Linux kernel 里自带的 cyapatp 驱动。cyapa 是 Google 为 Chromebook 内核专门修改的 Cypress Gen3 系列触控板驱动，而查看源代码之后发现 cyapatp 驱动不但支持 Cypress Gen3 系列触控板，也支持新的 Gen5 系列触控板，这样按说 cyapatp 直接就是支持我的 Chromebook 触控板设备的。

比较郁闷的是我直接在 Remix OS 终端里运行 modprobe cyapatp 命令虽然能成功加载驱动，但系统中并没有注册任何新的输入设备。

Chromebook kernel 研究

没办法就只能先检出 Chrome OS 当前使用的 3.8.11 版本内核源代码研究下了，检出方法可以参考我之前写的「在Koding云平台上编译Chromebook kernel」这篇文章，Chrome OS kernel 分支可以在这里看到：

https://chromium.googlesource.com/chromiumos/third_party/kernel/

稍微研究后发现原来 Chrome OS kernel 里增加了一个 chromeos_laptop 平台相关的驱动，Chrome OS 系统启动时会加载这个驱动（实际上是直接编译到 Chrome OS kernel 中的），chromeos_laptop 中会自动尝试查找并实例化 Chromebook 上的 I2C/SMBus 设备，看看其中的部分代码：

#define CYAPA_TP_I2C_ADDR	0x67

const char *i2c_adapter_names[] = {
	"SMBus I801 adapter",
	"i915 gmbus vga",
	"i915 gmbus panel",
	"i2c-designware-pci-0",
	"i2c-designware-pci-1",
};

/* Keep this enum consistent with i2c_adapter_names */
enum i2c_adapter_type {
	I2C_ADAPTER_SMBUS = 0,
	I2C_ADAPTER_VGADDC,
	I2C_ADAPTER_PANEL,
	I2C_ADAPTER_I2C0,
	I2C_ADAPTER_I2C1,
};

static struct i2c_board_info cyapa_device = {
	I2C_BOARD_INFO("cyapa", CYAPA_TP_I2C_ADDR),
	.flags		= I2C_CLIENT_WAKE,
};

static struct chromeos_laptop wolf = {
	.i2c_peripherals = {
		/* Touchpad. */
		{ .add = setup_cyapa_tp, I2C_ADAPTER_I2C0 },
		/* Elan Touchpad option. */
		{ .add = setup_elantech_tp, I2C_ADAPTER_I2C0 },
	},
};

static struct i2c_client *add_i2c_device(const char *name,
						enum i2c_adapter_type type,
						struct i2c_board_info *info)
{
	const unsigned short addr_list[] = { info->addr, I2C_CLIENT_END };
	return __add_probed_i2c_device(name,
				       find_i2c_adapter_num(type),
				       info,
				       addr_list);
}

static int setup_cyapa_tp(enum i2c_adapter_type type)
{
	if (tp)
		return 0;

	/* add cyapa touchpad */
	tp = add_i2c_device("trackpad", type, &cyapa_device);
	return (!tp) ? -EAGAIN : 0;
}

稍微分析下可以看到 chromeos_laptop 驱动是根据名称找到当前系统中的 I2C 适配器的，找到之后最后根据 I2C 地址调用 i2c_new_probed_device 函数实例化 I2C 设备，而这里 cyapa 触控板驱动使用的 I2C 适配器名称固定为 i2c-designware-pci-0。

这样就有 Remix OS 下使用触控板的解决思路了，我们可以修改 i2c-designware-pci 驱动使其报上来的两个 I2C 适配器使用不同的名称，并加入 chromeos_laptop 驱动这样就可以正常使用新的 cyapatp 驱动；或者也可以不修改 i2c-designware-pci 而直接加入并修改 chromeos_laptop 中的触控板 I2C 适配器名称，为了后续 I2C 的区分我决定用第一种方法。

Remix OS kernel 修改

首先我们就要检出技德不久前开放的 Remix OS kernel 代码了，地址在这里：

https://github.com/jide-opensource/remixos-kernel/

值得一提的是 Remix OS 内核基本就是使用的默认 android-x86_64_defconfig 配置，先开始修改 i2c-designware-pcidrv.c 代码以支持使用不同的 I2C 适配器名称：

--- a/i2c-designware-pcidrv.c	2016-03-02 01:04:19.330843871 +0800
+++ b/i2c-designware-pcidrv.c	2016-03-01 00:18:04.502977140 +0800
@@ -48,7 +48,8 @@ enum dw_pci_ctl_id_t {
 	medfield_5,
 
 	baytrail,
-	haswell,
+	haswell_0,
+	haswell_1,
 };
 
 struct dw_scl_sda_cfg {
@@ -148,7 +149,15 @@ static struct dw_pci_controller dw_pci_c
 		.functionality = I2C_FUNC_10BIT_ADDR,
 		.scl_sda_cfg = &byt_config,
 	},
-	[haswell] = {
+	[haswell_0] = {
+		.bus_num = -1,
+		.bus_cfg = INTEL_MID_STD_CFG | DW_IC_CON_SPEED_FAST,
+		.tx_fifo_depth = 32,
+		.rx_fifo_depth = 32,
+		.functionality = I2C_FUNC_10BIT_ADDR,
+		.scl_sda_cfg = &hsw_config,
+	},
+	[haswell_1] = {
 		.bus_num = -1,
 		.bus_cfg = INTEL_MID_STD_CFG | DW_IC_CON_SPEED_FAST,
 		.tx_fifo_depth = 32,
@@ -258,7 +267,8 @@ static int i2c_dw_pci_probe(struct pci_d
 	adap->dev.parent = &pdev->dev;
 	adap->nr = controller->bus_num;
 
-	snprintf(adap->name, sizeof(adap->name), "i2c-designware-pci");
+	snprintf(adap->name, sizeof(adap->name), "i2c-designware-pci-%ld",
+		(adap->nr < 0) ? id->driver_data - haswell_0 : adap->nr);
 
 	r = devm_request_irq(&pdev->dev, pdev->irq, i2c_dw_isr, IRQF_SHARED,
 			adap->name, dev);
@@ -314,8 +324,8 @@ static const struct pci_device_id i2_des
 	{ PCI_VDEVICE(INTEL, 0x0F46), baytrail },
 	{ PCI_VDEVICE(INTEL, 0x0F47), baytrail },
 	/* Haswell */
-	{ PCI_VDEVICE(INTEL, 0x9c61), haswell },
-	{ PCI_VDEVICE(INTEL, 0x9c62), haswell },
+	{ PCI_VDEVICE(INTEL, 0x9c61), haswell_0 },
+	{ PCI_VDEVICE(INTEL, 0x9c62), haswell_1 },
 	/* Braswell / Cherrytrail */
 	{ PCI_VDEVICE(INTEL, 0x22C1), baytrail },
 	{ PCI_VDEVICE(INTEL, 0x22C2), baytrail },

然后将 Chrome OS 3.8.11 版本 kernel 中的 chromeos_laptop 平台相关驱动加到 Remix OS 4.0.9 版本 kernel 中，最后开始编译内核 bzImage 和对应的内核模块文件，实际上编译 bzImage 只是为了生成需要的 Module.symvers 符号文件，真正要使用的是新编译生成的 i2c-designware-pci.ko 和 chromeos_laptop.ko 文件。

提示

我是在 Chromebook Crouton 64 位 Ubuntu 14.04 环境中检出并修改 Remix OS kernel 进行编译的，实际 kernel 修改、加入新驱动修改 Makefile 和 Kconfig 等还有编译操作步骤什么的这里就不说明了，编译中间可能会有无线驱动报错，稍微修改下内核配置就可以通过了。

修改 Remix OS 系统文件

我编译好的两个内核模块文件下载地址（只适用于 Remix OS PC 版 alpha 4.0.9 内核）：

https://zohead.com/downloads/cbtp-remixos-20160201alpha.zip

首先可以在 Chromebook 上将新的内核模块文件放到 Remix OS U 盘中，如果你使用的是按照我之前的「Chromebook使用ext4 U盘运行Remix OS」文章介绍的方法生成的 ext4 格式 U 盘，那么修改替换 Remix OS 系统文件还是非常简单的。

(trusty)zzm@localhost:~$ sudo cp i2c-designware-pci.ko /media/removable/Android-x86/android-2016-02-02/system/lib/modules/4.0.9-android-x86_64+/kernel/drivers/i2c/busses/
(trusty)zzm@localhost:~$ sudo cp chromeos_laptop.ko /media/removable/Android-x86/android-2016-02-02/system/lib/modules/4.0.9-android-x86_64+/kernel/drivers/platform/x86/

注意

上面的命令例子中假定 Remix OS U 盘已经自动被 Chrome OS 挂载到 /media/removable/Android-x86 目录了，android-2016-02-02 是 Remix OS 系统路径，实际的挂载和系统路径不完全相同请自行检查。

下面是使用 depmod 命令重新生成新的模块依赖关系等文件，这样 Remix OS 系统在启动的时候就会自动尝试加载 chromeos_laptop 驱动，接着自动加载 cyapatp 驱动成功之后就可以直接 Chromebook 触控板了。

sudo depmod -A -b /media/removable/Android-x86/android-2016-02-02/system 4.0.9-android-x86_64+

最后说下我简单测试之后 Remix OS 中 Chromebook 触控板的使用效果：

• 基本的移动、点击等操作可以正常工作；
• 看起来也是支持简单的多点触控的；
• Remix OS 桌面图标的双击功能不起作用；
• Chrome OS 下特色的两指上下滚动功能也可以正常使用（不过由于 Android 的自然滚动方式所以方向和 Chrome OS 下是相反的）；
• 某些 App 下面支持三指同时长按然后放开之后出现右键菜单；
• Chrome OS 下特色的两指同时点击呼出右键菜单功能无效。

总之虽然触控版的使用不像 Chrome OS 下那样完美但基本还是能满足需求的，本文中有任何错误或疑问欢迎提出指正哦，祝玩的开心～～～。

Chromebook 上的特殊按键包括最上面一排的功能按键和专用搜索键；
功能按键和普通 PC 机上的 F1 - F12 功能按键有点类似，包括专门为 Chrome OS 设计的前进、后退、全屏、显示亮度控制、音量控制 等按键；
有关 Chromebook 键盘的相关信息请参考 Google 官方帮助文档 Use your Chromebook keyboard 。

首先可以用 Crouton Linux 环境中的命令行 showkey 命令或者图形界面下的 xev 命令检查 Chromebook 上特殊按键的 scan code，确认之后发现：

直接运行 Remix OS 的话也可以安装 KeyEvent Display 这款 App 来确认 Chromebook 上按键的 scan code。

• Chromebook 搜索键的 scan code 为：125；
• Chromebook 上面一排从后退键到提高音量键这些特殊功能键的 scan code 为：59 - 68；
• 特殊功能键的 scan code 和普通 PC 上的 F1 - F10 一致。

注意

不同 Chromebook 上特殊按键的 scan code 也有可能和上面的结果不同，我列出的结果适用于 Dell Chromebook 11 系列。

知道这些特殊按键的 scan code 之后就可以修改 Android keylayout 以适配 Chromebook 键盘，不过这一步需要修改 Remix OS PC 版 system 目录中的文件。如果你是按照我写的 Chromebook使用ext4 U盘运行Remix OS 文章中的方法安装的，那只要安装过程中启用了 system 目录的可写功能，那可以直接在 Remix OS（Remix OS 中直接修改需要开启 root 权限） 或者 Chrome OS 里修改还是很方便的。

如果你是用技德官方的工具烧写的 U 盘那会稍微麻烦点，需要在 Chromebook 等 Linux 系统中挂载 system 映像文件修改并重新打包，网上应该也能找到对应的教程，这里就不做详细介绍了。

修改 Remix OS 中的 /system/usr/keylayout/Generic.kl 文件，首先注释掉这些已有的行（Android 默认的键盘 scan code 到 key code 映射）：

#key 59    F1
#key 60    F2
#key 61    F3
#key 62    F4
#key 63    F5
#key 64    F6
#key 65    F7
#key 66    F8
#key 67    F9
#key 68    F10
#key 125   META_LEFT

然后增加这些行：

key 59    MEDIA_PREVIOUS
key 60    MEDIA_NEXT
key 61    MEDIA_PLAY_PAUSE
key 62    MENU
key 63    APP_SWITCH
key 64    BRIGHTNESS_DOWN
key 65    BRIGHTNESS_UP
key 66    VOLUME_MUTE
key 67    VOLUME_DOWN
key 68    VOLUME_UP
key 125   CAPS_LOCK

这里分别简单解释下：

• 59 - 后退键，改成了「上一个节目」键，改成 BACK 后退键等特殊键似乎会导致 Remix OS 下键盘输入有点问题，索性改成切换节目键可以配合各种音乐 App 方便切换歌曲；
• 60 - 前进键，改成了「下一个节目」键；
• 61 - 刷新键，改成了「播放/暂停」键，本来想改成 MEDIA_REWIND 也就是「倒回」键符合原来刷新键的意思，但测试后发现好多 App 不支持就算了；
• 62 - 全屏键，改成了「菜单」键，Remix OS 下没有直接的全屏按键，这里就用做现在比较少用了的「菜单」键了，目前看起来只有手动退出手机 QQ 时有用 ^_^；
• 63 - 切换窗口键，改成了「应用切换」键，类似 Android 原生的效果，和 Remix OS 自带的按 Alt+Tab 键切换应用效果稍微有点不一样；
• 64 - 降低亮度键；
• 65 - 提高亮度键；
• 66 - 静音键；
• 67 - 降低音量键；
• 68 - 提高音量键；
• 125 - 搜索键，改成了「大小写切换」键，因为发现现在 Android 下对原生搜索键支持的 App 太少（测试了只有 Chrome 支持），就改成了更常用的 Caps lock 键了，如果你想换成 Android 原生搜索键的话可以将值改为 SEARCH。

修改之后重新启动 Remix OS 系统就可以看到这些特殊按键的效果了，这样起码能让 Chromebook 用的更顺利咯。如果文章中有任何问题欢迎提出指正哦，祝元宵节后玩的开心～～～

我的老宏碁 Iconia W700 平板基本配置为：

• Intel Core i3-2375M 处理器;
• 4GB 内存;
• Intel HD Graphics 3000 集成显卡;
• 平板默认分辨率 1920x1080;
• 升级的 256GB SSD.

这款机器用来跑 Chrome OS 绝对是绰绰有余的，有些网友都是用配置比较烂的 Intel Atom CPU 上网本安装 CloudReady 系统的。

CloudReady相关介绍

CloudReady 是 Neverware 公司基于 Google 开源 Chromium OS 系统开发出的操作系统，可以提供基本类似 Google 在 Chromebook 等设备上的官方 Chrome OS 系统的功能，目前提供面向个人的免费版和面向教育结构的收费版本，两种版本的比较请参考 这里，个人版本主要少了技术支持服务之类的，建议直接到 Neverware官网 下载最新的个人版本。

我写这篇文章时 CloudReady 最新个人版本是 45.1.20 版本，虽然还跟不上 Google 官方已经推出的 Chrome OS 47.0 版本，但使用起来还是没什么大碍的哦。

另外目前网上也有一些网友自己编译的 Chromium OS 系统提供下载安装，CloudReady 系统相对来说比较好的地方就是其主要方向在这方面，有一定的技术支持，使用时遇到什么问题也可以到其论坛上提问得到解答。

安装说明

将下载到的 zip 压缩文件解压缩会得到一个 5GB 左右的镜像文件，准备一个容量为 8GB 以上的 U 盘（如果你的电脑有 USB 3.0 接口的话那强烈建议使用 USB 3.0 U 盘，会明显提升 CloudReady 系统速度），使用镜像写入工具直接将解压缩出来的镜像文件写入 U 盘即可（Windows 上可以使用 Win32 Disk Imager 之类的工具，Linux 等系统上可以直接使用 dd 命令写入）。

写入完成之后重启电脑，并将电脑设置为从 USB 启动，这样就可以直接引导并体验 CloudReady 系统了，系统主界面如下：

可以看到 CloudReady 系统界面和 Chrome OS 基本没有任何区别，启动完成之后可以在右下角菜单中选择 “Install CloudReady…” 将 CloudReady 系统直接安装到硬盘。

注意

由于 CloudReady 系统暂时还不支持多系统启动功能，通过 Install CloudReady 功能将 CloudReady 系统安装到硬盘会直接擦除掉硬盘的原有数据，如果需要保留硬盘上的原有系统请注意谨慎操作。

不过我可没有打算把我的平板上的 Win10 系统直接擦除掉用 CloudReady Chrome OS 系统，还是准备直接用 USB 3.0 U 盘体验 Chrome OS，这样也比较方便。

我安装 CloudReady 系统时使用的是 16GB 的 U 盘，但启动起来之类才发现 CloudReady 默认留给 home 用户的空间差不多就 1GB（U 盘多余的空间并没有利用到），对于我这种安装了很多 Chrome 插件和 App 的人来说，开机激活并自动同步所有软件和 Chrome 配置之后就已经开始报空间不足了，所以这里强烈建议在第一次启动之间直接按照下面的步骤先扩容 home 用户空间方便使用。

Chrome OS 的 home 用户空间是专门存放登录用户的配置文件、历史记录、浏览的缓存数据、安装的扩展和 App 等私人数据的单独分区，Chrome OS 上默认唯一可写的专用下载目录也在此空间中，home 用户空间大小可以在 Chrome OS 自带的 文件 App 中查看到。

U 盘用户空间扩容

这一步由于需要直接扩容 U 盘分区，所以最好在 Linux 系统（也可以使用安装了 crouton 的 Chromebook）下操作，在任何一个普通 Linux 系统下插入 U 盘，使用 parted 命令的 p 打印命令可以看到安装了 CloudReady 系统的 U 盘（设备名为：/dev/sda）分区布局如下：

(trusty)root@localhost:/home/zzm# parted
GNU Parted 2.3
使用 /dev/sda
欢迎使用 GNU Parted! 输入 'help'可获得命令列表.
(parted) p
Model: Teclast CoolFlash USB3.0 (scsi)
磁盘 /dev/sda: 15.7GB
Sector size (logical/physical): 512B/512B
分区表：gpt

数字  开始：  End     大小    文件系统  Name        标志
11    32.8kB  8421kB  8389kB            RWFW
 6    8421kB  8422kB  512B              KERN-C
 7    8422kB  8422kB  512B              ROOT-C
 9    8422kB  8423kB  512B              reserved
10    8423kB  8423kB  512B              reserved
 2    10.5MB  27.3MB  16.8MB            KERN-A
 4    27.3MB  44.0MB  16.8MB            KERN-B
 8    44.0MB  1118MB  1074MB  ext4      OEM         msftdata
12    1185MB  1202MB  16.8MB  fat16     EFI-SYSTEM  启动
 5    1202MB  1204MB  2097kB            ROOT-B
 3    1204MB  4387MB  3183MB  ext2      ROOT-A
 1    4387MB  5461MB  1074MB  ext4      STATE       msftdata

从上面的结果我们可以看到用户空间正是 U 盘上序号为 1 的分区（文件系统类型为：ext4，实际对应设备为：/dev/sda1），只不过刚好在分区表上是最后一个，不过其实这也是非常好的地方，这样我们可以直接对序号为 1 的分区进行扩容而不影响其它分区。

下面使用 parted 的 resizepart 命令对序号为 1 的分区进行扩容并验证：

提示

老版本的 parted 并不支持 resizepart 命令，如果你在 parted 中运行 resizepart 提示不支持的话那就需要升级 parted 软件包了。

(parted) resizepart 1 -1
(parted) p
Model: Teclast CoolFlash USB3.0 (scsi)
磁盘 /dev/sda: 15.7GB
Sector size (logical/physical): 512B/512B
分区表：gpt

数字  开始：  End     大小    文件系统  Name        标志
11    32.8kB  8421kB  8389kB            RWFW
 6    8421kB  8422kB  512B              KERN-C
 7    8422kB  8422kB  512B              ROOT-C
 9    8422kB  8423kB  512B              reserved
10    8423kB  8423kB  512B              reserved
 2    10.5MB  27.3MB  16.8MB            KERN-A
 4    27.3MB  44.0MB  16.8MB            KERN-B
 8    44.0MB  1118MB  1074MB  ext4      OEM         msftdata
12    1185MB  1202MB  16.8MB  fat16     EFI-SYSTEM  启动
 5    1202MB  1204MB  2097kB            ROOT-B
 3    1204MB  4387MB  3183MB  ext2      ROOT-A
 1    4387MB  15.7GB  11.3GB  ext4      STATE       msftdata

可以看到序号为 1 的分区已经扩容为 11.3GB 了，但实际底层的 ext4 文件系统还没有扩容，扩容 ext4 文件系统之前需要先用 e2fsck 命令检查文件系统：

(trusty)root@localhost:/home/zzm# e2fsck -f /dev/sda1
e2fsck 1.42.9 (4-Feb-2014)
第一步: 检查inode,块,和大小
第二步: 检查目录结构
第3步: 检查目录连接性
Pass 4: Checking reference counts
第5步: 检查簇概要信息
STATE: 30211/65536 files (0.3% non-contiguous), 228239/262144 blocks

完成之后再使用 resize2fs 命令扩展 U 盘上序号为 1 的分区的文件系统：

(trusty)root@localhost:/home/zzm# resize2fs /dev/sda1
resize2fs 1.42.9 (4-Feb-2014)
Resizing the filesystem on /dev/sda1 to 2755852 (4k) blocks.
The filesystem on /dev/sda1 is now 2755852 blocks long.

没什么意外的话 resize2fs 操作将能很快完成，此时 U 盘上 home 用户空间的扩容也就完成了，可以重启用 U 盘引导计算机进入 CloudReady 系统了。

安装 Flash 插件

CloudReady 系统在第一次激活启动的时候就会提示你安装 Adobe Flash 插件，如果你身在墙外或者全程 VPN 的话点击继续应该可以直接安装成功。

如果启动时提示安装 Adobe Flash 插件时安装失败（被墙阻挡是国内用户安装失败的主要原因，因为 Flash 插件需要从 Google 网站上下载 Chrome Linux 安装包），也可以进入系统之后在 Shell 环境下手工安装。

CloudReady 安装 Flash 插件的脚本在 /opt/neverware/check_or_install_flash.py 路径下，查看其中的代码可以发现其从这个网址下载 Chrome Linux 安装包并自动解压缩出 Flash 插件文件安装到当前系统 /opt/google/chrome/pepper 中：

https://dl-ssl.google.com/linux/direct/google-chrome-stable_current_i386.deb

我们可以在浏览器中手工下载该文件，并修改 check_or_install_flash.py 文件中的 deb_path 为实际下载到的文件的路径，例如：

deb_path = "/home/chronos/user/Downloads/google-chrome-stable_current_i386.deb"

提示

CloudReady 系统下 home 用户路径为 /home/chronos/user，这一点和 Chrome OS 有点不一样（Chrome OS 路径中会附加随机生成的用户 ID），/home/chronos/user/Downloads 即为用户下载目录路径。

之后再到 Shell 终端中手工运行 check_or_install_flash.py 应该就可以正确安装了，完成之后最好重启下系统使 Flash 插件生效。

使用体验

经过一段时间的实际使用，我发现 CloudReady 还是基本达到了其宣称的类似 Chromebook 体验的，系统界面看起来和 Google 官方 Chrome OS 基本没什么区别，在一般的 PC 机上使用起来也挺流畅的，使用 Google 账户登录之后原先在 Chromebook 或者 PC 端 Chrome 浏览器上使用的所有书签、历史记录、插件和 App 都可以自动同步过来，我之前发布的 Chrome OS 下的 快盘文件系统 App 使用起来也没什么问题。

下面总结一下我个人认为的 CloudReady 系统目前的优劣之处：

优点：

• 无缝支持 Google 账户并同步;
• 支持 Android Runtime，可以运行一些 Android App;
• 新版本增加了 Netflix 等相关支持;
• 免费个人版本直接支持 mp3、mp4（H264）硬件解码;
• 支持单独安装 Adobe Flash 插件;
• 相对完善的社区支持.

缺点：

• Evernote（印象笔记）等需要 Chrome OS 的 App 无法运行（提示与设备不兼容）;
• 底层仍然是 32 位 x86 Linux 系统，最大只能使用 4GB 内存;
• CloudReady 不支持直接的在线更新.

当然实际使用感受还是见仁见智的，欢迎各位安装 CloudReady 系统进行测试咯，文章中有任何问题欢迎提出指正，祝玩的开心~~~

Chromebook 重新开机之后进入时间设置可以看到这样的报错信息：

Chromebook无法设置系统时间错误

之前遇到这种情况我都是傻傻的再设置下系统时间，最近准备专门看下系统时间不能正确同步的原因。

目前用户最常用的时间同步方法一般是通过广域网上的 NTP 时间服务器进行（Linux 下对应 ntpdate 命令），另一种是直接通过连接 HTTPS（TLS）服务器获取时间戳来同步时间（Linux 下对应 tlsdate 命令），这种方式相比 NTP 协议的主要优势就是更加安全了（NTP 协议可是诞生于上个世纪八九十年代的，协议本身没有任何加密认证之类的处理），另外还有一种是通过 HTTP 协议连接 Web 服务器时间来同步时间（对应 htpdate 命令，这个也算是非常通用了，具体见我之前的一篇博文 [树莓派上使用htpdate同步时间]）。

Chrome OS 默认使用的就是 TLS 方式进行时间同步，这个可以通过登录到 Chrome OS Linux Shell 中查看运行进程进行确认：

chronos@localhost / $ ps ax | grep tlsdate | grep -v grep
13799 ?        S      0:00 tlsdated -v -- /usr/bin/tlsdate -v -C /usr/share/chromeos-ca-certificates -l
13800 ?        S      0:00 logger -t tlsdate
13801 ?        S      0:00 tlsdated -v -- /usr/bin/tlsdate -v -C /usr/share/chromeos-ca-certificates -l

可以看到 Chrome OS 自带的 tlsdated 服务运行 tlsdate 程序进行时间同步，查看 tlsdate 的日志文件 /var/log/tlsdate.log 检查为什么会时间同步出错：

chronos@localhost / $ cat /var/log/tlsdate.log
2015-11-10T01:55:05.881307+08:00 NOTICE tlsdate[3050]: V: tlsdate version 0.0.5
2015-11-10T01:55:05.881395+08:00 NOTICE tlsdate[3050]: V: We were called with the following arguments:
2015-11-10T01:55:05.881445+08:00 NOTICE tlsdate[3050]: V: validate SSL certificates host = clients3.google.com:443
2015-11-10T01:55:05.888424+08:00 NOTICE tlsdate[3050]: V: time is currently 1447091705.888190273
2015-11-10T01:55:05.888485+08:00 NOTICE tlsdate[3050]: V: time is greater than RECENT_COMPILE_DATE
2015-11-10T01:55:05.895243+08:00 NOTICE tlsdate[3050]: V: using TLSv1_client_method()
2015-11-10T01:55:05.896043+08:00 NOTICE tlsdate[3050]: V: opening socket to clients3.google.com:443
2015-11-10T01:55:08.881106+08:00 INFO tlsdated[3049]: [event:action_tlsdate_timeout] tlsdate timed out
2015-11-10T01:55:08.881361+08:00 NOTICE tlsdate[3050]: [event:action_tlsdate_timeout] tlsdate timed out
2015-11-10T01:55:08.883912+08:00 INFO tlsdated[3049]: [event:handle_child_death] tlsdate reaped => pid:3841 uid:234 status:9 code:2
2015-11-10T01:55:08.884132+08:00 NOTICE tlsdate[3050]: [event:handle_child_death] tlsdate reaped => pid:3841 uid:234 status:9 code:2
2015-11-10T01:57:13.153015+08:00 NOTICE tlsdate[3050]: SSL connection failed

这下直接就明白了，tlsdate 连接 clients3.google.com HTTPS 端口进行同步，但由于众所周知的大陆 GFW 系统原罪，我们国内的 Chromebook 用户是无法同步成功的（除非已经通过 VPN 之类的进行全局翻墙了）。

解决起来也就很简单了，下面直接列出几种解决方法：

1、通过 VPN 进行全局翻墙：

这是比较方便的解决办法，直接所有流量都走 VPN 就不存在问题了，只是我不太喜欢全局翻墙的方式，会影响国内网站的访问速度；不过如果你有支持隧道分流的 Cisco AnyConnect 之类的 VPN 账户，那也完全可以用这种简单的方式；

2、修改 tlsdate 连接的服务器地址：

这种方法需要先开启 Chromebook 的开发者模式，将 tlsdate 连接的 HTTPS 服务器地址改为任何一个国内可访问的信任服务器地址，Chrome OS 下 tlsdated 服务的配置文件路径为：/etc/tlsdate/tlsdated.conf，默认内容如下：

base-path                          /var/cache/tlsdated
dry-run                            no
jitter                             0
max-tries                          10
min-steady-state-interval          86400
should-load-disk                   yes
should-netlink                     yes
should-save-disk                   yes
should-sync-hwclock                yes
steady-state-interval              86400
subprocess-tries                   10
subprocess-wait-between-tries      3
verbose                            yes
wait-between-tries                 10

# Host configuration.
source
	host clients3.google.com
	port 443
	proxy dynamic
end

# Try it without the proxy.
source
	host clients3.google.com
	port 443
	proxy none
end

修改此 tlsdated 服务配置文件需要 root 身份，切换到 root 用户后执行下面的命令可以将 Chrome OS 的根文件系统改为可写的状态（默认只读的配置文件无法修改），执行完成之后必须重启才能生效：

chronos@localhost ~ $ sudo su -
Password:
localhost ~ # cd /usr/share/vboot/bin/
localhost bin # ./make_dev_ssd.sh --remove_rootfs_verification --partitions 4
Kernel B: Disabled rootfs verification.
Backup of Kernel B is stored in: /mnt/stateful_partition/backups/kernel_B_20151110_020745.bin
Kernel B: Re-signed with developer keys successfully.
Successfully re-signed 1 of 1 kernel(s)  on device /dev/mmcblk0.

重启之后我们就可以很 happy 的将 tlsdated.conf 配置文件中默认的 clients3.google.com 改为其它服务器地址了，我是直接改为 www.net.cn 万网的主页地址，修改完成之后直接运行 restart tlsdated 命令重启 tlsdated 服务就可以马上看到效果了，Chromebook 系统时间已经正常同步过来了。

3、为 tlsdate 指定时间同步代理服务器：

相信你也看到上面的 tlsdated.conf 配置文件中的 proxy 参数了，没错 tlsdate 也直接支持通过代理服务器连接 HTTPS 服务器同步时间，如果你信不过其它的服务器，坚持要用 Google 的服务器进行时间同步，那也可以将配置文件中的 proxy 参数由 none 改为代理服务器地址，代理服务器地址的写法也比较简单，例如如果要用 Shadowsocks 的 SOCKS5 代理，则写法如下（假设 Shadowsocks 使用的本地代理端口是 8050）：

socks5://127.0.0.1:8050

修改完成之后重启 tlsdated 服务不出意外也能看到起作用咯。

有 ARM Chromebook 使用经验的朋友们应该都知道 ARM Chromebook 在可折腾性上要比 x86 的 Chromebook 要差上不少，最主要一个原因就是在 Crouton 下的 ARM Linux 无法运行很多流行的 x86 应用程序。

之前我写过一篇在 Raspberry Pi 上运行 x86 Sopcast 程序的文章，这个主要是使用 QEMU 的用户模式实现在 ARM Linux 上运行 x86 的应用程序，但这种方式的主要问题是 QEMU 的性能比较差。一个比较好的消息是国外的 Eltechs 公司推出的 Exgear Desktop 软件宣称可以在 ARM Linux 上以接近 x86 原生的性能运行 x86 Linux 程序，综合性能是 QEMU 的 5 倍。这样对于我的三星 ARM Chromebook 来说可是相当有用的，因此考虑买一个授权（你没看错，Exagear Desktop 是收费软件，根据设备不同需要 20-30 美元）看看实际效果。

有关 Exagear Desktop 的介绍可以参考 Eltechs 的介绍页面：

http://eltechs.com/product/exagear-desktop/

花了 30 美元购买 Exagear Desktop 之后 Eltechs 会将软件下载方式及授权文件以邮件方式发过来，通过 Google Drive 下载安装。

安装 Exagear Desktop

安装之前可以了解下 Exagear Desktop 的系统概念，运行 ARM Linux 的主机系统被称为 host system，需要运行的 x86 系统被称为 guest system，首先需要先确认所使用的 ARM 设备是否满足要求：

• ARMv6 或 ARMv7 CPU；
• 512MB 或更多的内存；
• Ubuntu 12.04 14.04 或者 Debian 之类的系统

上面的几个要求对于 ARM Chromebook 没有压力了，如果想省事可以直接使用 Crouton 安装 Ubuntu 系统使用。这里我使用 XUbuntu 14.04 armhf 系统测试 Exagear Desktop 的效果。

解压缩 Exagear Desktop 的安装包，可以看到类似这些文件：

chronos@localhost ~ $ ls exagear/
eltechs_exagear_desktop_1.1_guide.pdf  exagear-guest-debian-7-wine2g_3_all.deb  exagear-mem2g_2254-1_armhf.deb
exagear_2254-1_armhf.deb               exagear-guest-ubuntu-1204lts_9_all.deb   install-exagear.sh
exagear-guest-debian-7_3_all.deb       exagear-guest-ubuntu-1404lts_1_all.deb   README

Exagear Desktop 提供了 Debian 7、Ubuntu 12.04、Ubuntu 14.04 等几种不同的 x86 系统，一般按照 user guide PDF 文件的介绍运行 install-exagear.sh 脚本就可以自动完成安装，中间会提示你安装哪种类型的 x86 guest 系统，选择之后会自动通过网络加载安装 x86 的应用包。

安装完成之后运行 exagear-ls 命令可以查看已经安装的客户机系统，直接运行 exagear 命令就可以进入 x86 客户系统，进行 x86 环境之后可以直接运行或安装 x86 的应用程序。

关于 binfmt_misc

Eltechs 建议为了达到无缝运行 x86 程序的效果（特别是能更好的支持运行 需要 SUID 或者 SGID 的 x86 程序），ARM Linux host 系统里最好能支持 binfmt_misc。

不过 Chromebook 上的 Linux kernel 一般没有自带这个，需要自己编译，可以参考我之前写的文章 在Koding云平台上编译Chromebook kernel 自己编译 Chromebook 下的 binfmt_misc 模块。

另外由于 binfmt_misc 没有默认在 Chromebook kernel 中，这样即使加载手工 binfmt_misc 模块之后也是没有 /proc/sys/fs/binfmt_misc 目录的，你需要在 Crouton 等 ARM Linux host 系统中创建 /var/binfmt_misc 目录，这样 Exagear Desktop 服务在启动时才可以自动挂载并启用 binfmt_misc 支持（具体可以参考 /etc/init.d/exagear 服务脚本）。

另外我在 /etc/init.d/exagear 服务脚本里加了一条自动加载 binfmt_misc 模块的处理（Chromebook 的 Crouton 上仍然需要自行编译并安装到系统模块目录中）：

[ -d /sys/module/binfmt_misc ] || modprobe binfmt_misc

总结

最后从我最近简单的测试情况来看，Exagear Desktop 对于 x86 程序的兼容性做的还是不错的，平常用的 Sublime Text、Skype 之类的软件可以正常运行，TeamViewer 用起来似乎也无碍，虽然我最想用的 Visual Studio Code 还是运行不了有点遗憾。实际 x86 程序的运行速度也是比较接近 ARM 程序的体验呢。

最后放张 Sublime Text 在我的三星 ARM Chromebook 上的运行效果：

Sublime Text on ARM Chromebook

祝各位玩的开心～～～

KeePass 目前相对也有个劣势就是浏览器插件功能不强，基本都需要配合 KeePass 客户端软件使用，好在 KeePass 也支持 Windows、Mac OS X、Linux、Android、iOS 等各种操作系统，可惜目前在 Chromebook 这种不能直接运行客户端软件的系统上使用时会有一些障碍。LastPass 由于是通过 Chrome 浏览器扩展直接在线同步的没有这个问题，而你如果是 Chromebook 和 KeePass 的重度用户，那还是相当不便的。

有关 KeePass 的详细介绍和原理请参考其官方网站：http://keepass.info/。

经过初步研究，这里我列出几种在 Chromebook 上使用 KeePass 的方法供读者参考：

• Crouton + keepass2 + chromeIPass：

这个方法可能暂时只适用于使用 x86 处理器的 Chromebook，Chromebook 上可以使用 Crouton 安装基本完整的 Linux 系统，安装完成之后可以直接在 Linux 系统中安装 keepass2 软件包（比较新的 Linux 系统软件源中一般会自带这个的），并从 KeePass 官网下载启用 KeePassHttp 插件，这样就可以在 Chrome OS 系统里安装 chromeIPass 扩展愉快的使用 KeePass 密码数据库了。

这里就不详细介绍 keepass2 软件如何安装，chromeIPass 扩展如何使用之类的了。无奈由于目前 armhf 版本的 Linux 系统自带的 mono （KeePass 图形程序依赖开源的 mono .NET 开发环境）版本的问题，armhf 下的 keepass2 可以安装但无法正常运行。

笔者在目前使用的三星 ARM Chromebook 安装的 Ubuntu 14.04 版本上就无法正常运行，将 Crouton Linux 系统升级到最新的 Ubuntu 15.04 或者 15.10 等系统（自带的 mono 环境已经升级）有可能能正常运行，这里没有继续尝试了。

• CKP Chrome 扩展程序：

CKP （KeePass integration for Chrome）是 Chrome 应用商店里的一款 KeePass 嵌入式扩展程序，安装之后导入 KeePass 数据库就可以实现访问网站时自动填入用户名和密码，可惜就是 CKP 只能以只读方式使用 KeePass 密码数据库，如果数据库文件变化了只能重新导入（Chromebook 上还没有太好的办法能直接修改密码数据库文件）。

CKP 同时功能上也存在限制：无法完整浏览密码数据库里的全部条目，如果某个服务密码存在密码数据库里但不能直接通过 Chrome 浏览器访问这样就没法取出密码了。

• BrowsePass Chrome 应用：

BrowsePass 则是另一款独立的 Chrome Packaged App，因此不能实现根据当前浏览的网页自动填写用户名和密码的功能，这个 App 目前对密码数据库文件支持文件好，可以完整浏览全部目录和条目，可以复制密码到相应的网页，但是仍然还有一个主要问题：BrowsePass 目前也只支持只读方式打开密码数据库，作者说后续可能会增加写数据库支持，但不保证什么时候能加入的。

• Chrome ARC + KeePassDroid：

这个是目前我正在使用的方法，主要这种方式完全支持对密码数据库的各种写入操作，不需要另外运行一个 Crouton Linux 系统，而且这也是比较通用的方法哦，不只是能在 Chromebook 下使用，其实也可以直接在 Windows、Linux 等其它安装了普通 Chrome 浏览器的系统下使用。

Chrome 现在支持通过 ARC（App Runtime for Chrome） 直接运行 Android 程序，虽然目前兼容性还不是特别好，但 KeePassDroid 这种没有使用 NDK 代码的简单 Android 应用还是完全支持的。

首先安装 ARC Welder Chrome 应用，安装完成之后会自动安装其依赖的 App Runtime for Chrome 运行环境，然后从网上下载 KeePassDroid 的安装 apk 文件，打开 ARC Welder 应用加载对应的 apk 文件将其转换为 Chrome 应用，不过需要注意的是转换的时候必须启用剪贴板访问权限，而且记得增加这个参数：

{"enableExternalDirectory": true}

启用外部 SD 卡目录访问权限，这样转换出来的 KeePassDroid Chrome 应用才可以正常打开 KeePass 密码数据库文件，具体如下图所示：

ARC Welder 转换 KeePassDroid

然后点击 Download ZIP 按钮保存成 zip 文件，并将 zip 文件解压缩并在扩展程序界面加载为 Chrome 应用。

第一次启动 KeePassDroid 应用时 Chrome OS 系统会提示你选择一个 SD 卡目录，选择之后会让你选择密码数据库文件路径，只要把你的 KeePass 数据库文件放到对应的路径打开即可，例如我使用的路径就是这样：/storage/sdcard/Download/zzm.kdbx。

选择密码数据库文件之后输入你的数据库主密码，KeePassDroid 就会列出数据库里的所有目录和条目，进入一个任何条目，KeePassDroid 会自动弹出通知消息提示你复制用户名和密码，这样就可以正常在各类网站上使用 KeePass 密码咯。

后记：

目前 GitHub 上的 Pascal Mathis 开发了一款基于 Node.js 的 KeePass 库：keepass.io，这个 Node.js 库实现了完整的密码数据库读取和写入功能，在和开发者简单沟通之后，有想法在后面有空时基于 keepass.io 将其完整功能改为通过 Chrome Filesystem 等 API 实现从而不依赖 Node.js，这样能以单独 Chrome App 的形式使用 KeePass 密码数据库。只是在发现 KeePassDroid 能正常使用的情况，这个就当作后面有空时的一个念想再说咯～～～ 祝各位玩的开心。 ^_^