2026년 9월 8일 화요일

PiKVM에 맥 미니 화면이 안 뜰 때 — EDID 설정 메모

예전 EDID 설정 메모

PiKVM 설정 메모를 다시 열어 보니 첫 줄에 이렇게 적혀 있었다.

기본설치 끝내고 화면이 안나오는 경우 드라이버를 바꾸어주어야함

그 아래에는 드라이버 설치 명령 대신 kvmd-edidconf가 남아 있었다. 공식 문서와 대조해 보니 당시 메모에 적은 작업은 PiKVM의 EDID 설정 변경으로 설명하는 편이 정확했다.[1]

이 글은 그 짧은 기록을 다시 정리한 설정 해설이다. 해당 명령으로 화면을 나오게 했으나 모든 모델에서 동일하다는 보장은 없다.

EDID는 화면을 보내기 전에 읽는 정보다

EDID는 디스플레이의 식별 정보와 지원하는 영상 모드 등을 컴퓨터에 알려준다. PiKVM에서는 HDMI 캡처 장치가 이 정보를 제공한다.[1][2]

맥 미니에서 PiKVM으로는 HDMI 영상이 들어가고 EDID 정보는 반대로 맥 미니가 어떤 영상 모드를 보낼지 결정하는 데 쓰인다.[1]

맥 미니영상 출력
영상 →
← EDID
영상 ↓ · EDID ↑
PiKVMHDMI 캡처
영상 →영상 ↓
브라우저Web UI
영상과 EDID의 방향을 구분한 개념도. 실제 배선·네트워크 구성도는 아니다.

그래서 화면이 없다고 곧바로 명령을 실행할 일은 아니다. 이 글에서는 전원·HDMI 케이블·입력 포트·브라우저 상태를 먼저 점검하고 그다음 EDID를 확인하는 순서를 권한다. PiKVM 공식 문서도 기본 EDID는 대체로 충분히 유연하므로 보통 변경할 필요가 없다고 설명한다.[1]

메모에 섞여 있던 두 프리셋

원문에는 rw, 다음 명령, reboot가 순서대로 적혀 있었다.

kvmd-edidconf --import-preset=v3.1080p-by-default

‘맥미니에 설치하기’ 항목에는 아래 두 줄도 남아 있었다. 과거 메모를 옮긴 것이며, 두 줄을 차례로 실행하라는 뜻은 아니다.

kvmd-edidconf --import-preset=v3.1080p-by-default --set-audio=yes
kvmd-edidconf --import-preset=v4plus --set-audio=yes --apply

v3.1080p-by-default는 V3의 기본 영상 모드를 1080p로 선택하는 프리셋이다. V3는 1080p에서 50Hz 한계가 있어 기본 모드는 720p로 설정된다.[1]

반면 v4plus는 V4 Plus의 기본 EDID 프리셋이다. V4 Mini에는 별도의 v4mini 프리셋이 있다.[1]

메모에 나온 모니터 이름만으로 실제 기기 모델을 확정하지는 않았다. PiKVM의 HDMI 식별 정보는 변경할 수 있기 때문이다.[2] 본체·구매 내역 등으로 모델부터 확인하고, DIY 장치라면 캡처 방식과 해당 장치의 문서를 따로 확인하는 편이 낫다.

바꾸기 전에 현재 설정부터 확인한다

아래 명령은 맥 미니가 아니라 PiKVM의 터미널에서 현재 EDID 정보를 확인하는 용도다. 옵션 없는 실행 예시는 공식 문서에도 나온다.[1]

kvmd-edidconf

설정을 바꿀 계획이라면 현재 EDID 파일인 /etc/kvmd/tc358743-edid.hex를 먼저 백업한다. PiKVM은 부팅할 때 이 파일을 캡처 칩에 적용한다.[1]

백업뿐 아니라 문제가 생겼을 때 PiKVM에 다시 접속하거나 현장에서 복구할 방법도 준비하는 것을 권한다. 아래 예시는 모델을 확인하고 변경이 필요하다고 판단한 경우에만 참고한다.

V3에서 1080p를 기본 모드로 선택할 때

공식 문서의 V3 예시다. DIY V0–V2에 이 명령을 그대로 적용하지 말고 해당 모델의 프리셋을 확인한다.[1]

rw
kvmd-edidconf --import-preset=v3.1080p-by-default --apply
ro

V4 Plus의 기본 EDID로 되돌릴 때

이 예시는 V4 Plus용이다. V3나 V4 Mini에 공통으로 쓰는 명령이 아니다.[1]

rw
kvmd-edidconf --import-preset=v4plus --apply
ro

공식 절차는 rw로 쓰기를 허용하고 EDID를 변경한 뒤 ro로 읽기 전용 상태를 복원한다. --apply는 PiKVM을 재부팅하지 않고 변경한 EDID를 적용하는 옵션이다.[1]

적용 후에는 kvmd-edidconf로 설정을 다시 확인하고 브라우저의 실제 영상도 확인한다. 호스트가 새 정보를 반영하려면 대상 컴퓨터를 재부팅해야 하는 경우도 있다.[1] 설정값 변경과 실제 화면 복구는 별도로 확인할 일이다.

오디오 옵션은 따로 읽어야 한다

원문에 남아 있는 --set-audio=yes는 EDID에 오디오 지원 정보를 켜는 옵션이다. 이 옵션을 검은 화면의 공통 해결책으로 받아들이지는 말자.[3]

공식 문서에 따르면 V4 Mini/Plus는 기본적으로 오디오가 활성화돼 있다. V3에서 오디오를 켜려면 HAT의 오디오 점퍼와 /boot/config.txt의 dtoverlay=tc358743-audio 설정 등도 확인해야 한다.[3]

PiKVM 오디오는 Web UI의 WebRTC 모드에서 지원되며, DIY 장치와 VNC에서는 지원되지 않는다. 맥의 오디오 출력이 HDMI로 선택됐는지도 확인한다.[3]

따라서 화면 확인과 오디오 확인은 따로 기록하는 편이 좋다. Audio: yes라는 설정 표시만으로 브라우저에서 실제 소리가 들리는지까지 확인할 수는 없다.

다음에 같은 문제를 만나면

이번 메모에서 건질 수 있는 요점은 ‘드라이버를 바꾼다’는 표현보다 무엇을 바꾸는 명령인지 구분해서 남기는 것이다.

전원과 연결을 확인하고 장비 모델과 현재 EDID를 읽는다. 변경이 필요하면 백업과 복구 수단부터 준비한다. 모델에 맞는 설정을 적용한 뒤에는 화면과 오디오를 각각 확인한다.

다음 기록에는 장비 모델, OS 버전, 적용한 명령, 적용 전후 화면을 함께 남겨 두려고 한다. 그래야 나중에 같은 문제를 만났을 때 복사할 명령뿐 아니라, 그 명령을 선택한 이유까지 찾을 수 있다.

공식 출처

  1. PiKVM Handbook — Tuning HDMI EDID
  2. PiKVM Handbook — PiKVM identification
  3. PiKVM Handbook — Audio / Microphone

2026년 9월 7일 월요일

Apple Code Signing, Explained with Three Cards

APPLE SIGNING · 01 / 12

Stop memorizing certificates, App IDs, and provisioning profiles as separate objects. Connect who may sign what, and where it may run, and Xcode's signing errors begin to make sense.

Code signing matches a trusted identity to an execution policy.

WHO
Signing certificate
Is this signer trusted?
WHAT
App ID
Which bundle and capabilities?
WHERE · WHEN · HOW
Scope and rights
Devices, dates, and entitlements

↓

AUTHORIZATION
Provisioning Profile
Apple's signed authorization that binds these conditions

Why signing configuration feels confusing

A signing error rarely points to a single cause. The certificate may have expired, the bundle identifier may not match the profile, or the app may request an entitlement that the profile does not authorize.

The confusion starts when we memorize certificates and provisioning profiles as unrelated files. Apple's technical note frames a provisioning profile as an authorization mechanism for running third-party code—not merely a file you download for development.[1]

The one sentence to remember
A certificate proves who signed the code. A provisioning profile proves that this signer is authorized to run this app under these conditions.

Separate the three core pieces

CERTIFICATE

The signer's identity. An Apple Development certificate signs builds that run on development devices. An Apple Distribution certificate is used for distribution workflows, including submission to App Store Connect.[2] The actual signing operation also needs the matching private key stored in the Mac's Keychain.

APP ID

The app's identity and capability scope. A practical mental model is Team ID + Bundle ID. If the target's Bundle Identifier does not match the App ID authorized by the profile, Xcode cannot use that profile.

PROFILE

A bundle of execution conditions. It connects signing certificates, an App ID, allowed devices, an expiration date, and entitlement limits. You create it through the Apple Developer website or Xcode, and Apple signs it cryptographically.[1]

The five questions a profile answers

  1. Who? Was the app signed by an allowed development certificate?
  2. What? Does the application's identifier match the App ID?
  3. Where? For development or Ad Hoc, is this device registered?
  4. When? Is the profile still valid?
  5. How? Are the requested entitlements allowed?

Apple's TN3125 explains the structure in terms of who, what, where, when, and how.[1] This frame turns a vague signing failure into a much smaller search space.

MYTH
“The provisioning profile contains my private key.”
CORRECTION
The profile contains information about allowed certificates. The private key remains part of the signing identity in Keychain.

App Store distribution has one apparent exception. After validating the submitted signature and profile, the App Store re-signs the app. The final app downloaded by a customer therefore has no embedded provisioning profile.[1]

What Xcode does when automatic signing is on

After you select a Team, provide a unique Bundle ID, and enable Automatically manage signing, Xcode can manage device registration and development provisioning profiles for you.[3]

  1. Select a Team — choose the developer account and organization scope.
  2. Check the Bundle ID — provide the identifier connected to the App ID.
  3. Manage assets — let Xcode manage development devices and profiles.
  4. Apply at build time — select a compatible identity and profile.

Automatic signing does not remove the model. It asks Xcode to satisfy the same model on your behalf. When it fails, you still return to the Team, Bundle ID, certificate, device, and entitlements.

Inspect the state on your own Mac

1. List usable code-signing identities

security find-identity -v -p codesigning

If the list is empty—or the expected team's identity is missing—check the certificate and private-key pair before recreating profiles.

2. Inspect the signature applied to the app

codesign -dvvv --entitlements :- "/path/to/MyApp.app"

Inspect the Authority, TeamIdentifier, Identifier, and entitlement output. Reading the built app's actual signature is usually faster than arguing with an error message from memory.

3. Decode the embedded profile for inspection

security cms -D \
  -i "/path/to/MyApp.app/embedded.mobileprovision" \
  -o /tmp/profile.plist
plutil -p /tmp/profile.plist

Use this only for diagnosis. Apple warns that the exact internal format of a provisioning profile is not a documented contract and may change. Production logic should not depend on its private structure.[1]

Use this troubleshooting order

  1. Team — Did you select the correct personal or organization team?
  2. Bundle ID — Do the target, App ID, and profile identify the same app?
  3. Signing identity — Is the matching private key in Keychain, not just the certificate?
  4. Purpose — Are you mixing Development and Distribution assets?
  5. Device — For development or Ad Hoc distribution, is the device registered?
  6. Expiration — Are both the certificate and profile still valid?
  7. Entitlements — Does the App ID and profile authorize every capability the app requests?

What to take away

  • A certificate represents the signer's identity.
  • An App ID represents the app and its capability scope.
  • A provisioning profile binds who may run what, where, when, and with which entitlements.
  • Automatic signing preserves this relationship; Xcode merely manages it for you.

Official sources

  1. Apple TN3125: Inside Code Signing — Provisioning Profiles
  2. Apple Developer Account Help — Certificates overview
  3. Apple Developer Documentation — Running your app on simulated or physical devices

This article reorganizes the concepts and diagnostic workflow for readers rather than reproducing Apple's wording. Apple, Xcode, and App Store are trademarks of Apple Inc.

PiKVM에 맥 미니 화면이 안 뜰 때 — EDID 설정 메모

예전 EDID 설정 메모 PiKVM 설정 메모를 다시 열어 보니 첫 줄에 이렇게 적혀 있었다. 기본설치 끝내고 화면이 안나오는 경우 드라이버를 바꾸어주어야함 그 아래에는 드라이버 설치 명령 대신 kvmd-edidconf 가 남아 있었다....