[Kos-dev] Driver TTY

[Raphaël Junqueira]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mardi 06 Mai 2003 10:39, Thomas Petazzoni a écrit :
> Hello,

Salut ,)

> Comme je l'avais annoncé, j'ai commencé à refaire le driver de tty =
pour
> qu'il fonctionne avec le nouveau système (simple pour l'instant) de
> kernel ressources et de user ressources.

;)

> Je me suis aperçu que l'ancien driver était assez mal conçu : les
> entrées clavier étaient faites par le driver clavier (module klavier/)
> alors que la sortie était faite directement par le driver tty (écritu=
re
> directe dans la mémoire vidéo). Bref, clairement, il faudrait faire un
> peu d'ordre dans ceci, de manière à avoir :
>  * klavier -> s'occupe du clavier
>  * console -> s'occupe de l'affiche sur une console
>  * tty -> permet de regrouper les 2

pkoi pas

> Soit klavier et console exportent des interfaces au sens "karm", soit
> une interface spécifique est utilisée. J'avoue préferer la premiè=
re
> solution, mais je ne suis pas sûr que ce soit la meilleure. Qu'en
> pensez-vous ?

je pense que tu as raison, mais on pourra facilement evoluer au cas ou

> Par ailleurs, ce modèle de fonctionnement pose deux questions :
>  * Qui doit être bloquant en lecture : le driver klavier ou bien le
> driver tty ? Dans le cas ou c'est tty (ce qui est le cas actuellement je
> crois), comment tty va-t-il se débloquer lors d'une saisie au clavier ?

Moi j'aurait pris le clavier. Le tty je ne voit pas en quoi serait il bloquant 
(surtout qu'il se peut que l'entre ne soit pas tjs le clavier)

>  * Pour les consoles multiples, comment cela peut-il se passer ? A
> priori, il n'y a qu'une seule console et qu'un seul clavier, donc
> /dev/klavier et /dev/console, et à partir de là, tty doit créer
> /dev/tty0, /dev/tty1, /dev/tty2, etc... 

ben pour moi je le verrait plutot que la console n'aurait connaissance que 
d'un /dev/activetty. la console ne serait que le moteur d'affichage du buffer 
de /dev/activetty

> C'est donc tty qui doit gérer ce probleme des consoles multiples. 
> Comment est-il signalé de la volonté de l'utilisateur de changer de 
> console ? 

Ben comme vu ci-dessus, le ttyYY (qui est actuellement /dev/activetty) 
recevrait via le "klavier" l'ordre de passer la main au ttyXX qui devient le 
nouveau /dev/activetty, la konsole recevrait alors la notification que 
/dev/activetty vient de changer (donc refresh)

> Pour le moment, on filtre les Alt+Fx et je pense qu'on n'a pas trop 
> d'autre solution. Comment tty signale-t-il à /dev/console qu'il veut 
> changer de console ? 

Avec mon truc il ne le notifie pas vraiment, il ne fait que passer la main de 
tty actif a un autre tty. Ca serait la console qui serait a l'ecoute des 
modification de tty actifs.

> Par une interface spéciale lui permettant de dire quelle est l'adresse =
de la
> console à afficher ?

s/console/tty
Pkoi pas ca peut etre une solution

> Si on résume, on aurait :
>  * klavier qui exporte INTERFACE_CHAR_INPUT (lecture)
>  * console qui exporte INTERFACE_CHAR_OUTPUT (écriture) et
> INTERFACE_CONSOLE (changement de console)
>  * tty qui exporte INTERFACE_CHAR
>
> Dernière question : dans le cas de console sur port série, comment ce=
la
> va-t-il se passer ?

avec une machine au bout ou non ?
si oui la machine au bout aurait un tty serveur qui ecrirait sur la konsole de 
la machine, alors qu'en local un tty client servirait de relait (donc pas de 
konsole en local)

> Voila quelques questions en vrac, j'attends vos suggestions ;-)

tu as les miennes ;)

> Bonne journée,

De meme

> Thomas

Amicalement,
Raphael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+uAXQp7NA3AmQTU4RAsenAKCDqSKHSzetV55MTp73N4SuC3sXPACfcUQR
FdWuJv0DhmeHK/pp0ZIybts=
=wDf5
-----END PGP SIGNATURE-----