▲

Phoenix - Zig로 처음부터 새로 작성된 최신 X 서버

 (git.dec05eba.com)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • Phoenix는 기존 Xorg를 포크하지 않고 Zig 언어로 처음부터 작성된 새로운 X 서버로, 현대적 대안을 목표로 함
  • 현재는 GLX, EGL, Vulkan 그래픽을 사용하는 간단한 애플리케이션을 기존 X 서버 내에서 중첩 실행할 수 있으며, 독립 실행은 아직 지원되지 않음
  • 단순성을 위해 최근 20년 내 작성된 애플리케이션과 15년 내 하드웨어만 지원하며, 서버 드라이버 인터페이스 없이 동작
  • 보안성을 강화해 프로토콜 메시지를 자동 파싱하고, 애플리케이션 간 접근은 권한 요청 기반 격리 구조로 제한
  • HDR, VRR, 다중 모니터, 내장 컴포지터 등 현대 기술을 지원하며, Wayland 호환성과 X11 프로토콜 확장도 계획

Phoenix 개요

  • Phoenix는 Xorg 서버를 대체할 현대적 X 서버로, Zig 언어로 완전 새로 작성된 구현체
    • Xorg의 포크가 아니며, 보다 단순하고 안전한 구조를 지향
  • 현재는 완전한 사용 단계가 아니며, 기존 X 서버 내 중첩 실행(nested mode) 만 지원
    • GLX, EGL, Vulkan 기반의 하드웨어 가속 렌더링을 수행 가능

목표

단순성

  • Xorg보다 단순한 서버로, X11 프로토콜의 일부만 지원
    • 최근 20년 내 작성된 애플리케이션에 필요한 기능만 포함
  • Linux DRM과 Mesa GBM을 지원하는 최근 15년 내 하드웨어만 대상
  • Xorg처럼 별도의 서버 드라이버 인터페이스는 사용하지 않음
    • Wayland 컴포지터와 유사한 구조

보안성

  • 프로토콜 메시지 자동 파싱으로 안전성 확보
    • Zig의 ReleaseSafe 빌드 옵션을 통해 배열 인덱스 초과 등 불법 동작 자동 감지
  • 기본적으로 애플리케이션 간 격리 실행
    • 다른 앱과의 상호작용은 GUI 권한 요청 또는 사전 권한 부여를 통해서만 가능
    • 예: 화면 녹화 앱은 지정된 창만 녹화 가능
  • 접근 제한 시 클라이언트는 오류 대신 더미 데이터를 수신
  • 글로벌 단축키는 수정키(ctrl, shift 등) 포함 시 동작
    • 수정키 없이 전역 단축키 사용 시 명시적 권한 필요
  • 옵션을 통해 Xorg와 동일한 동작 방식으로 전환 가능

현대 기술 지원

  • 다중 모니터, 서로 다른 주사율, VRR, HDR 등 최신 디스플레이 기술 지원
  • 단일 프레임버퍼 대신 각 디스플레이별 독립 처리

그래픽 처리 개선

  • 기본적으로 티어링 없는 렌더링과 내장 컴포지터 제공
    • 외부 컴포지터(picom 등) 실행 시 자동 비활성화
    • 전체화면 앱이 vsync를 끄면 해당 앱에 맞춰 조정
  • vsync 및 컴포지터 지연 시간 감소 목표

새로운 표준

  • 모니터별 DPI 속성(randr property) 정의 및 문서화
    • 애플리케이션이 모니터별 DPI에 맞춰 콘텐츠 스케일링 가능

X11 프로토콜 확장

  • HDR 등 새로운 기능 필요 시 X11 프로토콜 확장 예정

Wayland 호환성

  • 일부 앱이 Wayland 전용일 가능성을 고려
    • Phoenix가 Wayland를 직접 지원하거나, Wayland–X11 브리지(예: 12to11) 를 통해 실행 가능

중첩 디스플레이 서버

  • X11 또는 Wayland 내에서 하드웨어 가속 중첩 실행 가능
    • Phoenix 디버깅 및 윈도우 매니저·컴포지터 테스트에 유용
    • Wayland 환경에서 Xwayland 대안 서버로 활용 가능

비목표 (Non-goals)

  • Xorg 서버 완전 대체는 목표 아님
    • Xorg는 더 많은 X11 기능과 구형 하드웨어 지원 유지
  • 여러 X11 스크린은 지원하지 않음 (다중 모니터만 지원)
  • GrabServer 호출은 무효
  • 엔디안 스왑 클라이언트/서버는 필요 시 재검토
  • 간접 GLX(원격 렌더링) 지원 없음
    • 복잡성이 높으며, 원격 스트리밍이 더 효율적
    • 필요 시 GLX 프록시를 통한 원격 렌더링 가능

X11 프로토콜과의 차이

  • 폰트 관련 기능 등 X11 핵심 프로토콜 일부 미구현
  • 문자열 인코딩은 기본적으로 UTF-8 사용
    • 단, 프로토콜에서 ISO Latin-1로 명시된 경우 예외

설치 및 빌드

  • 설치 명령: 
    zig build -Doptimize=ReleaseSafe
sudo zig build install -p /usr/local -Doptimize=ReleaseSafe
  • 제거는 수동으로 /usr/local/bin/phoenix 삭제 필요
  • 개발용 빌드: 
    zig build
    • 결과 바이너리: ./zig-out/bin/phoenix
    • 실행과 빌드를 동시에 수행 가능: zig build run

X11 프로토콜 문서 생성

  • 명령: zig build -Dgenerate-docs=true
    • 결과: ./zig-out/protocol/ 내 .txt 파일 생성
    • 공식 문서 스타일의 자동 생성 문서이며, 현재 진행 중 기능

의존성

  • Zig 0.14.1
  • x11 (xcb) — X11 중첩 모드용 (-Dbackends=x11)
  • wayland (wayland-client, wayland-egl) — Wayland 중첩 모드용 (-Dbackends=wayland, 현재 미지원)
  • drm (libdrm, gbm) — 독립 실행용 (-Dbackends=drm, 현재 미지원)
  • OpenGL (libglvnd) — gl 및 egl 제공
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • X 서버를 Wayland 스타일로 재구성하려는 접근이 흥미로움
    디스플레이 서버와 컴포지터를 기본적으로 통합하고, 앱을 기본적으로 격리하며, GLX 원격 기능을 제거하고, 구식 프로토콜을 과감히 버린 점이 인상적임
    누가 이걸 필요로 할지는 모르겠지만, 선택 자체는 꽤 합리적으로 보임

    • X11을 꼭 써야 하는 사람들에게는 XLibre보다 더 나은 선택처럼 보임
    • 직접 써보진 않았지만, 기존 기능을 제거했다면 결국 Wayland와 비슷한 상황일 것 같음
      그렇다면 차이가 뭔지 모르겠음. 아마 분석이 불완전했을 수도 있음
    • 만약 이게 더 일찍 나왔다면 많은 사람들이 Wayland 대신 이걸 선호했을 것 같음
      게다가 Wayland 앱도 실행된다면 실제로 더 많은 사용자가 선택할 수도 있음

  • Phoenix라는 이름이 너무 많이 쓰이고 있음
    Elixir 프레임워크에도 Phoenix가 있고, 다른 프로젝트에서도 여러 번 본 기억이 있음
    ‘Apollo’처럼 흔한 이름이라, 새 프로젝트를 만들 땐 검색부터 해야 한다고 생각함

    • Elixir 생태계의 Phoenix는 오히려 덜 혼란스러운 편임
      그쪽은 bandit, cowboy, thousand island, ranch, mint, finch 같은 독특한 이름들이 많음
      ExThing, ThingEx, Thingx 같은 이름 중복도 흔해서 뭐가 표준인지 헷갈림
    • 예전부터 ‘재에서 부활하는 프로젝트’라는 상징으로 Phoenix라는 이름을 많이 썼음
      1980년대에도 그런 식으로 새 소프트웨어를 명명하던 기억이 있음
    • Firefox도 Phoenix라는 이름을 쓰려다 상표권 문제로 소송당했었음
      wxPython에도 Phoenix 프로젝트가 있음. 멋지지만 너무 흔한 이름임

  • 이 프로젝트 정말 멋짐
    Wayland를 좋아하지만 포털 프로토콜과 확장 메커니즘은 여전히 아쉬움
    Windows나 macOS에 비해 생산성 측면에서 부족한 부분이 있음
    보안이 내장된 X11 리라이트라니, 기대되는 접근임

    • Wayland 대신 정리된 X 버전을 만드는 게 낫다고 오래 생각해왔음
      유용한 프로젝트로 보이며, 발전하길 바람
    • Wayland가 생산성 면에서 부족하다고 했는데, 구체적으로 무엇이 빠져 있는지 궁금함
    • Windows나 macOS가 오히려 창 관리조차 제대로 못한다고 생각함
      2000년대 초반엔 설치조차 어려웠고, 일반 사용자가 직접 설치하기엔 불가능에 가까웠음
      Linux 배포판은 훨씬 설치가 쉬웠고, Windows가 느려지면 새 PC를 사는 이유도 그 때문이었음
    • 나는 오히려 Wayland에서 생산성에 부족함을 느끼지 못했음
      회사에서도 GNOME + Wayland로 문제없이 일하고 있음

  • 이런 식의 X 보존 프로젝트가 반가움
    Wayland를 선호하지만, 여전히 X가 필요한 영역이 있다고 생각함
    새로운 개발팀이 부담을 나눠야 함

    • 하지만 이런 선택이 파편화를 초래한다고 봄
      X11은 이제 완전히 묻고, 하나의 디스플레이 서버에 집중해야 함

  • 이 프로젝트가 얼마나 잘 작동할지는 모르겠지만,
    기업 중심의 단일화 흐름(예: Wayland, GNOME, KDE의 유료 개발자)에 맞서
    경쟁 프로젝트가 더 많아지는 건 좋다고 생각함
    Xorg를 현대화하려면 얼마나 많은 자금이 필요할지도 궁금함
    Wayland는 2008년에 나왔지만, 20년 가까이 지나도 사용자 요구를 다 충족하지 못했음
    기업이 원하는 좁은 사양에 맞추려다 보니 한계가 분명함

  • 애플리케이션 개발자는 빌드 스크립트에서 zig build --release 형태로
    릴리스 모드를 지정할 수 있음
    사용자가 직접 --release를 전달해도 됨
    Phoenix의 작성자는 ReleaseSafe 모드를 공식 릴리스로 선택한 듯함
    참고로 Phoenix는 내 고향 이름이기도 함

  • 같은 작성자가 만든 gpu-screen-recorder는
    Wayland에서 써본 최고의 화면 녹화기임
    4K 60fps 녹화도 별 설정 없이 바로 작동했음

  • xterm, emacs, xfig, ghostview 같은 기존 X11 앱이 작동하는지 궁금함

    • 대부분의 오래된 X11 프로그램은 X11 드로잉 API에 의존하기 때문에
      제대로 작동하지 않을 가능성이 높지만, 구현 자체는 간단함

  • 다중 스크린 지원이 비목표로 되어 있는데,
    그럼 가상 데스크톱을 지원하는 윈도 매니저(i3 등)에서 쓸 수 없는지 궁금함

    • X11에서 “screen”은 특정 의미를 가지므로, 단일 스크린만 지원해도
      멀티모니터나 가상 데스크톱 사용에는 문제가 없음
    • Xinerama 같은 연속 멀티모니터 기능은 나중에 쉽게 추가할 수 있는 구조임

  • Xorg처럼 XML 프로토콜 스펙을 코드 생성에 쓰지 않는 점이 흥미로움

답변달기