The Dvorak keyboard doesn't work in the console on Puppy Quirky 1.3, Wary .96 or .98. I've tried dvorak, dvorak l, and dvorak r- the results are the same: The key-mapping is correct in the xserver(including xterms.) In the console, the mapping isn't dvorak or qwerty. It seems almost random(although it is the same on every boot.) I have figured out how to type xwin, all four letters are on the bottom row.
Edit-This is true on the live CD with 'puppy pfix=ram' and a frugal install.
Wary/Quirky Dvorak keyboard not working.
How are the keymaps in /lib/keymaps generated? I can see the faulty dvorak map in /lib/keymaps/dvorak.gz if I gunzip it and look at the result with a hex editor.
/lib/keymaps does not seem to be persistent between boots. I can see it in my save file(booted with pfix=ram,) but if I copy us.gz to dvorak.gz for example, the original will be restored as far a puppy is concerned after a shutdown and reboot.
/etc/codepage is empty(0 bytes.) Should it be empty?
It appears as though I should be able to get a working dvorak keyboard if I hexedit the correct map into /lib/keymaps/dvorak.gz and remaster, but obviously this isn't the correct way to do it.
I have decided on a compromise I can live with: copying /etc/X11/xkb/symbols/dvorak to /etc/X11/xkb/symbols/pc/us then choosing the us keyboard in the Mouse/Keyboard Wizard gives me a working dvorak keyboard for X11 apps(incl. xterms) and a working qwerty keyboard in the text console. This is not a big deal for me as I usually have the xserver running anyway(plus I can touch type qwerty for when I need a text console.)
/lib/keymaps does not seem to be persistent between boots. I can see it in my save file(booted with pfix=ram,) but if I copy us.gz to dvorak.gz for example, the original will be restored as far a puppy is concerned after a shutdown and reboot.
/etc/codepage is empty(0 bytes.) Should it be empty?
It appears as though I should be able to get a working dvorak keyboard if I hexedit the correct map into /lib/keymaps/dvorak.gz and remaster, but obviously this isn't the correct way to do it.
I have decided on a compromise I can live with: copying /etc/X11/xkb/symbols/dvorak to /etc/X11/xkb/symbols/pc/us then choosing the us keyboard in the Mouse/Keyboard Wizard gives me a working dvorak keyboard for X11 apps(incl. xterms) and a working qwerty keyboard in the text console. This is not a big deal for me as I usually have the xserver running anyway(plus I can touch type qwerty for when I need a text console.)
I have had Wary 098 and just installed (full install) Wary 102 and the Dvorak keyboard setup worked on both without any issues at all. Very odd
Regards Dennis.
OOPS I see what you mean.Exit to prompt and disaster. I dont know what keymap it is but I have a Switchable Dvorak keyboard and it did not work in either position.
Takes a while to work out where xorgwizard letters are.
Above me I am afraid. D
Regards Dennis.
OOPS I see what you mean.Exit to prompt and disaster. I dont know what keymap it is but I have a Switchable Dvorak keyboard and it did not work in either position.
Takes a while to work out where xorgwizard letters are.
Above me I am afraid. D
With one exception, the binary keytable files in /lib/keymaps/ are gzipped versions of a subset of the keytables from the kmap-1.14.1.pet, which was posted by ecube here:
http://murga-linux.com/puppy/viewtopic.php?t=40658
(The exception is se.gz, which contains the same binary Swedish keytable that has been in Puppies forever.) The keytables in that .pet were keytables that had been converted to binary by someone at Tiny Core Linux. Unfortunately, the dvorak-r.map, which was converted to the dvorak-r.kmap file, was apparently also converted to the dvorak.kmap file. So, when you select dvorak, you are getting a dvorak-r keytable (a one-handed keyboard layout for the right hand), which explains the strange placement that you are seeing.
I am attaching a dvorak binary keytable, converted from the dvorak.map file in kbd-1.15.2.tar.gz, downloaded from http://www.kernel.org/pub/linux/utils/kbd/
If you place the attached file in /lib/keymaps/ you should be able to get a proper dvorak layout in the text console by going to the text console and executing this command:
The /lib/keymaps/ directory originates from the initrd.gz file, so in order to use the new dvorak.gz when you reboot, you will need to rebuild initrd.gz with the new file in it.
Although the above should take care of the problem with dvorak.gz, looking into this uncovered problems with other keytable files.
Tiny Core has a newer package of .kmap files in which they have corrected dvorak.kmap. I had considered suggesting that perhaps it would be a good idea to use this newer package in Woof. But when I took a good close look at the package I saw that doing so would not be a good idea.
Opening that package was like opening a can of worms. Apparently someone wrote a script for doing the conversion, and that script boldly converted anything thrown at it (whether or not it was an actual .map file), and plunged ahead despite any error messages it ran into. While many of the resulting .kmap files are functional, few of them actually match the .map files that they were converted from, and some have glaring problems (what good is a Russian keytable with no Cyrillic characters?). Let's say that quality control was not a priority.
Tiny Core's short description of their package is "All keymaps from kbd-1.15.1 converted kmaps", and their longer description is "All keymaps available in kbd-1.15.1 converted to the binary kmap format used in Busybox."
Given those descriptions, one would think that loading one of these binary .kmap files would be equivalent to loading one of the original text .map files from the kbd-1.15.1 package. Often that is not the case because many of the files contain data that differs significantly from the data in the original files.
Here are some of the problems with the kmaps.tcz package from Tiny Core. I list them here as reasons why I am not recommending that Puppy use .kmap files from that package. It can also be considered a list of pitfalls to watch out for when converting .map files to binary .kmap files.
Problems with kmaps.tcz - - -
1. Files missing because of filenames repeated in different directories.
In the kbd-1.15.1 package the .map files are grouped in separate directories according to the keyboard layout. There are four filenames that are used in more than one directory. For instance there is qwerty/cz.map and qwertz/cz.map. When these were converted to .kmap files for the kmaps.tcz package, all .kmap files were written in one directory. So apparently the second of each pair converted overwrote the first. And there is no indication of which version survived without examining the file.
2. Files created from old backup files.
Apparently the directory holding the .map files had a couple of old backup files remaining after editing, for instance the lt-l4.map~ file, and the conversion script didn't filter these out, so the old versions got converted as well, creating, for instance, the lt-l4.map~.kmap file.
3. Files attempted to be created from non-.map files.
The kbd-1.15.1 package has a couple of files in the qwerty directory that are not .map files, hypermap.m4 and no-latin1.doc. The script apparently tried to convert these too, and, of course, failed. Nevertheless, it did create .kmap files which actually are just duplicates of the last .map file that was successfully converted.
4. Files not updated to 1.15.1
Despite the "All keymaps available in kbd-1.15.1 converted to the binary kmap format . . ." description, the file dates indicate that most of the .kmap files are the same as the .kmap files in the old kmaps.tce package, which was supposedly based upon the kbd-1.14.1 package. Many .map files changed between kbd-1.14.1 and kbd-1.15.1, but the corresponding .kmap file was not updated. However, that isn't as much of a problem as one might think. Many of the files that changed had only changes in white space, so had no effect on the resulting .kmap files. And of the twenty-four that did have other changes, only about five .kmap files would have been changed. So not a big a deal as it might have been, but still, that is five more incorrect files than there should have been.
5. Files with maps missing that were in .map file.
When a keytable file (a .map file) is loaded, the keytable in memory contains a number of maps -- one for each combination of modifier keys (one for use when no modifier key is pressed, one for use when Shift is pressed, one for use when AltGr is pressed, one for use when both Shift and AltGr are pressed, etc.). In theory there can be 256 of these maps. In practice there are usually less than a dozen. The .kmap files in kmaps.tcz were apparently converted with the dumpkmap function of busybox. That function creates a file with exactly ten maps, specifically maps 0, 1, 2, 4, 5, 6, 8, 9, 10, and 12. Many of the .map files that were converted had other maps, not in that list. So all information from those maps was lost in the conversion process. For instance, when a keytable contains an alternate alphabet, such as the Cyrillic alphabet, the AltGr key is often the key defined for accessing that alphabet, and the combination of Shift and AltGr are used to change case. Unfortunately, the map required for the Shift and AltGr combination is map 3, which is discarded by the busybox dumpkmap function. So, for instance, for the ru.map file, all information about upper-case Cyrillic characters is lost, so they cannot be entered from the keyboard.
6. Files with extra maps that were not in .map file.
Similarly, some of these .kmap files contain maps that did not come from the original .map file being converted. This is because the loadkeys utility is designed to allow loading maps without disturbing maps that are not defined in the file, and are already loaded in memory. This happens when a .map file contains no map specification line.
In some cases the maps already in memory are there because the user loaded one .map file and then supplemented it with another .map file. In other cases the maps already in memory are just left over from a previous .map file, and serve no purpose. They won't cause a problem if the user never uses the corresponding modifier keys, but could cause a little confusion if he does. At any rate, there is no reason for that extraneous information to be saved in the .kmap file. But it is, unless the person doing the conversion is careful to clear it out before using the dumpkmap function of busybox.
7. Files with maps having extra definitions that were not in the .map file.
This is much like item 6, but refers to entries that were in a map that was defined by the .map file, but had entries within that map that were not defined. Entries from previously loaded .map files will remain. As with item 7, sometimes that is desired; sometimes not.
For instance, the dvorak-r.kmap in keymaps.tcz maps the key beside the left shift key on a European 105-key or 102-key keyboard to í (iacute) and
http://murga-linux.com/puppy/viewtopic.php?t=40658
(The exception is se.gz, which contains the same binary Swedish keytable that has been in Puppies forever.) The keytables in that .pet were keytables that had been converted to binary by someone at Tiny Core Linux. Unfortunately, the dvorak-r.map, which was converted to the dvorak-r.kmap file, was apparently also converted to the dvorak.kmap file. So, when you select dvorak, you are getting a dvorak-r keytable (a one-handed keyboard layout for the right hand), which explains the strange placement that you are seeing.
I am attaching a dvorak binary keytable, converted from the dvorak.map file in kbd-1.15.2.tar.gz, downloaded from http://www.kernel.org/pub/linux/utils/kbd/
If you place the attached file in /lib/keymaps/ you should be able to get a proper dvorak layout in the text console by going to the text console and executing this command:
Code: Select all
zcat /lib/keymaps/dvorak.gz | loadkmapAlthough the above should take care of the problem with dvorak.gz, looking into this uncovered problems with other keytable files.
Tiny Core has a newer package of .kmap files in which they have corrected dvorak.kmap. I had considered suggesting that perhaps it would be a good idea to use this newer package in Woof. But when I took a good close look at the package I saw that doing so would not be a good idea.
Opening that package was like opening a can of worms. Apparently someone wrote a script for doing the conversion, and that script boldly converted anything thrown at it (whether or not it was an actual .map file), and plunged ahead despite any error messages it ran into. While many of the resulting .kmap files are functional, few of them actually match the .map files that they were converted from, and some have glaring problems (what good is a Russian keytable with no Cyrillic characters?). Let's say that quality control was not a priority.
Tiny Core's short description of their package is "All keymaps from kbd-1.15.1 converted kmaps", and their longer description is "All keymaps available in kbd-1.15.1 converted to the binary kmap format used in Busybox."
Given those descriptions, one would think that loading one of these binary .kmap files would be equivalent to loading one of the original text .map files from the kbd-1.15.1 package. Often that is not the case because many of the files contain data that differs significantly from the data in the original files.
Here are some of the problems with the kmaps.tcz package from Tiny Core. I list them here as reasons why I am not recommending that Puppy use .kmap files from that package. It can also be considered a list of pitfalls to watch out for when converting .map files to binary .kmap files.
Problems with kmaps.tcz - - -
1. Files missing because of filenames repeated in different directories.
In the kbd-1.15.1 package the .map files are grouped in separate directories according to the keyboard layout. There are four filenames that are used in more than one directory. For instance there is qwerty/cz.map and qwertz/cz.map. When these were converted to .kmap files for the kmaps.tcz package, all .kmap files were written in one directory. So apparently the second of each pair converted overwrote the first. And there is no indication of which version survived without examining the file.
2. Files created from old backup files.
Apparently the directory holding the .map files had a couple of old backup files remaining after editing, for instance the lt-l4.map~ file, and the conversion script didn't filter these out, so the old versions got converted as well, creating, for instance, the lt-l4.map~.kmap file.
3. Files attempted to be created from non-.map files.
The kbd-1.15.1 package has a couple of files in the qwerty directory that are not .map files, hypermap.m4 and no-latin1.doc. The script apparently tried to convert these too, and, of course, failed. Nevertheless, it did create .kmap files which actually are just duplicates of the last .map file that was successfully converted.
4. Files not updated to 1.15.1
Despite the "All keymaps available in kbd-1.15.1 converted to the binary kmap format . . ." description, the file dates indicate that most of the .kmap files are the same as the .kmap files in the old kmaps.tce package, which was supposedly based upon the kbd-1.14.1 package. Many .map files changed between kbd-1.14.1 and kbd-1.15.1, but the corresponding .kmap file was not updated. However, that isn't as much of a problem as one might think. Many of the files that changed had only changes in white space, so had no effect on the resulting .kmap files. And of the twenty-four that did have other changes, only about five .kmap files would have been changed. So not a big a deal as it might have been, but still, that is five more incorrect files than there should have been.
5. Files with maps missing that were in .map file.
When a keytable file (a .map file) is loaded, the keytable in memory contains a number of maps -- one for each combination of modifier keys (one for use when no modifier key is pressed, one for use when Shift is pressed, one for use when AltGr is pressed, one for use when both Shift and AltGr are pressed, etc.). In theory there can be 256 of these maps. In practice there are usually less than a dozen. The .kmap files in kmaps.tcz were apparently converted with the dumpkmap function of busybox. That function creates a file with exactly ten maps, specifically maps 0, 1, 2, 4, 5, 6, 8, 9, 10, and 12. Many of the .map files that were converted had other maps, not in that list. So all information from those maps was lost in the conversion process. For instance, when a keytable contains an alternate alphabet, such as the Cyrillic alphabet, the AltGr key is often the key defined for accessing that alphabet, and the combination of Shift and AltGr are used to change case. Unfortunately, the map required for the Shift and AltGr combination is map 3, which is discarded by the busybox dumpkmap function. So, for instance, for the ru.map file, all information about upper-case Cyrillic characters is lost, so they cannot be entered from the keyboard.
6. Files with extra maps that were not in .map file.
Similarly, some of these .kmap files contain maps that did not come from the original .map file being converted. This is because the loadkeys utility is designed to allow loading maps without disturbing maps that are not defined in the file, and are already loaded in memory. This happens when a .map file contains no map specification line.
In some cases the maps already in memory are there because the user loaded one .map file and then supplemented it with another .map file. In other cases the maps already in memory are just left over from a previous .map file, and serve no purpose. They won't cause a problem if the user never uses the corresponding modifier keys, but could cause a little confusion if he does. At any rate, there is no reason for that extraneous information to be saved in the .kmap file. But it is, unless the person doing the conversion is careful to clear it out before using the dumpkmap function of busybox.
7. Files with maps having extra definitions that were not in the .map file.
This is much like item 6, but refers to entries that were in a map that was defined by the .map file, but had entries within that map that were not defined. Entries from previously loaded .map files will remain. As with item 7, sometimes that is desired; sometimes not.
For instance, the dvorak-r.kmap in keymaps.tcz maps the key beside the left shift key on a European 105-key or 102-key keyboard to í (iacute) and
- Attachments
-
- dvorak.gz
- Binary keytable converted from dvorak.map in kbd-1.15.2
- (854 Bytes) Downloaded 578 times
That works great. Thank you.npierce wrote: I am attaching a dvorak binary keytable, converted from the dvorak.map file in kbd-1.15.2.tar.gz, downloaded from http://www.kernel.org/pub/linux/utils/kbd/
If you place the attached file in /lib/keymaps/ you should be able to get a proper dvorak layout in the text console by going to the text console and executing this command:The /lib/keymaps/ directory originates from the initrd.gz file, so in order to use the new dvorak.gz when you reboot, you will need to rebuild initrd.gz with the new file in it.Code: Select all
zcat /lib/keymaps/dvorak.gz | loadkmap
You're welcome.
If you need to customize your keytable, I see that the .map files and the loadkeys utility are available for Wary in the repository:
http://distro.ibiblio.org/pub/linux/dis ... .15-w5.pet
It looks like the include files required by many of the .map files seem to be missing from that package. You can find them in the DEV package:
http://distro.ibiblio.org/pub/linux/dis ... .15-w5.pet
I've not tried these packages, since I am using Puppy 4.3.1, which came with loadkeys and the .map files already installed.
If you need to customize your keytable, I see that the .map files and the loadkeys utility are available for Wary in the repository:
http://distro.ibiblio.org/pub/linux/dis ... .15-w5.pet
It looks like the include files required by many of the .map files seem to be missing from that package. You can find them in the DEV package:
http://distro.ibiblio.org/pub/linux/dis ... .15-w5.pet
I've not tried these packages, since I am using Puppy 4.3.1, which came with loadkeys and the .map files already installed.