tags 221290 + patch
tags 221290 - l10n
thanks
Hi,
At last I discovered that bug report :) I indeed noticed the strange
behavior and was never able to reproduce it reliably. So now it's done,
and now I understand.
This is not a bug, this is a feature: as said in manual, getty detects
tty parity and control characters, which is quite nice in many
situations, but not 8bit ones. Here, the umlauted letter you type is
considered as a 7bit character with a 8th bit parity. The 7 lower bits
are then interpreted (wrong).
So detection is really not reliable in 8bit environments (be it utf-8 or
not). What I suggest then is the attached patch: just adding a -8
option that makes agetty assume that the tty is 8bits and hence disable
parity detection. Adding that option in /etc/inittab for new installs
should then be fine:
1:2345:respawn:/sbin/getty -8 38400 tty1
etc.
Note: with this patch, 8bit characters are just silently dropped (that's
the expected getty behavior), this is quite neat since you then don't
even need to backspace your 8bit characters :)
Samuel
Index: Programs/api_client.c
===================================================================
--- Programs/api_client.c (r�vision 2675)
+++ Programs/api_client.c (copie de travail)
@@ -1192,22 +1192,24 @@
{
int res;
unsigned int size = handle->brlx * handle->brly;
- char text[size+1];
- unsigned char attrAnd[size], attrOr[size];
brlapi_writeStruct ws = BRLAPI_WRITESTRUCT_INITIALIZER;
if (size == 0) {
brlapi_errno=BRLERR_INVALID_PARAMETER;
return -1;
}
- memset(text, ' ', size);
- text[size] = 0;
- ws.text = text;
- memcpy(attrOr, dots, size);
- ws.attrOr = attrOr;
- memset(attrAnd, 0, size);
- ws.attrAnd = attrAnd;
- ws.cursor = 0;
- res = brlapi__write(handle,&ws);
+ {
+ char text[size+1];
+ unsigned char attrAnd[size], attrOr[size];
+ memset(text, ' ', size);
+ text[size] = 0;
+ ws.text = text;
+ memcpy(attrOr, dots, size);
+ ws.attrOr = attrOr;
+ memset(attrAnd, 0, size);
+ ws.attrAnd = attrAnd;
+ ws.cursor = 0;
+ res = brlapi__write(handle,&ws);
+ }
return res;
}
