Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 21 Oct 2014, 01:36
All times are UTC - 4
 Forum index » House Training » Bugs ( Submit bugs )
Wary/Quirky Dvorak keyboard not working.
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [7 Posts]  
Author Message
fluxit


Joined: 24 Jun 2006
Posts: 326
Location: Ketchikan, AK USA

PostPosted: Thu 18 Nov 2010, 23:09    Post subject:  Wary/Quirky Dvorak keyboard not working.
Subject description: Dvorak keymapping not working in console.
 

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.
Back to top
View user's profile Send private message 
fluxit


Joined: 24 Jun 2006
Posts: 326
Location: Ketchikan, AK USA

PostPosted: Sun 12 Dec 2010, 09:53    Post subject:  

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.)
Back to top
View user's profile Send private message 
dalderton

Joined: 22 Apr 2007
Posts: 145

PostPosted: Tue 14 Dec 2010, 00:37    Post subject:  

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
Back to top
View user's profile Send private message 
fluxit


Joined: 24 Jun 2006
Posts: 326
Location: Ketchikan, AK USA

PostPosted: Tue 14 Dec 2010, 09:55    Post subject:  

Thank you for the testing and confirmation.

I wasn't sure that there was anyone else using a dvorak keyboard who reads the forum, due to the apparent lack of interest.
Back to top
View user's profile Send private message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Tue 14 Dec 2010, 12:28    Post subject:  

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:
Code:
zcat /lib/keymaps/dvorak.gz | loadkmap

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 Í (Iacute), like it is for the qwertz/hu.map and qwerty/hu101.map keytable. However, dvorak-r.map doesn't map that key. So apparently qwertz/hu.map or qwerty/hu101.map was loaded sometime before dvorak-r.map.


8. Files with Unicode symbols replaced by VoidSymbol.

Some of the .map files that were converted had Unicode values in them. These files were apparently converted when the keyboard was not in Unicode mode, so loadkeys attempted to convert the Unicode values to the values used with a legacy 8-bit character set. If the .map file has a line in it which specifies the name of the 8-bit character set, this usually works. But Unicode .map files often omit that line either because it contains symbols from more than one 8-bit character set, or because the author never thought that the file would be used when not in Unicode mode. Some Unicode values will be successfully converted anyway because loadkeys searches for the symbol in the latin1, latin2, latin3, latin4, and iso-8859-15 character sets. But if the symbol is not in one of those sets, the conversion fails and a VoidSymbol is used in its place. This results in, for example, a Russian .kmap file (ru.kmap) that doesn't support Cyrillic characters.


9. Files created from incomplete keytables.

Not all of the .map files contain complete keytables. Some are meant to be supplemental, and are intended to be loaded after loading another .map file. The supplemental .map file will add a number of other keys.

For instance, using the keytable loaded from se-latin6.map file, oslash can be entered without the need to press a modifier key, but odiaeresis requires the AltGr key to be pressed. The se-fi-latin6.map file is used to modify that keytable to make oslash the character requiring the AltGr key, and vice versa.

Using the loadkmap function of busybox, however, overwrites all entries in each of the maps contained in the .kmap file. So one cannot use that function to load supplemental keytables unless all keys in each of the maps in the supplemental keytable are defined, which is not usually the case.

So, creating a .kmap from, for instance, se-fi-latin6.map, is pointless. If, for instance, a .kmap was created that matched se-fi-latin6.map, loading it with loadkmap would allow the user to type exactly eight characters. This would probably not be a particularly useful keytable, and would likely result in the user reaching in frustration for the power button.

It is possible, of course, to load se-latin6.map, then load se-fi-latin6.map on top of it, as intended, and then save the resulting keytable as a .kmap. That would be useful, although a new base filename should probably be given to it to avoid confusion with the original supplemental-only file.

The actual se-fi-latin6.kmap contained in kmaps.tcz does have more than the eight characters defined for se-fi-latin6.map. This is because it contains the remains of previously loaded .map files, as discussed previously. If the previously loaded .map file had been se-latin6.map, a useful file would have been created, as described in the previous paragraph. Unfortunately that was not the case; the previously loaded .map file was something else.


10. File missing.

The colemak/en-latin9.map was not converted to en-latin9.kmap. There is a file named colemak.kmap which might or might not be equivalent.



While the above list of problems applies to the kmaps.tcz package, some of the items in the list also apply to the files currently available in Woof, which came from the old kmaps.tce package. Those would be items 5, 6, 7, and 8.

As an alternative to using the .kmap files from those packages, I would suggest converting .map files using loadkeys -bq. The -b option is available in the current version of loadkeys from the kbd-1.15.2 package. That utility converts directly from the .map files, and so doesn't include old data leftover in memory from previously loaded keytables, such as maps that are not part of the new keytable, or entries that were not defined by the new keytable in maps that are used by it (items 6 and 7 in the above list. It also converts all maps, not just the ten maps that busybox converts, so you don't loose stuff like the ability to use Shift+AltGr (item 5 in the above list).

To eliminate the problem of item 8, one should ensure that the keyboard is in Unicode mode before attempting to convert .map files containing non-latin Unicode characters. This, of course, will result in a Unicode .kmap file. If a non-Unicode version of such a .map file is desired, it may be necessary to study the .map file and add an appropriate charset specification to it.

Item 9 can only be eliminated by actually looking at the .map file to see if it is complete, or intended to supplement another .map file, and then simply not making the attempt to convert it if the latter is true. Because of the format of the binary .kmap files, all entries are defined (even though the definition of some entries is VoidSymbol). This is different from a text .map file where some entries can simply be left undefined, which is necessary for a supplemental keytable to work. If desired, a new .map file can be created that simply contains "include" lines to include both the desired complete .map file and the supplemental .map file. Then that file can be converted. This would create an keytable equivalent to using loadkeys to load both .map files.

Clearly, converting .map files to .kmap files could be time-consuming, and not easily done by writing a simple script. But doing so would be an improvement on using the existing .kmap files from the packages at Tiny Core.
dvorak.gz
Description  Binary keytable converted from dvorak.map in kbd-1.15.2
gz

 Download 
Filename  dvorak.gz 
Filesize  854 Bytes 
Downloaded  375 Time(s) 
Back to top
View user's profile Send private message 
fluxit


Joined: 24 Jun 2006
Posts: 326
Location: Ketchikan, AK USA

PostPosted: Tue 14 Dec 2010, 13:37    Post subject:  

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:
Code:
zcat /lib/keymaps/dvorak.gz | loadkmap

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.


That works great. Thank you.
Back to top
View user's profile Send private message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Tue 14 Dec 2010, 19:45    Post subject:  

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/distributions/quirky/pet_packages-wary5/kbd-1.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/distributions/quirky/pet_packages-wary5/kbd_DEV-1.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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [7 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » House Training » Bugs ( Submit bugs )
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0960s ][ Queries: 12 (0.0029s) ][ GZIP on ]