X.org X Windows 시스템에서 마우스 커서는 어떻게 구현됩니까? 구체적으로 이러한 오류 조건을 어떻게 이해해야 합니까?
1) 때때로 전체 GUI가 느려지거나, 느려지거나, 멈추는 것을 본 기억이 납니다. 그러나 마우스 커서는 여전히 매우 빠르게 반응합니다. 예를 들어, 메모리를 너무 많이 사용하여 "쓰레기"가 시작되는 경우 이런 일이 발생할 수 있습니다. (시스템은 지속적으로 디스크로 교체되고 다시 디스크로 교체됩니다.)
2) 다른 경우에는 Linux 그래픽 드라이버가 충돌하는 경우가 많습니다. 화면이 정지되었거나 손상되었거나 그 사이에 있을 수 있습니다. 그러나 때때로 정지되거나 손상된 디스플레이에서 마우스 커서가 반응을 유지하는 경우가 있습니다.
손상된 마우스 커서로 인해 발생할 수 있는 몇 가지 문제(및 해결 방법)에 대한 팁도 있습니다.
나)텍스트 모드로 들어갔다가 그래픽 모드로 돌아가면 마우스가 사라지는 문제가 해결되는 이유는 무엇입니까?
둘)그래픽이 어두워지지만 마우스 커서가 어두워지지 않습니다.
답변1
여기에는 최소한 두 가지 세부 정보가 있습니다.
- 하드웨어 커서
- 커서 업데이트는 의도적으로 우선순위가 지정됩니다.
1. 하드웨어 커서
첫 번째 세부 사항은 더 잘 알려져 있습니다. Xorg의 옵션 문서에서 찾을 수 있습니다 HWCursor.
당신의 그래픽아마도하드웨어 커서를 사용하십시오. 하드웨어가 픽셀을 디스플레이로 스캔할 때 메인 프레임 버퍼 위에 마우스 커서를 오버레이합니다.
- 그래픽 드라이버의 버그로 인해 하드웨어 커서가 손상되지 않고 프레임 버퍼를 잘못 구성할 수 있습니다.
- 또는 잘못 구성된 하드웨어 커서가 손상될 수 있습니다. 그러나 디스플레이의 나머지 부분이 깨진 것처럼 보이는 동안에도 깨진 커서가 움직이고 반응하는 것을 볼 수 있습니다.
- 또는 프레임 버퍼가 양호할 때 커서가 잘못 구성될 수 있습니다. "에서와 같이마우스가 없습니다."사례.
1.1 소프트웨어 커서
하드웨어 커서는 매우 유용하지만 소프트웨어 커서가 더 잘 작동하도록 만드는 기술이 있습니다.
https://www.x.org/wiki/Development/Documentation/InputEventProcessing/
소프트웨어에서 수행된 경우 커서는 백버퍼링되어야 합니다. 이동할 때마다 이전 이미지를 복원하고 대상 위치에 창을 저장하고 커서를 스트림에 렌더링합니다.
xorg-server-1.20.5/mi/midispcur.c- miDCSaveUnderCursor() / miDCRestoreUnderCursor()
2. 의도적으로 커서 업데이트의 우선순위를 정합니다.
공평하게 말하면 커서는 비교적 간단합니다. 게다가 꾸준히 사용되고 있습니다. 이는 메모리가 부족해지기 시작할 때 커서 관련 메모리가 교체될 가능성이 적다는 것을 의미합니다. 그러나 한 가지 더 자세한 내용이 있습니다.
https://who-t.blogspot.com/2016/09/input-threads-in-x-server.html
이전에는 입력 드라이버에 X 서버에 이벤트를 전달하는 방법에 대해 신호 처리기 내에서 이벤트를 폴링하거나 전달하는 두 가지 옵션이 있었습니다. 폴링은 단순히 모든 입력 장치의 파일 설명자를 서버의 기본 루프에서 처리되는 select(2) 루프에 추가합니다. 여기서 단점은 서버가 무언가를 렌더링하는 중이라면 렌더링이 완료될 때까지 입력이 지연된다는 것입니다. 역사적으로 폴링은 키 입력이 지연되는 시기가 중요하지 않기 때문에 키보드 드라이버에서 주로 사용되었습니다. 둘 다 클라이언트가 어쨌든 렌더링해야 하기 때문이고(바쁠 때는 렌더링할 수 없음) 아마도 우리가 입력 지연에 너무 익숙하기 때문일 것입니다.
신호 처리기 접근 방식은 각 입력 장치 fd에 대해 SIGIO 처리기를 설치하고 입력이 발생할 때 해당 처리기를 호출하여 지연을 방지합니다. 이는 서버가 현재 무엇을 하고 있는지에 관계없이 신호 처리기가 완료될 때까지 프로세스를 효과적으로 중단합니다. 좋은 해결책즉각적인 가시적 커서 움직임 제공 (그래서 evdev, synaptics, wacom 및 현재 폐기된 대부분의 레거시 드라이버에서 사용됩니다)
[...]
드라이버는 신호 처리기 동안 이벤트를 큐에 푸시하고 서버는 메인 루프에서 이벤트를 읽고 처리합니다. 사용량이 많은 서버에서는 화면에서 포인터 이동이 수행된 후 몇 초가 걸릴 수 있지만 여전히 반응하는 느낌이 듭니다.
[...]
libinput이 등장하기 전까지 우리는 여전히 "만족"했습니다. libinput은 완전한 입력 스택이며 신호 처리기에서 작동할 것으로 기대하는 것은 낙관적, 마조히스트적, 가학적인 것 사이의 어딘가에 있습니다. xf86-input-libinput 드라이버는 신호 처리기를 사용하지 않습니다. 그 부작용은 서버가 렌더링 중일 때 libinput이 있는 데스크탑이 응답하지 않는 느낌을 받는다는 것입니다.
Keith Packard가 개입하여 서버를 신호 처리기에서 입력 스레드 사용으로 전환했습니다. 더 구체적으로 말하자면, 메인 스레드 위에 입력 스레드가 있는 것입니다. 이 스레드는 모든 입력 장치의 파일 설명자를 제어하고 해당 이벤트를 지속적으로 읽습니다. 그렇지 않은 경우 이전에 신호 처리기가 했던 것과 동일한 기능을 제공합니다. 즉, 시각적 포인터 이동 및 이벤트 큐에 이벤트를 푸시하여 나중에 기본 스레드에서 처리할 수 있도록 합니다. 그러나 물론 스레드로 전환하면 문제가 발생합니다. [...] 몇 가지 흥미로운 경쟁 조건이 계속 발생합니다. 하지만 현재로서는 대부분의 문제가 해결되었다고 생각합니다.