Comment définir un mode vidéo sous Linux avec kms / drm?


12

Comment puis-je définir le mode vidéo sous Linux de bas niveau? Pour autant que je sache, la couche la plus basse de l'espace utilisateur serait de demander KMS via DRM. Est-ce correct? Et si oui, comment pourrais-je réaliser un changement de mode et l'accès à la "mémoire vidéo" associée?


Qu'est-ce que les kms? Jusqu'à présent, je n'ai pas entendu parler de KSM ou de changement de mode.
BЈовић

Je veux dire par KMS: lien Kernel-Mode-Setting .

Voulez-vous dire pour le framebuffer / console? Ou pour X11 / Xorg?
penguin359

@ penguin359 Soit. X et fb si possible tant que j'utilise directement la libdrm ... (PS: de préférence via C ++)

4
@litro qu'essayez-vous de réaliser? et dans de nombreux kms de distro s'activera si disponible et non éteint.
xenoterracide

Réponses:


3

KMS - Réglage du mode noyau, pour ceux qui n'en ont pas entendu parler - est rendu possible par les pilotes vidéo en mode noyau. Ces pilotes vidéo en mode noyau configurent un affichage de tampon d'image qui, par défaut, est la résolution native du ou des moniteurs connectés. S'il y a plus d'un moniteur connecté, chaque moniteur obtiendra sa résolution native et la console virtuelle sera limitée à la largeur et à la hauteur minimales des deux moniteurs.

Étant donné que l'utilisation de KMS entraîne un framebuffer, les éléments de configuration du framebuffer doivent fonctionner. Je ne peux pas vérifier cela sur le système sur lequel je suis actuellement, car il n'a pas de pilote KMS. Mais je serai à un système plus tard avec KMS et je vous le ferai savoir.

Voir la documentation du noyau sur la définition des modes avec le paramètre video = boot up pour les tampons d' images pour plus d'informations.


2

Je ne suis pas sûr que vous sachiez vraiment ce que vous demandez, sinon vous l'auriez formulé de manière à répondre. ... Mais pour faire de mon mieux, en répondant à votre question.

Vous voulez définir un mode et penser à de la «mémoire vidéo»? comme l'ancien mode dos X jours ?? Si c'est ce que vous voulez, vous devez programmer avec le Framebuffer. Cela dit, il serait préférable de travailler avec DirectFB. DirectFB est comme une couche très fine, avec accélération, sur le Framebuffer. Son faible niveau et, à vrai dire, son aussi bas que vous devriez raisonnablement vouloir écrire des applications. Vous seriez en mesure de définir des modes et d'avoir un contrôle dans un style plus bas. Si vous voulez un contrôle direct et direct du style, vous devez écrire Framebuffer brut, vous devez essentiellement sortir un ram vidéo. Si vous pensez que Framebuffer fonctionne mal, je ne saurais trop insister, consultez DirectFB. Si quelqu'un a un pilote KMS chargé, son Framebuffer est défini via KMS / libdrm.

Maintenant, comme pour libdrm, c'est une bibliothèque d'espace utilisateur pour travailler avec le noyau DRM. Ce n'est pas un Framebuffer, ce n'est pas une API d'application, c'est une bibliothèque de périphériques système. Si vous souhaitez créer un nouveau pilote de périphérique, libdrm est le chemin absolu. Par exemple, libdrm-radeon. Linux n'est pas DOS, le seul moyen de communiquer directement avec le matériel est via le noyau. Toutes les applications normales n'envoient jamais de code directement au matériel, il doit être supprimé dans certains appels lib / API /. Il existe des projets qui ont adopté l'approche intégrée au noyau, à des fins académiques / expérimentales, tels que FBUI.

J'espère que j'aurais pu au moins vous orienter dans la bonne direction, sinon vous devriez commenter et mettre à jour votre question. J'ai suivi cette question depuis sa conception, qui était il y a au moins deux migrations et pas plus proche de la réponse. Sans plus d'informations, il n'y a vraiment plus rien à dire.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.