PowerShellでVCP 0x60を書き換え、KVMホットキー切替はWindowsも外部ツール不要

こんにちは。エアコンをつけるか迷う、じっとりした日が増えてきましたね。机の裏に手を回してモニターのボタンを探す手間は、こういう季節ほど省きたくなります。

JAPANNEXTのKVMモニター（1組のキーボード・マウスを複数のPCで共有できるモニター）をLinux、Windows、Macで使い回すとき、入力切替はキー1つにできます。メーカーがホットキーの作り方を案内していなくても、切替の本体はモニターの「入力ソース」という設定項目、番号でいうとVCP 0x60 を書き換えるだけだからです。Linux→Windowsと、Windows→Linuxの2経路は、2026年7月13日に実機で動くのを確かめました。しかもWindows側はPowerShellの標準機能だけで済み、ControlMyMonitorのような外部ツールを入れずに作れます。

いっぽうで、Win→MacとMac→Linuxは仕組みのうえでは同じでも未検証です。それに、画面が切り替わることと、キーボードやマウスが付いてくることは別の話です。このあたりの線引きも含めて、手順と検証した範囲を順に書いていきます。

いつもは入力を切り替えるたびに、モニター背面のボタンやOSD（モニター本体の設定メニュー）を操作することになります。製品レビューは画面やKVM機能そのものを扱えても、メーカーがホットキー実装の手順まで案内しているとは限りません。この機種がどんなモニターかは 全エンジニアに送る、JAPANNEXT KVMという選択肢：4K 120HzとUSB-C 65Wが4万円台以下に降りてきた に書いたので、あわせて読むと今回の話とのつながりが分かりやすいと思います。

本記事で扱う JN-IPS27G120U2-HSPC6の製品ページ、他のKVM対応モニターを探すなら モニター一覧でKVM・USB-C・4Kを絞り込む も参照してください。

使うのはDDC/CI（PCからケーブル越しにモニターの設定を読み書きする仕組み）です。VCPコードはその設定項目ごとの番号で、0x60 が入力ソースの選択にあたります。LinuxからWindowsへはGNOMEのカスタムショートカットと ddcutil を組み合わせ、WindowsからLinuxへはPowerShellから dxva2.dll の SetVCPFeature を呼び出しました。

Windows側に外部CLIを入れないので、会社PCで追加のexe実行が禁止されている環境でも検討しやすい構成です。ただし、PowerShellそのものの実行ポリシーやAppLockerの制限を回避する方法ではありません。

ここで切り替えているのはOSではなく、モニターが表示する入力端子です。PC側のログイン状態やUSB機器の接続状態は別に残るため、画面切替後にキーボードやマウスがどのPCへ渡るかは、モニターのKVM実装とUSB配線にも左右されます。

始める前に確かめたいのは、次の3点です。どれか1つでも確認できない場合は、OSD操作を残したほうが安全です。

• モニターがDDC/CIの入力切替に対応していること
• 現在の入力値と、切替先の値を確認できること
• 画面だけでなく、USB KVMの復帰動作も自分の構成で確認できること

Linux側では、GNOME（Wayland）のカスタムショートカットにシェルスクリプトを割り当てます。実機では Ctrl+Alt+W に /home/YOUR_USER/Project/homelab/scripts/switch-monitor-to-windows.sh を登録し、次の内容でWindows接続側のUSB-C入力へ切り替えています。確認日は2026年7月13日です。

#!/usr/bin/env bash
set -euo pipefail

# VCP 0x60 is the monitor input source selector.
# JN-IPS27G120U2-HSPC6 on this setup reports Windows USB-C as 0x10.
WINDOWS_INPUT="${WINDOWS_INPUT:-0x10}"

if ! command -v ddcutil >/dev/null 2>&1; then
  echo "ddcutil is not installed. Install it with: sudo apt install ddcutil" >&2
  exit 127
fi

ddcutil setvcp 60 "$WINDOWS_INPUT"

60 はVCPコード 0x60、既定の 0x10 はこの実機でWindowsがつながっている入力の値です。VCP値は端子名そのものではなく、モニター内部の入力ソース番号なので、別の機種や配線では同じ値にならない可能性があります。

まず ddcutil detect でディスプレイが見えているかを確かめ、現在値を読める環境なら ddcutil getvcp 60 で記録してから書き込みます。getvcp が失敗する場合でも、OSDに出る入力状態と setvcp 実行後の画面を照らし合わせることはできます。ただ、OSDだけではVCPの数値そのものまでは分かりません。

ddcutil detect
ddcutil getvcp 60
ddcutil setvcp 60 0x10

ddcutil getvcp 60 の結果が、たとえば current value = 0x1A のように表示されれば、現在の入力値を数値として記録できます。setvcp の後にもう一度 getvcp 60 を実行し、値が変わったことと画面の入力表示が一致するかを見てください。

GNOMEでは「設定」から「キーボード」へ進み、「カスタムショートカット」を追加します。コマンド欄にはスクリプトの絶対パスを指定します。実行権限がない場合は、先に次を実行してください。

chmod +x /home/YOUR_USER/Project/homelab/scripts/switch-monitor-to-windows.sh

Waylandでは、X11時代のキーフックツール（キー入力を横取りして監視する常駐ソフト）をそのまま持ち込んでも安定しないことがあります。今回の構成はキー入力を横取りせず、GNOMEのカスタムショートカットから普通のプロセスとしてスクリプトを起動するだけです。おかげで、キー入力を見張る仕組みを別に常駐させずに済みました。

Windows側では外部CLIを使わず、PowerShellのP/Invoke（WindowsのDLLにある関数を直接呼ぶ仕組み）で user32.dll と dxva2.dll を呼び出します。EnumDisplayMonitors で表示モニターを列挙し、物理モニターのハンドルを取得してから SetVCPFeature でVCP 0x60 を書き込む流れです。

この実機ではLinux側の入力値が 0x1A、Windows側が 0x10 でした。値はモニターの機種や配線によって変わるので、下のスクリプトを別のモニターへそのまま移しても動くとは限りません。

# switch-monitor-to-linux.ps1
[CmdletBinding()]
param(
    [ValidateSet("Linux", "Windows")]
    [string]$Target = "Linux"
)

$inputValues = @{
    Linux   = [uint32]0x1A
    Windows = [uint32]0x10
}

if (-not ("KvmDdcNative" -as [type])) {
    Add-Type -TypeDefinition @'
using System;
using System.Runtime.InteropServices;

public static class KvmDdcNative
{
    [StructLayout(LayoutKind.Sequential)]
    private struct RECT
    {
        public int Left;
        public int Top;
        public int Right;
        public int Bottom;
    }

    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
    private struct PHYSICAL_MONITOR
    {
        public IntPtr hPhysicalMonitor;

        [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 128)]
        public string szPhysicalMonitorDescription;
    }

    private delegate bool MonitorEnumProc(
        IntPtr hMonitor,
        IntPtr hdcMonitor,
        ref RECT lprcMonitor,
        IntPtr dwData
    );

    [DllImport("user32.dll")]
    private static extern bool EnumDisplayMonitors(
        IntPtr hdc,
        IntPtr lprcClip,
        MonitorEnumProc lpfnEnum,
        IntPtr dwData
    );

    [DllImport("dxva2.dll", SetLastError = true)]
    private static extern bool GetNumberOfPhysicalMonitorsFromHMONITOR(
        IntPtr hMonitor,
        out uint pdwNumberOfPhysicalMonitors
    );

    [DllImport("dxva2.dll", SetLastError = true)]
    private static extern bool GetPhysicalMonitorsFromHMONITOR(
        IntPtr hMonitor,
        uint dwPhysicalMonitorArraySize,
        [Out] PHYSICAL_MONITOR[] pPhysicalMonitorArray
    );

    [DllImport("dxva2.dll", SetLastError = true)]
    private static extern bool SetVCPFeature(
        IntPtr hPhysicalMonitor,
        byte bVCPCode,
        uint dwNewValue
    );

    [DllImport("dxva2.dll", SetLastError = true)]
    private static extern bool DestroyPhysicalMonitor(
        IntPtr hPhysicalMonitor
    );

    public static bool SetInput(
        byte vcpCode,
        uint value,
        out int total,
        out int success
    )
    {
        total = 0;
        success = 0;

        MonitorEnumProc callback = delegate(
            IntPtr hMonitor,
            IntPtr hdcMonitor,
            ref RECT rect,
            IntPtr data
        )
        {
            uint count;

            if (!GetNumberOfPhysicalMonitorsFromHMONITOR(
                hMonitor, out count) || count == 0)
            {
                return true;
            }

            PHYSICAL_MONITOR[] monitors =
                new PHYSICAL_MONITOR[(int)count];

            if (!GetPhysicalMonitorsFromHMONITOR(
                hMonitor, count, monitors))
            {
                return true;
            }

            foreach (PHYSICAL_MONITOR monitor in monitors)
            {
                total++;

                if (SetVCPFeature(
                    monitor.hPhysicalMonitor,
                    vcpCode,
                    value))
                {
                    success++;
                }

                if (monitor.hPhysicalMonitor != IntPtr.Zero)
                {
                    DestroyPhysicalMonitor(
                        monitor.hPhysicalMonitor);
                }
            }

            return true;
        };

        return EnumDisplayMonitors(
            IntPtr.Zero,
            IntPtr.Zero,
            callback,
            IntPtr.Zero
        );
    }
}
'@
}

$total = 0
$success = 0
$value = $inputValues[$Target]

$result = [KvmDdcNative]::SetInput(
    0x60,
    $value,
    [ref]$total,
    [ref]$success
)

if (-not $result -or $total -eq 0 -or $success -eq 0) {
    throw "DDC/CIでモニター入力を切り替えられませんでした。DDC/CI設定を確認してください。"
}

Write-Host "モニター入力を $Target に切り替えました。"
Write-Host ("VCP 0x60 = 0x{0:X2} / 成功: {1}/{2}" -f $value, $success, $total)

EnumDisplayMonitors で見つかった物理モニターすべてに SetVCPFeature を試すので、対象を取りこぼしにくい作りです。実行はこうなります。

powershell.exe -ExecutionPolicy Bypass -File .\switch-monitor-to-linux.ps1

Windowsへ戻す場合は -Target Windows を渡します。

powershell.exe -ExecutionPolicy Bypass -File .\switch-monitor-to-linux.ps1 -Target Windows

-ExecutionPolicy Bypass は、このPowerShellプロセスに限って、未署名スクリプトの実行ブロックを一時的に無視するフラグです。AppLockerのようなアプリケーション実行制御は別の層で動いているので、このフラグを付けてもAppLockerのルール自体を回避できるわけではありません。会社PCでは、PowerShellスクリプトの実行そのものが許可されているかを、別途管理者に確かめる必要があります。

ホットキーは、このスクリプトを呼び出すショートカットファイル（.lnk）を作り、そのプロパティの「ショートカットキー」欄で割り当てました。タスクスケジューラや常駐型のキー割り当てツールは使っていません。

⚠️ ただし、このスクリプトは見つかった物理モニターすべてにVCP 0x60 を書き込みます。1台構成のこの実機では意図通りに動きますが、複数台をつないでいると、意図しないモニターまで切り替わる可能性があります。

複数台を同時に使っている環境では、GetPhysicalMonitorsFromHMONITOR が返す物理モニターの説明文字列（szPhysicalMonitorDescription）で、書き込む相手を絞り込む拡張が考えられます。

# ⚠️ 未検証の拡張案。この実機は1台構成のため動作確認していません
param(
    [ValidateSet("Linux", "Windows")]
    [string]$Target = "Linux",
    [string]$MonitorDescription = ""   # 空文字列なら全物理モニターが対象
)

# SetInput の第3引数を targetDescription として受け取り、
# szPhysicalMonitorDescription が部分一致した物理モニターだけに
# SetVCPFeature を実行するよう foreach 内へ条件分岐を追加する。

ただ、説明文字列は機種や接続構成によって空になったり、複数台で同じ文字列になったりすることがあります。同じ文字列のモニターが複数あると、この方法だけでは一意に見分けられず、EDID（モニターが自分の情報をPCへ伝えるデータ）や物理モニターのハンドルを使った、より厳密な識別が必要になります。この拡張を使うなら、まず1台構成で SetVCPFeature の呼び出し回数と対象が期待通りかを確かめてから、複数台へ広げてください。

上のPowerShell例は、決めた値を SetVCPFeature で書き込むだけで、Windows側で現在のVCP値を読み出しているわけではありません。OSDや説明書との照合だけでは、0x10 や 0x1A という数値が正しいかまでは確定できないんですよね。数値を確かめたい場合は GetVCPFeatureAndVCPFeatureReply を使います。

MicrosoftのAPIには、物理モニターのハンドルとVCPコードを渡すと、現在値と最大値を返してくれる GetVCPFeatureAndVCPFeatureReply が用意されています。SetVCPFeature と同じく、先に GetPhysicalMonitorsFromHMONITOR で取得した各物理モニターのハンドルに対して呼び出します。

P/Invoke宣言は次の形です。

[DllImport("dxva2.dll", SetLastError = true)]
private static extern bool GetVCPFeatureAndVCPFeatureReply(
    IntPtr hPhysicalMonitor,
    byte bVCPCode,
    out uint pvct,
    out uint pdwCurrentValue,
    out uint pdwMaximumValue
);

たとえば SetVCPFeature の直前に次のような読み出しを入れれば、書き込む前の値を記録できます。

uint valueType;
uint currentValue;
uint maximumValue;

bool readOk = GetVCPFeatureAndVCPFeatureReply(
    monitor.hPhysicalMonitor,
    0x60,
    out valueType,
    out currentValue,
    out maximumValue
);

readOk が true なら、currentValue がその物理モニターから読み出したVCP 0x60 の現在値です。実装するときは、対象の説明文字列、読み出し結果、書き込み後の結果を一緒に表示しておくと、複数台環境で別のモニターを操作していないかが分かりやすくなります。

モニターや接続経路がDDC/CIを通さない場合、GetVCPFeatureAndVCPFeatureReply も SetVCPFeature も失敗します。USB-CドックやKVMがDDC/CIを遮断する構成も同じです。また、VCP 0x60 を実装していても、現在値の読み出しには対応しない機種はあり得ます。その場合、Windows側では数値をAPIで確かめられないので、OSDの入力表示と切替前後の画面による動作確認にとどまります。読み出せない環境で、説明書の値だけを根拠に「検証済み」と扱わないでください。

switch-monitor-to-linux.ps1 の構造で宛先を増やすなら、$inputValues と ValidateSet に候補を足します。SetInput はVCPコードと値を渡すだけの汎用処理なので、宛先ごとにスクリプトを書き直す必要はありません。

[ValidateSet("Linux", "Windows", "WindowsB")]
[string]$Target = "Linux"

$inputValues = @{
    Linux    = [uint32]0x1A
    Windows  = [uint32]0x10
    WindowsB = [uint32]0x11   # 例。2台目Windows機の入力値は環境ごとに要確認
}

0x11 はあくまで例示の値です。この実機には2台目のWindows機をつないでいないので、実際の入力値は確認していません。KVMモニターの入力ポート一覧（OSDメニューや取扱説明書）と、Linuxの ddcutil getvcp 60、Windowsの GetVCPFeatureAndVCPFeatureReply の結果を突き合わせてから $inputValues に追加してください。

もう1つ気をつけたいのは、画面だけ先に切り替わって、USB入力が前のPCに残るケースです。VCPの書き込みが成功しても、キーボード・マウスの操作先が想定通りに動くかは別に確かめる必要があります。

⚠️ Win→Macは未検証です。

Windows側からMac接続の入力へ切り替える処理は、Mac専用のAPIを呼ぶ必要はありません。$inputValues にMac用のエントリを足せば、同じ SetInput 呼び出しに乗るはずです。

$inputValues = @{
    Linux   = [uint32]0x1A
    Windows = [uint32]0x10
    Mac     = [uint32]0x0F   # 例示の値。実機のMac入力では未確認
}

ただし、この値と実際の切替結果はこの環境で確かめていません。DDC/CIのVCP実装はモニター側の機能なので、OSの種類だけで可否が決まるわけではないのですが、実機で試すまでは「動作確認済み」とは書けません。

⚠️ Mac→Linuxも未検証です。

Mac側からDDC/CIを送るには、Windowsの dxva2.dll に相当するOS標準のAPIがないため、別のツールが必要です。候補になり得るのは、Homebrew版の ddcutil（brew install ddcutil。Apple Siliconでは追加設定が必要な場合があります）や、Apple Silicon向けの軽量CLIである m1ddc です。どちらもこの環境では実機で試していないので、具体的なコマンド例は控えます。

未検証の経路を足すときは、まずモニターの入力値を1つずつ確かめます。Windows側なら GetVCPFeatureAndVCPFeatureReply、Linux側なら ddcutil getvcp 60、Mac側なら採用するDDC/CI実装というように、OSごとに「VCP 0x60 を読み書きできるか」を分けて検証します。OSの組み合わせを先に増やしてしまうと、画面切替の失敗とUSB KVMの復帰失敗が、同じ問題に見えてしまうからです。

宛先が増えても、処理そのものは SetInput(0x60, 値) から変わりません。宛先ごとにファイルを分けるより、$inputValues へ宛先を足していくほうが、どこまで検証済みかを把握しやすくなります。いまの状況はこうです。

本文やスクリプトの中で、検証済みの値と未検証の値を混ぜないことも大事です。未検証のエントリにはコメントで「未検証」と残し、確かめたら確認日と実際のVCP値へ書き換えます。

複数台の環境では、入力値だけでなく対象のモニターも記録しておいてください。VCP 0x10 が正しくても、別の物理モニターへ書き込めば、結果として意図しない画面が切り替わります。

Linux側では、画面ブランク（無操作で画面が消える状態）から戻ったあと、KVM経由のキーボードとマウスが反応しなくなることがありました。これはVCP 0x60 の切替とは別の問題で、PCI接続のUSB xHCIコントローラー（PC側のUSBの制御部品）が省電力状態からうまく戻れないものとして切り分けました。

実機では、対象PCIデバイスの電源管理設定を auto から on へ変えています。現在値は次のコマンドで確認できます。

cat /sys/bus/pci/devices/<PCI ID>/power/control

ここで on と表示されれば、そのデバイスは省電力で止まらない設定になっています。<PCI ID> は環境ごとに違うので、記事の値をそのままコピーしないでください。まず lspci でUSB controllerやxHCIに当たるデバイスを探し、自分の環境のPCI IDに置き換えます。

この対策を入れても、USBの復帰問題がすべて解決するとは限りません。電源管理、KVM内部のUSB切替、カーネル、接続機器の相性が絡むため、画面切替のテストとは別に、ブランクから戻った後の入力テストもしておくと安心です。

この方法が向いているのは、KVMモニターのOSD操作を減らしたい人で、なおかつ接続先のVCP値と対象モニターを自分で確かめられる人です。特に会社PCへ外部ツールを入れられない場合、Windows標準のPowerShellとショートカットファイルだけで切替の経路を作れるのは実用的だと思います。

逆に、1台のPCしか使わない人や、モニターのボタン操作が数秒で済む環境なら、スクリプトを保守する手間のほうが大きくなります。複数台モニターを使っていて対象を見分けられない場合も、すべてのモニターへ書き込む方式は避けるべきです。

⚠️ Win→MacとMac→Linuxは未検証なので、業務の主経路として採用する前に、入力値、画面復帰、USB入力の3点を自分の機材で確かめてください。

メーカーのホットキー案内がなくても、VCP 0x60 へ入力値を書き込むという共通の原理は使えます。ただ、実際に安定するかどうかは、OSのショートカットの仕組み、DDC/CIへの対応、対象モニターの識別、USB KVMの復帰動作まで含めて決まります。

この記事は、経路ごとに検証の範囲を分けて書いています。

Linux→Windows（GNOMEカスタムショートカット + switch-monitor-to-windows.sh + ddcutil setvcp 60 0x10）は、実機で日常的に使っている構成をそのまま載せました。確認日は2026年7月13日です。Linux側の画面ブランク復帰後のUSB停止と、その対策（xHCIコントローラーの power/control 変更）も、実機で起きた不具合と実際に行った対処です。

Windows→Linux（PowerShellの KvmDdcNative::SetInput によるVCP書き込み）も、実際に運用しているスクリプトをそのまま載せています。ホットキー登録に「ショートカットのプロパティ」だけを使い、外部exeを入れていない点も実機の構成どおりです。

Windows側の現在値の読み出し（GetVCPFeatureAndVCPFeatureReply）と、複数台モニター向けの対象限定の拡張（$MonitorDescription）は、この記事のために足した応用例です。元の運用スクリプトは1台構成・書き込み専用なので、どちらもこの実機では動作確認していません。

Win→Winは、確認済みのWindows側の処理を土台に、値を足せば同じ型で広げられることをコードで示しただけで、2台目のWindows機をつないだ検証はしていません。Win→MacとMac→Linuxも、DDC/CIの仕組み上は動く可能性がある、という整理にとどまります。

• VESA Standards — MCCSを含むディスプレイ関連標準の一次情報
• ddcutil: Set VCP Feature — setvcp の仕様と使用方法
• ddcutil: Get VCP Feature — getvcp による現在値の読み出し
• ddcutil: VCP Feature Codes — MCCS/VCPコードの解説
• Microsoft: SetVCPFeature function — WindowsのVCP書き込みAPI
• Microsoft: GetVCPFeatureAndVCPFeatureReply function — WindowsのVCP現在値読み出しAPI
• Microsoft: EnumDisplayMonitors function — 表示モニター列挙API
• Microsoft: GetPhysicalMonitorsFromHMONITOR function — DDC/CI操作用の物理モニター取得API
• GNOME Help: Set keyboard shortcuts — GNOMEのカスタムショートカット設定

いきなりホットキーを組む前に、ddcutil detect でモニターがDDC/CI経由で見えているかを確かめ、ddcutil getvcp 60 で今の入力値を読みます。値が読めたら ddcutil setvcp 60 0x10 のように書き込み、画面の入力が切り替わるかを見てください。

ddcutil detect
ddcutil getvcp 60
ddcutil setvcp 60 0x10

書き込んだ後にもう一度 ddcutil getvcp 60 を実行し、現在値が狙った値になったかも確かめます。値はこの実機のもの（Linux側 0x1A、Windows側 0x10）なので、機種や接続ポートが変われば別の値になります。Windows側は、GetVCPFeatureAndVCPFeatureReply を組み込んだ読み出し処理を使わない限り、現在値をAPIで確かめているわけではありません。OSD表示と画面の切替だけで検証した場合は、その範囲だと分かるように記録しておいてください。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！