Peter Hutterer 和 Wacom 绘图板的 GNOME Applet
搭载 GNOME 3.2.1 的 Fedora 16 的发布前夕，Libre Graphic World 的朋友对 GNOME Wacom Applet 的作者和 Linuxwacom 项目的活跃成员Peter Hutterer 进行了专访。感谢 jcome 翻译来稿
有了更好的色彩管理支持以及新的 Wacom 配置小程序(Applet)，最近发布的 GNOME 3.2 看上去对我们这些创作人员来说是个实实在在的进步。
上一次，对 Richard Hughes 的访谈做的有些长了，我原想着这次 Wacom 配置工具的开发者 Petter Hutterer 的就做简短些，可是当得知他和那个在 Linuxwacom 项目上超活跃的成员是同一个人后，我这个打算就彻底失败了。
所以，有了另外一篇长篇幅的访谈。请你读一读，希望你喜欢，也欢迎指教。
用于 Wacom 手写板的 GNOME 配置小程序
能麻烦你自我介绍一下吗？
我在 Red Hat 的图形团队(graphics team)工作。可是，我有些与众不同：我只负责输入部分（input）而不是图形。总之，我一直忙不停。我的职责范围不只是 X Server 的输入堆栈，还包括 evdev， synaptics 和 wacom 驱动，还有其它一些不太重要输入驱动的扩展。
我住在澳大利亚的 Brisbane。好处是天气比我住过的其他大多数地方都好（我们不妨假装今年早些时候的大洪水和飓风是个异常天气）。不好的是我的时区和其他人不一样，所以如果你在 IRC 上叫我时，我可能正睡觉呢。这是人们想在 IRC 上找我说话时首先会注意到的 :)
这个 GNOME 配置工具是怎么开始做的？是来自 GNOME 设计团队的推动吗？或者只是自发的？
这里头有些陈年旧事。
Linuxwacom 项目在好几年前就开始了。如果看CVS历史的话，是2002年。传统上，wacom 驱动是要无所不包的：内核补丁、 X 输入驱动、用户空间的配置和追踪调试工具，以及图形配置工具 wacomcpl 。
两年前，当我开始做驱动部分时，我们把 X 的输入驱动剥离为单独的 xf86-input-wacom 。主要原因是那时这个驱动让我非常不爽。我们为 X Server增加好多特性，但是 wacom 驱动却只能在后面苦苦追赶这些特性。
举个热插拔输入设备的例子，这方面，wacom 驱动是很特殊的，它会从一个内核设备里头分别创建多个X输入设备，一个对应笔尖，一个对应橡皮擦，还有一个用于侦测其它工具。这样，类似 GIMP 的应用程序可以分配不同的工具和（或）颜色给各个物理设备。
GIMP 中针对 Wacom 设备的分别设定
传统上，这要通过 xorg.conf 文件的多个 InputDevice
段落来处理的，这些段落中的设备都指向同一个设备文件。在热插拔的世界里，这个方法行不通——配置用的后端程序（之前用
HAL，现在用 udev）对每一个新设备只作一次通告。
在经历几个驱动和 X 服务器版本发布之后，我们在驱动中整合了热插拔支持，现在只要你插入设备，设备马上就起来了。可是这还遗留了另一个问题：一旦设备被拔出，所有在运行期间给设备做的配置都会被简单的重置回缺省值。
我上面提到过的 wacomcpl 工具不再适用于该情形。它只是提供运行时的配置，而无法永久保存。我们是可以编写后台守护程序（daemon）和 wacomcpl 进行协作配合，但我们没有这样做，有两个理由：wacomcpl 有一些其它的设计上的问题，而且我们已经有这样一个后台守护程序：gnome-settings-daemon 了。
这就是整合开始点。GNOME 已经能处理所有其它的输入设备并根据需要进行配置。为什么手写板(Tablet)不能也这样做呢？
非常有趣，GNOME
也只是在运行状态下应用配置的，但它监视设备列表，无论新设备是何时插入的，它都会被并重新应用配置，故而得到前后一致的配置（真正的前后一致的配置是放在在
gsettings 里的）。
那为什么我们要弄个新的小程序呢？
在配置界面上，对一个内核和一个物理设备同时拥有多个 X 设备进行处理需要一些额外的知识。比如，如果你选择切换笔尖（stylus）为绝对模式，橡皮擦（在同一根物理笔上）也会被切换到绝对模式去。驱动和 gnome-settings-daemon 两者的配合就容许我们使用不同的模式，但我想这个不是一个常见的使用案例。配置小程序 (applet) 隐藏了更多的关于驱动和设备语义知识。
在 GIMP 中设定高级绘图刷的动态范围
还有，驱动支持很多配置选项，其中许多都很有些用的。所以这个不是仅仅添加多一个面板到鼠标配置面板上的事情，可以预见 wacom 配置工具最终会变得相当复杂。
控制中心的小程序目前提供了基本的选项，如选择绝对和相对模式，左右手操作模式，橡皮擦和笔尖的线性压力控制，按钮的行为动作。然而还有很多的功能没有在用户界面上体现出来。你能说说具体是哪些功能，打算怎样实现它们吗？
目前，我们在关注三个功能：按钮的配置，校准（Calibration）以及显示器的分配（Monitor Assignment）。Wacom 驱动具有相当巧妙复杂的映射能力，尽管它们很常用，却还不能通过小程序来配置。比如，常见的一个配置：映射 Ctrl+Z 到一个平板的按钮上。按下那个按钮就触发当前打开的程序的Undo。目前我觉得此正确的解决方案是把动作整合到 toolkit 里。这样一个按钮才能够被真正映射到“Undo”。但其时，我们需要那些键序列（key sequences）作为一个替代方法。
KDE 下的 Wacom 配置小程序
校准不仅被如 Wacom Cintiq 这样的屏幕平板所需要的，有些平板电脑的内置绘板也会需要校准。然而，校准不只是针对图形绘板，我希望可以看到使用不同驱动程序的绝对设备共享一个小程序。 evdev 驱动也是有一些基本的校准能力，可能会对这个有所帮助。
最后，监视器映射是个比较多人要求的功能特性。默认情况下，在多监视器配置中，任何绝对设备映射的是整个桌面。这对内置设备来说显然是个问题，我们需要一个方法可以只映射这些设备到单一的监视器上。我们有命令行工具来完成该任务，但没有 GUI 工具。监视器映射是完全驱动无关的，所以我们也应该和其它设备一起共享相关代码和 UI。
关于这个，有趣的是我们事实上并不那么关心监视器的映射。服务器提供将任意的绝对设备映射到屏幕上的任何区域的功能。比如，当用户想映射右边的监视器，我们在幕后要做的是计算相对整个桌面的偏移量和维度，之后将设备映射到那个区域上去。
目前计划是要尽快把它们实现，但现实也许会有些不同。在我的工作清单上这些都是 Fedora 17 的事情，我希望能在那个时候它们都被完成。除非有人在我开始做之前插手进来实现它。我会很震惊的 ;)
我们也有些尚未与蓝图的目标，如侦测连接了何种类型的平板，从而显示适当的配置选项给该平板。这需要的时间和思考已经超出我目前的能力了。
Wacom Graphics Tablet 这个名字听上去感觉是特指了制造商。在 Linux 上还支持很多其它厂商的图形绘图板，比如 Genius，还有后来的汉王。这个小程序有抽象层来配置其它种类的绘图板吗？
从 X 这边，只有两个驱动是和平板有关系的：evdev 和 wacom。任何只支持一个工具和一些额外坐标的简单的平板都是由 evdev 处理的。使用 wacom 驱动的设备会分离成多个 X 设备。因为这个区分，一个通用“平板设定”面板可能反而变得更加复杂，因为有些平板不是由 wacom 驱动处理的。
没理由在 GNOME 控制中心小程序里我们不能同时支持这两个类型的平板，但是合适的设定会很大差异，我们现在还没有时间来处理这个。当然，另一个选择是通过 wacom 驱动来支持那些简化的平板。一旦有这个要求，我们会考虑。至少目前没有。
对于 Wacom 这个名字的使用：我给这个小程序起的第一个名字只是“Wacom Tablet”，在后来把它改了。我用这个名字的原因是因为 X 驱动命名为 wacom（当然，它是 Wacom Inc. 制作的）。现在我们确实支持多种平板，Wacom，Waltop，某些兼容 Fujitsu 平板电脑和一些 N-Trig 设备也支持。就我所知，Wacom Inc. 拥有专业平板市场，从来没有人要求哦我把驱动的名字从 wacom 改为更常见的一类。对我而言，这只是个名字而已。
对此，我的主要担心是如果我们直接把它改成图形板（Graphics Tablet），某些平板或者不能通过它来做配置。对当前的名字我倒没有什么个人感情在上面，如果某人想给它改名，请便。
凑巧的是，以上所说的一切同样适用于目前名为 "synaptics" 的触摸板驱动，但它现在就仅仅是一个适用于内核能处理的所有触摸板的通用驱动。
如今 Wacom 对 Linux 的支持是个什么情况？我们只要插入一个绘图板就可以吗？不需要重启应用程序？
对多数平板是这样的，有些新的平板可能不被支持或者不完全被支持。我们在正式发布（或者已经有用户购买）之前无法获得设备信息。Chris Bagwell 做了一些很棒的工作，可以在新硬件出来之后，驱动也不需要更新，但是就我所知，它还没有到实用的阶段。
应用程序是不需要重启的，除非它们只支持X Input Extension版本。我无法断言说所有应用程序/Toolkits 都是这样，这得视具体情况。能确认的是，再也不用重启 X 服务器来让平板工作了。
Linuxwacom 项目的情况怎么样，目前都有哪些要优先考虑的事情？
一个我们一直追求的目标是支持更多的硬件，但当前还有其他一些特性是我们也在关注的。Eduard Hasenleithner 刚把针对 Wacom Intuos4 系列平板的 OLED 补丁整合到了内核中。我们现在正通过X驱动让它暴露给客户端使用。这些在按钮边上的OLED是属于小显示器，它们能够显示位图。同样，状态指示的 LED 也是由 Eduard 和 Ping Cheng 负责的。
Intuos4 上的 OLED，Wacom 有限公司提供
Jason Gerecke 在把很多功能做到 xsetwacom 的命令行工具里去。他当前的目标是将实现的功能恢复到分离之前的程度。在分离之前，X 输入驱动有很多我认为不应该由一个输入驱动支持的功能，比如多监视器处理。这些功能之前都被清理掉，现在又一个一个加回来的。我的确承认这个驱动在一段时间里少了些功能，但现在和之前的功能相当了。当然，代码库变得更容易维护了，还增添了新功能。
Chris Bagwell 在改进 Bamboo 的支持，在内核和X驱动两边都保持非常不错的势头。最后，David Foley 对我们的 wiki 的维护更新同步也做的非常不错。
还有一个在我们工作清单里但位置比较靠后的项目是一个程序库，通过这个程序库，应用程序可以获取更多有关平板信息和其功能。目前还只是设想阶段。
看以前的更改清单，绝大多数得开发和维护工作都是 Ping Cheng 做的。直到0.10.x系列的版本，包括你在内，有六个人好像突然的冒出来似的。你们是在周围打转了一段时间后，突然闯进来的，还是这这是个新团队的组建？
简而言之是 linuxwacom 源代码树是放在 CVS 中的，Ping 基本上是经常做代码提交的事情。我开始的一些补丁提交到了 CVS 中，但是这些提交都比较巨大，于是几乎不可能很难再被找出来，这在 CVS 上十分常见。我很快就很快就受不了这点儿于是就 fork 了驱动。
在做这个过程的同时我也移掉了非 X 驱动部分，因为在我看来，一个 X 驱动的源应该只包含这个 X 驱动（和相关的实用工具）。在源码树中也还有一些重复的——如，一个后来被 evtest 替代了的工具和另一个提供和 xinput 类似功能的工具等。
所以，你看见的数字既是令人迷惑的同时也是正确的。令人迷惑，是因为他们是被夸大的——应该是在 Ping 名下的 1 个提交现在变成是在我们所有人名下的 10 个提交。当然，同时也有新的开发者加入分担了更多的工作。
我知道 Ping Cheng 是在 Wacm Inc., 工作的，但是对 Linux 的支持从来都不算是官方的。不过对新 Bamboo Pen 和 Touch 的支持是紧跟 Wacom 的声明之后就被发布了。你从这个公司里得到多少协助和支持？
Ping 仍然在 Wacom Inc.，但是她如今更多的在内核这方面，有时也为客户 backporting 一些项目。Jason 是 Wacom 方面的“新人”，他在 X 驱动方面做出了非常不錯成绩。在 Bamboo 支持方面，Chris 作出了卓越的贡献，多数 Bamboo 代码都出自他手，不局限于 X 驱动，连内核驱动也有。我不是很清楚他有没有得到 Wacom 的支持。我想他有收到一些平板用来测试吧，这点我不是很确定。
使用 Wacom Cintiq 在 Krita 中绘图，David Revoy 提供图片
所以，显然对 Linux 的支持上，Wacom 有两个全职的员工，他们也有参与一些内部的项目，我们无需知道。所以说 Wacom Inc. 是支持 linuxwacom 项目的。很显然因为这个项目其实也是 Wacom Inc. 发起的。
对于这两个项目，你觉得需要什么帮助吗？
当然需要。我非常开心，以 linuxwacom 项目为中心，我们已经有了个的小社区，但是，我们需要更多的人来测试平板，报告问题，帮助我们修复 bug 和检视补丁。这对 GNOME 控制中心小程序和 gnome-settings-daemon 也是一样的。我不愿意自己完全控制这些， 而更希望有参与到这些工作中来。我还有其他的工作要忙，所以欢迎任何想要参与进来的朋友。
这个好像不属于 linuxwacom 的目标范围里的，但还是我情不自禁要问这个问题：）你觉得将来有可能在 Linux 支持 Wacom Inkling 吗？你知道有人写这个软件吗？
坦白讲，我这也是第一次听到这个产品，所以我真的没法对它说太多。我能说的是从其产品页面来看，要做的支持是转换文件格式转换能力，把该设备提供的文件某种我们能读取的格式。
尽管这和我们当前做的颇有不同，但也不代表绝对在 linuxwacom 项目的之外。我们当然可以提供项目存储控件和 wiki 的访问权。如果有人在做这个，而且看到了这文章，请告我一声，我们可以一起来解决。
感谢你的回复！
译注：文章中的，applet 全部翻译成小程序； tablet全部翻译成平板。
