[Kos-dev] Re: [Kos-bug] Bugs

[Christophe Avoinne]

Aurélien a écrit :

> Bonjour,
>
> J'ai profité de ce week-end un peu "tranquille" pour travailler sur KOS.
> Malheureusement, dès que je démarrais KOS, mon clavier était en mode
> Majuscule et donc je ne pouvais accéder aux fonctions. J'ai résolvé de
> problème en mettant en commentaire 4 lignes dans le driver clavier qui
> s'occupait de la gestion du CapsLock.
> Alors, j'en ai profité pour vous faire part de quelques bugs, mais je pense
> que vous êtes au courant :
> - Clavier : Touches de fonction : CapsLock, NumLock et ScrollLock ne
> fonctionnent pas et plante le kernel
> - Scan PCI devices : sur mon ordinateur, aucun périphérique PCI n'est
> détecté

Il y a deux types de configuration pour détecter le PCI, il est possible qu'ils
ne soient pas gérés les deux (je n'ai pas participé à son élaboration), je
conseille de regarder le source de linux 2.4.0 à ce sujet et de s'en inspirer
pour déterminer laquelle des deux configurations il faut utiliser pour
déterminer (histoire de port d'entrée/sortie). La version BIOS32 est à utiliser
en dernier recours.

> - Vesa : le kernel plante dès que l'on envoie la souris en haut de l'écran

Ne sais pas, je n'ai pas participer à son élaboration, mais si tu connais la
programmation de la souris PS/2, jette un coup d'oeil. Bien que j'ai déjà
programmé ça il y d'antan, on a eu quelques problèmes à mettre en place durant
le WE II. Il y avait des versions contradictoires entre ce qui se disait dans
les manuels, ce que l'on trouvait dans les sources et le comportement
effectif... Quand j'ai quitté WE II, ce n'était pas réglé du tout...

> - Mauvaise interprétation des données qui arrivent sur le port série : par
> exemple, quand mon modem envoie "OK" sur le COM1, ce n'est pas du tout cela
> qui apparaît sur l'écran.

Non plus... pas participé du tout

> Pour le reste, ça fonctionne. J'aurais aimé savoir si c'est normal qu'au
> démarrage de KOS, il marque "FAILED" à la recherche des données du VESA ???

C'est sans doute pour déterminer la présence du VBE 3.0 or, peu de carte,
semble-t-il, l'implémente dans leur BIOS...

> Comme Thomas voulait que l'on recode intégralement le driver clavier,
> peut-être que je pourrais essayer (Le driver clavier de mon OS fonctionne
> très bien), mais je ne vous promets rien.

Non, effectivement tu peux le faire... si c'est mieux fait que le précédent,
c'est d'autant mieux. :)

Seulement, évite la gestion simpliste du clavier à la DOS - KOS est destiné à
être multi-tâche, ce qui signifie que le clavier n'est pas une ressource
partageable simultanément.

- l'IRQ doit seulement recevoir le scancode, le mettre en buffer (ni trop petit,
ni trop gros), et installer un callback qui va traiter les scancodes dans le
buffer et les placer dans un autre buffer dynamique (enfin bon, pour commencer,
tu le fais fixe).
- C'est seulement quand la cascade des irqs a terminé, on tente d'exécuter alors
les callbacks pour les traiter, avant de retourner au code interrompu par le
premier IRQ.

Par contre, je ne serais pas contre la possibilité d'une gestion bitmap du
scancode pour les jeux par exemple. Le scancode faisant 128, ca fait un bitmap
de 128 bit, soit 4 mots 32-bit. C'est un truc qu'on utilisait pour les démos et
le jeux et permet de détecter les combinaisons de touches comme les touches de
curseur gauche et haut de pressées, pour déplacer un vaisseau en diagonale
(souvenir, souvenir...). Le clavier du DOS ne nous le permettait pas :(.

Cette gestion des callbacks n'est pas encore mis en place, aussi tu devra
exécuter ce callback juste après la mise en buffer en l'appellant dans un
premier temps : JE NE VEUX PAS VOIR DU CODE DE TRAITEMENT DANS LE CODE MËME DE
L'IRQ. Quand ce mécanisme de callback existera, on pourra alors différer l'appel
de ce callback.

David, si tu pouvais expliquer la raison des callbacks différés, ce serait cool
- tu sais la discussion de WE II...


> De plus, je pense que je vais rajouter une fonction qui permet de placer le
> curseur (quelque fois, c'est pratique de savoir où en est le curseur) :
> c'est pas très compliqué, c'est seulement de l'hardware (I/O avec la carte
> graphique).

Surtout pas ! ca s'est du vga text ! rien a voire avec le clavier !
sinon effectivement c'est pas compliqué :

extern inline void gotoxy (int x,int y)
  {
    asm
      (
        "
    xchg %b2,%h0
    outw %w0,%w1
    mov %2,%0
    outw %w0,%w1
       "
       :
       : "a"((y * 80) + x), // dans eax
         "d"(0x3d4), // dans edx
         "q"(0x0e0f) // q = laisse choisir gcc entre eax ou ebx ou edx ou ecx,
i.e, un registre découplable en byte al, ah..., ici, seul ecx ou ebx peuvent
être candidat, puisque eax et edx seront déjà utilisés
      );
  }
Ce qui nous donnera :

    ...
    mov $0x0e0f,%eax
    mov $0x3d4,%edx
    ...
    xchg %cl,%ah     // ch <- hi(y*80+x), cl <- 0x0e; ah <- lo(y*80+x); al <-
0x0f;
    outw %ax,%dx   // outb (0x0f,0x3d4); outb (lo(y*80+w),0x3d5);
    mov %ecx,%eax // ah <- hi(y*80+x), cl <- 0x0e;
    outw %ax,%dx   // outb (0x0e,0x3d4); outb (hi(y*80+w),0x3d5);
    ...
gcc ayant choisi par exemple ecx pour %2 (contrainte "q")


Amicalement,

Hlide