The french keymap seems to be left out of Racy
Don't get me wrong, I LOVE Puppy Linux. But I'm about to go crazy trying to get a french keyboard to work in Racy. Normally this shouldn't be too hard but try navigating using a keyboard where all the (\|/?.><;)s can't be found.
Could anyone please tell me what files I have to put in what paths so I could at least type setxkbmap fr.
Thanks
ccaaee
No french keyboard in Racy
The version of xkbcomp in Racy 5.2.2 has trouble interpreting the symbols file for the fr layout. This confuses it and causes it to give a misleading error message:
I suspect that it is not the fault of the pc/fr file, since it hasn't changed since earlier Puppies, where it worked fine with an older version of xkbcomp. This is probably a bug in xkbcomp.
Eventually I determined that xkbcomp is unhappy with only a single character in the pc/fr file. That character is buried in a long comment which describes the "latin9" variant, specifically in a table illustrating the layout. (One would not expect that a utility would choke on something buried in a comment, and yet it does. This increases my belief that xkbcomp itself is the culprit.)
I've tried the latest version of xkbcomp (1.2.3), but it chokes as well.
So, until that gets fixed (if it is indeed the culprit), I have removed the character from the pc/fr symbol file (and added a note explaining what character belongs in the hole I left behind, without using the character itself). Remember, this is in a comment, so does not affect the actual data in the file.
I have attached the revised file. Simply gunzip it and copy it to the /etc/X11/xkb/symbols/pc/ directory. Then try again to change your layout.
Please let me know if this works for you.
I will look into this further. It is remotely possible the standard format for symbol files has been revised, and our pc/fr file is no longer compliant. In which case xkbcomp would be innocent. But I strongly doubt that.
By the way, I've grepped the xkb tree and found no other data files using the character in question (which is ÿ (Unicode point: U+00FF, Unicode name: LATIN SMALL LETTER Y WITH DIAERESIS)). So this problem should not come back to haunt us in other layouts.
Actually, the pc/latin file is fine. It turned out to be the pc/fr file that was confusing things./usr/X11R7/bin/xkbcomp wrote:syntax error: line 1 of pc/latin
last scanned symbol is: abovedot
Error: Error interpreting include file "pc/latin"
Exiting
Abandoning symbols file "basic"
Abandoning symbols file "(null)"
I suspect that it is not the fault of the pc/fr file, since it hasn't changed since earlier Puppies, where it worked fine with an older version of xkbcomp. This is probably a bug in xkbcomp.
Eventually I determined that xkbcomp is unhappy with only a single character in the pc/fr file. That character is buried in a long comment which describes the "latin9" variant, specifically in a table illustrating the layout. (One would not expect that a utility would choke on something buried in a comment, and yet it does. This increases my belief that xkbcomp itself is the culprit.)
I've tried the latest version of xkbcomp (1.2.3), but it chokes as well.
So, until that gets fixed (if it is indeed the culprit), I have removed the character from the pc/fr symbol file (and added a note explaining what character belongs in the hole I left behind, without using the character itself). Remember, this is in a comment, so does not affect the actual data in the file.
I have attached the revised file. Simply gunzip it and copy it to the /etc/X11/xkb/symbols/pc/ directory. Then try again to change your layout.
Please let me know if this works for you.
I will look into this further. It is remotely possible the standard format for symbol files has been revised, and our pc/fr file is no longer compliant. In which case xkbcomp would be innocent. But I strongly doubt that.
By the way, I've grepped the xkb tree and found no other data files using the character in question (which is ÿ (Unicode point: U+00FF, Unicode name: LATIN SMALL LETTER Y WITH DIAERESIS)). So this problem should not come back to haunt us in other layouts.
- Attachments
-
- fr.gz
- Revised /etc/X11/xkb/symbols/pc/fr
- (4.64 KiB) Downloaded 445 times
I made some time to look into this further.
This problem does, in fact, result from a bug in xkbcomp.
The good news is that somebody already wrote a patch to fix this.
The bad news is that the patch was never applied.
In June of 2010, somebody made some modifications to xkbscan.c, part of the source for xkbcomp. He decided to "Use fread() instead of getc()". While that was a good idea, he inadvertently introduced this bug.
Apparently the function he wrote that used fread() used an array of chars for the buffer, and returned one char from that buffer. The problem was that the char 0xff equates to -1, which is also used to indicate end of file, so this confused the caller. (The function he replaced, getc() returns an integer, and since int 0xff equates to 256, the caller could distinguish it from EOF.)
OK, I've probably given more detail than necessary here already, but if curious you can see the discussion at: http://patchwork.freedesktop.org/patch/3671/
There was some discussion about reverting the changes that caused this bug, instead of keeping them and applying the patch. Perhaps they never decided which to do, and so did neither.
I have tried the latest xkbcomp (xkbcomp 1.2.3, dated 2011-06-24) which I found in the package x11-xkb-utils (7.6+4). This version still fails.
And the current source code for xkbscan.c at cgit.freedesktop.org (dated 2011-12-29) has not had the patch applied.
I have written to Matthieu Herrb, who reviewed the patch back in January 2011, to alert him to this. Perhaps he will finally get this fixed.
In the meantime, the modified symbol file (fr) that I posted earlier should solve the immediate problem.
This problem does, in fact, result from a bug in xkbcomp.
The good news is that somebody already wrote a patch to fix this.
The bad news is that the patch was never applied.
In June of 2010, somebody made some modifications to xkbscan.c, part of the source for xkbcomp. He decided to "Use fread() instead of getc()". While that was a good idea, he inadvertently introduced this bug.
Apparently the function he wrote that used fread() used an array of chars for the buffer, and returned one char from that buffer. The problem was that the char 0xff equates to -1, which is also used to indicate end of file, so this confused the caller. (The function he replaced, getc() returns an integer, and since int 0xff equates to 256, the caller could distinguish it from EOF.)
OK, I've probably given more detail than necessary here already, but if curious you can see the discussion at: http://patchwork.freedesktop.org/patch/3671/
There was some discussion about reverting the changes that caused this bug, instead of keeping them and applying the patch. Perhaps they never decided which to do, and so did neither.
I have tried the latest xkbcomp (xkbcomp 1.2.3, dated 2011-06-24) which I found in the package x11-xkb-utils (7.6+4). This version still fails.
And the current source code for xkbscan.c at cgit.freedesktop.org (dated 2011-12-29) has not had the patch applied.
I have written to Matthieu Herrb, who reviewed the patch back in January 2011, to alert him to this. Perhaps he will finally get this fixed.
In the meantime, the modified symbol file (fr) that I posted earlier should solve the immediate problem.
- esmourguit
- Posts: 1410
- Joined: Fri 17 Nov 2006, 14:45
- Location: Entre l'ile aux oiseaux.et l'ile de sainte Lucie
Bonjour à tous,
A big thank you npierce, I could get the French keyboard. BK has posted a package see his blog
Cordialement,
A big thank you npierce, I could get the French keyboard. BK has posted a package see his blog
Cordialement,
[url=http://moulinier.net/][color=blue][b]Toutou Linux[/b][/color][/url] - [url=http://toutoulinux.free.fr/pet.php][color=blue][b]Paquets français[/b][/color][/url]
Oui mais, quand un français charge la distro
The problem is still here. Why hav'nt you corrected the ISO in your repositery ? This morning I decided to trash it as soon i have to burn a new one.
Further more the distro does not bring lot of improvment. Tonight, i shall repair it with french keyboard, it gives it a chance to survive.
Racy 5.3.3 is very safe, no problem, but i like some fantasy time to time.
Dom Pelo de Franciano, no ! trash !
Further more the distro does not bring lot of improvment. Tonight, i shall repair it with french keyboard, it gives it a chance to survive.
Racy 5.3.3 is very safe, no problem, but i like some fantasy time to time.
Dom Pelo de Franciano, no ! trash !
Puppy customers are not only british or their cousins
pourriez-vous sortir une distro avec un clavier en ou us ne fonctionnant pas ?
Do you imagine releasing a new puppy with us keyboard not working ? NO ? Some puppies still release without fr keyboard. People dont test before ? (on major languages). Are puppies for the poor people with old computers or for very clever students speaking english and computing very well ?
I love Puppies, nevertheless.
Do you imagine releasing a new puppy with us keyboard not working ? NO ? Some puppies still release without fr keyboard. People dont test before ? (on major languages). Are puppies for the poor people with old computers or for very clever students speaking english and computing very well ?
I love Puppies, nevertheless.
- Attachments
-
- Japy.jpg
- Japy For Puppy
- (23.22 KiB) Downloaded 45 times
-
- Japy.jpg
- Japy For Puppy
- (23.22 KiB) Downloaded 45 times
Last edited by Pelo on Wed 25 Jan 2017, 11:04, edited 2 times in total.
Racy works well now.
But tell it to Macpup (529 issue) to verify keymaps. Thanks for coop. Merci beaucoup.