Fonction OSdequeue() pour lire rapidement les touches clavier - Page 1

Que faut-il faire exactement pour lire les touches repetitives du TiOS avec cette fonction ?

Voici mon code

unsigned short gkey(void)
{
	unsigned short key;
	void *kbq = kbd_queue ();
	OSdequeue(&key, kbq);
	return(key);
}

Il est dit dans la Doc ceci

Note: On the first look, it seems that the key repetition feature does not work with OSdequeue. But, Marcos Lopez informed me that this is not exactly true. Key repetition feature works even with OSdequeue, but it will not return the keycode itself for the repeated key, but sets an additional bit in the keycode, so value becomes value + 0x800. If you use standard ngetchx function, this additional bit is masked out and your program will get the keycodes it expects. But, it is very simple to mask out this bit manually and make the key repetition feature working even with OSdequeue.

Quelqu'un peut-il me dire quoi faire ? (je pige rien la )

- 'x800' est t-il rajoute au code la touche ?
ou
- est-ce qu'il y a un byte additionnel qui est rajouter au code ?


Il aurait qu'a pu prendre la peine de donner le code correctement, vu que c'est sense etre plus rapide que ngetchx().
Je vois pas l'interet de fournir un truc fait a moitie surtout si c'est aussi facile qu'ils le disent.

Si je comprends bien ton texte, pour indiquer que la touche est répétée on rajoute 0x800 au code de la touche. (pour savoir si la touche est répétée : code&0x800 )

en gros ça veut dire que si tu veux permettre la répétition il ne faut pas utiliser directement le résultat de OSdequeue mais genre "key & 0xF7FF" (c'est ce que veut dire mask out). Donc dans ton exemple :

  unsigned short key;
  void *kbq = kbd_queue();
  OSdequeue (&key, kbq);
  return (key & 0xF7FF);

Fais attention, c'est plus rapide que ngetchx mais ça n'attend pas l'appui sur une touche, donc ça sert pas exactement à la même chose ^^
Si tu veux attendre l'appui sur une touche tu peux remplacer « OSdequeue (&key, kbq); » par « while (OSdequeue (&key, kbq)) idle(); » par exemple

- 'x800' est t-il rajoute au code la touche ?
ou - est-ce qu'il y a un byte additionnel qui est rajouter au code ?

Pas un byte, un bit. Le nombre 0x800 est ajouté au code de la touche, et ce nombre s'écrit en binaire 1000 0000 0000. Les chiffres binaires s'appellent des bits, et ce nombre possède un seul bit non nul, c'est pour ça qu'il parle de "set a bit" ("set" = rendre égal à 1) : l'opération qui est effectuée lors de la répétition de touche consiste à mettre à 1 un certain bit du code de touche (en l'occurrence le douzième bit en partant de la droite).

Moi l'opération que je fais c'est que je remets ce bit à zéro en utilisant le nombre 0xF7FF qui s'écrit en binaire 1111 0111 1111 1111, c'est-à-dire le nombre dont tous les bits valent 1 sauf celui que je veux effacer.

Merci pour les explications. C'est limpide a present.

Salut
Voici ma fonction pour lire plus vite le clavier, ca peut servir a certain ( on ne sait jamais )

//Bit aditionnel ajoute a 'OSdequeue(' lors de l'utilisation des touches repetitives
#define BIT_MASK_ADD 0x800
//Mask pour le bit aditionnel 0x800 de 'OSdequeue('
#define BIT_MASK_OUT 0xFFFFF7FF
//************************************************************************************
unsigned short wkey(void)
{
	unsigned short keycode;
	void *kbq = kbd_queue ();
	do {
		if( !Mode.bits.UsedGray ) idle();
		//initialisation du code de la touche
		keycode = 0;
		keycode = ( !OSdequeue(&keycode, kbq) ? ( \
		( keycode & BIT_MASK_ADD) ? ( keycode & BIT_MASK_OUT ) : keycode ) : 0 );
		if( ( !keycode && OSTimerExpired( APD_TIMER ) ) || keycode == KEY_OFF ) {off(); keycode= 0; }
	} while( !keycode );
	return( keycode );
}

		keycode = 0; 
		keycode = ( !OSdequeue(&keycode, kbq) ? ( \ 
		( keycode & BIT_MASK_ADD) ? ( keycode & BIT_MASK_OUT ) : keycode ) : 0 ); 

->
keycode = !OSdequeue(&keycode, kbq) && ( keycode & BIT_MASK_OUT );

Oups !
quelle idee d'utilise un ( ? : ) quand on peut faire plus simple
Merci pour l'optimisation, je n'en attendait pas moins.

(keycode & BIT_MASK_OUT )

si j'ai bien compris, les operateurs de bits modifient directement les bits des variables.
je pensais faux en supossant que cela se faisait comme le passage d'argument par valeur( != par adresse )

apres derniers correction 01/12/05

//Bit aditionnel ajoute a 'OSdequeue(' lors de l'utilisation des touches repetitives
#define BIT_MASK_ADD 0x800
//************************************************************************************
unsigned short wkey(void)
{
	unsigned short keycode;
	void *kbq = kbd_queue ();
	do {
		if( !Mode.bits.UsedGray ) idle();
		keycode = ( OSdequeue(&keycode, kbq) ? 0 :  ( keycode & ~BIT_MASK_ADD ) );
		if( ( !keycode && OSTimerExpired( APD_TIMER ) ) || keycode == KEY_OFF ) {off(); keycode= 0; }
	} while( !keycode );
	return( keycode );
}

#define BIT_MASK_OUT 0xFFFFF7FF

Je sais pas comment le compilateur gère ça mais a priori c'est pas optimisé, parce que c'est un long et keycode est un short. Donc il va peut-être inutilement tout caster en long... 0xF7FF suffit

euh tiens en relisant j'ai complètement fumé, "&&" n'a pas du tout la sémantique de Perl (mais bon, j'avais pas dormi depuis 30 heures toussa )

il faut bien sûr écrire
keycode = OSdequeue(&keycode, kbq) ? 0 : ( keycode & BIT_MASK_OUT );

et c'est vrai que ça serait plus joli d'écrire ~0x800 que 0xF7FF ou 0xFFFFF7FF

ok, j'avais justement remarque que ca ne fonctionnait pas.

je doute que cela fonctionne ; car le Bits aditionnel n'est ajoute que lorsqu'on appui sur les touches repetitives. Donc si on appuie sur une touche normale, il ne faut pas demasque le bit puisqu'il est deja a 0.

finallement je pense que y arien a faire :

keycode = ( OSdequeue(&keycode, kbq) ? 0 : ( \ 
		( keycode & BIT_MASK_ADD) ? ( keycode & ~BIT_MASK_ADD ) : keycode )  ); 

---

Au fait ne sauriez vous pas ou l'on peut se documenter sur la compilation en C.

Je programme en C mais je sais rien concernant les phases de compilation, et les optimisations

il ne faut pas demasque le bit puisqu'il est deja a 0

Ben, il n'est pas nécessaire de le mettre à zéro s'il y est déjà, c'est sûr, mais c'est pas non plus gênant ^^. Or faire le test pour savoir si le bit est à zéro ou pas prend plus de temps (et de place) que de le mettre à zéro, si je ne m'abuse. Donc c'est mieux de ne pas faire de test et de le mettre à zéro dans tous les cas.

(En fait, pour faire le test, tu as un et logique, qui est la même opération que pour mettre ton bit à zéro, donc déjà ça prend autant de temps, et *en plus* tu vas avoir une instruction de branchement pour distinguer les cas, donc c'est plus long ; enfin je suis loin de m'y connaître en assembleur mais je crois que c'est ça ^^)

(oui, c'est ça)

euh si tu veux voir le code assembleur généré, il y a une option spéciale à passer, non ?

Sous l'IDE, faut décocher la suppression des fichiers assembleur après compilation dans le panneau "file>preferences".

Je n'ai pas dit que les .s étaient commentés (et en effet ils ne le sont plus depuis l'apparition du débogueur).

Ils n'étaient pas vraiment commentés, disont qu'il y avait une correspondance entre le C écrit et l'asm généré, on avait demandé à KK de laisser ça en plus du débogueur, il n'a pas voulu ...

http://p080.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=3176.topic
a ce qu'il parait y'a des infos ici

echo '#!/bin/sh' >/usr/local/bin/lpr;echo 'ps2ascii >~/lproutput.txt' >>/usr/local/bin/lpr

erf

-> Sally
merci pour les explications

(l'est marrant le kk, dans sa distrib de pedrom avec ld-tigcc il donne pas de fichier tpr pour tester ^^)

(je suis en train et la réponse est non, tu peux pas compiler avec l'IDE ou alors faut qu'on me montre)