コグノスケ

画面のブランクを無効にする

目次: Linux

ROCK 3 model CのDebian bullseyeイメージは10分ほど？放置していると画面が消えてロック画面に戻る設定になっています。これはこれでありがたい動作ですが実験用に使っていてキーボードを繋いでいないことがあるので、ロック画面への移行と、画面が消える動作を無効化する方法をメモしておきます。

ロック画面の設定

ロック画面を無効化するには、Xfce4の[アプリケーション] - [設定] - [スクリーンセーバー]（xfce4-screensaver-preferences）の、

xfce4-screensaver-preferences

タブ[ロック画面] - [ロック画面を有効にする]をOFFにすれば良いみたいです。再起動後も設定を覚えてくれています。

画面が消える（DPMS）設定

画面が消える機能はDPMS（Display Power Management Signaling）といって、Xfce4の設定パネルからだと[アプリケーション] - [設定] - [電源管理]（xfce4-power-manager-settings）の、

xfce4-power-manager-settings

タブ[ディスプレイ] - [ブランク画面にするまでの時間]などから設定できます。しかしロック画面と違って設定を覚えてくれない？みたいで、再起動すると元に戻ってしまいます。理由が良くわからない……困った。

xsetとXDGで起動時にDPMSを設定

Xfce4は良くわからないので降参して、X Windowに頑張ってもらうことにします。DPMSの状態の設定と取得にはxsetを使います。リモートから実行するなら他のX Window Systemのアプリと同様にDISPLAY=:0などのように、どのディスプレイか指定する必要があります。

DPMSのStandby, Suspend, Offを一気に無効にするにはdpms 0 0 0と指定すれば良いです。DPMSの設定は最後の方に表示されます。

$ xset dpms 0 0 0

$ xset -q

Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  500    repeat rate:  20
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  2/1    threshold:  4
Screen Saver:
  prefer blanking:  no    allow exposures:  no
  timeout:  0    cycle:  300
Colors:
  default colormap:  0x20    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  /usr/share/fonts/X11/misc,/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/75dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,/usr/share/fonts/X11/75dpi,built-ins
DPMS (Energy Star):
  Standby: 0    Suspend: 0    Off: 0
  DPMS is Disabled

これだけだと再起動すると元に戻ってしまいますから、XDG autostartで毎回起動時に勝手に設定する仕掛けにします。システム全体ならば/etc/xdg/autostart/に、ユーザーごとに設定したいなら.config/autostart/に設定ファイルを作成します。ファイル名は何でも良いですが、今回はxset.desktopという名前にしました。

[Desktop Entry]
Name=xset
Comment=Disable DPM
Type=Application
Exec=/usr/bin/xset dpms 0 0 0
X-GNOME-Autostart-Phase=Initialization

ファイルを作成したら再起動して、DPMSが望み通りの設定に変わるか確かめます。

Xfce4の設定パネルからだと[アプリケーション] - [設定] - [セッションと起動]（xfce4-session-settings）からも作成＆設定できるはずです。たぶん。

JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信

目次: Arduino

M5Stamp C3をBluetooth LEデバイスにして、Linux PCもしくはRaspberry PiなどのLinux SBCとお話する取り組みの続編です。

今回はbluez-dbusを使ってBluetoothデバイスと通信します。

データ通信の仕組み

前回の話と少し重複しますが、Bluetoothデバイス特にBLEデバイスとはGATTプロファイルを使って通信します。BLEデバイスはサーバーになります。サーバーはService（＝提供する機能）を1つもしくは複数持っていて、Service、Characteristic、ValueとDescriptorが入れ子の構造になっています。

GATTサーバー（BLEデバイス）

Service

Characteristic

• Value
• Descriptor
• Descriptor
• ...

GATTのデータ送受信はCharacteristicのValueを読み書きすることで実現します。まずは簡単な送信側（Write）からご紹介します。

private BluetoothGattCharacteristic GattTx;

byte[] dat = new byte[len];

//送信するデータを用意する
//...

GattTx.writeValue(bpart, null);

バイト配列を用意してwriteValue()を呼びます。書き換え属性を持っているCharacteristicでないと書き込みが失敗します。

次は受信側（Read）です。writeValue()と同様にreadValue()も用意されていて、最後にReadした値を読み出せます。しかし一度読んだ値なのか新しい値なのか区別が付きません、つまり値の更新の有無がわかりません。

BluetoothGattCharacteristic GattRx;

byte[] dat = GattRx.readValue(null);

ではこの方法はダメなのか？というとそんなことはありません。一定時間ごとに現在値を見たい場合、例えば「温度計の値を1分ごとに読み出す」といった用途で役立ちます。

一方でストリームデータを扱う場合、新しい値がきたときだけ読み出したいので更新を検出する必要があります。検出には少しややこしい処理が必要です。bluez-dbusは何かの状態変化が起きるとPropertiesChangedというイベントで知らせてくることを利用します。使い方は、

• AbstractPropertiesChangedHandlerを継承したハンドラクラスを作成
• ハンドラクラスのインスタンスをDeviceManagerに登録
• BluetoothGattCharacteristicのstartNotify()を呼ぶ（BLEデバイスからのNotifyを検知できるようになる）

コードで書くと下記のようになります。

public class PropertiesChangedHandler extends AbstractPropertiesChangedHandler {
    @Override
    public void handle(Properties.PropertiesChanged props) {
    }
}

BluetoothGattCharacteristic GattRx;

DeviceManager deviceManager = DeviceManager.getInstance();
PropertiesChangedHandler handler = new PropertiesChangedHandler(...);
deviceManager.registerPropertyHandler(handler);

GattRx.startNotify();

PropertiesChangedハンドラはCharacteristicsの値の更新も、別の関係ないイベントも何でも受け取るので、何のイベントが発生したか判定する必要があります。bluez-dbusのBluetoothGattCharacteristicクラスと、PropertiesChangedクラスはいずれもD-Busのパス（/org/bluez/hci0/dev_xx_xx_xx_xx_xx_xx/service0028/char0029のような文字列）を返すメソッドを持っていますので、D-Busのパスが一致するかどうかで確かめます。

変化した値と名前のMapをgetPropertiesChanged()で取得できるので、全要素を調べて名前がValueであり、バイト配列を保持していればCharacteristicの値の変化を通知するイベントのはずです。

BluetoothGattCharacteristic GattRx;

Map<String, Variant<?>> mapProp = props.getPropertiesChanged();

if (GattRx.getDbusPath().equalsIgnoreCase(props.getPath())) {
    for (Map.Entry<String, Variant<?>> e : mapProp.entrySet()) {
        if (e.getValue().getValue() instanceof byte[]) {
            dat = (byte[])e.getValue().getValue();
        }
    }
}

自分でBLEデバイス側の実装をしているなら、意図しないイベントが混ざることはありません。上記のコードのように簡素なチェック（例えば単にバイト配列かどうかだけチェック）でも動作するはずです。

誕生日

早いもので41歳になりました。昨年の日記（2023年3月10日の日記参照）を見ると、コロナの流行を心配していました。

コロナの流行は相変わらずのように思いますが、世の人々はもう対策に疲れたのか、感染リスクを無視して暮らすスタイルが定着したようです。個人的には感染しないに越したことはないので、これからもマスクなど予防は心がけたいと思います。花粉症にもなりたくないし……。

働き方はリモート10割から、リモート:出社=7:3〜5:5くらいの割合に落ち着きつつあります。特にオフィスに用事がなければ行かないなんて、昔では考えられない通勤スタイルですね。

この働き方の利点は「遠隔地に居る人」が気にならなくなることです。オフィスに集まる場合を除けば、家も沖縄も北海道も大して変わらないのです。実際、東京から離れて住んでいる人もいるようですね。

車のバッテリー完全に死亡で交換かと思いきや

目次: 車

またまた車のバッテリーが干上がって死にました。写真は撮っていませんが2Vくらいになっていたように思います。

しかし今日はディーラーでの半年点検の日でディーラーに行かなければならないので、ジャンプスタートしてエンジンをかけてディーラーまで行きました。去年買った（2023年4月22日の日記参照）KashimuraのジャンプスターターKD-238が大活躍です。活躍しないほうが本当は良いけど。

ディーラーに辿り着いて車を預けたら、ディーラーの駐車場から動かそうとしたらバッテリーが上がってて動かせなかった、ジャンプスタートしたと言われました。ごめんね……。

ディーラーからの意外な提案

またバッテリー交換で財布が軽くなるな〜と思っていたら、整備士さんからは意外な提案が返ってきました。

• 一時的にディーラー所有のバッテリーに交換して車を返す
• 上がった方のバッテリーは1週間掛けて充電してみる
• バッテリーが充電できたら連絡するからまた来てほしい

とのこと。

バッテリー交換以外の新たなパターンに出会いました。交換して1年、走行距離も1000km程度、バッテリーはこんなに劣化しないはず？と判断したみたいです。たぶん安く何とかしてみたい、というご提案だと理解して素直に承諾しました。

バッテリー復活なるか？いつもと違うので楽しみですね。

JavaとM5Stamp C3とBluetooth LE - BluetoothデバイスとServiceの列挙

目次: Arduino

M5Stamp C3をBluetooth LEデバイスにして、Linux PCもしくはRaspberry PiなどのLinux SBCとお話する取り組みの続編です。

今回はbluez-dbusを使ってBluetoothデバイスの列挙、GATTのServiceの列挙を行います。

アダプタとデバイスの列挙

DeviceManagerというクラスとDeviceManagerクラスのスタティックメソッドが、bluez-dbusを使うときの根っこになります。

DeviceManagerのインスタンスを作成するため最初にcreateInstance()を呼ぶ必要があります。1回で良いです。これ以降はDeviceManager.getInstance()でDeviceManagerのインスタンスが取得できます。引数はfalseならシステム全体用のバスインタフェース、trueなら現在のログインセッション用のバスインタフェースに接続します。Bluetoothの仕組みとは関係なくて、Bluezが依存しているD-Busの仕組みが透けて見えています。たぶんfalseで良いはず。

//一番最初に1回呼ぶ
DeviceManager.createInstance(false);

//以降はgetInstance()でDeviceManagerオブジェクトを取得できる
DeviceManager.getInstance();

システムに存在するBluetoothアダプターの一覧を得る方法はこんな感じです。お手軽です。

DeviceManager deviceManager = DeviceManager.getInstance();

List<BluetoothAdapter> adapters = deviceManager.getAdapters();

Bluetoothアダプターを1つ選んだら、Bluetoothデバイスを探して（Discovery）、ある程度時間を置いて見つかったデバイスの一覧を取得します。

BluetoothAdapter adapter;

adapter.startDiscovery();
try {
    Thread.sleep(3000);
} catch (InterruptedException ex) {
    //ignore
}
adapter.stopDiscovery();

List<BluetoothDevice> devices = deviceManager.getDevices(true);

注意点としてはstartDiscovery()とstopDiscovery()の間はある程度の時間を開けないとデバイスが1個も見つかりません。

Serviceの列挙

Bluetoothデバイス特にBLE（Bluetooth Low Energy）デバイスとはGATTプロファイルを使って通信します。BluetoothにはATTプロトコル（Attribute Protocol）という属性をやり取りするプロトコルがあります。GATTはATTプロトコルの上で汎用的（Generic）にデータを通信するための取り決め（プロファイル）になります。

GATTというかATTはクライアント・サーバー方式のプロトコルでして、BLEデバイスはサーバーになります。サーバーはService（＝提供する機能）を1つもしくは複数持っています。1つのService内にはCharacteristicが並んでおり、CharacteristicにはValueとDescriptorが並んでいます。こんな感じです。

GATTサーバー（BLEデバイス）

Service

Characteristic

• Value
• Descriptor
• Descriptor
• ...

Characteristic

• Value
• Descriptor

Service

Characteristic

...

Characteristic

...

通信に使うのはCharacteristicですが、いきなりCharacteristicを列挙することはできません。上位側にあるServiceから列挙します。Serviceを探すにはconnect()してgetGattServices()を呼びます。connect()とdisconnect()は数秒レベルで時間がかかります。

今回はM5Stamp C3に対してペアリングなしで接続しています。ペアリングなし＝通信路の盗聴や乗っ取りをされる可能性があります。今回は特に困らないのでこのまま話を進めますが、盗聴や乗っ取りをされると困る場合はペアリングをする必要があります。ペアリングの方法もご紹介したいですが、今はやり方がわかりません。わかったらまた別の日記にでも書きます。

Serviceの列挙

BluetoothDevice device;
device.connect();
device.refreshGattServices();

List<BluetoothGattService> gattServices = device.getGattServices();

device.disconnect();

GATTのService内のCharacteristicを探すにはgetGattCharacteristics()を呼びます。

Characteristicの列挙

BluetoothGattService srv;
srv.refreshGattCharacteristics();

List<BluetoothGattCharacteristic> gattCharacteristics = srv.getGattCharacteristics();

CharacteristicのDescriptorも取得できます（getGattDescriptors()メソッドを使います）が、今回は特に必要ありませんので列挙するためのコードは割愛します。

送受信の方法はまた今度。

Raspberry Pi 3 model Bの代わりにROCK 3 model C

目次: ARM

最近、M5Stamp C3 + Raspberry Piを組み合わせて的あてゲームを作っています。Bluetooth通信クライアント側のLinuxマシンにRaspberry Pi 3 model Bを使っているものの、販売終了につき新品が手に入りません。今は1台あれば良いので困りませんが、後でN増しするとき困りそうです。

Linuxマシン側の要件を挙げると、

• Must: Linuxが動作、x86でもARMでも良い
• Must: HDMI出力、USBホスト機能
• Want: Bluetooth 4.0以上（BLEを使う）
• Want: Raspberry Pi 3より速い、Raspberry Pi 5ほど性能は要らない
• Want: 昔のRaspberry Pi 3Bくらいの価格（5,000円くらい）

まず値段的にx86のノートPCやNUCは購入候補から外れます（中古品でも厳しい）。ARMのSBCですと、FRIENDLY ELECのNanoPi R5系（Rockcihp RK3568B, Cortex-A55 x 4）か、OKDO/Radxa ROCK 3 model C 1GB版（Rockchip RK3566, Cortex-A55 x 4）がちょうど良さそうでした。

NanoPiとROCK 3はどちらでも良かったのですが、RSコンポーネンツで容易に購入できるROCK 3 model C 1GB版に決めました。

JavaのGraphics 2Dが遅い？

ROCK 3 model CはRaspberry Pi 3 model Bを置き換えるにふさわしい製品だと思いますが、私の使い方だと1点だけ問題があって、Javaの画面描画が致命的に遅いです。5秒に1回くらいしか描画されません。このままでは使いたい目的に合いません。

最初にGPUが有効になっているか確認です。GPU使用率を/sys/devices/platform/fed60000.gpu/utilizationを見ると、無負荷のときは0、アプリ起動時で20くらいでGPUは動いています。問題なさそうです。むしろ暇しているというか余裕すらありそうです。Javaのライブラリ系orアプリ実装の問題でしょう。

次にJavaのライブラリ系を確認です。現在、画面描画のダブルバッファリングに使っているのはBufferStrategyで、BufferStrategyが返すVolatileImageのisAccelerated()はTrueを返します。OpenGLによるHW描画が使われているようです。これも問題なさそうです。残るはアプリ実装の問題ですね。

余談ですが下記のようにGraphics2D経由で確認すると、

((Graphics2D)strategy.getDrawGraphics()).getDeviceConfiguration().getImageCapabilities().isAccelerated()

なぜかisAccelerated()がFalseになります。良くわからん動きです。

Graphics2Dのアンチエイリアス機能が遅い

タイトルの通りですが、アプリ実装が原因でした。コードでいえば下記の部分です。

Graphics2D g2;

g2.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);
g2.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_ON);

図形描画とテキスト描画のアンチエイリアスをONにして使っていましたが、このうち図形描画のアンチエイリアスをONにすると著しく描画速度が下がることがわかりました。Raspberry Pi 3 model Bは双方のアンチエイリアスをONにしても特に問題がなかったため、気づくまで結構手間取りました。

図形描画のアンチエイリアスは今のところ見た目にさほど影響がないので、OFFにしました。テキスト描画のアンチエイリアスも描画速度に多少影響ありますが、OFFにすると見た目が悪くなりすぎるので、ONのまま使います。

問題の解決はしていませんが、回避できたのは良かったです。勢いで3つも買ってしまったROCK 3 model Cの不良在庫化を避けられました……。