如何调试iptables [CentOS 7]

首先,来一张非常有用的图:

基础知识

iptables可以jump到TRACE目标,开启包追踪(packet tracing)选项。

iptables有一个raw表,基本上是iptables最先处理包的地方。

 开始调试

在最入口的位置给符合条件的包开启包追踪,比如对所有进入的icmp包:

iptables -t raw -I PREROUTING -p icmp -j TRACE

有的时候,还需要加载需要的模块(CentOS 7下):

modprobe nf_log_ipv4

然后你就可以在/var/log/messages看到包追踪信息了。

关闭

删除掉TRACE规则即可:

iptables -t raw -D PREROUTING 1

这是一次对机器ping产生的trace信息:

 可以看到,firewalld强行加戏:)

Oct 21 15:34:50 vultr kernel: TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PREROUTING_direct:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PREROUTING:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PREROUTING_ZONES_SOURCE:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PREROUTING:rule:3 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PREROUTING_ZONES:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PRE_public:rule:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PRE_public_log:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PRE_public:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PRE_public_deny:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PRE_public:rule:3 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PRE_public_allow:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PRE_public:return:4 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:PREROUTING:policy:4 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING_direct:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING_ZONES_SOURCE:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING:rule:3 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING_ZONES:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PRE_public:rule:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PRE_public_log:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PRE_public:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PRE_public_deny:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PRE_public:rule:3 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PRE_public_allow:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PRE_public:return:4 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING:rule:4 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:DOCKER:return:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:PREROUTING:policy:5 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:INPUT:rule:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:INPUT_direct:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: mangle:INPUT:policy:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:INPUT:rule:3 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:INPUT_direct:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:INPUT:rule:4 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:INPUT_ZONES_SOURCE:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:INPUT:rule:5 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:INPUT_ZONES:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:IN_public:rule:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:IN_public_log:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:IN_public:rule:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:IN_public_deny:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:IN_public:rule:3 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:IN_public_allow:return:13 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: filter:IN_public:rule:4 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: security:INPUT:rule:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: security:INPUT_direct:return:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: security:INPUT:policy:2 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0
Oct 21 15:34:50 vultr kernel: TRACE: nat:INPUT:policy:1 IN=eth0 OUT= MAC=56:00:00:7c:40:0c:fe:00:00:7c:40:0c:08:00 SRC=183.192.89.160 DST=1.2.53.225 LEN=84 TOS=0x04 PREC=0x00 TTL=43 ID=32583 PROTO=ICMP TYPE=8 CODE=0 ID=8765 SEQ=0

参考资料

Hello Wayland — Wayland教程

翻译自https://hdante.wordpress.com/2014/07/08/the-hello-wayland-tutorial/

TLDR

我写了一个wayland下的hello world,源码在 https://github.com/hdante/hello_wayland

介绍

从最终用户的角度,很容易理解wayland是什么:它是一个新的窗口系统,它将显示服务器和窗口管理器合并了[1]。从技术角度来看,wayland是为了摆脱传统,使用现代设计来实现一个高效的窗口系统,解决X窗口系统中长期存在的效率问题和一些极端情况[2]。这个教程展示如何实现一个作为wayland客户端的hello world程序、解释基础的wayland概念、创建一个GUI程序的必要流程。hello world程序不需要任何GUI工具包,它直接使用底层的wayland协议,以便解释wayland的基础概念。本教程是我自己研究wayland协议的结果。教程分为两部分。这是第一篇教程,解释所有的概念和程序的高级部分。

再问一次,什么是wayland?

wayland窗口系统的的完整设计分为好几层。如果你下载了wayland library的代码[3],或者你看了下wayland的API[4],你会注意到两层:

  1. 最基础的一层是进程间通讯功能的实现,以及一些实用工具。比如主循环调度器和一些数据类型。大部分这些代码都出现在wayland library中(所有在src文件夹[5]中的内容),并且和窗口系统无关。
  2. 第二层是窗口系统协议。它的描述在protocol/wayland.xml[6]文件中,这个文件应该算是一种接口定义语言。IDL文件可以用wayland-scanner 工具处理,并在 wayland-client-protocol.h 和 wayland-server-protocol.h中生成代理方法。协议定义了客户端程序和显示服务器的基础功能。比如访问输入设备、注册共享缓存以便显示在屏幕上。wayland library并不实现这些协议。这些协议的实现被分割到一个第三方层。服务端的参考实现是weston的一部分[7],它在客户端和服务端都定义了一些附加层。以实现wayland协议。在hello world程序中,我们并不需要了解任何关于weston的东西。我们仅仅需要IDL文件。

从上面关于wayland library的描述中,我们发现wayland的三个定义。它是一个(额听用途的)IPC库,不像D-Bus库,它仅仅用于显示服务器,并且它没有定义wayland到底是什么、wayland协议的定义以及如何找到协议定义。我相信即使人们在阅读官方文档后,大部分人也不明白wayland到底是什么。我想,这三个定义澄清了“什么是wayland”这个问题,每一个定义都能够用在不同的上下文中。

Hello, World!

介绍的部分已经够长了,我们来看看hello world的代码:

#include <fcntl.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <wayland-client.h>

#include "helpers.h"

static const unsigned WIDTH = 320;
static const unsigned HEIGHT = 200;
static const unsigned CURSOR_WIDTH = 100;
static const unsigned CURSOR_HEIGHT = 59;
static const int32_t CURSOR_HOT_SPOT_X = 10;
static const int32_t CURSOR_HOT_SPOT_Y = 35;

static bool done = false;

void on_button(uint32_t button)
{
    done = true;
}

int main(void)
{
    struct wl_buffer *buffer;
    struct wl_shm_pool *pool;
    struct wl_shell_surface *surface;
    int image;

    hello_setup_wayland();

    image = open("images.bin", O_RDWR);

    if (image < 0) {
        perror("Error opening surface image");
        return EXIT_FAILURE;
    }

    pool = hello_create_memory_pool(image);
    surface = hello_create_surface();
    buffer = hello_create_buffer(pool, WIDTH, HEIGHT);
    hello_bind_buffer(buffer, surface);
    hello_set_cursor_from_pool(pool, CURSOR_WIDTH,
        CURSOR_HEIGHT, CURSOR_HOT_SPOT_X, CURSOR_HOT_SPOT_Y);
    hello_set_button_callback(surface, on_button);

    while (!done) {
        if (wl_display_dispatch(display) < 0) {
            perror("Main loop error");
            done = true;
        }
    }

    fprintf(stderr, "Exiting sample wayland client...\n");

    hello_free_cursor();
    hello_free_buffer(buffer);
    hello_free_surface(surface);
    hello_free_memory_pool(pool);
    close(image);
    hello_cleanup_wayland();

    return EXIT_SUCCESS;
}

wayland协议太啰嗦,所以我将代码分成两部分,包含了协议细节的部分以及其他部分。主模块,如上所述,包含了高级层面的hello world实现。main函数代表与显示服务器进行通信以显示hello world窗口并接受指针设备输入所需的完整步骤,在单击时关闭应用程序。代码的相关部分的描述如下:

#include "helpers.h"

helper模块包含了hello_*函数和wayland中的一大堆全局对象。全局根对象是一个名字为display的对象,代表了一个与显示服务器的连接,并且被用于发送请求、接受事件。在运行主循环的时候,也会用到display对象。在本教程的下一部分中将详细介绍helper模块。

static const unsigned WIDTH = 320;
static const unsigned HEIGHT = 200;
static const unsigned CURSOR_WIDTH = 100;
static const unsigned CURSOR_HEIGHT = 59;
static const int32_t CURSOR_HOT_SPOT_X = 10;
static const int32_t CURSOR_HOT_SPOT_Y = 35;
在本教程中,我们将一个图像显示为主窗口,另一个用于显示光标。 它们的位置是硬编码的。 然而,在一般应用中,值将被动态计算。
void on_button(uint32_t button)
{
    done = true;
}

这是按钮回调。当一个按钮被点击的时候,我们设置done为true,可以让我们离开main中的主循环。

hello_setup_wayland();

程序开始就会调用setup函数,连接到显示服务器,从服务器请求一系列的全局对象,填充到代理变量中去。

image = open("images.bin", O_RDWR);

然后,我们打开图片文件。这个图片文件包含了硬编码的图片,已经是显示用的数据格式了:它是显示用的像素值。

pool = hello_create_memory_pool(image);

wayland的主要设计哲学就是处理图像的时候更加高效。wayland使用在客户端和服务器端共享内存的方式达到这个目标,所以数据不会在服务器和客户端之间复制。客户端和服务器端共享的基本元素就是共享内存池,就是一段内存被mmap到客户端和服务器端。在内存池中,一系列图片能够被当作缓存对象添加到其中,这些图片也都是共享的。

在hello world程序中,我们mmap了我们的硬编码图像文件。在一般程序中,会创建一个空的内存池,比如用shm_open()创建一个共享内存对象,然后用展示widget的图片,动态构造图片缓存。在写hello world程序的时候,我必须决定我应不应该创建空的内存池、分配内存,以及哪种方式更容易理解。或者我使用一个不太直观的例子来创建一个预建内存池。我决定用这个直观的例子,有一个重要的原因:如果你阅读整个hello world的源代码,你会发现在任何地方都没有内存复制操作。图像文件打开一次,并显示一次。不需要额外的副本。这样做是为了明确指出,如果认真实施,wayalnd应用程序可以实现效率最大化。

surface = hello_create_surface();

代表了可见元素的对象变成了平面。平面是一个长方形区域,有自己的位置和大小。平面被缓冲对象填充。在平面的生命周期中,将附加几个缓冲区作为平面内容,并且会求服务器重绘平面。在hello world例子中,平面对象的类型是wl_shell_surface,被用来创建顶级窗口。

buffer = hello_create_buffer(pool, WIDTH, HEIGHT);

缓冲对象里面有平面要显示的内容。缓冲在内存池中被创建(它们是内存池切片),以便它们由客户端和服务器共享。在我们的例子中,我们不会创建一个空的缓冲对象,我们用一个已经填充好数据的的缓冲对象。

hello_bind_buffer(buffer, surface);

为了使缓冲区显示到屏幕,我们需要将缓冲区数据绑定到平面,也就是将平面内容设置为缓冲区数据。绑定操作也会讲平面提交到服务器。在wayland中,有一个平面所有权的概念:要不就是客户端拥有平面:客户端可以在平面上绘制(服务端复制了一份旧的平面);要不就是服务端拥有平面:客户端无法修改平面,因为服务器正在屏幕上绘制它。为了将所有权转移到服务器,我们给服务器提交请求;为了将所有权返回给客户端,服务器发送一个release事件。在一般应用程序中,表面将来回转移所有权,但在hello应用程序中,只需执行一次即可,作为绑定操作的一部分。

hello_set_cursor_from_pool(pool, CURSOR_WIDTH,
    CURSOR_HEIGHT, CURSOR_HOT_SPOT_X, CURSOR_HOT_SPOT_Y);

设置了主窗口了之后,我们来配置鼠标指针。这是必须的步骤:客户端必须设置鼠标指针。在这儿,我们将鼠标指针设置为内存池中的内容。helper模块为鼠标指针创建一个平面和缓冲对象。我必须决定是将指针配置放在helper里面,还是将它放到外面的高层逻辑里面来。我决定用后者,来展示wayland中的角色划分:客户端能够控制绘制什么、如何绘制。

hello_set_button_callback(surface, on_button);

设置的最后一步是设置回调:将界面点击和on_callback回调关联起来。

while (!done) {
    if (wl_display_dispatch(display) < 0) {
        perror("Main loop error");
        done = true;
    }
}

这段代码调用主循环,将全局变量display作为参数。当done为true的时候,主循环退出——或者因为出错了,或者因为按钮被点击了。

hello_free_cursor();
hello_free_buffer(buffer);
hello_free_surface(surface);
hello_free_memory_pool(pool);
close(image);
hello_cleanup_wayland();

程序结束了,清理所有我们申请的资源。

总结

这是wayland的hello world教程的第一部分。主要讨论什么是wayland,如何描述操作,在一个高级的例子中。在下一部分,我将会详细介绍helper函数。

截图

原作者截图:

我的截图:

参考

[1] http://wayland.freedesktop.org/architecture.html
[2] http://mirror.linux.org.au/linux.conf.au/2013/ogv/The_real_story_behind_Wayland_and_X.ogv
[3] http://cgit.freedesktop.org/wayland/wayland/tree/
[4] http://wayland.freedesktop.org/docs/html/
[5] http://cgit.freedesktop.org/wayland/wayland/tree/src
[6] http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml
[7] http://cgit.freedesktop.org/wayland/weston/tree/

推荐下目前在用的云存储厂商又拍云

最近在做一个 https://packagist.org 的镜像,所以需要一个CDN来做国内加速。国内比较适合的也就七牛和又拍云了。

作为CDN

后来比较了下,发现七牛仅仅是做存储,它会忽略用户设置的超时时间(Cache-Control 字段)。而又拍云则会遵守源站的缓存设置。

比如我如果设置我的url缓存为5min,那又拍云就只会保留缓存5min。

在这一点上,又拍云就做的非常好,可以选择存储模式,也可以选择CDN模式。当然,更重要的一点是有免费额度。相比七牛的免费额度来讲,确实比较宽裕。

比如,我的这个项目,源站是在我的vps上,接受http访问。那我只需要将空间的回源设置如图即可:

支持SSL/TLS

为了让我的域名支持SSL/TLS,我只需在云拍云上花费0元购买Let’s Encrypt的SSL证书,然后补全信息即可。

如图:

我绑定了又拍云,然后又拍云直接向Let’s Encrypt申请DV证书,绑定到域名就行。

相比其他服务商,需要手动上传服务器证书,确实方便了很多。而且自己手动申请的Let’s Encrypt证书,需要每90天更新一次,所以还是直接交给又拍云比较方便。

云存储

和云存储厂商一样,又拍云也提供了对象存储服务。

基本的文件操作都是支持的。当然,也必须支持断点续传,对于上传大文件来说,这个尤其方便。

还可以给文件添加各种自定义的元数据,比如我可以给文件设置x-upyun-meta-sha512: 123456,可以参考https://docs.upyun.com/api/rest_api/#metadata

但是这儿也有一些坑:

比如,获取文件信息:

MD5算法确实有很严重的漏洞,容易产生重复的哈希值。建议又拍云下一版换成sha512算法。

还有,如果我设置了自定义元数据,比如x-upyun-meta-sha512: 123456,那我只能通过下载文件接口来获取这个元数据,通过获取文件信息接口反而没有自定义的元数据,这一点很不方便。

文件拉取

做镜像的过程中,很重要的一个点就是文件拉取。

比如,我要代理laravel的下载地址:https://github.com/laravel/framework/archive/v5.5.13.zip,我只需要将url拉取到又拍云上对应的地址就好。

但是,由于要使用回调,在调试的时候很不方便,所以目前我用的比较少。

建议又拍云在拉取文件的时候,给拉取任务一个id,然后客户端根据这个id查询拉取状态,会方便开发。

又拍云重度用户

这个项目很依赖CDN,所以很耗流量。


最后,附上我的邀请链接:

https://upyun.com/

Cannot install MySQL-python at macOS 10.13 Beta

Round #1

Complete output from command python setup.py egg_info:
    sh: mysql_config: command not found

Solution

brew install mysql
# or
brew reinstall mysql

Round #2

clang -bundle -undefined dynamic_lookup ****/_mysql.o -L/usr/local/Cellar/mysql/5.7.18_1/lib -lmysqlclient -lssl -lcrypto -o build/lib.macosx-10.12-x86_64-2.7/_mysql.so
ld: library not found for -lssl

Solution

brew install openssl
export LDFLAGS="-I/usr/local/opt/openssl/include -L/usr/local/opt/openssl/lib"
pip install mysql-python

Sometimes, you need xcode-select --install

[译]输入系统如何工作——指针输入

翻译自 How input works – pointer input

上一篇博文中,我讨论了键盘输入。这篇博文将会讨论指针设备——多被称为鼠标。就像本系列文章一样,本文仅仅讨论了KWin/Wayland上面的情形。

不同的硬件类型

有好几种不同的设备被识别为指针设备。有轨迹球这样的传统鼠标,也有在笔记本上的触摸板。此外,还有可绝对定位的设备,比如触摸屏。

在libinput中,对于不同的设备,有很多不同的选项可供配置。比如指针加速等其他选项。我们正在开发Wayland的触摸板配置模块,看起来会合并到Plasma 5.9中。像第一篇博文描述的,一旦设备创建,一系列配置选项会被立马设置。

指针运动

指针设备生成不同种类的事件,其中一种就是指针运动事件。通常来说,有两种指针运动事件:绝对运动和相对运动。大多数设备,比如鼠标,产生相对运动事件,所以我们在本文中只关注相对运动事件。

确定新的位置

相对运动是一组带x和y坐标的距离向量,它描述了指针位置该如何移动。

所以,一旦事件从KWin队列中读取出来,需要确定新的指针位置。这并不单单是最后的指针位置再加上一个运动向量。这会导致指针离开可视区域。

相反,指针运动得验证和约束。我们确保光标不会离开可视区域,并且还要遵守应用程序窗口对指针的约束。

这是KWin在Plasma 5.9中支持的新协议。它允许Wayland窗口将指针锁定到某个位置或将指针限制在某个区域。在第一种情况下,指针根本不移动,在第二种情况下,只允许指针在窗口的特定区域移动。

处理新的位置

即使在光标被限定的情况下,不需要移动鼠标指针,事件也会得到进一步处理。即使光标不移动,应用程序也可能对相对运动感兴趣,并对其做出反应。

像键盘的情况一样,为了进一步处理,会生成QMouseEvent并发送到KWin的输入过滤器。指针运动可能在KWin内部处理,例如:指针位置超出了当前的屏幕边缘。或者通过KWayland将指针运动转发到窗口。

更新获取焦点的窗口

如果指针移动,光标可能从一个窗口移动到另一个窗口,或从窗口移动到Wayland服务器端的窗口装饰上。这意味着对于每个指针位置的变化,KWin需要计算当前位置的窗口。

与键盘输入相比,KWin只需要考虑活动窗口,但这也是一个相当复杂的任务。我们需要考虑将输入变换应用于屏幕还是窗口,我们需要在窗口上应用输入掩码,考虑窗口装饰,检查屏幕是否被锁定,Xwayland 1.18之前的临时解决方案等一大堆问题。

最后,该方法可能已经确定了一个获得指针焦点的新平面。KWin使用KWayland来更新聚焦的指针表面,确保离开旧表面和进入新平面的事件触发。

当然,当移动鼠标时,应该更新焦点。如果拖放(按下指针按钮并移动),则不会更新焦点。

更新指针图案

如果指针移动到新的位置,指针图标有可能会改变。不幸的是,这可能需要多次往返消息才能确定。窗口管理器不知道窗口想要使用哪个指针图标,直到动作被发送到窗口。一个窗口可以通过两种方式做出反应:它可以更新光标图像,也可以不更新。在第一种情况下,KWin通过KWayland通知图像发生变化,在第二种情况下根本没有通知。

这意味着移动光标时,KWin不知道光标图标是否是正确的。所以在指针运动时,KWin更新光标到新的位置,但是光标图标仍然是旧的,但可能在一帧之后,客户端就会更新光标图案了。不得不说,在Wayland的显示下,并不是每一帧都是完美的,这是我遇到的唯一一个此类情况:光标可能显示错误的图标。

进入窗口时,光标尚未定义。直到窗口设置光标,否则光标还是未设置的状态。此时,KWin不会渲染光标;这意味着当进入冻结窗口(程序无响应的窗口)时,我们没有光标。我们以后必须改进这一点。目前,我们没有检测挂起的应用程序,因为我认为我们无法检测到它们:客户端使用专用的Wayland事件线程,因此程序可以永远给一切事件回复OK,即使事件并没有处理。

但是,KWin也可能需要设置一个光标图像。例如,当鼠标在窗户装饰上悬停,或进入特殊模式以选择窗口时,就使用KWin提供的光标图像。KWin从主题中加载这个光标图案。在内部,KWin记录光标图案应该使用的源图像。无论是Wayland窗口还是窗口选择界面,还是使用特定的光标图像。

更新实际光标

通过KWin的内部平台API实现光标位置和图标的实际更新。每个平台以不同的方式设置光标图像。对于我们的主要平台,我们使用DRM API来更新位置并更新图标——如果有新图标的话。

对于Wayland中嵌套的X11这样的嵌套平台,这通过窗口系统内的特定的调用处理。嵌套平台不允许更新光标位置——这是由窗口系统之间通过指针运动间接更新的。但是,光标图案可以更新。

虚拟出来的平台只知道软件指针的概念。这是在合成器渲染过程中渲染出来的光标。目前这只有在QPainter合成器中实现,在OpenGL合成器中还没有实现。

按钮事件

libinput支持指针设备产生的指针按钮的按下、释放事件。这些事件携带着它们触发的指针按钮。

和指针运动事件相比,按钮事件的处理更加直接。指针事件被事件过滤器拦截(比如Alt+Tab)或者被转发到当前获取焦点的窗口。

这相比于X11,是一个巨大的进步。在X11下,如果KWin希望独占的处理指针事件,则需要锁定指针。这意味着屏幕无法锁定。如果当前窗口处于活动状态,屏幕不锁定。在Wayland,这并不重要。如果当前窗口处于活动状态,屏幕可以锁定,也可以获取所有指针事件。一旦解锁当前的窗口仍然是活动窗口。“我”很轻松地为这种情况添加了自动测试。

轴事件

许多指针设备有一个或者两个轴。在X11的核心协议中,轴事件被实现为指针按钮。在Wayland和libinput的情况下,我们有了自己的轴事件,能告诉我们哪个轴被移动了,移动了多少。这是一个很大的提升,相比于X11,这意味着“平滑滚动”是标准的一部分了,在滚动事件的处理过程中,额外的事件处理部分也不会执行。

其他事件的处理也非常简单。KWin创建了一个QWheelEvent并将其传递给许多事件过滤器,如果过滤器没有拦截事件,它会被转发到KWayland::Server,KWayland::Server再把事件发送到获得焦点的指针平面。

触摸板手势

对于触摸板,我们还有别的事件。对于触摸板,Libinput不仅仅识别运动事件和按压事件,还能识别多指手势。它支持两种手势:滑动手势,捏合/旋转手势。KWin获取手势事件,转发给正常的事件系统。我们在Wayland协议中添加了特殊的支持。这允许转发鼠标手势Wayland应用程序,如视频所见。

很不幸,我们还没有真正地使用这些手势。QtWayland没有实现这个协议,所以转发的消息并不会到达应用程序,我们还没有使用它,比如全局手势就没有使用,我们仍在努力界定我们要支持的手势。我希望我们在Plasma 5.9能够改进这点,但是这也不确定。

假期愉快

这是“我”今年的最后一篇博客。下一年我将继续这一系列博客,会谈谈触摸屏事件,或许会包括数位版。

“我”希望每个人都有一个愉快的假期,在2017年有一个不错的开始。

如果你想支持“我”的工作,请考虑捐款。让世界变得更好!——KDE 2016年末募捐

如何在Linux/Fedora下编译安装为知笔记

虽然为知收费了,但是目前只有为知笔记的Linux客户端做的不错,也只能用它了。

首先,安装编译期间的依赖:

# git拉代码,cmake编译
sudo dnf install -y git cmake
# 编译器
sudo dnf install -y gcc gcc-c++
# qt5相关的包
sudo dnf install -y qt5-qtbase-devel qt5-linguist qt5-qtwebengine-devel qt5-qtwebsockets-devel

sudo dnf install -y zlib-devel

拉代码(此处以v2.5.0分支为例):

git clone https://github.com/WizTeam/WizQTClient.git
cd /path/to/WizQTClient
git checkout v2.5.0

编译:

# 安装到~/.local/目录
cmake . -DCMAKE_INSTALL_PREFIX=$HOME/.local/
# -j 参数加速编译
make -j $(nproc)
# 安装
make install

安装完成后,为知笔记位于$HOME/.local/bin/WizNote,也可以在应用列表中找到。


  • 编译的时候cmake检测模块不通过,会提示如下错误:
CMake Error at cmake/QtChooser.cmake:1 (find_package):
  By not providing "FindQt5.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Qt5", but
  CMake did not find one.
  Could not find a package configuration file provided by "Qt5" with any of
  the following names:
    Qt5Config.cmake
    qt5-config.cmake

你只需要通过dnf provides */Qt5Config.cmake 命令来找找哪个包提供了,比如qt5-qtbase-devel

  • make的时候会报:
lib/quazip/zip.h:56:18: fatal error: zlib.h: No such file or directory
 #include "zlib.h"

也是一样的处理方式,使用dnf provides */zlib.h 找到包,比如zlib-devel

  • 为什么使用 $HOME/.local/ 作为安装目录:

首先,/usr/local 作为安装目录,需要root权限才能安装,删除的时候也不好删除,因为/usr/local/ 下可能也有别的软件。

其次,/opt/wiznote 作为安装目录,也需要root权限,而且也会导致wiznote.desktop中申明的图标名称找不到。

$HOME/.local/ 作为安装目录,生成的wiznote.desktop开箱即用,也不需要root权限,比较方便。

[译]输入系统如何工作——键盘输入

本文是 How input works – Keyboard input 的翻译。

上一篇博文中,我[作者]解释了KWin中,输入设备是如何打开和处理的。在这篇博文中,我们将仔细关注下键盘设备和键盘事件。

键盘并不总是键盘

在Linux中,键盘是一个非常奇特的设备。你不会只有一个键盘,你肯定会有很多个。很多设备宣称自己是键盘,但是只支持一个键。比如,电源按钮或者带静音按钮、音量加减按钮的外置耳机。从输入系统的角度来看,这些设备也是键盘。

对于KWin,发现真正支持的键盘是很重要的。如果没有一个“真的”键盘连接(或者说开启),我们的虚拟键盘应该自动激活。比如,如果你从平板PC二合一设备上拔了键盘,它应该转换为平板模式,即有虚拟键盘的模式。如果连接上了键盘,虚拟键盘就不是主要的输入设备了。libinput提供了函数来检测键盘支持哪些键。我们使用这个功能来区分不同的键盘类型。

键盘事件

在这里,键盘是最简单的输入设备。libinput仅仅触发一个LIBINPUT_EVENT_KEYBOARD_KEY事件,并包含了被按下或者释放的键。KWin有一个专用线程,用来从libinput读取事件。所以这些事件现在仅仅是放在处理队列中,主线程同时也得到新事件通知。一旦主线程处理事件,事件就被转换成我们的输入重定向类。不管事件是通过哪种源头抵达,所有输入事件都会通过输入重定向。KWin不仅仅支持来自libinput的事件,并且支持嵌套会话(即KWin运行在X11之上,或者在另一个Wayland服务器之上),还有在集成测试中使用的模拟事件。这意味着一旦事件到达输入重定向,我们基本上就丢失了事件来自哪个设备这些信息。最近,我们扩展了内部API,可以在事件处理函数中包含设备源,这是可选的。可以在调试终端中使用,来显示哪些设备产生了哪些事件。

xkbcommon

现在,一个键的按下、释放事件到达了中心分发方法KeyboardInputRedirection::processKey。第一件也是重要的一件事就是在xbkcommon中更新键盘状态。xkbcommon被用将物理键为事件,转换过程根据键盘布局、键盘状态(比如激活的修饰符)来进行。比如:如果我按下了“y”键(键码是21)并且“Shift”键是按下的状态,在德语键盘布局下,就会创建“Z”按下的事件;但是在英语键盘布局下,它会是“Y”。

在KWin中,我们将所有需要的xkbcommon功能都封装到Xkb类中。这个类追踪活跃的键盘布局、执行键盘布局切换(当布局变换的时候展示OSD)。它知道上一次按键的符号,当前活跃的修饰符和快捷键相关的修饰符。

当xkb的状态更新的时候,我们也检查很多键盘状态变更。用户是不是激活了数字锁定?如果是这样,我们需要让键盘上的LED做对应的变化,所以我们的libinput代码能够更新物理键盘上LED的状态。修饰副是不是变掉了?如果是这样,我们要将新的修饰符集合通知给Wayland窗口。尽管实际上从key到符号的翻译发生在Wayland客户端,但刚刚讲的翻译过程也在Wayland服务端进行了。为什么KWin也要做这一层翻译呢?这是因为KWin也需要在很多地方使用键盘符号,比如在当前窗口中过滤按键,来实现全局快捷键。

调试终端中的键盘状态

Xkb状态更新功能也能够处理哪些只需要修饰符键就能触发的快捷键。实际上,在这儿处理是不对的,但我们的输入过滤代码没法保证能捕获到所有的输入事件。对于快捷键中的修饰符,看多所有的事件是很基础的需求。所以,唯一的处理地方只能在Xkb中了。这不是最优雅的解决方案,但是能工作。这个功能也被X11使用,我在之前的博文中讲过。

KWin的过滤

现在KWin有足够的信息来处理键盘事件。对于此,它创建自定义的QKeyEvent并将其送到输入过滤链。KWin的输入处理使用了输入过滤器组成的链。每个过滤器都能够对事件做一系列操作,并决定这个事件是不是应该被继续处理,或结束处理。

比如,我们有锁屏过滤器。如果屏幕是锁屏状态,这个过滤器就会过滤事件处理,确保事件只会被送到屏幕锁定程序,不会被其他窗口处理。或者这儿有一个过滤器,确保ctrl+alt+f1在锁屏情况下仍然能够工作。另一个过滤器用来处理全局快捷键,一个将事件传递给特效系统,比如窗口轮转。

在调试终端中,一个输入事件过滤器显示被按下的键

最后一个过滤器是我们的转发过滤器。这个过滤器的任务是转发事件到窗口。它将事件从当前活动的Wayland平面,传递到KWayland::Server。

获得键盘输入焦点的Wayland表面

Wayland服务器需要获取了键盘焦点的平面。在获取了键盘焦点的情况下,KWin相比而言微不足道。KWin有一个叫活动窗口的概念。在转发事件之前,KWin会检查哪个是键盘焦点窗口。如果有一个活动窗口,则该窗口平面被标记为KWayland::Server中的键盘焦点平面。

我们的KWayland::Server库关注发送丢失键盘焦点和获取键盘焦点事件到窗口,所以KWin不需要关注这些。这是我们有一个KWayland::Server抽象层的优势——和混成器无关的一切都在库中被处理了。

Wayland中键盘事件的处理

之前提到的转发过滤器更新键盘平面,并且将当前键盘事件发送到Wayland客户端。对于所有在keysymbol中的处理,都不需要了。key code已经送到了客户端。

客户端从回调中得到键盘事件,现在也将其送到xkbcommon。在Wayland中,keymap从服务端送到客户端,以便服务端和客户端有同样的keymap。客户端现在将key code转换成key symbol,和之前KWin做的一样。

接下来的事件处理在客户端完成。比如在QT中,这一步会产生QKeyEvent,然后送到当前输入焦点的widget。

重复输入键

键盘输入也有一些特殊的模式:重复键。当一些键被按下,产生重复的键输入。KWin使用来自键盘模块的配置来决定什么时候、什么频率来产生重复的按键。一个重复的键不会被转发到KWayland客户端。而是KWin通过Wayland键盘协议告诉键重复的设定,而不是被客户端直接处理。

不幸的是,QT中这个是不能工作的,使用的是硬编码。所以当前在Plasma Wayland的会话中,根据使用的GUI库不同,对重复键的支持很破碎。如果运行在Wayland上的话,KWin支持是正常的,X11程序是对的,GTK程序是对的,QT程序是错的。


如果你想支持我们[作者]的工作,请考虑捐助

ssh卡在debug1: SSH2_MSG_KEXINIT sent的解决办法

在公司通过kerberos登录ssh,完全没有问题。但是在家里通过l2tp连接vpn后,就无法登录了。

通过ssh -v查看日志,发现卡在debug1: SSH2_MSG_KEXINIT sent这一步。

查了下,发现是因为mtu设置太大


但是由于系统的网络是NetworkManager管理的,如果需要自动设置mtu,connection的配置中并没有vpn对应的mtu设置。后来,看了有人使用dispatcher脚本来设置。

创建/etc/NetworkManager/dispatcher.d/vpn-up文件:

#!/bin/sh

if [ "$2" = "vpn-up" ]; then
        ip link set "$1" mtu 1350
fi

然后vpn连接的时候,就会自动设置mtu了。

[译]输入系统如何工作——创建设备

本文是How input works – creating a Device的翻译。

最近,我[作者]在KWin/Wayland输入栈上做了一些工作,比如实现了鼠标手势和鼠标限制协议(pointer constraints protocol),并且想写一些系列博客来描述输入事件是如何从设备传递到应用的。在第一篇博文中,我将关注于创建和配置输入设备,以及与此相关的其他事情。

evdev

Linux内核通过evdev API来产生输入事件。如果你对evdev如何工作感兴趣,我推荐你读一读Peter Hutterer写的优秀的博文。对于我们关注的层面来说,输入事件API太底层了,我们仅仅想用对它的一个抽象。

libinput 和设备文件

对输入事件API的抽象叫做libinput。它允许我们得到通知,不论何时添加、删除输入设备、不论何时产生输入事件。但是别急,我们首先需要打开输入设备,这是我们的第一个挑战。

正常情况下,设备文件不能被用户读取。这有好的一面,否则每个程序都能够读取所有的键盘事件。这种情况下,键盘记录器太容易实现了。

但是如果KWin以普通用户的方式运行,普通用户又无法读取设备文件,那KWin如何获取输入?为了让KWin获取输入,我们需要特殊的支持。libinput就是为这种情况准备的,它自己不会尝试打开文件,它会使用用户提供的open_restricted函数。KWin就是这么干的,并将打开文件的任务交给了logind。logind允许一个进程控制当前登录会话。并且这个登录会话的控制进程可以打开一些设备文件。所以KWin和logind的dbus API交互,成为登录会话的控制进程,通过logind的API打开设备文件,并将其传递回libinput。

这也是为什么对于整个Wayland会话,KWin在运行时依赖logind的DBus接口。请注意,这并不意味着你需要使用logind或者sysemd。这仅仅意味着需要一个进程来同logind的DBus接口通讯。

KWin中的设备

现在libinput已经准备好打开设备文件,并且为每个设备触发了LIBINPUT_EVENT_DEVICE_ADDED事件。KWin为每一种设备类型创建了一个小的门面类,来应用设备的配置。KWin支持读取Plasma的鼠标配置模块中的配置选项。并且KWin打开了LED灯,如果设备支持LED灯的话,比如数字锁定灯和大写锁定灯,这也是设备配置过程的一部分。

所有的输入设备都被KWin创建,并且可以在调试终端显示(打开KRunner,输入“KWin”)。KWin从libinput中读取了很多关于设备的信息,并展示在调试终端中。在输入事件选项卡中,每种事件都包含了设备产生该事件的一些信息。

所有的设备也通过DBus暴露出来,和KWin的调试终端信息一样。这意味着可以通过DBus来动态修改配置。不过,KWin在成功应用配置后,会将其保存,以确保你在重启系统、或者重新插拔外部设备后,你的设置能够被恢复。这是一个很重要的特性,用来支持触摸板配置模块。

如果你想支持作者的工作,考虑捐赠给作者,让世界变得更美好!——KDE 2016年年终募款