Bảng điều khiển không sử dụng được sau khi chạy ứng dụng SDL

Khi nào SDL dựa trên chương trình (ví dụ prboom , DOSBox ) đang chạy từ giao diện điều khiển (không X) và chấm dứt đột ngột vì một lý do (ví dụ như giết hoặc segfaults), màn hình khóa lên; Nó chỉ chuyển sang màu đen và duy trì màu đen cho đến khi bạn khởi động lại.

Điều này trái ngược với các bản demo hello_video và hello_trigin trả lại giao diện điều khiển về trạng thái ban đầu ngay cả khi chúng bị chấm dứt đột ngột.

Chính xác thì điều gì đang xảy ra ở đây, và có cách nào để phục hồi nó mà không cần khởi động lại không?

Tôi đã quan sát điều này trong Debian Squeeze . Tôi không biết các hệ điều hành khác có bị ảnh hưởng không.

Chỉnh sửa : Tôi chỉ nên làm rõ bảng điều khiển (đầu ra HDMI / RCA, bàn phím USB) bị ảnh hưởng, không kết nối ssh (vẫn tiếp tục hoạt động tốt.)

terminal sdl debian

— vây
nguồn

Bạn có thể thay đổi để tty được nhấn alt+F1-5?

— Jivings

@Jivings, không, những tổ hợp phím đó không có hiệu lực.

— vây

Hmm .. Bạn có thể sử dụng các lệnh SysRq và REISUB không?

— Jivings

@Jivings không, nhưng (1) Khả năng khởi động lại không phải là vấn đề: Tôi có thể ra lệnh tắt máy từ kết nối ssh và (2) Tôi đang tìm giải pháp không yêu cầu khởi động lại.

— Finnw

Oh ssh. Trong lời nhắc ssh của bạn, bạn có thể giết máy chủ X và khởi động lại. Hoặc khởi động lại runlevel.

— Jivings

Câu trả lời:

Đây gần như chắc chắn là một lỗi trong trình điều khiển đồ họa. Nghe có vẻ như SDL đang khởi tạo API đồ họa, tại thời điểm đó trình điều khiển đồ họa sẽ chiếm màn hình. Bởi vì bạn đã giết SDL, nó không bao giờ chạy mã để khử định nghĩa API đồ họa, và do đó, nó chỉ chờ đợi các lệnh đồ họa sẽ không bao giờ đến.

Điều này cho thấy API đồ họa được thiết kế tồi, nhưng vì toàn bộ nội dung là độc quyền nên không có cách nào để biết và không có cách nào khắc phục.

(Tôi đã quan sát hành vi tương tự trên PC khi SDL "chộp" con trỏ chuột và không làm phiền nó nếu nó gặp sự cố hoặc bị giết, nhưng không bao giờ với màn hình.)

— Alistair Buxton
nguồn

SDL có một "chiếc dù" mà nó triển khai bình thường để dọn dẹp ngay cả trong trường hợp của segfaults nên có gì đó không ổn.

— Flexo

Dù sẽ chỉ bắt SIGSEGV chứ không phải SIGKILL.

— Alistair Buxton

Điều đó thật thú vị, tôi sẽ phải thử gửi SIGKILLđến một trong những bản demo GLES2 và xem điều gì sẽ xảy ra.

— vây

Tôi đang phát triển một ứng dụng SDL vào năm 2017 và dường như vẫn có khả năng xảy ra lỗi khi sử dụng CTRL-C để thoát khỏi ứng dụng SDL. Tôi gặp vấn đề là SDL và đầu vào thiết bị đầu cuối sẽ dần trở nên không phản hồi khi tôi đang thử nghiệm ứng dụng, liên tục chạy nó và thoát khỏi CTRL-C. Tôi đã thấy rằng nếu tôi thoát khỏi ứng dụng đúng cách từ trong ứng dụng SDL thì tôi sẽ không gặp vấn đề gì.

— Paul Slocum

Tôi biết đây là một câu hỏi rất cũ, nhưng tôi đã gặp phải một vấn đề tương tự như vậy khi chạy Mupen64Plus thông qua EmulationStation. Bảng điều khiển của tôi sẽ hiển thị tốt, nhưng bàn phím sẽ hoàn toàn không phản hồi cho đến khi tôi thực hiện khởi động lại.

Vấn đề là bàn phím vẫn ở chế độ RAW sau khi chương trình kết thúc. Giải pháp là thêm dòng sau vào cuối tập lệnh shell chạy nó : kbd_mode -a. Điều này đặt lại bàn phím về chế độ XLATE và cho phép nó hoạt động trở lại.

Mặc dù điều này không giải quyết được phần "màn hình đen" của vấn đề, tôi đoán rằng phải có một cách tương tự để đặt lại bộ đệm khung điều khiển để lấy lại video.

— glindsey1979
nguồn

-5

Tôi không thể nói vấn đề với ứng dụng SDL là gì, nhưng chỉ cần gõ:

reset

nên làm cho giao diện điều khiển có thể sử dụng lại

— neofutur
nguồn

... Làm thế nào anh ta phải gõ nó nếu bàn điều khiển không thể sử dụng?

— Jivings

Những gì Jivings nói. Bàn phím không phản hồi SAU, nó không chỉ là màn hình.

— Finnw

Và việc ban hành lệnh này từ ssh (chuyển hướng đến / dev / tty1) cũng không giúp được gì.

— vây

Bạn nên xóa câu trả lời của mình để không bị phủ nhận vào quên lãng

— Alex L

Như một phần thưởng, bạn sẽ nhận được huy hiệu áp lực ngang hàng

— David Sykes