マルチスレッドとgenerator。

 通常の線形の処理なら問題ないのですが、処理を効率化しようとマルチスレッドにすると、処理をする対象をどうやってスレッドに渡そうかと思うことがあります。

たとえば、たこ焼きを焼いています。

たこ焼き器の凹みをなんて呼ぶのかは知らないのですが、タコツボとでも呼びましょう。

タコツボにはかならず1つのタコを入れます。2つ入れてはいけないし、1つも入ってないのもだめです。

たこ焼き職人が1人なら問題ありません。順序よくタコツボにタコを落としていきます。

職人が2人になると、問題が起こります。タコツボに入れたタコは沈んでしまうので、もうひとりの職人が間違ってもう1個のタコを入れてしまうかもしれません。

それを防ぐためにはタコツボを管理する人が必要です。タコツボを差し出しておいて、どちらかの職人がタコを入れたらすっと引っ込めて次のタコツボを差し出します。そうすればどちらの職人がタコを入れようが、タコツボには1つのタコだけが入ります。


なんて、よくわからない喩え話ですが、要は処理したいシーケンスがあり、そのシーケンスのアイテムは一度だけ処理されればよい、なのでスレッド外で誰かが管理しないといけない、ということです。

リストですと、シングルスレッドならば

for item in itemlist:

で片付きます。ところがマルチスレッドにするといきなりずっこけます。というか、どう言うコードを書いたらいいものかと考えてしまいます。

1つは明らかにitemlistのインデックスを管理するカウント変数を用意して、各スレッドは自分がitemを受け取ったらそのカウント変数を+1する方法です。当然ならそのカウント変数はグローバルになるでしょうから、スレッドセーフではありません。なので、itemを受け取ってカウント変数を+1するまでは、ロックしておかないといけません。

ところがこれがインデックスで管理できるものならよいのですが、たとえばディレクトリツリーを探索する、みたいな感じだとそうも言っていられません。ツリーが巨大になると、そのツリーをリスト化するだけでも結構な時間がかかります。

そこでgeneratorです。アイテムを返すジェネレータを1つだけ用意し、各スレッドから排他的にデータを受け取れれば、二重に処理されるということもありません。

ということで、こんな風にしてみました。


import threading
from random import random
from time import sleep



def get_word():
	l = """
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
"""
	s = l.split(" ")
    for t in s:
        yield t

def tthread(name=""):
    waittime = random()
    while True:
        with lock:
            try:
                t = gen.__next__()
            except StopIteration as e:
                break
        print(f"{t}", end=" ")
        sleep(waittime)


def main():
    t1 = threading.Thread(target=tthread)
    t2 = threading.Thread(target=tthread)
    t1.start()
    t2.start()

gen= get_word()
lock = threading.Lock()
main()
もとの文は PEP 20です。
lockを取得できたら1単語もらって表示する、というだけですが、__next__()がいい仕事してくれます。

IntelのドライバがWindowsUpdateで巻き戻される件。

ffmpeg や QSVEnc の関係で、Intel の Quick Sync Video を使っているので、ドライバのバージョンを勝手に上げられたり巻き戻されたりするのはすごくやっかいです。

デバイスドライバだけ Windows Update の対象外にできないか、と思ったのですが、検索してみたら次の記事が引っかかりました。


これによると、PowerShellの管理者モードで、レジストリに以下のキーと値を設定することで回避できる、とのこと。

reg add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v ExcludeWUDriversInQualityUpdate /t REG_DWORD /d 1 /f

最近ちょくちょく PowerShell は使っているのですが、ここはオーソドックスに Regedit でやってみました。

  1. HKLM\SOFTWARE\Policies\Microsoft\Windows に行く。
  2. 新規にキー WindowsUpdate を作成する。
  3. キーに移動して、新規に DWORD で ExcludeWUDriversInQualityUpdate を作成し、値を 1 にする。
これでほんとに回避できるかどうか、しばらく見てみようと思います。

Path.globでファイル名に[]を含む場合のエスケープ。

 Pythonのpathlib.Pathにあるglob()ですが、どうしても引っ掛けられないファイル名が出てきて、どうすればよいか調べ中です。

具体的には、globの引数に "*[123].txt" というような、[] で囲まれた文字があるファイル名を指定したいのですが、それが引っかかってこない。どうやらワイルドカードの特殊文字になっているようです。

別のライブラリ glob には glob.escape() というメソッドがあるのですが、それを使うと今度は "*" がエスケープされてしまい、やっぱりファイルが引っかかりません。

はてさてどうしたものか……。

足りない頭で考えましたが、結局pathlib.Path.glob()で扱うことは諦めて、glob.glob()とglob.escape()を組み合わせて使うことにしました。

from glob import glob, escape
from pathlib import Path

def bracketglob(s: str):
    """generate a list of filenames from a string that contains "[]".

    []で囲まれた文字列を含むワイルドカードを展開する。

    Args:
        s(str): ファイル名文字列

    Returns:
        f(Path): glob展開されたファイル名

    """
    #
    # [] で囲まれた文字とそれ以外を別扱いにするひつようがありそう
    #
    lsqbpos = rsqbpos = -1
    l1 = l2 = l3 = ""
    if (lsqbpos := s.find("[")) != -1:
        l1 = s[0:lsqbpos]
    if (rsqbpos := s.rfind("]")) != -1:
        l3 = s[rsqbpos + 1 :]
    l2 = s[lsqbpos : rsqbpos + 1]
    if (rsqbpos - lsqbpos > 0) and (lsqbpos > 0):
        for f in glob(l1 + escape(l2) + l3):
            yield Path(f)
    else:
        for f in glob(s):
            yield Path(f)
なんとなく yield 使ってますが、そもそも for ループで glob() 使ってるからいらないんじゃね?的なギモンはあるし、力技でエレガントではない感じがジンジョーじゃない……。
処理としては、"[]" で囲まれた文字列とそれ以外を分離して3つに分けて、"[]" 文字列をescape します。"[]"は最大長で解釈させているので、

"吾輩ハ猫デアル [夏目漱石][上][大倉書店][1905].doc"

などという場合、"[夏目漱石][上][大倉書店][1905]" はすべてエスケープされるので、たぶんこの中の文字も検索対象になる…と思います。検索したいパターンに "*[大倉*]*" などとするときっと無理ですが。

CKLauのブザー音をなんとかしてみる。準備編

 ゴールデンウィークに届きまして、調子良く動いてくれてますCKLauの4ポートHDMI KVMですが、ポート切り替え時に鳴るブザーの音がけっこう耳障りです。

かん高いピーっという音と音量が結構うるさい。なのでこれをマイルドな感じにできないかと開けてみました。


ひっくり返すと赤丸の4箇所にネジがあります。これは2番の+が必要です。左のシールは製造年月表示なんですが、ピンセットで持ち上げたら破れました。でもどうせマークされていないので気にしません。

開けてみると中はシンプルです。


シルクが天地逆ですが、右端にあるのがブザーです。マグネチックブザーというタイプで、型番はTMB12A05。定格は5V/30mAで音圧が85dB以上、周波数2300±500Hz。駆動信号を与えるのではなくて、電流を流してやれば自己励振して発音するようです。周波数低めの音の代替製品があればいいのですが、村田製作所などの圧電ブザーは3.6kHzとか。

自作するならNE555で無安定マルチバイブレータ作って、出力でトランジスタを駆動してスピーカを鳴らすといい音がするかもしれません。

ちなみにこの回路では発振周波数は480Hzくらいになるので、いわゆるA音(A3)の 440Hz よりは高めですが、どうでしょうか。鳴ればいいだけなら圧電スピーカを使うほうが安上がりですね。

その他の方法はというと、ブザーのケースを壊せば音は小さくなるかなとか、穴塞げばいいかなとか。

ついでに KVM スイッチの本体である LSI ですが、写真中央部の四角い QFP チップで、GSCoolink GSV2007 とあります。検索してみると、HDMI 2.0 RX4/TX1 で HDCP非対応のようです。

また左上の USBコネクタ付近の正方形のチップはRealtek RTS5411 USB3.0ハブコントローラです。


裏面。

左上に4つ並んだ IC は中央2つが無印、両側が WCH CH551G で E8051コアの1チップマイコンのようです。また、右上の正方形の IC は WCH CH559L で、これも E8051コアのUSBホストコントローラ。

結構しっかり作られてる感じです。

現在のところ不満点は切り替え時の音だけですが、NE555のマルチバイブレータ自作キットが AliExpress で送料込300円くらいであるんですが、どうしようかなぁ。

Mercurial から Git へ引越し。

母艦(という言い方もあまりしなくなってきたみたいですが)を切り替えるのにあわせて、これまでのメイン PC でやってきた各種設定や Python スクリプトをコピーして使おうとしたのですが、環境が違うと手直しも必要になってきます。

これまではバージョン管理はメイン PC の、たとえば c:\Apps\bin にリポジトリを作って、そこにコミットしたりしてたのですが、新規の PC で手直ししたりするとその変更をメイン側に反映するのも結構手間です。さらに、その結果としてメイン側でちょこっと変えて、それを新規側に戻して、とかになってくると、やっぱりリポジトリはサーバにおいたほうがいいかな、と。ちょー今更ですが。

実はかなり前になりますが Bitbucket にアカウントを作って、そちらをリポジトリにしようかなとしていたことがあります。なんだかんだでちょっとお試しでいじって放置してました。ところが Bitbucket は2010年に Atlassian に買収され、2020年6月で Mercurial のすべてのサポートを終了し、Mercurial リポジトリを削除し、Git のみにするということになっていたようです。そしてアカウントもいつのまにか Atlassian に移行していました。

一方、実は GitHub にもアカウントを作っていまして、こちらのほうはちょっとだけ使ったのですがやっぱり放置していました。Mercurial のローカルリポジトリで当面の用は足りていたのと、Python をメインで使うんだから VCS も Python 系の Mercurial がいいし、むしろ Git のみのために Perl をインストールするのがなんとなく嫌だったりしたもので。

といいつつ、やっぱり Visual Studio は Git を組み込んでそのまま VCS が使えたり、VSCode も Git リポジトリを見に行ったり、兎にも角にも Git がないと始まらない世の中になってきていたりするので、そろそろ Mercurial じゃなきゃ嫌だ!みたいなことやってると面倒だったりするんだろうなということで、すぱっと Git に切り替えて、リポジトリも GitHub を利用させてもらえばいろいろスッキリするじゃん、と。

ということで、移行することにしたのですが、たぶんステップとしては2つ。

  1. ローカルの hg リポジトリを git リポジトリに変換
  2. ローカルの git リポジトリを GitHub にインポート
手順については、9.2 Gitとその他のシステムの連携 - Git へ移行する にまとめられているので、これに沿ってやっていきます。

ローカルの hg リポジトリを git リポジトリに変換

まずは懸案の /Apps/bin から取り掛かります。

hg-fast-export をクローンします。
$ git clone http://repo.or.cz/r/fast-export.git /Apps/fast-export
説明では '/tmp/fast-export' となっていますが、ここではわかりやすいところとして '/Apps/fast-export' を指定します。クローン後に中身を見ると、 hg-fast-export.sh と hg-fast-export.py があります。この hg-fast-export.py は hg-fast-export.sh から呼び出されるため、sh 系のシェルで実行する必要があります。そのため、此処から先は MSYS2 で作業を行います。

次に、コマンドラインから Mercurial を使えるようにします。TortoiseHG はインストールしてありますが、ここでは hg-fast-export.sh を実行するので、MSYS2 に Python3 をインストールし、さらに Mercurial もインストールして hg コマンドを使えるようにしておきます。
$ pacman -S python mercurial
そうしたら次に author の正規化を行います。具体的には、コミットしたユーザ名を "ユーザ名" <メールアドレス> の形式に修正します。
$ cd /Apps/bin
$ hg log | grep user: | sort | uniq | sed 's/user: *//' > ../authors
ここでは authors をみると全部同じ名前だったけれどメールアドレスが入っていなかったので(なんたってローカルリポジトリですから……)
bob=Bob Jones <bob@company.com>
の例にあるように '=' に続けて正しいユーザ名形式で記述しておきます。

次は Mercurial リポジトリから Git リポジトリへの変換の準備です。
$ cd /c/Apps
$ git init converted
$ cd converted
$ ../fast-export/hg-fast-export.sh -r ../bin -A ../authors
ここでもしかしたら以下のようなエラーが出るかもしれません。
/c/Apps/converted% ../fast-export/hg-fast-export.sh -r ../bin -A ../authors
Error: The option core.ignoreCase is set to true in the git
repository. This will produce empty changesets for renames that just
change the case of the file name.
Use --force to skip this check or change the option with
git config core.ignoreCase false
/c/Apps/converted% 

なぜか core.ignoreCase が true になってるよ、ということですので、最後の行にあるように
/c/Apps/converted% git config core.ignoreCase false

で設定を追加しておきます。

いよいよコンバートです。
/c/Apps/converted% ../fast-export/hg-fast-export.sh -r ../bin -A ../authors
Invalid file format in [../authors], line 1
Loaded 0 authors
master: Exporting full revision 1/144 with 32/0/0 added/changed/removed files
master: Exporting simple delta revision 2/144 with 0/1/0 added/changed/removed files
master: Exporting simple delta revision 3/144 with 0/1/0 added/changed/removed files
[...]
master: Exporting simple delta revision 143/144 with 0/2/0 added/changed/removed files
master: Exporting simple delta revision 144/144 with 0/2/0 added/changed/removed files
Issued 144 commands
fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects:       5000
Total objects:          490 (         0 duplicates                  )
      blobs  :          202 (         0 duplicates        160 deltas of        200 attempts)
      trees  :          144 (         0 duplicates        141 deltas of        141 attempts)
      commits:          144 (         0 duplicates          0 deltas of          0 attempts)
      tags   :            0 (         0 duplicates          0 deltas of          0 attempts)
Total branches:           1 (         1 loads     )
      marks:           1024 (       144 unique    )
      atoms:             45
Memory total:          2493 KiB
       pools:          2141 KiB
     objects:           351 KiB


---------------------------------------------------------------------
pack_report: getpagesize()            =      65536
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit      = 35184372088832
pack_report: pack_used_ctr            =          2
pack_report: pack_mmap_calls          =          1
pack_report: pack_open_windows        =          1 /          1
pack_report: pack_mapped              =     277981 /     277981
---------------------------------------------------------------------
なんか最初にエラーが出てます。どうもauthorsファイルがダメって言ってるようですが。このままだとユーザ名が正しくありません。

ということで別の方法を取ります。
'/c/Apps/bin/.hg/hgrc' を開き、
[extensions]
hgext.convert=

を追加します。そして、
/c/Apps/bin% hg convert --authors ../authors . ../bak
initializing destination ../bak repository
scanning source...
sorting...
converting...
143 initial import
[...]
writing author map file C:\Apps\bak\.hg\authormap

/c/Apps/bin% 

としてやれば、'../bak' にリポジトリを作り直してくれます。
'../convert' をいったん削除してから、再度コンバートしてみます。
/c/Apps% rm -rf converted
/c/Apps% git init converted
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint:   git branch -m <name>
Initialized empty Git repository in /c/Apps/converted/.git/
/c/Apps% cd converted
/c/Apps/converted% git config core.ignoreCase false
/c/Apps/converted% ../fast-export/hg-fast-export.sh -r ../bak
master: Exporting full revision 1/144 with 32/0/0 added/changed/removed files
master: Exporting simple delta revision 2/144 with 0/1/0 added/changed/removed files
master: Exporting simple delta revision 3/144 with 0/1/0 added/changed/removed files
master: Exporting simple delta revision 4/144 with 1/0/0 added/changed/removed files
master: Exporting simple delta revision 5/144 with 0/1/0 added/changed/removed files
[...]
master: Exporting simple delta revision 144/144 with 1/2/1 added/changed/removed files
Issued 144 commands
fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects:       5000
Total objects:          490 (         1 duplicates                  )
      blobs  :          202 (         1 duplicates        160 deltas of        200 attempts)
      trees  :          144 (         0 duplicates        141 deltas of        141 attempts)
      commits:          144 (         0 duplicates          0 deltas of          0 attempts)
      tags   :            0 (         0 duplicates          0 deltas of          0 attempts)
Total branches:           1 (         1 loads     )
      marks:           1024 (       144 unique    )
      atoms:             46
Memory total:          2493 KiB
       pools:          2141 KiB
     objects:           351 KiB
---------------------------------------------------------------------
pack_report: getpagesize()            =      65536
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit      = 35184372088832
pack_report: pack_used_ctr            =          2
pack_report: pack_mmap_calls          =          1
pack_report: pack_open_windows        =          1 /          1
pack_report: pack_mapped              =     278859 /     278859
---------------------------------------------------------------------
/c/Apps/converted% git shortlog -sn
   144  Chiyosuke Fujii
/c/Apps/converted%

以上でローカル側での作業は終わりで、あとはできあがったリポジトリを GitHub にプッシュするだけです。
$ git remote add origin git@my-git-server:myrepository.git
$ git push origin --all
嘘でした。ここから苦難の道が始まりました。


Hyper-VとWindowsハイパーバイザープラットフォームと仮想マシンプラットフォーム。

https://docs.microsoft.com/ja-jp/windows/wsl/installPC を Core-i7 12700K で組み直したので、Windows11 もクリーンインストールし、環境構築中です。

UNIX 系のコマンドラインツールには Windows が持っていないものがたくさんあって、コンソール(Windows Terminal)を多用する自分としてはインストールしておきたい。Cygwin とか MSYS2 もあるけど、できれば使い慣れた ArchLinux がいい。そうすると WSL2 を使ってインストールしてしまえばいいのかな、と思ってたんですが……。

WSL2 を利用するには、Microsoft 公式の Windows Subsystem for Linux に関するドキュメント を読みながら進めるのが良さそうなんですが、ここで「Windows の機能の有効化または無効化」で、サービスを有効にしておく必要があります。なのでその設定を開いてみたのですが…。


なんか混乱します。ハイライトされている「Linux 用 Windows サブシステム」を有効化したいんだけれど、そのためには、「Hyper-V」と「Windows ハイパーバイザープラットフォーム」と「仮想マシンプラットフォーム」のどれを使えばいいの?しかも「コンテナー」なんてものまであるし。

  • Hyper-V
    ハードウェア上でハイパーバイザが動作し、その上にOSが乗る Type 1 ハイパーバイザ。Intel VT や AMD-V などのハードウェア支援が必須。高速。Windows もハイパーバイザの上で動作する形になる。
  • Windows ハイパーバイザープラットフォーム
    Hyper-V が管理するハイパーバイザー上でのパーティションの作成と管理、構成を行うプラットフォーム。
  • 仮想マシンプラットフォーム
    よくわからないけど、複数の仮想マシンの作成と管理のためのプラットフォームなんでしょう。違いがよくわかりませんが。

WSL2 はどれが必要なのか、やっぱりわかりません。WSL のインストール を見てもその辺は書いていないので、まずはこのページにあることをやってみましょう。

管理者の PowerShell または Windows コマンド プロンプトに次のコマンドを入力し、コンピューターを再起動することによって、Linux 用 Windows サブシステム (WSL) を実行するために必要なすべてをインストールできるようになりました。

 

wsl --install

このコマンドを実行すると、必要なオプション コンポーネントの有効化、最新 Linux カーネルのダウンロード、WSL 2 の既定としての設定、および Linux ディストリビューションのインストールが実行されます " (既定では Ubuntu です。変更するには以下を参照してください) "。

だそうなので、上記の「Windows の機能」の有効無効は気にせずにやってみます。
PowerShell 7 を管理者モードで開き、



なんとなんと!仮想マシンプラットフォームをインストールしています。それでいいの? Hyper-V はどこいったの?
ともあれ、リブートしてみます。
再起動して「Windowsの機能」を開いてみると、「Linux 用 Windows サブシステム」と「仮想マシンプラットフォーム」にチェックが入っていました。
そしてPowerShellが自動的に開き、Ubuntuをインストールし始めました。


やっぱり Hyper-V はノーチェックです。それだけでいいのかしら。ほんとに?
と思ってタスクマネージャーを開いてみると、

なんか動いてます。
でもまあ、標準の方法らしいですから、それでいいことにしましょう。よしよし。

CKLauのUSB3.0+HDMIのKVMスイッチ。

これまでのメイン PC(Core-i9 9900K)と新しいメイン予定の PC(Core-i7 12700K)、それにテレワーク用の PC と、PC の切り替えが大変になってきたので、これまで使っていた 2ポートの KVM スイッチから、新しく 4ポートのKVMスイッチを検討することにしました。

現在使用しているのが、corega の CG-PC2KDLMCA という DVI 2入力1出力のものです。これは Amazon で2010年2月に購入したもので、なんと12年も使っていたことになります。

途中、ACアダプタのケーブル断線?で調子が悪くなり、同等仕様のアダプタ(5.3V)を購入しています。サンワサプライの P-VGA-AC4で、5.3V/2.4Aというもの。CG-PC2KDLMCA はもともと ATEN CS1782A のOEMで、ボタンデザインなどがちょっと変わっているだけのものです。サンワサプライからも ATEN OEM の KVM スイッチが出ているので、アダプタも互換なのでした。ただ、ATEN からファームウェアアップデートがあったときに適用できなかった事はありました。もともと DVI-D のデュアルリンクで 2,560×1,600@60Hz の能力があったので、2560x1440@60Hzの IO-Data GigaCrysta EX-LDGCQ271DB にも対応できていました。なにげにすごいやつです。しかも HDMI オーディオも通していたので、モニタ側スピーカ(音はヘロヘロですが)からも HDMI 接続だけで音が出ます。

今では PC のマザーボード出力から DVI がほとんどなくなり、モニタ側の入力も HDMI か DisplayPort のみになってきていますが、幸い信号的には DVI と HDMI はほとんど互換なので、DVI-HDMI ケーブルを用意することで使用できていました。


と、能書きが長くなりましたが CKLau です。Amazon で購入しました。


届いた箱を開けたらこんな感じ。ごちゃごちゃ詰まってます。ケーブルを巻いてあるポリが擦り切れたのでしょうか、ちょっと裂けていますが、問題はありませんでした。


ケーブルはこんな感じ。


アダプタの箱が潰れています。これも箱だけで中身はちゃんとしてました。


上の写真の細長いダンボールの中に本体があります。ちなみにアダプタは USB 出力のもので、5V/2.0Aでした。



表と裏。USB 3.0 の B タイプで、二段重ねのやつです。左端に電源スイッチとアダプタジャック、それに有線リモコン用の USB miniB のコネクタがあります。ちなみに箱から出した写真のリモコンの隣りにある青いスリーブのケーブルが miniB です。

日本だと製造銘板があって、消費電力が明示されているのですが、この製品は Made in China と CE、FCC、RoHS、それに製造年月日を表すシール(ただしマーキングしてないのでいつ製造されたのか不明)しかありませんでした。ついでに言えば、型番もないようです。型式番号がないのにどうやって輸出通してるのかしら。ちなみに、箱には "Model: CKLau-64HUA-3N" と書かれたシールが貼ってありました。それはともかく、あとでワットチェッカーで電力測ります。


ケーブルは HDMI と USB 3.0 が各 4 本。1本にまとめているのではなく、2本ずつ束ねて使うようです。しかも長さが違っています。

HDMIケーブルはコネクタの内側(ケーブル部分のみ)で 140cm、一方 USBケーブルは 170cmと、30cmも違います。これはびっくり。しかも、現在のデスク周りの配置だとメイン PC にぎりぎり届かない感じ。PC を動かしての作業などがあれば確実に届きません。これはちょっとまずいので、急遽ケーブル調達。Amazon Basicsの 1.8m USBケーブルとHDMI 2.0ケーブルを3本ずつ購入しました。なぜ3本ずつかというと、HDMIケーブルが2本セット(1,206円)と3本セット(1,207円)で1円しか違わなかったので、どうせなら3本にしてしまえという、あまり良く考えていない理由。


これをコードプロテクターという名前の、ワイヤ織管ケーブルスリーブで包んでいきます。これも Amazon で購入してたものです。

とりあえずメイン系のタワー型2セット分を新規購入のケーブルで、残り2セットを添付のケーブルで組んでセッティングしてみます。

セッティングが終わってワットチェッカーを見てみると、表示が01。消費電力1Wと出ています。このあたりの数値は精度的にちょっと微妙なところなのですが、PCサスペンド時には04(4W)とか出ているので、でたらめな数値ではなさそうです。

……とここまでやって、計測も終わったからとアダプタをワットチェッカーから抜いても、スイッチは動作しっぱなし。そりゃそうです、USBからも給電されてるのですから。

ともあれ、どうやらちゃんと動いてくれているようです。もともと4K対応ということですから、WQHDごときは屁の河童なのでしょう。

機材もないので、アイパターンのチェックとか CEC の波形確認とかはしていませんが、無事使えましたということで。

あとは、機能としてはホットキーで切り替えもできるし、有線リモコンでもできるということですが、キーボードの向こう、モニタの下に本体を設置しているので、ホットキーは無効、リモコンは使わないので箱の中にしまっておきます。

ともあれ、これで4ポートKVMが動きました。ユーザレポートも少ないようなので、購入を検討されている方の参考になれば。

SWDなら3線でいいとはいうものの。

 安価で優秀なデバッグプローブはないかしら、と探したら、 Raspberry Pi Debug Probe というのがあったんですが、これは3線がにゅるんと出てるだけです。 もちろんSWDなら3線を繋げばいいのではありますが、汎用的に考えるなら5x2のリボンケーブルコネクタが欲し...