|
|
En fait, il ne s'agit pas de bugs de fonctionnalités à proprement parler. Aucun utilisateur n'a, à ce jour, reporté de crashs liés à
TwinVNC.
Les causes identifiées de crashs provenaient d'éléments externes.
|
Ben y a des crashs quand même...
|
TwinVNC peut potentiellement planter votre système s'il accède à un serveur VNC peu fiable. C'est le cas de certains serveurs VNC qui implémentent des codecs incorrectement.
Hormis pour le codec CoRRE, TwinVNC ne contrôle pas les informations graphiques provenants du serveur. Si le serveur demande de remplir un rectangle d'une taille supérieure à celle de l'écran, TwinVNC le fera sans se poser de question, ce qui provoquera un effet de bord potentiellement fatal pour votre système.
|
Kesako avec l'Overlay ?
|
L'overlay peut causer problème selon les configurations graphiques que vous utilisez.
- Certaines configs ne supportent pas l'overlay réduit. Dans ce cas, utilisez l'argument "OVERLAY=100".
- D'autres configs ne supportent pas l'overlay réduit en dessous de 50% de la taille originale. Dans ce cas, utilisez l'argument "OVERLAY=50".
- Enfin, sur ma config, l'overlay pose problème avec la toolbar. La zone d'affichage dépasse anormalement la fenêtre et j'ai développé un patch qui résout ce problème (voir la commande PatchOverlay fournie avec l'archive).
|
Bug potentiel avec la notion de "color map" du serveur
|
Ce problème pourrait intervenir sur un écran à palettes indexées (<=256 couleurs) côté serveur. Le protocole RFB de VNC permet à un serveur d'envoyer une table de couleurs définies au client. Aujourd'hui, peu de serveurs implémentent cette fonctionnalité, simplement parce qu'ils ont la possibilité de dialoguer en mode True Color (la couleur est codée par le pixel) avec le client, même pour un affichage 8 bits.
Bref, TwinVNC est censé pouvoir gérer cette fonctionnalité mais elle n'a pas pu être testée...
|
|
|
|
|
|