커널 모드 설정과 프레임 버퍼?

KMS를 사용하면 그래픽 드라이버가 커널로 이동됩니다. 프레임 버퍼가 이미 커널에 있었기 때문에 이것이 프레임 버퍼 작동에 영향을 미치지 않을 것으로 예상됩니다. 그러나 KMS가 fb를 대체하고 fb를 확장하며 fb가 필요하며 fb 지원을 제거해야한다는 것을 읽었습니다. 이런 젠장? 내가 찾고있는 대답은 KMS와 프레임 버퍼 간의 관계에 대한 설명입니다.

나는 tty에서 기본 해상도를 얻기 위해 uvesafb를 사용하고 있습니다. 여기서는 KMS를 사용하는 시스템에서 어떻게 작동하는지 이해하고자합니다. KMS를 사용하면 스크롤 속도가 더 빠릅니까? fbterm 및 fbida와 같은 유틸리티가 동일하게 작동합니까? 안정성이 더 좋습니까?

우선, 기본적으로 두 가지 유형의 클래식 프레임 버퍼 드라이버가 있습니다.

• 일반 하드웨어 및 펌웨어 드라이버 (예 : vga, vesafb / uvesafb, efifb)
• 하드웨어 별 드라이버 (예 : rivafb, atyfb)

클래식 프레임 버퍼 드라이버는 모두 기본 모드 설정을 지원했지만 하드웨어 가속을 거의 지원하지 않으면 거의 노출되지 않았습니다.

클래식 X 디자인에서는 실제로 문제가되지 않았습니다. 2D 가속을 얻으려면 X 서버가 루트로 실행되어 하드웨어에 직접 액세스 할 수 있습니다. 기본적으로 프레임 버퍼 드라이버를 완전히 우회했습니다. 3d (및 최신 카드의 2d 지원)의 경우 액세스 및 관리 비디오 메모리를 중재하는 커널 DRM 드라이버도 사용합니다.

이 설정에서는 커널 프레임 버퍼 드라이버와 사용자 공간 X 서버 모두에서 모드 설정이 수행 된 두 곳이있었습니다. 이러한 코드 복제 (및 VT 스위치 등의 드라이버 간 이따금의 싸움)는 이상적이지 않았습니다.

또한 동일한 하드웨어에 대해 커널에 프레임 버퍼 드라이버와 DRM 드라이버라는 두 개의 별도 드라이버가있었습니다. 경우에 따라 (예 : 사전 km intelfb) 동시에로드 할 수 있지만 둘 다로드 할 수는 없습니다.

KMS는 이러한 문제에 대한 해결책이었습니다. 그것:

• 커널 하드웨어 특정 프레임 버퍼 드라이버와 drm 드라이버를 단일 드라이버로 병합합니다.
• X 서버가 모드 설정을 제어하는 ​​데 사용할 인터페이스를 제공하므로 X 서버가 하드웨어에 직접 액세스 할 필요가 없습니다. 실제로 KMS를 사용하면 X 서버에 더 이상 루트 권한이 필요하지 않습니다.

흥미로운 점 : 현재 KMS 로의 마이그레이션은 실제로 2004 년경에 시작되었습니다. 콘솔 재구성에 관한 Jon Smirl의 이메일을 참조하십시오 .

보다 구체적인 질문에 답변하려면 :

• 속도는 일반적으로 가속되지 않은 일반 드라이버 (예 : VGA, vesafb) 중 하나보다 나쁘지 않지만 KMS 프레임 버퍼 텍스트 콘솔은 속도보다는 편의성과 비상 사용을 위해 설계되었으며 일부 드라이버에서는 콘솔이 완전히 가속되지 않습니다. 예를 들어, 줄이 긴 줄은 인텔 카드에서 꽤 나쁩니다.
• 기존 프레임 버퍼 인터페이스를 사용하도록 설계된 애플리케이션은 여전히 ​​KMS 프레임 버퍼에서 작동합니다.

KMS는 사용자 공간이 아닌 커널 공간에서 디스플레이 해상도와 깊이를 설정합니다. 따라서 그렇습니다. 프레임 버퍼에서 기본 해상도를 활성화합니다.

커널 모드 설정