Sorry for poking in, but why have kmscon, a complete re-implementation, run over then DRM when a generic and well-tested combination of a wayland compositor and a terminal emulator, like cage+foot, do the work just as well? Yes, setup is initially difficult. But it might be worth it.
An additional bonus of using the wayland method is extensibility and modularity. If the desktop protocols are inappropriate, new and separate wayland protocols exclusively designed for console use can be created. And can be used with existing protocols whenever appropriate. And yes, just like simple GUI programs in fbcon, you can have a simple single-purpose GUI programs run in a wayland compositor. (A kitty graphics protocol exists, but IDK if it is appropriate fora console...) Implementing this with kmscon, well... It might be easier to implement new wayland protocols for whatever the existing desktop-oriented wayland protocols are lacking or inappropriate in. Yes, it is easier said than done, I agree. But it *might* be worth the extra effort. If you ask the question of *why*, why so much in a VT console, I say that it is becuase: - fbcon VTs already support this. Image viewers are commonly used on VTs. I think it should be supported in userspace-VTs too, esp. when the effort is minimal. - It is less work to write wayland protocols than to arbitrarily extend kmscon, in case new functionality is needed. - wayland, the compositors, foot, all already exist. fakeKMSCon is one such setup which *already* supports this. I suggest new protocols **only if** the existing ones are lacking. - Theoretically in a utopian future, you could have such console-GUI tools, which are more accessible to the average users than cryptic commands, to find and solve small issues like SElinux... -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
