fbcp は何をしている？

frame buffer をコピーするアプリケーションなのは名前から明らかだけれど、何のために？と思った。結論をいうと GPU でレンダリングした結果を SPI 接続の液晶へ表示させるためのハックのようだ。GPU を使わないなら入れなくても動かすことはできる。

dtb dts

dtb ファイル (コンパイル済みのデバイスツリーブロブ) が含まれているけど、ソースファイルがない。以下のようにするとソースにディスアセンブルできる。

dtc -I dtb -O dts -o waveshare32b-overlay.dts waveshare32b-overlay.dtb

以下のような感じのデバイスツリーとなっていた。

/dts-v1/;

/ {
        compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

        fragment@0 {
                target = <0xdeadbeef>;

                __overlay__ {
                        status = "okay";

                        spidev@0 {
                                status = "disabled";
                        };

                        spidev@1 {
                                status = "disabled";
                        };
                };
        };

        fragment@1 {
                target = <0xdeadbeef>;

                __overlay__ {

                        waveshare32b_pins {
                                brcm,pins = <0x11 0x1b 0x16>;
                                brcm,function = <0x0 0x0 0x0>;
                                linux,phandle = <0x1>;
                                phandle = <0x1>;
                        };
                };
        };

        fragment@2 {
                target = <0xdeadbeef>;

                __overlay__ {
                        #address-cells = <0x1>;
                        #size-cells = <0x0>;

                        waveshare32b@0 {
                                compatible = "ilitek,ili9340";
                                reg = <0x0>;
                                pinctrl-names = "default";
                                pinctrl-0 = <0x1>;
                                spi-max-frequency = <0xf42400>;
                                rotate = <0x5a>;
                                fps = <0x19>;
                                bgr;
                                buswidth = <0x8>;
                                reset-gpios = <0xdeadbeef 0x1b 0x0>;
                                dc-gpios = <0xdeadbeef 0x16 0x0>;
                                debug = <0x0>;
                                linux,phandle = <0x2>;
                                phandle = <0x2>;
                        };

                        waveshare35a-ts@1 {
                                compatible = "ti,ads7846";
                                reg = <0x1>;
                        };

                        waveshare32b_ts@1 {
                                compatible = "ti,ads7846";
                                reg = <0x1>;
                                spi-max-frequency = <0x1e8480>;
                                interrupts = <0x11 0x2>;
                                interrupt-parent = <0xdeadbeef>;
                                pendown-gpio = <0xdeadbeef 0x11 0x0>;
                                ti,x-plate-ohms = [00 3c];
                                ti,pressure-max = [00 ff];
                        };
                };
        };

        __overrides__ {
                speed = <0x2 0x7370692d 0x6d61782d 0x66726571 0x75656e63 0x793a3000>;
                rotate = [00 00 00 02 72 6f 74 61 74 65 3a 30 00];
                fps = [00 00 00 02 66 70 73 3a 30 00];
                debug = <0x2 0x64656275 0x673a3000>;
        };

        __symbols__ {
                waveshare32b_pins = "/fragment@1/__overlay__/waveshare32b_pins";
                waveshare32b = "/fragment@2/__overlay__/waveshare32b@0";
        };
        __fixups__ {
                spi0 = "/fragment@0:target:0", "/fragment@2:target:0";
                gpio = "/fragment@1:target:0", "/fragment@2/__overlay__/waveshare32b@0:reset-gpios:0", "/fragment@2/__overlay__/waveshare32b@0:dc-gpios:0", "/fragment@2/__overlay__/waveshare32b_ts@1:interrupt-parent:0", "/fragment@2/__overlay__/waveshare32b_ts@1:pendown-gpio:0";
        };

        __local_fixups__ {
                fixup = "/fragment@2/__overlay__/waveshare32b@0:pinctrl-0:0", "/__overrides__:speed:0", "/__overrides__:rotate:0", "/__overrides__:fps:0", "/__overrides__:debug:0";
        };
};

Device Tree って何か？

簡単にいうとそのハードウェアのドライバの用の設定ファイル。ほぼ同じ制御方法をするハードウェアであっても、細かい制御アドレスの違い・使用バス・接続されているGPIOピンの違いが存在する。これらをいちいちカーネルにハードコードしてコンパイルするのは面倒なので、設定ファイルとして分離してある。ARM Linux だと標準的に使われている。

DTS ファイルの書きかた https://elinux.org/Device_Tree_Usage

• compatible = "ilitek,ili9340" の部分でドライバを指定している "vendor,product" 形式。

正直読むのに苦労する。完全に理解してない。

タッチコントローラのキャリブレーション

$ DISPLAY=:0 xinput_calibrator
...
Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "ADS7846 Touchscreen"
        Option  "Calibration"   "195 3780 3881 252"
        Option  "SwapAxes"      "1"
EndSection

$ sudo vi /usr/share/X11/xorg.conf.d/99-calibration.conf 
# copy calibration from above

Chromium を kiosk で自動起動する

raspi-config で起動モードを Desktop (autologin) に設定する。

sudo raspi-config

マウスカーソルを自動で消すやつをいれる。

$ sudo apt-get install unclutter

不正終了で残るファイルを reboot 時に消しておく。

$ crontab -e
@reboot rm -rf ~/.config/chromium/Singleton*

Raspberry Pi は Desktop の場合 LXDE が使われる。これの起動時に必要なものを自動起動するように設定する。

chromium-browser の引数は重要。とりあえずこのあたりを指定しておくと良い。

$ vi ~/.config/lxsession/LXDE-pi/autostart
#@lxpanel --profile LXDE-pi
#@pcmanfm --desktop --profile LXDE-pi
#@xscreensaver -no-splash
#@point-rpi

@xset s off
@xset -dpms
@xset s noblank
@unclutter
@chromium-browser --remote-debugging-port=9222 --no-default-browser-check --noerrdialogs --kiosk --incognito https://example.com

Chrome を remote-debugging

• • remote-debugging-port をつけているので remote debugging が有効なのだが、おそらくループバックインターフェイスしか受け付けてないのでLAN内の他のコンピュータからは直接アクセスできなかった。このため他のコンピュータから Raspberry Pi へログインするときにポートフォワードする。

ssh -L 9223:127.0.0.1:9222 pi@192.168.0.23 

これで、ログインしたコンピュータで http://localhost:9223/ するとデバッグコンソールを出せる (タブ一覧が出るので選択すれば良い)。JS が実行できるので、raspi 上で操作しなくとも特定 URL に移動したり、リロードしたりできる。もちろんエレメントインスペクタも使うことができる。

Import DXF File で位置が毎回ずれる

フットプリントエディタで Import DXF File をするとき、カーソルを動かしてしまうと、なぜか変なポイントがスナップされてしまってどうしよもうなくなる。

User Defined で 0, 0 に設定すると DXF の原点と footprint editor の原点があった状態で表示されるので、そのままクリックして位置を確定する。

Fusion360 のスケッチを書くとき、原点を外形ではなくピンの位置にしたほうが KiCAD で配置しやすい。(誤差0にしなくても、拡大して移動してだいたいあわせれば十分だけど)

DXF Import 時に線幅を設定したい

footprint editor では不可能っぽい。諦めよう

Fusion360 の補助線まで dxf に含まれてしまう

下書き用のスケッチと、エクスポート用のスケッチをわけて、エクスポート用のスケッチでプロジェクションするとよい

こういう感じ

ノングレアよりはすりガラスに近いのでほぼ透けないが、背景白だとあんまり変わらないでしょう。物撮り自体 (というか写真が……) 下手なのでもうちょい練習したさはある……

今回の写真は全部スマフォ (Huawei P20)。まじでコンデジはいらないですね……

PEIフィルムを剥す

交換方法のマニュアルがある。シートを剥すまではいいんだけど、接着剤を剥すのがとてつもなく大変だった。リモネンはいまいち買えないので市販のシール剥し剤を使うのが良さそう。今回はアセトンとアルコールでやってみたけどかなり時間がかかったのでこれはおすすめしない。

公式の代替PEIフィルムは$8.96とそれほど高価なわけではないが、送料が$20以上と高いのと、一度貼ると剥すのがとてつもなく大変なのがわかったため、気がすすまなかった。

磁石にくっつくことからして、普通の鉄のシートっぽいので露出して放置すると錆が心配になる。

交換

3M の 3D プリンタ用プラットフォームシートを試してみることにした。一枚あたり1500円とあまり安いとはいえない。

貼るのは難しくない。ぴったりサイズではないので結構余りがでる。もったいないけどカットして捨てている。

貼ったあとに保護シートを剥すと、すべり止めがきいたような表面材質がでてくる。このため、保護シートを剥したあとにスキージで貼りつけなおすみたいなことはできないので注意。必ず保護シートを剥すまえに密着させる必要がある。

表面は白っぽくほぼ不透明なため、元のスチールプレートの文字や印刷範囲の表示はほぼ見えなくなる。

雑感

数回 PETG でプリントしてみたが、今のところはとてもいい感じ。ちなみに最初のレイヤーも 0.2mm でプリントしている。このシートの説明では 0.1mm でベストと書いてあるので推奨設定ではない。

食いつきはよく最初のレイヤーが失敗することはまずない。PETG は PEI フィルムだとくっつきすぎることがあったけど、このシートだとそこそこ広い設置面のオブジェクトでも剥すに苦労しなかった。

ただ表面がつるつるではないのでスキージはちょっと入れにくいように感じる。あんまり強力に貼りついた場合剥せなくなるかもしれない。

耐久性はまだわからない。プリントして剥すとシートの表面の何かが少しくっついて剥れていくようにも見える。

箱

食品保存用のアスベル キッチンボックス 17L 「ウィル」 NF-45というのを買ってみた。フィラメントを納めるにはちょうどいい。3リールほど入れることができる。蓋にパッキンがついていて、これで密閉度を高めるようになっている。パッキンはメーカーでスペアも販売している。

アスベルのこのボックスは完全密閉というわけではないみたいだが、後述するようにフィラメントを通す穴をあけるので、いずれにせよ完全ではなくなる。目的は水を漏らさないということではなく湿度を下げた状態をキープすることなので、乾燥剤が十分に延命できれば良い。

加工

防湿しつつフィラメントをそのままプリンタに供給したいので、加工する。

フィラメントを出す部分のパーツは Angled Dry Box Feeder with Source を使った。ドリルするときのガイドパーツまであって親切。これに以下の PC4-M6 ワンタッチ継手と、OD=4mm ID=2mm の PTFEチューブを使っている。

フィラメントホルダーは Universal Filament Holder を使っている。これだと残念ながら3つのリールを入れることはできず、2つアクティブ+1つスタンバイという感じになる。

乾燥剤

ひとまず塩化力ルシウムのものを1つ入れている。これは使い捨てだが元の体積以上に吸湿できる。

またシリカゲルをリール近くにおいている。これはフライパンで炒れば再利用可能。

今一緒に入れている湿度計は20%未満になると湿度の表示を止めてしまうので、どのぐらいまで湿度が下げらているかよくわからないが、室内湿度が55%程度でもずっと20%未満なので割といいんじゃないでしょうか。

解決方法

• ベースブランチをPRブランチにマージする(または rebase する)
  • 重要：GitHub 上でコンフリクト表示が出ているか否かは関係ない

PRのテスト結果の表示

GitHub 上に表示されるテスト結果のインジケータには上記のように2つのケースがあり、Jenkins 側のログを見ないと厳密に判断することができない。

GitHub 上での Conflict 表示でもある程度判断できるが、CI を通ったあとにベースブランチに変更が入って Conflict した場合は PR ブランチで再テストが走るまで過去の結果が表示されるため正確ではない。

備考

• origin/pr/{pr}/merge は普通に clone すると含まれないため、Jenkins が存在しない謎のコミットをビルドしているようにみえる

仕組み

これは Credential Management API という仕組みを使うと実現できる。現状では Chrome しか対応していないようだ。Google が公開しているエントリにこれの実現方法も書いてある。https://developers.google.com/web/updates/2017/06/credential-management-updates 割と詳しい説明が書いてあるのでこれを読めばよろしい。が、自分でも試してみたのでメモしておく。

雑に自分のサイトに自動ログインを導入したい、と思った場合、ログインページに以下のようなコードを仕込むだけで実現できてしまう。

(async function () {
	const cred = await navigator.credentials.get({
		password: true
	});
	// console.log(cred);

	document.getElementById('username').value = cred.id;
	document.getElementById('password').value = cred.password;
	document.getElementById('login').submit();
})();

もちろんこれだけだと欠点がある。すなわち、ログインページを表示した際に強制的にログインしてしまう。もしあなたのサイトが認証状態がないときにログインページにリダイレクトして戻ってくるような仕様だとすると「ログアウト」が不可能になってしまいます。この実装だけではダメですね。

これを防ぐにはログアウト時に preventSilentAccess() を使ったり、 get() に指定する mediation の値を変更したりする必要があります。詳しくは前述の Google のエントリを読むと良いでしょう。

コードを見るとわかるが全く複雑なことはないですね。id と password が JavaScript から取得できるため、それを既設のフォームに埋めているだけ。console.log() のコメントアウトをはずすと、自分のパスワードが console に表示されるのでビビることができます。

JSからパスワードとれんの？？？ こわくない？？

こわいわ〜と直感的に思いますね。その感覚は正しいと思うんです。でもね、「ブラウザに保存しているパスワード」は実情、自動フィルインされるわけですが、このフィルインされたパスワードって Credential Management API に関係なく、そもそも input.value で JS から読めるんですよね。

そう考えると、このAPIは単にフィルイン+ログインボタンクリックという操作を、確実かついい感じに(ログアウトも考慮して)行える方法で代行しているだけという仕組みになりますね。複数アカウントを考慮しつつ1クリック減らせるという感じです。