KMSのearly modeでブート時にTuxを鎮座させる
(2015-03-05 追記:以下に示す方法であっても、特に私自身の環境ではTuxが出てこなくなってしまった。原因はいまだわからない)
Linuxカーネルのコンパイルを知って以来、ずっとブートシーケンス中にTuxを鎮座させる事を夢見ていた。Arch Linuxが配布するカーネルではブートロゴが表示される設定になっていないので、Tuxは鎮座しない。
基本的には Gentoo Forums :: View topic - Tux at top of screen during boot? に従えばいいんだけど、KMSを利用する環境でearly modeになっている場合*1、カーネルパラメータをいじくる手間がいらなくなるかわりにもう一手間増えて、グラフィックスに関するドライバをビルトインにしないといけなくなる。つまり、Intel製のグラフィックスの場合、
CONFIG_DRM_I915=y CONFIG_DRM_I915_KMS=y CONFIG_DRM_I915_FBDEV=y
という設定にしなければならない。上のリンクに沿って言えば、
Device Drivers --> Graphics support --> Direct Rendering Manager --> Intel 8xx/9xx/G3x/G4x/HD Graphics
の箇所をモジュール("M")ではなくビルトイン("*")にする必要がある。
理屈
正しい理解をしている確証もなく、一次資料に目を通したわけでもないので参考情報として解釈してほしい。
initramfsとKMS
- Arch Linuxでmkinitcpioはinitramfs(カーネルイメージとかいわれる)を生成するためのスクリプト
- mkinitcpioは /etc/mkinitcpio.conf の内容を読み込む
- KMSがearly modeになっている場合、KMSに必要なモジュールはシステム起動時の早い段階でカーネルに読み込まれる
- 早い段階でモジュールが読み込まれるとはいうものの、その際あるいはその前にドライバが読み込まれるとは限らない
- 実際、ドライバをビルトインにしなかった時はTux鎮座しなかった
- → カーネルにグラフィックスのドライバを組み込んでおけばモジュール読み込み後すぐグラフィックスが利用できる
おまけ
/proc/config.gz をzcatしたやつを晒す。AUR (en) - linux-ckをThinkPad X201sで利用することを前提としている。4000行くらいあって、ページを無駄に重くするだけだと思われるので、晒すとは書いたがリンクを貼るにとどめておくことにする:zcat /proc/config.gz
configの行数がかさむのは修行が足らない証だ。
参考
*1:/etc/mkinitcpio 内の"MODULES"にグラフィック関連のモジュールを加えている場合が該当する。MODULES=i915 みたいな記述があるなど。
ThinkPad X201s買った
物欲が爆発して頭が真っ白になり、気がついたら注文を完了していた。送料込54000円也。型番は5397-FUJ。
程度の良いX201(s)が2万円代で手に入る未来をずっと待っていたけれど、ThinkPadの凋落が悲鳴に近い形で叫ばれ始めたときにそんな未来は来ないだろうと見通しを立てるべきだったと思った。
これで当分物欲に苦しめられることはなくなるだろう。
Qtでの動作を念頭に置いて設定等をしたFcitxがGTK+なアプリ上で動かなくて困った時に確認すると嬉しいかもしれない事項一覧
いろいろあってTox*1シンパになった。
しかし困ったことに、慣れ親しんだuimはToxのQtフロントエンドであるqTox*2で必要となるQt5に公式には対応しておらず、結果日本語が使用できない。
githubにあるuimのレポジトリなどから入手できる最新の不安定版では一応Qt5に対応しているようだが*3、それを使うとqToxがSegmentation Faultという断末魔を上げて死んでしまう*4。日本語話者なのでToxでも日本語を使いたくて困っていたけれど、これまたいろいろあってuimをやめてQt5に対応済みのFcitxに移行すれば良いのだと気がついた。
ここでタイトルの登場となる。つまりはそうなったのだ。
前提
Qtでの動作を念頭に置いて
というのはつまりFcitxを導入するときに以下のようにインストールした場合という意味:
$ sudo pacman -S fcitx-im fcitx-im-qt5 kcm-fcitx kdeplasma-addons-applets-kimpanel
その他Fcitxのインストールや設定に関する情報は全てFcitx (日本語) - ArchWikiを参照した。
確認事項
プロファイル系の設定ファイル
.xprofileとか.xinitrcとかを意味する。ここに追記するFcitxに関しての内容が
export GTK_IM_MODULE="fcitx" export QT_IM_MODULE="fcitx" export XMODIFIERS="@im=fcitx"
となっているかをみる。以上の内容で駄目な場合は一行加わって
export GTK_IM_MODULE="fcitx" export QT_IM_MODULE="fcitx" export XMODIFIERS="@im=fcitx" export DefaultIMModule="fcitx"
となることもある。
ロケール
LC_CTYPEが"ja_JP.UTF-8"ではない場合、GTK+なアプリでIMEが有効にならない場合がある。
ArchWikiによれば(GTK+アプリではないものの)これはEmacsのバグでEmacs上で生じるみたいなことが書いてあった。だがGTK+を使用しているはずのChromiumやmikutter上でもIMEが有効にならないことがあった。
これについては/etc/locale.confや${HOME}/.xinitrcなどの適当な設定ファイルへ
export LC_CTYPE="ja_JP.UTF-8"
と書けばよい。
GTK IM Module
GTK+のIM関連の設定を更新するといい感じになることがある。これは以下のようにする。
# gtk-query-immodules-{x}.0 --update-cache
{x}は2か3で置き換える。GTK+ 2系を対象にする場合は"2"で、GTK+ 3系を対象にする場合は"3"でそれぞれ置き換えて実行する。
詳細はFcitx (日本語) - ArchWikiを参照。
GTK+の外観設定ファイル
.gtkrc-2.0や.gtkrc-2.0-kde4のようなファイルがホームディレクトリ直下に存在する場合、これをリネームするか削除するかすると良い感じになる事がある。GTK+ - ArchWikiによれば、これらのファイルはGTK+アプリで外観周りの設定を記述するための設定ファイルであるようだ。
参考
*3:こういうのがAURにもある:AUR (en) - uim-qt5
*4:qToxの問題かと思ったけれど、fcitxでもvi-cooperative modeもどき | とさいぬの隠し部屋によればQt5のアプリであればqToxに関わらず全部死ぬようだ
コマンドの終了をYoで知らせるシェルスクリプト書いた
2014-09-27 追記
デスクトップ環境の機能を利用してYoしたことを通知する機能をつけた。Xが起動してない場合は標準出力へ通知内容と同様の文言を表示する。変更点は一目瞭然なので注釈は省略。つかうアイコン画像にYoっぽい感じのものを選ぶと通知がおしゃれになって嬉しくなる。
Yo*1について
Yo、ナニコレ感すごい
— 之城坂貞太 (@ngsksdt) June 21, 2014
Yo、誰も傷付くことのない最高の意思疎通っぽい
— 之城坂貞太 (@ngsksdt) June 21, 2014
コミュニケーション、KISS原則を適当な回数繰り返して適用すると最終的にYoに落とし込まれる
— 之城坂貞太 (@ngsksdt) June 21, 2014
本題
前フリ
mozcやLinuxカーネルといった長大なプログラムのコンパイルをルーチンワークとしている人々にとって、それらをコンパイルしている間に何をすべきかというのが問題になることが多いと思う。
長大なプログラムのコンパイル時にはコンピュータのリソースがコンパイルに持っていかれてしまってパフォーマンスが急激に低下するためにコンピュータを使う作業が捗らなくなる。非コンピュータな作業をすれば解決するのだけど、コンパイルがいつ終わるのか気になってどうしようもなくなってしまう私のようなせっかちな人間は、コンパイルが終わるまで標準出力とかに吐き出される進捗をずっと見続けてしまい、結果時間を浪費することになってしまう。
ところで、Yoはただ単純にYoと飛ばし飛ばされるだけの単純明快なコミュニケーションツールである。コミュニケーション上ではYo以外の冗長な情報は必要とされない。となれば、前述したコンパイルやあるいはその他のコンピュータ上で行われる長大な作業の終了を通知するのに、Yoは最適なツールなのではなかろうか。かつてはメールで通知されたものはYoという現代的なツールに置き換わるのだ。
本題
Yo API*2を使用して、コマンドの終了を所望のYoユーザへYoして知らせるシェルスクリプトを書いた。
使用するのに必要なものは以下の通り。
- Yoのアカウント(通知を受ける)
- YoのAPIトークン(Yoするのに必要。http://yoapi.justyo.co/ から取得できる)
APIトークンの取得方法はブログにYoボタンを設置した | SOTAをみるとよい。APIトークンを取得したら、上述したスクリプト内の'<YOUR_API_TOKEN>'を取得したAPIトークンで、'<DESIRED_USERNAME>'をYoしたいユーザ名で書き換えればよい。これで、API登録時に指定したYoユーザから、DESIRED_USERNAMEを置き換えたYoユーザへYoが飛んでくる。
Elecom WDC-433SU2Mで802.11acな通信を実現したのかわからないけどとりあえず動いた
2015-03-08 追記
x86-64でも動くという情報をいただいた(x86_64 Linux上でELECOM WDC-433SU2Mを用いて802.11acな通信を実現する)。リンク先記事で紹介される方法で利用が可能となる。
ただし、Arch Linuxの場合はlinux-headersによるファイル群が /lib/modules/`uname -r`/ に配置されるので、Makefileにおける変数 "LINUX_SRC" は "/lib/modules/$(shell uname -r)/build" のままである必要がある。
また make install 後 modprobe を忘れずに(さもないとハマることになる。本記事コメント欄参照)。
id:grafiさん、有難うございました。
2015-03-11 追記
動作が確認できたカーネルは3.18系のもので、3.19.1では(少なくとも私の環境では)コンパイルに失敗した。
Elecom WDC-433SU2Mで802.11acな通信を実現したかった - テクニカルプアの続き。
以前の記事と同様の手順をx86-64な環境ではなくx86(Archでいうi686)な環境で実行し、そのままx86な環境で使用してみたところ、WDC-433SU2Mの動作に成功した。ただ、思ったような速度が出ず、802.11acとして接続されているのか不安になっている。でもまあいい感じに通信してもカーネルパニックは起こさないので、動いたとしてよいと思う。
というわけでドライバはx86向けに書かれていたようだ。
一応環境を以下に示す。同じバージョンでx86-64な環境ではカーネルパニックを引き起こした。
$ uname -r 3.14.6-1-ARCH $ gcc --version gcc (GCC) 4.9.0 20140521 (prerelease) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Elecom WDC-433SU2Mで802.11acな通信を実現したかった
2015-03-08 追記
体裁がグチャグチャになってたのに気がついたので直した。内容は変わってない)
2014-06-11 追記
進展があった
今まで使っていたwifiルータ(プラネックスのMZK-W04N)が長いこと不調で、とうとう我慢の限界に達したので、wifiルータを新調することにした。そういうわけで802.11acに対応しているバッファローのWHR-1166DHPを購入し、acが使えるならと併せてエレコムのWDC-433SU2MBKを買うことにした。
さて、WDC-433SU2MBKだが、こういうものの常として、何も考えずに挿しても認識することはない。適当に型番で検索するとElecom WDC-433SU2M - WikiDeviというのが出てきて、使えるドライバも掲載されていた。GNU/Linux用ドライバが入手出来るのなら動かせるだろうということで、やってみることにした。
で、結果だが、動作しなかった。
詳しく言うと、ドライバをインストールすればWDC-433SU2MBKを認識はする。netctlなりwicdなりのネットワーク管理ツールを使えば802.11acでつながりもする。しかし、いい感じに通信をしようとすると、カーネルパニックを起こしてシステムがまるごと死ぬ。原因として思い当たる節は多々あるが、そのへんは後述する。
環境
$ uname -r 3.14.4-2-ck $ gcc --version gcc (GCC) 4.9.0 20140521 (prerelease) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(2014-06-22 追記:ドライバのコンパイルにはカーネルのヘッダファイルが必要。linux-headersとかそういうのをインストールしないとコンパイル時に怒られる)
作業
ほぼPLANEX GW-450D KATANAをLinux(CentOS6.5)で動かす | hosiiのメモ帳に沿っている。
ドライバのソースコード入手
http://www.mediatek.com/en/downloads/mt7610u-usb/からダウンロードする。氏名とメールアドレスを入力し、CAPTCHAを通れば入手できる。GPLv2で頒布されている。
パッチ当て
以下のパッチをあてる。
planex_gw450_katana_linux_3_13_driver.patch · GitHub
最後のパッチはGW-450D KATANAのドライバ用みたいになっているが、これはGW-450D KATANAもWDC-433SU2Mも同じMediaTek製のMT7610Uというチップを使用しており、このためドライバも同一のものになるためである。
コンパイル
パッチを当てたらmakeする。makeが終わると、ドライバのソースがあるディレクトリのうち、os/linux/内にmt7650u_sta.koというカーネルモジュールができている。これを使う。
インストールとか
mt7650u_sta.koをカーネルモジュールが格納されているディレクトリへ配置して、設定ファイルを適切な位置へ置く。以下ではカレントディレクトリをドライバのソースがあるディレクトリとする。
# cp os/linux/mt7650u_sta.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless/ # mkdir -p /etc/Wireless/RT2870STA # cp RT2870STA.dat /etc/Wireless/RT2870STA/
次にWDC-433SU2Mをra0として扱えるように、modprobeの設定ファイルを書く。内容は以下の通り。
$ cat /etc/modprobe.d/99-local.conf alias ra0 mt7650u_sta
最後に、カーネルモジュールをカーネルに読み込んで、ドライバとして使えるようにする。
# depmod -a # modprobe mt7650u_sta
こうすれば、ifconfigなりiwconfigなり、あるいはip aとかでra0を確認できる。
結果
以上でWDC-433SU2Mをシステムへ認識させることはできる。しかし動かそうとすると、これはまた別の問題になる。前述のとおり、いい感じに通信させようとするとカーネルパニックを起こして死ぬのだ。いい感じに通信をすると死ぬというのは、pingを飛ばす程度なら死なないのにレポジトリを更新させようとしたり、ブラウザを立ち上げてインターネットしようとすると死ぬ、という意味でつかっている*1。
で、思い当たる節というのは、config.mkへのパッチでコンパイルオプションとして-Wno-date-timeをつけるようにしていることだ。こいつは
@item -Wdate-time
@opindex Wdate-time
@opindex Wno-date-time
Warn when macros @code{__TIME__}, @code{__DATE__} or @code{__TIMESTAMP__}
are encountered as they might prevent bit-wise-identical reproducable
compilations.
(Tobias Burnus - [Patch: libcpp, c-family, Fortran] Re: Warning about __DATE__ and __TIMEより引用、各行先頭'+'を除去)
だそうで、こいつを付けないと
CC [M] /dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.o /dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.c: In function ‘RTMPIoctlShow’: /dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.c:5401:85: error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time] snprintf(extra, size, "Driver version-%s, %s %s\n", STA_DRIVER_VERSION, __DATE__, __TIME__ ); ^ /dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.c:5401:95: error: macro "__TIME__" might prevent reproducible builds [-Werror=date-time] snprintf(extra, size, "Driver version-%s, %s %s\n", STA_DRIVER_VERSION, __DATE__, __TIME__ ); ^ cc1: some warnings being treated as errors scripts/Makefile.build:308: recipe for target '/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.o' failed make[2]: *** [/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux/../../sta/sta_cfg.o] Error 1 Makefile:1278: recipe for target '_module_/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux' failed make[1]: *** [_module_/dev/shm/mt7610u_wifi_sta_v3002_dpo_20130916/os/linux] Error 2 make[1]: Leaving directory '/usr/lib/modules/3.14.4-2-ck/build' Makefile:393: recipe for target 'LINUX' failed make: *** [LINUX] Error 2
とかいってコンパイルに失敗するのが、こいつをつけると抑制できる。しかし、無事コンパイルが通ってもカーネルパニックでシステムをブチ殺してしまうのなら、このオプションなしでコンパイルが通るようにしたほうがよさそうだ。しかし、上の中で表示されているエラーで検索してみても、AUR (en) - broadcom-wlなどのように、-Wno-date-timeでお茶を濁している感じで、どうにもならない。
802.11acの恩恵を受けたかった。WDC-433SU2MBKを使わず802.11nで過ごすぶんには何も問題はないので、こちらもそれでお茶を濁すことにしようと思う。