Qs about /usr/openwin/etc/keytables/*.kt.Z

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Erlend Legange » Sun, 30 Nov 2003 07:27:45



These files seems to contain keyboard layouts. Does anyone know how to use
them, for instance to load a new keyboard layout after logging in to CDE?

- Erlend Leganger

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Alan Coopersmit » Mon, 01 Dec 2003 02:14:31



|These files seems to contain keyboard layouts. Does anyone know how to use
|them, for instance to load a new keyboard layout after logging in to CDE?

They are read by the X server at startup time only - you can't reload a
different one after logging in.  On sparc, it chooses the layout by
mapping the keyboard layout reported by the keyboard using the mapping
in the keytable.map file - if you wanted to permanently change the
keyboard layout, you'ld have to edit that file to make it load a
different one.

--
________________________________________________________________________


  Working for, but definitely not speaking for, Sun Microsystems, Inc.

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Thomas Tornblo » Mon, 01 Dec 2003 05:07:12




> |These files seems to contain keyboard layouts. Does anyone know how to use
> |them, for instance to load a new keyboard layout after logging in to CDE?

> They are read by the X server at startup time only - you can't reload a
> different one after logging in.  On sparc, it chooses the layout by
> mapping the keyboard layout reported by the keyboard using the mapping
> in the keytable.map file - if you wanted to permanently change the
> keyboard layout, you'ld have to edit that file to make it load a
> different one.

I believe you can have a per user "$HOME/.keytable" that is read when
you start X. This was the way I fixed the broken PC-style keyboard
layout I had on the Sparcbook I had many years ago.

A snippet from /usr/openwin/etc/keytables/US5.kt:
---
# You should probably start with a copy of an existing keytable and
# replace the existing scancodes with your new scancodes.  Then,
# incrementally modify entries as needed.  To test a new keytable,
# copy it to $HOME/.keytable and start Xsun.
---

> --
> ________________________________________________________________________


>   Working for, but definitely not speaking for, Sun Microsystems, Inc.

Thomas
 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Alan Coopersmit » Mon, 01 Dec 2003 17:57:11



|

|> |These files seems to contain keyboard layouts. Does anyone know how to use
|> |them, for instance to load a new keyboard layout after logging in to CDE?
|>
|> They are read by the X server at startup time only - you can't reload a
|> different one after logging in.  On sparc, it chooses the layout by
|> mapping the keyboard layout reported by the keyboard using the mapping
|> in the keytable.map file - if you wanted to permanently change the
|> keyboard layout, you'ld have to edit that file to make it load a
|> different one.
|
|I believe you can have a per user "$HOME/.keytable" that is read when
|you start X. This was the way I fixed the broken PC-style keyboard
|layout I had on the Sparcbook I had many years ago.

Right.  I knew there was something I was forgetting.  It's still startup
time only though (which means I don't think it will work with dtlogin,
but only with xinit/openwin).   Of course, my brain's been on vacation
for a week, so don't hold me to it...

--
________________________________________________________________________


  Working for, but definitely not speaking for, Sun Microsystems, Inc.

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Erlend Legange » Wed, 03 Dec 2003 05:10:22





> > |These files seems to contain keyboard layouts. Does anyone know how to
use
> > |them, for instance to load a new keyboard layout after logging in to
CDE?

> > They are read by the X server at startup time only - you can't reload a
> > different one after logging in.  On sparc, it chooses the layout by
> > mapping the keyboard layout reported by the keyboard using the mapping
> > in the keytable.map file - if you wanted to permanently change the
> > keyboard layout, you'ld have to edit that file to make it load a
> > different one.

> I believe you can have a per user "$HOME/.keytable" that is read when
> you start X. This was the way I fixed the broken PC-style keyboard
> layout I had on the Sparcbook I had many years ago.

I tried this:
cd; cp /usr/openwin/etc/keytables/Norway4.kt.Z .
uncompress Norway4.kt.Z
cp Norway4.kt .keytable

I then logged out and in again, once in CDE, once in OpenLook. No change
found in the keyboard layout, it still used the US layout (which it
physically has). I tried this on a NatureTech GenialStation, a 500MHz SPARC
notebook with Solaris 8 02/02. What am I doing wrong?

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Alan Coopersmit » Thu, 04 Dec 2003 02:58:00



|I then logged out and in again, once in CDE, once in OpenLook. No change
|found in the keyboard layout, it still used the US layout (which it
|physically has). I tried this on a NatureTech GenialStation, a 500MHz SPARC
|notebook with Solaris 8 02/02. What am I doing wrong?

As I noted in my previous post, this file is read when Xsun starts,
which if you're using the dtlogin login screen, is before it knows
who the user is.  You might get it to work if you put it into
/.keytable since dtlogin starts Xsun as root, but I haven't tried
that.

--
________________________________________________________________________


  Working for, but definitely not speaking for, Sun Microsystems, Inc.

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Erlend Legange » Fri, 05 Dec 2003 06:06:24



Quote:> As I noted in my previous post, this file is read when Xsun starts,
> which if you're using the dtlogin login screen, is before it knows
> who the user is.  You might get it to work if you put it into
> /.keytable since dtlogin starts Xsun as root, but I haven't tried
> that.

I tried your suggestion, but to no avail, Xsun doesn't seem to pick up my
.keytable file.

I then tried a different approach. The file
/usr/openwin/etc/keytables/keytable.map determines which keytable to use,
given the keyboard type and keyboard layout. For example, 0,0 gives US4.kt,
4,4 gives Denmark4.kt etc. Since I dont know which keyboard type and layout
my keyboard returns, I just replaced all of the *.kt with Norway6.kt, ie,
regardless of the type and layout, Norway6.kt would be used. That did the
trick, the keyboard now behaved as a real Norwegian keyboard, even giving me
the \oslash and \aring on the command line. (BTW, I tried Norway4.kt and
Norway5.kt first, they were really bad, only the number keys seemed to
work.)

This is a crude method, but it works. I would like to find out which type
and layout my keyboard returns and then only update that one line in
keytable.map, that will be the subject of another posting to this group.

Thanks for your tips.

- Erlend Leganger

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Richard L. Hamilt » Fri, 05 Dec 2003 21:35:58






>> As I noted in my previous post, this file is read when Xsun starts,
>> which if you're using the dtlogin login screen, is before it knows
>> who the user is.  You might get it to work if you put it into
>> /.keytable since dtlogin starts Xsun as root, but I haven't tried
>> that.

> I tried your suggestion, but to no avail, Xsun doesn't seem to pick up my
> .keytable file.

> I then tried a different approach. The file
> /usr/openwin/etc/keytables/keytable.map determines which keytable to use,
> given the keyboard type and keyboard layout. For example, 0,0 gives US4.kt,
> 4,4 gives Denmark4.kt etc. Since I dont know which keyboard type and layout
> my keyboard returns, I just replaced all of the *.kt with Norway6.kt, ie,
> regardless of the type and layout, Norway6.kt would be used. That did the
> trick, the keyboard now behaved as a real Norwegian keyboard, even giving me
> the \oslash and \aring on the command line. (BTW, I tried Norway4.kt and
> Norway5.kt first, they were really bad, only the number keys seemed to
> work.)

> This is a crude method, but it works. I would like to find out which type
> and layout my keyboard returns and then only update that one line in
> keytable.map, that will be the subject of another posting to this group.

Compile the following and run it - that should tell you the keyboard type
number and layout number.  For example, on mine (Sun Blade 100, Type 6
(USB) US Unix keyboard), with X-windows running, the output looks like:

translation mode: TR_UNTRANS_EVENT
keyboard type: KB_USB 6
keyboard layout: 33
compatibility mode: on
key table file: US6.kt

(it looked up the line in keytable.map with type 6, layout 33, to find the
key table file)

============================== cut here ==============================
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <errno.h>
#include <strings.h>
#include <sys/kbd.h>
#include <sys/kbio.h>
#define KEYBOARD "/dev/kbd"
struct valtab
  {
    char *name;
    int value;
  };

struct valtab translations[] =
{
  {"TR_NONE", TR_NONE},
  {"TR_ASCII", TR_ASCII},
  {"TR_EVENT", TR_EVENT},
  {"TR_UNTRANS_EVENT", TR_UNTRANS_EVENT}

Quote:};

struct valtab kbdtypes[] =
{
  {"KB_KLUNK", KB_KLUNK},
  {"KB_VT100", KB_VT100},
  {"KB_SUN2", KB_SUN2},
  {"KB_VT220", KB_VT220},
  {"KB_VT220I", KB_VT220I},
  {"KB_SUN3", KB_SUN3},
  {"KB_SUN4", KB_SUN4},
#ifdef KB_SUN5U
  {"KB_SUN5U", KB_SUN5U},
#endif
  {"KB_PC", KB_PC},
  {"KB_ASCII", KB_ASCII},
#ifdef KB_USB
  {"KB_USB", KB_USB},
#endif

Quote:};

struct valtab on_off[] =
{
  {"on", 1},
  {"off", 0}

Quote:};

#define nelem(array) ((sizeof(array))/(sizeof(array[0])))

const char *
lookup_value (const struct valtab *v,
              int nents, int val, const char *unknown_name)
{
  register int x;

  for (x = 0; x < nents; x++, v++)
    if (v->value == val)
      return v->name;

  return unknown_name;

Quote:}

char *
errmsg ()
{
  static char buf[256];
  register char *msg;

  if ((msg = strerror (errno)) == NULL)
    sprintf (msg = buf, "unknown error, errno=%d", errno);
  return msg;

Quote:}

#define KEYTABLE_INDEX_FILE "/usr/openwin/etc/keytables/keytable.map"
char *
keytable (int type, int layout)
{
  FILE *fp;
  static char buf[BUFSIZ];

  if ((fp = fopen (KEYTABLE_INDEX_FILE, "r")) == NULL)
    return NULL;

  while (fgets (buf, sizeof buf, fp) != NULL)
    {
      static const char delims[] = " \t\n";
      int t, l;
      char *ts, *ls, *n;
      if (*buf == '#' || *buf == '\n')
        continue;
      if ((ts = strtok (buf, delims)) == NULL || atoi (ts) != type)
        continue;
      if ((ls = strtok (NULL, delims)) == NULL || atoi (ls) != layout)
        continue;
      if ((n = strtok (NULL, delims)) != NULL)
        return n;
      else
        return NULL;
    }
  return NULL;

Quote:}

int
main (int argc, char **argv)
{
  auto char *p, *keyboard, *file;
  auto int fd, trans, type, layout, compat, leds /* maybe later ... */ ;

  if (argc < 2)
    keyboard = KEYBOARD;
  else if (argc == 2)
    keyboard = argv[optind];
  else
    {
      fprintf (stderr, "usage: %s [kbd_dev]\n", argv[0]);
      return 2;
    }

  if ((fd = open (keyboard, O_RDWR)) == -1)
    {
      perror (keyboard);
      return 3;
    }

  if (ioctl (fd, KIOCGTRANS, &trans) == -1)
    fprintf (stderr, "%s: %s: KIOCGTRANS ioctl failed: %s\n", argv[0], keyboard,
             errmsg ());
  else
    printf ("translation mode: %s\n",
     lookup_value (translations, nelem (translations), trans, "(unknown)"));

  if (ioctl (fd, KIOCTYPE, &type) == -1)
    fprintf (stderr, "%s: %s: KIOCTYPE ioctl failed: %s\n", argv[0], keyboard,
             errmsg ());
  else
    printf ("keyboard type: %s %d\n",
            lookup_value (kbdtypes, nelem (kbdtypes), type, "(unknown)"),type);

  if (ioctl (fd, KIOCLAYOUT, &layout) == -1)
    fprintf (stderr, "%s: %s: KIOCLAYOUT ioctl failed: %s\n", argv[0], keyboard,
             errmsg ());
  else
    printf ("keyboard layout: %d\n", layout);

  if (ioctl (fd, KIOCGCOMPAT, &compat) == -1)
    fprintf (stderr, "%s: %s: KIOCGCOMPAT ioctl failed: %s\n", argv[0], keyboard,
             errmsg ());
  else
    printf ("compatibility mode: %s\n",
            lookup_value (on_off, nelem (on_off), compat, "(unknown)"));

  if ((file = keytable (type, layout)) != NULL)
    printf ("key table file: %s\n", file);

  close (fd);
  return 0;

Quote:}

============================== cut here ==============================

--

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Erlend Legange » Sat, 06 Dec 2003 05:59:31



message

Quote:> Compile the following and run it - that should tell you the keyboard type
> number and layout number.  For example, on mine (Sun Blade 100, Type 6
> (USB) US Unix keyboard), with X-windows running, the output looks like:

> translation mode: TR_UNTRANS_EVENT
> keyboard type: KB_USB 6
> keyboard layout: 33
> compatibility mode: on
> key table file: US6.kt

> (it looked up the line in keytable.map with type 6, layout 33, to find the
> key table file)

I'm truly impressed, your code compiled without a hitch and gave me the
following for my NatureTech GenialStation:
translation mode: TR_UNTRANS_EVENT
keyboard type: KB_USB 6
keyboard layout: 0
compatibility mode: on
key table file: US6.kt
Thanks for taking the time to provide me with this tool, I will certainly
make use of it.

- Erlend Leganger

 
 
 

Qs about /usr/openwin/etc/keytables/*.kt.Z

Post by Richard L. Hamilt » Sat, 06 Dec 2003 06:33:15





> message
>> Compile the following and run it - that should tell you the keyboard type
>> number and layout number.  For example, on mine (Sun Blade 100, Type 6
>> (USB) US Unix keyboard), with X-windows running, the output looks like:

>> translation mode: TR_UNTRANS_EVENT
>> keyboard type: KB_USB 6
>> keyboard layout: 33
>> compatibility mode: on
>> key table file: US6.kt

>> (it looked up the line in keytable.map with type 6, layout 33, to find the
>> key table file)

> I'm truly impressed, your code compiled without a hitch and gave me the
> following for my NatureTech GenialStation:
> translation mode: TR_UNTRANS_EVENT
> keyboard type: KB_USB 6
> keyboard layout: 0
> compatibility mode: on
> key table file: US6.kt
> Thanks for taking the time to provide me with this tool, I will certainly
> make use of it.

No problem, already had it; I just added the numeric to the existing
symbolic output of the keyboard type, so you wouldn't have to look it
up in sys/kbd.h.

--

 
 
 

1. How to use /usr/openwin/etc/keytables/Norway4.kt.Z ?

I have a Norwegain layout PC keyboard connected to several Sun consoles via
a KVM-switch. During reboot, the Solaris machines do not recognise the
keyboard and load US keyboard layout by default. This makes life hard when
working at the console, many of the keys I need are not in the expected
location (*;:|[]{} etc).

I figured out how to change the layout on the command line (ie without CDE
running) using loadkeys /usr/share/lib/keytables/norway.

In CDE, I know that you can use xmodmap to change a key here and there, but
I would like to change the whole layout at one go, much like loadkeys work.
I have found some files in /usr/openwin (eg
/usr/openwin/etc/keytables/Norway4.kt.Z ) which seems promising, how can I
use these files to modify my keyboard?

- Erlend Leganger

2. Compaq Deskpro (EISA): 16MB Limit?

3. load the /usr/share/lib/keytables/swiss_german

4. apache and msql and HTTP_AUTHORIZATION

5. Wanted: /usr/openwin/lib/sparcv9/libxil.so

6. Gateway 386DX25 - what would you pay?

7. Building X11R6.6 Xserver which links to /usr/openwin/server/lib/libfont.so.1

8. EVENT: Linux Users' Group of Davis, September 5 - More Perl

9. sdtfontls /usr/openwin/lib/X11/fonts/TrueType segfaults and dumps core

10. /usr/openwin/bin/xview/xview/xview...ad infinitum

11. how to /usr/openwin/lib/config/site.def up for gcc

12. llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll

13. "Exception Occurred" installling RedHat 6.2 /usr/lib/anaconda/todo.py........etc