AMD APU (A10-7870K Godavari) * Radeon VCE * AMDGPU * VA-API * ffmpeg

理屈としては解説してきたものの、実際にVA-APIでVCEを叩いたことがなかったのでやってみた。 ついでなので、qsvやnvenc、あるいはlibx264などでも応用できるウェブカメラとスクリーンキャスティングの話もしておく。

基本的な手順は単純で、AMDGPU(事実上現在唯一となったAMDビデオドライバ)を選択した上で、 VA-APIを有効にし、VA-API経由でエンコーディングを行う。

注意点としては古くなったプロプライエタリドライバ(Catalyst)ではなく、AMDGPUドライバーを使用することと、 MESA VAドライバを使用することである。

RadeonはVA-API/VDPAUの両方をサポートしており、NvidiaのようにVDPAUドライバをインストールし、VA VDPAUアダプタを使用するという方法(libva-dvpau-driver)も成立してしまう。 しかし、この場合は動作しなくなるので、必ずMESA VAドライバ(libva-mesa-driver)を使用する必要がある。

その上で基本はこんな感じ。 (Arch/ManjaroのffmpegはVA-APIを含んでいるのでffmpeg云々の話はない)

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 24 -c:a copy outfile.mp4

ffmpeg上でのVA-APIは公式にドキュメントがある

ソースファイルがビデオアクセラレーションが効くのであればUVDをVA-API経由で叩いてデコードすることもできる。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -qp 24 -c:a copy outfile.mp4

ところがこれではうまくいかなかった。 一件成功しているように見えるのだが、フレームの全くないビデオファイルが出来上がってしまい再生できない。

多分、新しいRadeonだとそんなことはないのだろうと思うけれども、Godavari(2015年)のR7グラフィックスでは問題があったため、-profile 578を指定すると解決した。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -i source.avi -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -bf 0 -qp 24 -c:a copy outfile.mp4

ウェブカムからキャプチャする場合はエンコードのみ、入力はv4l2:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f v4l2 -i /dev/video0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 outfile.mp4

さらにマイクをPulseAudio経由で拾う場合。音声は192k AAC:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f v4l2 -i /dev/video0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

X11のスクリーンキャスティング 音声つき。 A10-7870Kだとh264_vaapiは34fpsくらいなので、60fpsはフレーム落ちばかりになる。30fpsも無理で24fpsがドロップしない限界。 ultrafastにした場合は30fpsは可能だけれど60fpsは無理。

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 24 -video_size 1920x1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

ultrafastで30fps:

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size 1920x1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

なお、-video_size-iよりも先に指定することが必須である。基本的にffmpegはオプションは順番に厳しい。

300×300のウィンドウを左上から200×200のオフセットで録画する場合

$ ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size 300x300 -i $DISPLAY+200,200 -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

-video_sizeの指定方法は色々あって、公式ドキュメントで解説されている。 なので、-video_size 1920x1080ならば-video_size hd1080とも書ける。

録画領域を表示するには-show_region 1

$ ffmpeg -show_region 1 -vaapi_device /dev/dri/renderD128 -f x11grab -framerate 30 -video_size hd1080 -i $DISPLAY -vf 'format=nv12,hwupload' -c:v h264_vaapi -profile 578 -preset ultrafast -qp 24 -f alsa -i pulse -c:a aac -b:a 192k outfile.mp4

NVENCだとmkvにもできるので音声はFLACやOpusで撮ることもできるのだけど、AMDGPU VA-APIはmp4だけ

使ってみた感想としては、QSVと違ってCPUがあくのは良いけれど、R7の速度自体がCPUと大差ない(libx264でやったのと同程度)であるため、ちょっと微妙かもしれない。 A10でもスクリーンキャスティングしながら配信みたいなことができるというメリットはあるけれども。

Linux: 特定のアドレスに到達しないことを明示する (route/ipコマンド)

open-iscsiを用いたiSCSIイニシエータの場合、iSCSIターゲットが複数のIPアドレスを持っているとMultipathによってその全てのアドレスで接続しようとする。

だが、例えば192.168.1.0/24に属するコンピュータで、192.168.1.0/24, 192.168.2.0/24の両方に属しているNASを使おうとすると、192.168.2.0/24に対する経路がなければタイムアウトするまでひどく待たされることになる。 デフォルトゲートウェイ経由で192.168.2.0/24に対するパケットを投げ続けるためだ。

そこで、このコンピュータは192.168.2.0/24には通じていないことを明示して、即座に失敗させたい。

これはネットワークマネージャの設定では行うことができない。 コマンドで行う必要がある。

routeコマンドに関してはManpageに書いてあるのでわかりやすい。

# route add 192.168.2.0 netmask 255.255.255.0 reject

だが、Arch Linux系列のディストリビューションで標準採用されるipコマンド (iproute2) のほうは1Manpageがものすごく読みにくい上に日本語訳もされていないのでちょっと大変だ。 ipコマンドの場合は次のようにする。

# ip route add prohibit 192.168.2.0/24

これにより192.168.2.0/24に対する接続はそもそも禁止されることになる。

% ping 192.168.2.64
Do you want to ping broadcast? Then -b. If not, check your local firewall rules.
% telnet 192.168.2.64
Trying 192.168.2.64...
telnet: Unable to connect to remote host: 許可がありません

  1. そもそもrouteやifconfigなどを使わず、iproute2(ip)を使うということをどれくらいの人が知っているのだろう? arp, ifconfig, iwconfig, nameif, netstat, route を兼ねる仕組みになっており、Manjaro Linuxではこれらのコマンドは標準では入っていない。 digやnslookupも含まれておらず、getentを使用する。

【注意】 Arch/Manjaro 最新 open-iscsi パッケージにバグ

Arch / Manjaro Linux の最新 open-iscsi パッケージをインストールすると、 libopeniscsiusr.so.0.1.0 というライブラリが欠如しているためにiSCSIが動作しなくなる。

システム構成の中核部に採用している場合はシステムが利用できなくなるため要注意。

有志がAURのgitバージョンからビルドした2.0.876-2をアップロードしており、このパッケージはManjaroでもそのまま動作する。

ArchLinux * Nginx * php-fpm * MariaDB * WordPress

慣れている人にとっては常識レベルなのだろうけれど、つまずきどころ満載だったので、メモ。

Nginxのインストール

# pacman -S nginx

PHP / php-fpmのインストール

# pacman -S php-fpm

MariaDBのインストール

“MySQL”と認識している人も多いだろうけれども、 現在は圧倒的にMySQLよりMariaDBが一般的である。

MySQL自体は継続しているが、MySQLを提供しているディストリビューションは非常に少なく、 そもそもアプリケーションが想定しているデータベースもMySQLよりMariaDBのほうが一般的だ。

MariaDBはMySQL5.5から派生したコミュニティベースのデータベースである。

# pacman -S mariadb

有効化する前に 初期設定を行う。

# mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql

そしてセキュアな設定を行う。 (省略しても構わない)

# mysql_secure_installation

リモートホストからのアクセスを拒絶しておく。 /etc/mysql/my.cnfskip-networkingをアンコメントすればOK。この状態でもローカルホストからは接続できる。

これでMariaDBを起動・有効化できる。

PHPの設定

PHPのモジュールが無効になっているので有効にしておく。 これがなければデータベースに接続できず、500 Internal Server Errorになる。

/etc/php/php.iniを編集する。bz2, mysqli, pdo_mysqlを有効にする必要がある。

これをしていないとWordPressの初期設定でデータベース設定後に500エラーになることになり困惑することになる。

これでphp-fpmを起動・有効化できる。

Nginxの設定

まずはサーバー設定を書いておく。 設定を書かない場合、WordPressにアクセス自体できない。

どこに何を書くかという解説はしない(Nginxについて説明をはじめると長い)ので、それを理解しているという前提で進める。 もしろん、コピペでなく値は合わせること。

最低限だとこんな感じ。

server {
  listen 80;
  listen [::]:80;
  server_name blog.example.com;
  root /srv/http/blog/example.com;

  access_log /var/log/nginx/blog-example.log;

          location / {
               index  index.html index.htm index.php;
          }
          location ~ \.php$ {
               fastcgi_index  index.php;
               include        fastcgi.conf;
          }

}

公式の設定から引用するとこんな感じ。

server {
  listen 80;
  listen [::]:80;
  server_name blog.example.com;
  root /srv/http/blog/example.com;


  location / {
    try_files $uri $uri/ /index.php?$args;
  }

  rewrite /wp-admin$ $scheme://$host$uri/ permanent;

  location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires 24h;
    log_not_found off;
  }

  location ~ \.php$ {
    try_files $uri =404;
    
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    include fastcgi_params;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#   fastcgi_intercept_errors on;
    fastcgi_pass php;
  }

}

公式の場合サイト別ではなく上流で次のような設定も必要になる。

upstream php {
  server unix:/run/php-fpm/php-fpm.sock;
}

php-fpmのソケットファイルが間違っている場合、502 Bad Gatewayになる。

WordPressのインストール

「公式パッケージはあるけどWordPress公式からインストールしたほうがいいよ」というのがArchの姿勢。

$ cd /srv/http
$ wget https://wordpress.org/latest.tar.gz
$ tar xvzf latest.tar.gz
$ sudo chown -R http:http wordpress
$ mv wordpress blog/example.com

パーミッションが間違っていると403 Forbiddenになる。 これは主に所有者で、Nginxプロセスの所有にする必要がある。 現在のArch LinuxではNginxプロセスはhttp:httpで動作する。

起動と有効化

# systemctl start nginx
# systemctl enable nginx
# systemctl start mariadb
# systemctl enable mariadb
# systemctl start php-fpm
# systemctl enable php-fpm

php-fpmが起動されていない場合は502 Bad Gateway、MariaDBが起動されていない場合は500 Internal Server Errorになる。

別のWordPressから移行する

WordPressのファイル側にもファイルがあるらしい(どうも画像データはこっちらしい)ので、MySQLのエクスポートと同時にファイルもとっておく必要がある。

取得したファイルはWordPressインストールの代わりに展開し、パーミッション(所有者)を変更する。 パーミッションの変更は忘れがち。

SiteGuardでログインアドレスを変更している場合は、この機能がApacheに依存しているためログインできなくなってしまうので、wp_content/plugins/site-guardを削除しておく。あるいは、エクスポート前にこの機能を無効にしておいてもいい。 ログインページをNginx上で変更したい場合は他のプラグインを仕様する必要がある。私の場合は“Login Rebuilder”を利用した。

従来が第三者サービスなどによって提供されていたWordPressで、データベース名やユーザー名が好ましくない場合、あるいは複数サイトをインストールするために指定したい場合はwp_config.phpも編集。

データベースをインポートする前にデータベースを用意しておく。

# mysql
> create database <database_name>
> create user '<username>'@'localhost'
> grant all privileges on <database_name>.* to '<username>'@'localhost' identified by '<password>'
> quit

そしてインポート

# mysql <database_name> < wordpress_database_file.sql

そんなわけでブログ引っ越し完了

ブログはXdomainの付属サービスから自サーバーに移動した。

これによりパフォーマンスが改善し、またスマートフォンでの閲覧において広告がでなくなった。

パフォーマンスは最善ではない。これはこのサーバーでWordPressだけが動いているわけではないため、リソースをWordPressに大量に割くことができないからだ。 必要ならば将来的にWordPressを独立したサーバーにしてパフォーマンスを向上させたり(Kasanagi導入が妥当だろう)、リソースを増強してパフォーマンスチューニングを行うかもしれない。

現状ではこのChienomiのほうのデイリーPVは1500から6000程度である。 特に広告などを出して収益があるわけでもないので、今のところあまり考えていない。 そうね、ヒューマンユニークがデイリー1500を越えるか、月間1000円以上の広告収入が発生するようなことがあれば考えようかな。

いずれ広告を出す可能性があるにせよ、それはChienomi側で選定しコントロールした話であり、プロバイダー広告が出るのは(広告を出さないというポリシーに基づく)ユーザービリティ的にもパフォーマンス的にもデメリットしかないので、Chienomiがそれなりにアクセスがあることを踏まえて対応した。

AURにfcitx-mozc-neologd-utを上げました

fcitx-mozc-neologd-ut/mozc-neologd-utをメンテナンスされていた方がut2に移行したため、 これらのパッケージがAURからなくなっていた。

そこで、私がAURにputしておいた

これらに関してはupstreamの作者の方(utuhiro氏)がAnterogos使いであるため、 PKGBUILDが標準で用意されている。 私がアップロードしたものはこれを調整したものとなっている。

行った調整は主に次のようなものだ。

  • メンテナの表示を私に
  • pkgnamefcitx-mozc-neologd-utを先に
  • 本体アーカイブをインターネットから取得するように
  • 本体アーカイブのチェックサムの追加
  • makedependsqt5-baseを追加(mozcが要求する)

手法はおおよそ先人に近いもの(fc2 blog))だが、次のような点が違う

  • ダウンロードはupstreamから行っている
  • makedependsなどの調整を行った

ディスク故障でbtrfsの機能を使い倒す

対応方法

ディスク容量が逼迫しているので何らかの対処が必要である。
とりあえず考えられる方法としては

  • ディスクを大容量のものに交換する
  • USBあるいはeSATA接続のディスクを追加する
  • NASを追加してディスクを追加する
  • AoEを使って他ホストのディスクを追加する
  • 内蔵ディスクを追加する

のいずれかだ。そもそも取り扱うデータ量が多いため、削減ということは考えられない。
もちろん、削減自体は行っているが、その精査にあてる時間のほうが重要で、無効な対策であると考えられる。それほど引き延ばすこともできない。

大容量への交換は効果的だが、現在3TBを使用しており、4TBの場合は33%の容量増となり、不足である。
6TB以上は高額すぎるため却下された。

USB/eSATAを最も有力な候補としていたが、台数搭載するためには金額的にも高く、またいずれの製品も信頼性に劣るようだ。

多数搭載のケースを使用するのであればReadyNASも有力な候補だった。ReadyNASはiSCSIに対応するが、「ReadyNASに搭載されているディスクを指定する」ことはできない。何台搭載しても、btrfs的に見れば1台にしかならないのだ。

そのため、btrfsで管理するためにはReadyNASを複数台追加する必要がある。ReadyNAS全体でbtrfsから見て1台のディスクであり、ReadyNASの台数=ディスク台数になる。
btrfsは不均等なRAID1をサポートするため、例えばReadyNASに12TBを搭載すれば12TB RAID1を構成することが可能だが、あまりうれしくはない状態になる。

AoEを使うのは追加費用のかからない方法だ(ディスクとホストはあるため)。
だが、問題はAoEを使う方法は常に

  • マウント前にターゲットホストを起動していなければならない
  • アンマウント前にターゲットホストを終了してはいけない
  • ネットワークを切断してはいけない

と結構厳しい条件になる。
ターゲットホストが消費電力が大きく、また冗長系システムであり、日常稼働しているものであることを考えるとこれは厳しい。

そこで内蔵ディスク追加を選択した。

Z400の3.5inchシャドウベイの数は2、SATAポート数は6である。
現在、iStarUSAの5.25inchベイ*2を3.5inch HDD*3に変換するリムーバブルラックを使用してシステムSSDを含む計5台を搭載している。
そのため、2台追加となると、マウント的にもSATAポート的にも足りない。

採用した方法はエアリアのSATA*2 PCI-e 1xカードによりポートを2増設し、DVDドライブを除去してiStarUSAの5.25inch*3をHDD*5に変換するリムーバブルラックを搭載するというもの。

かなり無茶だが、さらに無茶なのが、そもそもビデオカードがGeForce GTX750Tiに変更されているために、隣のPCI-e 4xが埋まってしまっており、逆側のPCI-e 4xは使用済みなので、PCI-e 16xに接続した、ということか。

ディスク追加手順

ディスクの追加は、ディスクを装着した状態で

# btrfs device add /dev/sdx /path/to/volume
# btrfs device add /dev/sdy /path/to/volume
# btrfs balance /path/to/volume

のようになる。
balanceの所要時間は果てしなく、うちのケースでは40時間ほどかかった。

そして、balanceがまもなく終わろうという頃に、もともとあったほうのディスクが壊れた。

故障ディスクの除去と交換

故障ディスクが正常にアクセスできない状態にあるとき、btrfsファイルシステムへのアクセスはシステム全体を止めてしまう。
この状態ではbtrfs device deleteもできない。

もしこれが可能な状態であればdeleteよりも新規ディスクも装着した状態でのreplaceのほうが早い。

故障ディスクはオフラインの状態でまず除去してしまい、その上で新規ディスクに交換する。
そして、新規ディスクに対して

# btrfs device add /dev/sdx /path/to/volume

したあと、

# btrfs device delete missing /path/to/volume

するとreplaceに近い挙動になる。

しかし、実際にやるとシステムが死んでしまった。ログにがっつりRIPが残っていた。

ファイルシステム新規作成

もはや修復は不可能なので、ファイルシステムを再作成してバックアップから書き戻す。

dm_crypt上に作成するのであれば、dmデバイスを用意したうえで

$ sudo mkfs.btrfs -L labelname -d raid1 -m raid1 /dev/mapper/crypt_dev_*

こうしてみると気づくのだが、btrfsのミラーリングはミラーレッグの指定ができない。
ジャーナリングの強化版というコンセプトなので当然なのかもしれないが、結構不安。本物のRAID1がほしい人はLVMを使うほうが良さそう。LVM+Btrfsであれば、2台ずつ容量を揃える必要があるが、容量の異なるディスクを混在できる。

バックアップのbtrfsファイルシステムからのリストア

btrfsにはsend/receive機能があり、簡単にバックアップができる。

btrfs sendは差分も可能でストリームで送られる。つまりファイルとして保存することもできる。
この場合復元はcatによって行うことになるだろう。差分だとどうなるのかはわからない。

recieveはsendによって出力されるストリームを元にファイルへと書き出す。

ネットワーク越しのバックアップ手段として行う場合は、権限的な難しさがある。send/receiveはroot権限が必要なためだ。
rsyncであればユーザー権限でのバックアップが可能だが、send/receiveを使う場合はそうはいかない。
受け渡しをssh経由で行おうとすると、rootでのsshアクセスを許していなかったりして結構なネックになる。
別に鍵を作れば良い話ではあるが。

sudoを用いたコマンドラインで行うのであれば、socatを使用する方法がある。receive側は

$ socat tcp-listen:30000 | sudo btrfs receive /path/to/volume

send側は

$ sudo btrfs subvolume snapshot -r /path/to/volume /path/to/snapshot
$ sudo btrfs send /path/to/snapshot | socat stdin tcp-connect:receiverhost:30000

経路安全性を問題にするのであれば、openssl-listenを使うか、ssh -Lを使うなどの方法がある。
インターフェイスを限定できないのが問題なら、rubyワンライナーを使う方法や、もうひとつプログラムを増やし、ソケットで読んで書き込む仕様として、ssh経由でソケットに出力するプログラムを起動するという方法もある。

例えば次のようなスクリプトである。

#!/usr/bin/zsh
zmodload zsh/net/socket

zsocket -l /tmp/btrfs-syncer
sock=$REPLY
while zsocket -a $sock
do
  (
    btrfs receive /path/to/volume <&$REPLY
  ) &
done

こちらはrootで実行する。対してsshで実行すべきは

#!/usr/bin/zsh
zmodload zsh/net/socket
zsocket /tmp/btrfs-syncer
cat >&$REPLY
exec {REPLY}>&-

あとは

$ sudo btrfs subvolume snapshot -r /path/to/volume /path/to/snapshot
$ sudo btrfs send /path/to/snapshot | ssh receivinghost.locadomain btrfs-syncer-client

注意点として、例えばsubvolというサブボリュームに書き戻したい場合、subvolというサブボリューム上にreceiveすると結構困ってしまう。
その場合はそのペアレントボリュームにreceiveした上で(snapshotの名前になってしまうので)mvするのが正しい。

なお、mvしてもreadonlyのままになるため、ロールバックするためには属性変更が必要。

$ sudo btrfs property set -ts subvol ro false

ro trueでreadonly。
IDによるマウントを使っているのであれば、set-default

追加のクリティカルヒット

しかし、またも/dev/sdgの大量エラーという結果になった。一見すると正常だが、ログを見ると1.77TiBの書き込みの間に71456ものblk_update_requestが発行されている。

2度続けてsdgだったため、ケーブル、ラック、ボードのいずれかが問題である可能性も考えられたため、ディスクを入れ替えて(/dev/sdfの位置にあるディスクと入れ替えた)試したところエラーはなく、ディスクの不良と断定。初期不良を申請し、翌日回答、翌々日到着となった(NTT-Xの対応は早い)。

ちなみに、NTT-Xにディスクの初期不良対応を申請したところ、

  • メーカーに確認→メーカー回答を得て応答(交換or返金)→交換の回答を得て発送→到着時に集荷として引き渡し

という手順だった。

交換ディスクは

# dd if=/dev/zero of=/dev/sdf bs=512M

として全域書き込みを行い、

# journalctl --no-pager | grep -F blk_ | tail

としてblk_update_requestが発生していないことを確認した。

そして前述の通り、新規ファイルシステム作成、マスターボリュームのマウント、socatと連動したsend/receive、リネーム、プロパティ変更と行い、エラーがないことを確認した。
なぜか全域でデータ量が5.30TiBまで減少していた。

しかしtopで、kworker/3:2及びksoftirqd/3が張り付いたままになっている。
kworkerはおそらくbtrfs絡みだろうし、ksoftirqdが固まっているということはディスク処理だろうから、しばらく待つことにする。特にkworkerはずっとS欄がR(Running)であり、明らかに忙しくしているので安全を考えて待つ。

結局kworderがしずまらなかったので、syncしてunmountし、それが問題なくunmountされたことを確認してからreboot。

エラーが何もないことを確認して、おそらくこれで完了。
とてもとてもとても大変だった。

ThinkPad e440 * Manjaro Linux x86_64 XFce 16.06

概要

これまでManjaro Linux KDEを使用してきたThinkPad e440だが、Manjaro Linux XFceに変更した。

e440のOSは安定せず、かなり変更を重ねている。これまで

  • openSUSE
  • Mageia
  • Manjaro XFce
  • PCLinuxOS FullMonty
  • Linux Mint
  • Manjaro LXQt
  • PCLinuxOS KDE
  • Manjaro KDE
  • Manjaro XFce

という流れだ。求められる条件は

  • BIOSでWindowsとのデュアルブートが可能
  • /の暗号化が可能
  • ローリング・リリースあるいは長期運用が可能
  • 先進的
  • RealTek RT8168 無線LANが利用可能

これがなかなか難しい。
ちなみに、Manjaro Linuxも現状、GUIインストーラでWindowsのデュアルブートとLUKSを両立させる場合、MBRの書き換えを防ぐことはできない。

Manjaro Linux KDEとXFceの違い

違わないようで、実は結構違う。

XFceの設定

Manjaroのパッケージ内にXFceに関する設定が不足している。特にKDEでインストールした場合は、XFceに関する設定は全くない。

XFceから新規ユーザーを作った場合は、おおよそ反映されるし、そのためパネルやアプレットが大きく異なるが、Mnajaroのメニューは階層化されていない状態になる。

LXQtとWiFi

KDEでインストールした場合、LXQtはconnmanを使おうとnm-appletを使おうと、D-BusエラーになりWi-Fiを使うことができない。XFceでインストールした場合はnm-appletが問題なく動作する

XDM

KDEはKDM、XFceはLightDMを使う。

KDEアプリの動作

XFceでインストールした場合、Akonadiが正常動作せず、KDEコンポーネントが完全には動かない。

KDEコンポーネントをフルに活用しとたKDE環境を望む場合は素直にKDEでインストールのが良い。

Wi-Fiの挙動

KDEの場合、Wi-Fiがおかしくなり、やがて接続は確立しているのに通信しなくなる。(チップはRT8168)
頻繁に発生し、再接続すれば復帰する場合が多いが、あまり放置しすぎると切断自体不可能になる。

XFceの場合は、その状態が発生しない。

また、mkwd-kernelを使うと、XFceの場合だけrt8168パッケージをインストールするようになっている。KDEの場合はndiswrapperパッケージをインストールする。これは、15.12と16.06の違いもあるのかもしれない。

アップデートアプレット

KDEの場合はOctopiを使うし、アプレットもOctopiのものになっている。

ファーストインプレッション

もちろん、Manjaroということで同じものなのだが、実際には結構な違いがある。

Plasma Workspaceが結構不安定で(ハードウェア的な問題だろう。Manjaroに限らない)、よくKWinが再起動するのだが、安定しており、最初からWi-Fiを利用することができる(速度的には有線のほうが良いが)といったメリットがある。

機能的にはXFceはかなりそろっていて、非常に使いやすい。ただし、Thunarなど一部のXFceアプリはパスを問答模様で補完するため、普通に打っていると勝手に補完されてパスが違っているということがあったりする点はマイナス。
ただ、機能的な不足はないはずだが、実感としてはやはりCinnamonのほうが使い心地は良い。

XFceでインストールすると、KDEコンポーネントを使わない設定となるため(これを変更するのはなかなか大変)、全体に動作が軽く、安定している。e440程度の性能であればこのほうが良いかもしれない。

RT8168

ThinkPad e440に搭載されているのはLinuxでの扱いの難しいRealTek製WiFiチップRT8168だ。

XFceの場合はmhwd-kernelで自動的にこのドライバを含み、適切に動作するが、RT8168にはRT8169ドライバをロードしてしまう、という問題があり、mhwd-kernelによる新カーネルインストール時にもその回避を勧められる。

# echo "blacklist r8169" > /etc/modprobe.d/r8169_blacklist.conf

およその作業記録

# pacman-mirrors -g #ミラーを並び替える
# yaourt -Syuu --noconfirm # アップグレード
# mhwd-kernel -i linux46 # Linux 4.6カーネルのインストール(現在の最新)
# echo "blacklist r8169" > /etc/modprobe.d/r8169_blacklist.conf # RT8169モジュールの無効化
# reboot
$ yaourt -S gvim vi #viがないため、visudoなどが使えない
$ sudo visudo # パスワードタイムアウトの無効化
$ sudo vim /etc/yaourtrc #ビルドディレクトリ、エクスポートディレクトリなどの変更のため
$ yaourt -S medit geany geany-plusings ruby ruby-docs zsh mate-gtk3 qterminal lxqt leafpad #エディタ及び諸環境のインストール
$ yaourt -S mate-extra-gtk3 #一部conflictがあるため、全コンポーネントはインストールできない
$ yaourt -S adobe-source-han-sans-jp-fonts ttf-ohruri ttf-komatuna ttf-meguri ttf-migu ttf-ricty ttf-vlgothic tth-vlkoruri #フォント周り
$ mkdir ~/.config/fontconfig
$ medit !!$/fonts.conf #フォント設定
$ yaourt -S sshfs
$ yaourt -S xf86-input-synaptics #Touchpad Synaptics
$ sudo cp /usr/share/X11/xorg.conf.d/70-synaptics.conf /etc/X11/xorg.conf.d #設定ファイルのコピー
$ sudo vim !!$/70-synaptics.conf # Synapticsの設定
$ yaourt -S vivaldi-snapshot opera-developer chromium google-chrome chromium-widevine #ウェブブラウザ
$ yaourt -S atom-editor-git #Atom。時間がかかる
$ yaourt -S --noconfirm fcitx fcitx-anthy fcitx-mozc-neologd-ut fcitx-kkc fcitx-gtk{2,3} fcitx-qt{4,5} fcitx-m17n fcitx-configtool # IM関連
$ yaourt -S w3m lv #日本語環境向け
$ yaourt -S xorg-server-xephyr # XDMCPリモートログイン
$ yaourt -S claws-mail # メールクライアント
$ chsh #シェルをzshに
$ vim ~/.config/user-dirs.dirs # XDGディレクトリの変更
$ vim ~/.xprofile
$ mkdir bin lib mnt #個人的に必要とするディレクトリ

MDNSの設定などは最初からされている。

Synapticsの設定。2本指スクロールの有効化とナチュラルスクロール化、サーキュラースクローリング(左下起点)の有効化を設定してある。

# Example xorg.conf.d snippet that assigns the touchpad driver
# to all touchpads. See xorg.conf.d(5) for more information on
# InputClass.
# DO NOT EDIT THIS FILE, your distribution will likely overwrite
# it when updating. Copy (and rename) this file into
# /etc/X11/xorg.conf.d first.
# Additional options may be added in the form of
#   Option "OptionName" "value"
#
Section "InputClass"
        Identifier "touchpad catchall"
        Driver "synaptics"
        MatchIsTouchpad "on"
# This option is recommend on all Linux systems using evdev, but cannot be
# enabled by default. See the following link for details:
# http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
#       MatchDevicePath "/dev/input/event*"
            Option "VertTwoFingerScroll" "on"
            Option "HorizTwoFingerScroll" "on"
            Option "CircularScrolling" "on"
            Option "CircScrollTrigger" "6"
            Option "VertScrollDelta" "-111"
            Option "HorizScrollDelta" "-111"
EndSection

Section "InputClass"
        Identifier "touchpad ignore duplicates"
        MatchIsTouchpad "on"
        MatchOS "Linux"
        MatchDevicePath "/dev/input/mouse*"
        Option "Ignore" "on"
EndSection

# This option enables the bottom right corner to be a right button on clickpads
# and the right and middle top areas to be right / middle buttons on clickpads
# with a top button area.
# This option is only interpreted by clickpads.
Section "InputClass"
        Identifier "Default clickpad buttons"
        MatchDriver "synaptics"
        Option "SoftButtonAreas" "50% 0 82% 0 0 0 0 0"
        Option "SecondarySoftButtonAreas" "58% 0 0 15% 42% 58% 0 15%"
EndSection

# This option disables software buttons on Apple touchpads.
# This option is only interpreted by clickpads.
Section "InputClass"
        Identifier "Disable clickpad buttons on Apple touchpads"
        MatchProduct "Apple|bcm5974"
        MatchDriver "synaptics"
        Option "SoftButtonAreas" "0 0 0 0 0 0 0 0"
EndSection

fonts.confの設定。

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
  <match target="pattern">
    <edit name="dpi" mode="assign"><double>103</double></edit>
  </match>
  <match target="font">
    <edit name="hinting" mode="assign">
      <bool>true</bool>
    </edit>
  </match>
  <match target="font">
    <edit name="autohint" mode="assign">
      <bool>true</bool>
    </edit>
  </match>
  <match target="font">
    <edit name="hintstyle" mode="assign">
      <const>hintfull</const>
    </edit>
  </match>
  <match target="font">
    <edit name="rgba" mode="assign">
      <const>rgb</const>
    </edit>
  </match>
 <match target="font">
  <edit name="lcdfilter" mode="assign">
   <const>lcddefault</const>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>serif</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>Ohruri</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>sans-serif</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>VlKoruri</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>sans</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>VlKoruri</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="any" name="family">
   <string>monospace</string>
  </test>
  <edit binding="strong" name="family" mode="assign">
   <string>Migu 1M</string>
  </edit>
 </match>
 <match target="pattern">
  <test qual="all" compare="not_eq" name="family">
   <string>sans-serif</string>
  </test>
  <test qual="all" compare="not_eq" name="family">
   <string>serif</string>
  </test>
  <test qual="all" compare="not_eq" name="family">
   <string>monospace</string>
  </test>
  <edit name="family" mode="append_last">
   <string>Migu 1C</string>
  </edit>
 </match>
 <dir>~/.fonts</dir>
</fontconfig>

.xprofile。日本語入力関係ほか

#
# ~/.xprofile
#
# sourced by /etc/lxdm/Xsession
#

if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then
    eval "$(dbus-launch --sh-syntax --exit-with-session)"
fi

# Environment variables
#
export GTK2_RC_FILES="$HOME/.gtkrc-2.0"
export GTK_IM_MODULE=fcitx
export GTK2_IM_MODULE=fcitx
export GTK3_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx
export XMODIFIERS="@im=fcitx"
export DefaultIMModule=fcitx
export PATH=$HOME/bin:$PATH
setxkbmap -model jp106 -layout jp

メインマシンをZ400からGodavariに戻して3画面にする

変更

昨日、GodavariマシンのグラフィックドライバをプロプライエタリなCatalystからオープンソースのAMDGPUに変更したが、だいぶ安定している印象なので、メインマシンをそちらに戻した。

Z400とGodavariはマシン選択としては結構微妙で、Z400は

  • 性能が1割程度高い
  • 画像・映像処理は2-3倍くらい速い
  • 全体的に安定している
  • 全体に帯域が広い
  • Intel CPUということもありDTM環境が正常に動く

一方Godavariは

  • 3画面出力が可能
  • 規格が新しいのでUSB3.0をはじめ新しいハードウェアがサポートされている
  • 最新のRCカーネルでもCPUが機能的に対応していないと文句を言われることがない
  • Z400のドライブ数6に対して8と多い
  • インターフェイス的に拡張性で有利。外部インターフェイスそのものも多い
  • 動作音が静か

安定して動作するのであれば3画面をとってメインをGodavariにした形だ。
処理性能をうまく使って分散できると全体のパフォーマンスは向上するかもしれない。
このマシンでやらざるをえないScrubの時間が伸びるのが不安だが。

FHD 3画面

うちの環境は変則的な配置で計5画面がセットされているが、通常利用可能なディスプレイはFHDが3台だ。

  • LG 22EN33
  • LG 22EN43
  • SAMSUNG S22B300

いずれも低価格帯のものだが、21.5インチのFHDの液晶ディスプレイである。インターフェイスはLG 22EN43がHDMIを備える以外はDVI-DとVGAを備えている。

LGのものは画質も悪く、INPUT切り替えが極めて遅い(特に信号がないチャンネルを経由する場合はものすごく遅い)。ついでにいうとサポートの対応が極めて悪い。視野角も狭く、色も明らかにおかしい。はっきりいって、とても気に入らない。

サムスンのものは、視野角が広く色味も良い。画面は綺麗だし、最低限の機能ではあるが、使いやすい。
ただし、スタンドは完全な固定で、しかもVESAマウントもないためアームも使えない。

これまでは左右で(DVIと、DP-DVI)左がプライマリだった。
基本的にどのような配置にしても、結局左側ばかり見てしまう。左右均一に見られるようになるまでは結構なトレーニングが必要だ。

トリプルにした場合、左をプライマリにすると間違いなく右ディスプレイは見られない。
真ん中(サムスン)をプライマリにするしかないが、ここで思わぬ問題。

FM2+Killerのディスプレイ出力はHDMI, VGA, DVI-Iで、かなり配置は固定されてしまう。
この都合でサムスンはVGA接続なのだが、もともと画面がゆるめなサムスン、VGA接続だとすごく滲む。
プライマリが滲むというのは、ものすごく気になる。結局、Z400のディスプレイが真ん中をとばして左右になってしまうが、サムスンと22EN33の接続を両方とも入れ替えた。

トリプルってどうなの

一言でいえば難しい。
プライマリディスプレイが正面にあるわけで、今までよりも左右どちらも見えなくなった。

隠さなくても切り替えて使えるというメリットはもちろんあるのだが、一覧できる情報量は減ってしまった。

また、配置についても、頭を囲むように角度をつけて配置したほうが一覧性が上がる、と考えていたのだが、実際はフラットに近づけるほうが情報を把握できる。

当たり前だが、画面に接近するほど視野は狭くなり一度に入る情報量は減る。

そう考えると、一覧性からいえばウルトラワイドディスプレイが良さそうに思える。
あちらは縦はFHD相当だが、横はFHDの2倍ある(4kと同じ)。
幅が随分と必要になるが、ウルトラワイドディスプレイ2枚というのも選択肢なのかもしれない。

もし、並列作業があまり得意ではないが情報の一覧性を向上させたいのであれば、マルチディスプレイよりも4k1枚にしたほうが明らかに捗る。

もし、FHDから4kにした場合に液晶一辺の長さも倍になるのであれば、情報量は単純に4倍と考えていい。
しかし、そうでないのであれば4倍には到達しない可能性が高い。それでも、ひとつの画面となり、見やすくなることでデュアルディスプレイよりも情報量は増えたと感じるのが一般的であるようだ。

もちろん、この問題はコンテキストスイッチとは別に考えなくてはいけない。

例えば資料をみながら作業をするような場合に、作業側をみなくてもブラインドでできるが、資料は見なくてはいけない状態だとしても、単一のディスプレイで資料だけを広げていると(Windows、あるいはそれに類する挙動を示すウィンドウマネージャでは)資料を最大化して上にしたままでは作業することができない。
さらに、トレーダーがよく行うように複数の情報を監視しながら作業するのであれば多数の情報が一覧できる状態でなくてはならない。こうしたことが並列性としてのニーズであり、実際にアクティブに利用されている「作業空間」として使用するためには訓練が必要になる。

一方、単純に複数の情報を切り替えながら行うために、ウィンドウ出し入れの切り替えではなく視線移動で行うことで効率化したいというのがコンテキストスイッチだ。例えば、ニコニコ生放送をみながらツイッターしたい…といったことでもそうだ。典型的にはドキュメントを開いたままプログラミングというのがある。
切り替え時間がつまり、またその際に目に入れておくことができることで情報をロストしにくく、結果的に効率をあげることができる。
ウィンドウが増えればスイッチのコストがあがるため、余計に大きくなる。

つまり、必ずしも同時に視界に入っている必要はないのだが、意識されていないと同じディスプレイでのウィンドウスイッチで済ませてしまい、切り替えるのにもそれなりに慣れが必要になる。

いずれにせよ、枚数が増えるというのは結構な難易度増であり、シングル→デュアル→トリプルと増えるにつ違って著しく使いこなすのが難しくなる。
ただし、定期的にアクセスしている、あるいは状態を確認する必要のために結局常にひらいておきたいウィンドウというのはあるわけで、そのためにウィンドウが一枚使われてしまい、そのウィンドウに専有されないことで作業効率が上がったりもする。

ディスプレイ枚数を増やすと即ち作業効率があがるということはなく、PCの性能同様、それを使いこなすだけの腕があるかという問題が生じる。だから、それを踏まえてサイズと解像度を選択するほうが効率は簡単に上がる(もちろん、ウィンドウを並べるくらいのスキルはある前提だ)。

VGA

VGAは長らくコンピュータで使われてきたアナログ端子である。

デジタル表示を行う液晶ディスプレイにアナログインターフェイスをもちいるというのはかなり理解に苦しむ。そもそもディスプレイ描画はデジタルで行っているわけで、アナログインターフェイスで出力するからにはD/A変換を行っているわけだ。CRT(ブラウン管)なら表示がアナログなので、アナログ信号をそのまま表示にすればよく、取り扱いが簡単なのでそれで良いとしても、液晶の場合点描であるから結局A/D変換が必要になる。

最初から最後までデジタルなら別に変換がいらないのに、途中をアナログにするせいで2回変換するので非常に無駄だ。もちろん、液晶ディスプレイ普及とともにDVIが一般化したのだが、なぜか根強く残ってしまい、残っているからには対応せざるをえないということで、DVI2個にしてくれれば良いものをDVI+VGAにしたりして苦慮させられている。

2015年に終了した、レガシーインターフェイスである。

さて、VGAについてだが、多かれ少なかれ液晶に表示してもCRTのようなぼやっとした画面になる。ディスプレイによってその度合いは大きくことなり、今回の場合はサムスンのディスプレイはVGA入力ではにじみがひどく、文字が読みづらいレベル。LGのものはそこまで気にならない。

ビデオを表示している分にはVGAのみづらさというのはそこまで目立たないし、TVを観るためという人にとってはそれほど重要ではいなのかもしれないが、文字をみる時にはVGAは明らかに読みづらい。高解像ディスプレイで文字を小さくしている人にとっては、一段とその読みづらさが目立つ。

ビジネス用コンピュータではずっとVGAのみ採用ということが続いてきたが(NVSで、変換アダプタはVGA*2という状況)、VGAで事務作業はものすごく向いていないと思う。

学び

  • ディスプレイ解像度の向上は多かれ少なかれ作業効率に寄与するが、その度合いは条件による
  • ディスプレイサイズの向上の作業効率への影響は条件による
  • ディスプレイの枚数増は使いこなすのにスキルが必要。トリプルになるとかなり難しい
  • ディスプレイ枚数を増やすよりはより大きくドット数の多いディスプレイにかえるほうが有効
  • 特に文字作業の場合はVGA接続をやめるだけでも効率あがるかもしれない
  • ディスプレイの配置は大事。作業効率に影響する。マルチディスプレイならなるべく視線にフラットなほうがいい
  • 安いディスプレイと高いディスプレイにはかなりの差がある
  • LGはやめておこう

AMDGPUドライバーを試す

AMDGPU

Catalystドライバーの出来がよくないので、そして一向によくならないので、デキが良いと評判のamdgpuドライバーを使ってみることにした。

AMDGPUドライバーは、mesa上で動作するオープンソースドライバーであり、ベンチマークテストではCatalystには及ばないが良好な成績を収めている。
実験的だが、AMDGPUドライバー上でカーネル/Xバイナリに依存しないプロプライエタリドライバーを使用するAMDGPU PROドライバーも存在する。

インストール

Manjaroではcoreにmhwd-amdgpuが含まれているが、本体はextraにあるxf86-video-amdgpu。

なお、AURにあるAMDGPU PROは軒並みOUT OF DATEになっている。

VDPAUおよびVA-API

勝手に有効化されるため、$VDPAU_DRIVERは無効化する。

VA-API設定は環境変数として

LIBVA_DRIVER_NAME=gallium

VLCでは出力設定をVDPAUではなく、OpenGL GLXビデオ出力(XCB)に設定しないとビデオによってはエラーを吐き、動作しない。
画像が乱れる場合もあるが、VLCではありがちなことと理解している(Quadro+nVidiaでも同じだから)。

Flashのアクセラレーションも/etc/adobe/mms.cfgの

EnableLinuxHWVideoDecode=1

で動作する。

Cinnamon 3D

特に設定しなくても問題なく動作する。

マルチモニター

テストの限りではカーソルの歪みはない

Skype

テストできず。

Cinnamon 3.0.1, Linux 4.6 RC4

Cinnamon 3

Manjaro Update 2016-04-26でCinnamonが3.0.1になっていた。リリースでは触れられていないけれど…

これで結構変わっていたので、ポイントを挙げておくと

  • ダイアログ表示がフェードイン/フェードアウトアニメーション追加
  • 警告音がぽこぽこに変更された
  • テーマ設定でコントロールがかなりの部分使えなくなった
  • Dropboxが0秒起動だとsystrayに入らなくなった
  • Mail.ruは自動起動でsystrayに入るようになった

ダイアログがフェードインするようになったのは非常にかっこいいが、Fcitxのサジェスト/プレエディットもフェードインするようになり、実用性が明らかに低下した。このあたりは開発者は意識しないのだろう。(Fcitxを使うようなことがないだろうから)

Cinnamonは機能はシンプル、特に設定項目は少ない。デスクトップエフェクトもほとんど選択できないし、ショートカットの設定も少ない。

だが、非常にツボを抑えた機能を持っている。

例えば、クイックタイルはシンプルにSuper+Cursorであり、現在位置を基準にしてタイルする。Super+Leftは非タイルなら左にタイルし、右タイルならフローティングする。

PAアプレットではサウンド出力先を一括で変更できる。この機能で変更した場合カスタマイズされた設定に戻すのが大変なので使用していないが。

他にも

  • ネットワークアプレットによる切り替え・切断が加担
  • ウィンドウのボタンは配置も任意に設定できる
  • ウィンドウコーナー機能もある
  • デスクレット機能
  • 拡張機能(ほとんど正常に動作しない)
  • 通知のオンオフ
  • サブメニューを持つsystrayアイテムはスライド式で階層化される

軽量で安定していることもあって(さらには高速でハードウェアアクセラレーションも使用することもあって)、本来はPlasmaを利用したいと思いつつ、Cinnamonから抜けられないのもこうしたことからだろう。

Linux 4.6 rc4

Linux 4.6 rc2においては、Godavariマシンでは問題がなかったものの、Nehalem-WSマシンでは

  • btrfsマウント時に大量のメッセージが表示される(RAID6のベンチマーク?)
  • シャットダウン時、dmなどが閉じられず電源停止に至らない
  • オーディオデバイスの入力が大量のノイズで埋もれる

といった問題が生じていた。

だがこれらはRC4で解決した

btrfs関連の修正も既に多く入っており、非常に期待できる。相変わらずのいい仕事だ。