Let's note CF-SV8RDCVSのFreeBSD/amd64 15.1-RELEASEの内蔵カメラ

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンには内蔵カメラがついています。これまで所有してきたデスクトップPCやノートPCで内蔵カメラがあるのは初めてです。当面使う予定はありませんが、ちょっと試してみました。

 

設定手順は難しくありません。

1. 「pkg install webcamd」でwebcamdをインストールします。
2. 本来なら「sysrc webcamd_enable="YES"」しておいて、「service webcamd start」すべきなのですが、一時的なテスト目的ですので、以下の手順で直接起動しました。
3. 「kldload cuse」しておいて、「webcamd -d ugen0.2 -B」として起動します。ここで「ugen0.2」は内蔵カメラのデバイス番号です。ここで「/dev/video0」などのデバイスが出来ていることを確認します。
4. 内蔵カメラを使うユーザは「pw groupmod webcamd -m ユーザ名」としてグループ「webcamd」を加えておく必要があります。

これで設定できたので、内蔵カメラを使ってみます。

1. 「v4l2-ctl -d /dev/video0 --list-ctrls」や「v4l2-ctl -d /dev/video0 --list-formats-ext」で内蔵カメラの情報を取得してみます。
2. 実際のアプリケーションで内蔵カメラを使ってみます。今回は「ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -ss 2 -i /dev/video0 -vframes 1 test.jpg」として、静止画をファイルに落としてみました。

 

以上で、動作は確認できました。当面利用することはないのですが、何かの折に役立つのではないかと思います。

Let's note CF-SV8RDCVSのFreeBSD/amd64 15.1-RELEASEでBluetooth

Let's note CF-SV8RDCVSにFreeBSD/amd64 15.1-RELEASEをインストールしました。このマシンにはBluetoothがあります。Bluetoothを積極的に使ってみたいという訳ではないのですが、どんな風に使うのか気になったので、設定してみました。

 

設定手順は難しくありません。

1. 「pkg install iwmbt-firmware」でファームウェアパッケージをインストールします。
2. 「usbconfig | grep -i bluetooth」でデバイスの番号を確認しておきます。
3. 「iwmbtfw -d ugen0.3 -f /usr/local/share/iwmbt-firmware」でファームウェアを転送します。ここでは「ugen0.3」が前項で確認したデバイス番号です。

 

これで設定できたので、Bluetoothを使ってみます。

1. 「hccontrol -n ubt0hci Read_BD_ADDR」でBluetooth MACアドレスを読み取ってみます。
2. 「hccontrol -n ubt0hci Inquiry」で周辺にある機器が反応するか確認してみます。

 

Bluetoothに対応した機器はスマホくらいしか所有していません。「Inquiry」で検出できたのは確認しました。しかしBluetoothを使って、何かをしようという気にはならなかったので、確認はここまでとしました。 

KB5124008の影響で「ファイル履歴が外付けドライブを認識しない」という問題が発生しているらしい

記事「Windows 11の大型アップデートKB5124008で深刻な不具合続出…「更新を遅らせるな」の直後に混乱発生」によると、「ファイル履歴(File History)がバックアップ用ドライブを認識しないという報告が多数上がって」いるそうです。私が「ファイル履歴」が動かなくなったのも、これが原因なのかもしれません。

 

マイクロソフトは「ファイル履歴」を重視していないように見受けられます。推測となりますが「OneDrive」を推しているのでしょう。

 

もしかすると、この問題が解決するパッチが出るかもしれません。しかし私自身は、「ファイル履歴」からFreeFileSyncに移行するつもりです。 

FreeFileSyncにおける「比較」の挙動

Windows11では「ファイル履歴」の動作が怪しいので、FreeFileSyncを使用して同等機能を実現しようと思います。ちょっと試したら、ほぼ期待したようになったのですが、こちらはこちらで動作が怪しいです。

 

同期元はWindows11で、同期先はFreeBSD上のSambaです。初回は同期対象ファイルを全てコピーします。これは想定しているとおりです。問題は、2回目以降の同期対象ファイルが多すぎることです。ログを残す設定にしているので、どのファイルがコピーされたのかは把握できます。しかし、全く変更していないファイルが同期対象ファイルとして選ばれています。これは、FreeFileSyncにおける「比較」処理の問題です。

 

FreeFileSyncでは、同期元と同期先のファイルを「比較」し、同期対象ファイルを選択します。この「比較」では、「変更日時とファイルサイズ」、「ファイル内容」、「ファイルサイズのみ」という手段が提供されています。よく利用されるのは「変更日時とファイルサイズ」のようです。

 

FreeFileSyncには、デバッグ用ログというものが存在しないので、挙動を観察して状況を推測するしかありません。同期対象として選択されるファイルについて、Windows11側とSamba側のタイムスタンプの精度が関係している気がします。Windows11側では秒以下の時間も記録しているようですが、Samba側では記録していないようなので、「比較」すると「差異がある」という判断になってしまうようなのです。

 

それでは「比較」を「ファイルサイズのみ」でおこなうことにしたら、うまくいくのではないかと思い、試してみました。ところが相変わらず、全く変更していないファイルが同期対象ファイルとして選択されてしまいます。「比較」には「ファイル内容」という手法もありますが、ファイルの内容を読むのは処理時間が相当長くなる恐れがあるので、試してみるのは避けようと思います。 

 

2回目以降の同期で誤って同期対象ファイルを選択していると思われるのは、全ファイルの1%弱なので、スッキリと納得はできませんが、このまま利用を続けてみようと思います。 

Windows11の「ファイル履歴」は非推奨なのか

自宅で使用しているデスクトップPCは、Windows8からWindows10に移行し、昨年にはWindows11を使っています。Windows10の頃から「ファイル履歴」を使用してきました。普段のオペレーションで、うっかりファイルを削除してしまったり、上書きしてしまったことがあり、その場合に救出するのに役立ちました。

Windows11になってから、「ファイル履歴」の動作がWindos10の頃とは違う気がしていましたが、動作はしていました。しかし数日前に動作が止まり、再実行させようとしても、「ファイル履歴のドライブに再接続してバックアップを実行するまでの間、ファイルは一時的にハードドライブにコピーされます。」というエラーがでてしまいます。解決を試みましたが、動作するようになりません。

 

Geminiに相談すると、Windows11では「ファイル履歴」を非推奨にしようとしている傾向がみられるとのことでした。そうであれば、もう「ファイル履歴」を使い続けるのは諦め、何か別の手段に移行しようと思います。FreeFileSyncというものがあるそうなので、使ってみようと思います。

FreeBSDにおいてディスプレイマネージャのパッケージは共存できない

Let's note CF-SV8RDCVSに様々なディスプレイマネージャをパッケージからインストールしてみました。最初はKDEと親和性が高いSDDM、次にGNOMEのお友達のGDM、それからLightDMなどです。全て「pkg install」でインストールしました。その時に画面をよく見ていなかったのが悪いと言われれば、その通りなのですが、これらのディスプレイマネージャは、共存できないようです。つまり、他のディスプレイマネージャをインストールしようとすると、既にインストールされているディスプレイマネージャは、自動的に削除されてしまいます。

 

ディスプレイマネージャを使うには、/etc/rc.confに「lightdm_enable="YES"」のような設定が必要です。昔はエディタで手書きしていましたが、今は「sysrc」というコマンドを使うのが推奨されているようです。

 

複数のディスプレイマネージャを入れると、/etc/rc.confに「sddm_enable="NO"」とか「lightdm_enable="YES"」のような設定が残ります。複数のディスプレイマネージャを「YES」にするのは、さすがにマズいと思いますが、どれか一つだけを「YES」にして、残りを「NO」にするのは、問題ないと思います。それでは、「YES」と「NO」を切り替えながら、複数のディスプレイマネージャを切り替えて使えるのかというと、どうも違うようです。つまり、そのYESやNOの設定とは無関係に、最後に「pkg install」したディスプレイマネージャ以外は、削除されているからです。

 

もしSDDMをインストールし、「sddm_enable="YES"」としたとします。次にLightDMをインストールし、「lightdm_enable="YES"」として、忘れずに「sddm_enable="NO"」とします。さて、再度SDDMを使う場合は、どうなるでしょうか。「sddm_enable="YES"」とするだけではダメなのです。何故ならSDDMのパッケージは、LightDMをインストールした際に削除されているからです。あらためてSDDMをインストールし直さなければなりません。

 

KDEやXfceのようなデスクトップ環境は、複数インストールしておいて、切り替えて使用できます。しかしSDDMやLightDMのようなディスプレイマネージャは、複数インストールできませんので、切り替えてるつもりなら、そのたびにインストールが必要です。

 

ディスプレイマネージャもデスクトップ環境のように、複数インストールして、切り替えて使用できても良いような気もしますが、できない「仕様」のようです。ちょっと混乱して、勘違いしてしまいました。 

KDE、GNOMEに次いで、Xfce

Let's note CF-SV8RDCVSにインストールしたFreeBSD/amd64 15.1-RELEASE環境で、KDE、GNOMEに次いでXfceを入れてみました。導入手順は、これまでと同様で、『FreeBSD Handbook』の「8.2.3. XFCE」に従いました。GNOMEでは手順通りでは動作しなくて苦労しましたが、Xfceはあっさり動作しました。

 

これまで、KDEやGNOMEをインストールしてきたので、Xfceのプログラムメニューには、KDEやGNOMEのアプリケーションも出現しています。しかも、KDEでは、note-jpやfcitx5-anthyなどの日本語環境を整えておいたので、Xfceでも日本語環境が引き継がれています。そういうものなのでしょうか。デスクトップ環境を入れるたびに、個別に日本語環境を設定する必要があると思い込んでいたので、何もしなくて済んで有難いことです。

 

ディスプレイマネージャはLightDMです。これまでインストールしたKDEやGNOMEを選ぶこともできます。その日の気分でディスプレイ環境を切り替えられるというのも、予想外なので、驚きです。