[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference unxa::cde

Title:CDE on Digital UNIXonment - CDE
Notice:CDE on Digital UNIX - for CDE on VMS, please see Note 1.3
Moderator:UNXA::SYSTEM
Created:Tue Nov 23 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:660
Total number of notes:2674

556.0. "AltGR not working within dtlogin box, PCXAL keyboard" by SWTHOM::TISSERAND (Jean-Marc Tisserand, French CSC, 858-6801) Wed Nov 20 1996 08:13

T.RTitleUserPersonal
Name
DateLines
556.1SWTHOM::TISSERANDJean-Marc Tisserand, French CSC, 858-6801Wed Nov 20 1996 09:5612
556.2Dtlogin*preeditType in Xresources is the culpritSMURF::WOODBURNWed Nov 20 1996 14:4832
556.3SWTHOM::TISSERANDJean-Marc Tisserand, French CSC, 858-6801Thu Nov 21 1996 08:0212
556.4expected behaviorSMURF::WOODBURNThu Nov 21 1996 12:0933
556.5Thanks Tom, your second interpretation was correct.SWTHOM::TISSERANDJean-Marc Tisserand, French CSC, 858-6801Thu Nov 28 1996 04:580
556.6workaround: disable xkbSMURF::WOODBURNFri Feb 07 1997 11:42204
	Jean-Marc,

	I apologize, I gave you the wrong answer about why you can't
	enter AltGR characters in the CDE login window.  The culprit
	is not the mode switch disabling code I added.  That only
	disables lock-down mode switches, and AltGR is a different
	type of mode switch.  A lock-down  mode switch is analogous to
	the CapsLock key, while AltGR is analogous to the Shift key.

	The real reason AltGR does not work in the CDE login window
	is because of XKB, a keyboard extension that was added to the
	X server in V4.0.  When you disable XKB by adding -kb to the
	server command-line arguments in /var/X11/Xserver.conf, AltGR
	works fine.

	The specific problem is that AltGR stops working when XKB
	is enabled and the keyboard is grabbed.  The CDE login window
	grabs the keyboard to prevent someone from snooping the
	password, so that is why you see the problem there.  Several
	other applications do too (xterm with its secure mode, xdm,
	etc.), so the problem can show up in other places as well.

	I've attached the QAR I entered on the XKB problem.
	Realistically, I don't know if it will be fixed because our
	XKB expert is now working at Sun and the workstation area in
	general has been cut back in favor of servers.

	But the -kb option is a good workaround.  If you use it,
	dxkeyboard and xmodmap will still work fine.

	Again, I apologize for not digging deeper the first time
	around.

	Tom

------------- Begin Forwarded Message -------------

QAR # St Sev Pub Cat Maintainer   Component  T Entered-by   Date in     Answer
----- -- --- --- --- ------------ ---------- - ------------ ----------- ------
51402 OP  M  No      QAR$ASSIGNER            M WOODBURN      6-FEB-1997
<no abstract available>

Site name:        35G
Product/Version:  DEC OSF/1  PLA12386           CPU type:  DEC/3000-4
Op Syst/Version:  DEC OSF/1  PLA12386

QAR 51402  Version PLA12386   6-FEB-1997 18:40:20.5

-- Submitted by --                      -- DIGITAL contact --
TOM WOODBURN                            QUARRY::WOODBURN
35G
herron                                  RZ26, RZ26, CD-ROM
ZKO3-3/Y25
381-0429, ZK03-3/Y25

Attachments: NONE                      		Customer severity: M
Reproducible at will: Y

CPU        Memory     System device
DEC/3000-4 64         RZ26

	In Digital UNIX V4.0, you can't enter AltGR characters in the
	login windows for CDE or xdm if XKB is enabled (it's enabled
	by default).  If you disable it, you can enter the characters
	fine.  You could always enter them in earlier releases,
	which didn't have XKB.

	The change can affect customers with keyboards like the
	French PCXAL, where '@' is an AltGR character, i.e., to enter
	it, you hold down the AltGr key (RightAlt) and press the '0'
	key.  If any of those customers have an '@' in their password
	and upgrade to V4.0, they won't be able to login anymore!

	What's special about the login windows is that they grab the
	keyboard.  If you comment out their calls to XGrabKeyboard(),
	you can enter the AltGR characters fine.  So this problem
	actually applies to any program that grabs the keyboard, for
	example, xterm in secure mode.

	I've attached a test program I used to narrow the problem
	down to XGrabKeyboard().

	A workaround to the problem is to disable XKB by adding -kb
	to the X server options in /var/X11/Xserver.conf.

	This problem seems like an important one, but I've only
	heard of one customer that's run into it.  They worked around
	it by switching keyboards.  My contact there was Jean-Marc
	Tisserand (swthom::[email protected]) in the
	French CSC.

	If you decide to go ahead and fix this problem, please let
	me (or someone else in the I18N group) test the fix.  I want
	to check that in Japanese locales, you can still drag windows
	while in Kana mode.  I have a hunch that dtwm may need some
	changes for that to still work.

	Thank you.

#include <locale.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <X11/Xlib.h>
#include <X11/Xresource.h>
#include <X11/Xutil.h>

#define NUM_ELEMENTS(a) (sizeof(a) / sizeof((a)[0]))

static int true = True;
static XrmOptionDescRec options[] = {
    { "-grab", "*grab", XrmoptionNoArg, (char *) &true }
};
static XrmDatabase options_db;

int main(int argc, char *argv[])
{
    char *appname = "XGrabKeyboard";
    Display *dpy;
    int scr;
    Window win;
    int grab;
    char *type;
    XrmValue value;
    int done;
    XEvent event;
    char s[32];
    KeySym keysym;
    int n;

    if (!setlocale(LC_ALL, "")) {
	fprintf(stderr, "cannot set locale\n");
	exit(1);
    }
    if (!XSupportsLocale()) {
	fprintf(stderr, "locale not supported by X\n");
	exit(1);
    }
    if (!XSetLocaleModifiers("")) {
	fprintf(stderr, "cannot set locale modifiers\n");
	exit(1);
    }

    XrmInitialize();
    XrmParseCommand(&options_db, options, NUM_ELEMENTS(options),
		    appname, &argc, argv);

    grab = 0;
    if (XrmGetResource(options_db, "xGrabKeyboard.grab",
		       "XGrabKeyboard.Grab", &type, &value))
	grab = *value.addr;

    if (!(dpy = XOpenDisplay(NULL))) {
	fprintf(stderr, "unable to open display\n");
	exit(1);
    }

    scr = DefaultScreen(dpy);
    win = XCreateSimpleWindow(dpy, RootWindow(dpy, scr),
			      100, 100, 100, 100, 5,
			      BlackPixel(dpy, scr),
			      WhitePixel(dpy, scr));
    XmbSetWMProperties(dpy, win, appname, appname, NULL, 0, NULL,
		       NULL, NULL);
    XSelectInput(dpy, win, KeyPressMask | ButtonPressMask);
    XMapWindow(dpy, win);

    if (grab) {
	int status = XGrabKeyboard(dpy, DefaultRootWindow(dpy),
				   True, GrabModeAsync, GrabModeAsync,
				   CurrentTime);
	if (status != GrabSuccess) {
	    fprintf(stderr, "XGrabKeyboard() failed\n");
	    exit(1);
	}
    }

    done = 0;
    while (!done) {
	XNextEvent(dpy, &event);
	switch (event.type) {
	case ButtonPress:
	    done = 1;
	    break;
	case KeyPress:
	    n = XLookupString((XKeyEvent *) &event, s, sizeof s,
			      &keysym, NULL);
	    if (n > 0) {
		s[n] = '\0';
		puts(s);
	    }

	    break;
	}
    }

    exit(0);
}

No answer for QAR report #51402.

------------- End Forwarded Message -------------

556.7instructions for workaroundSMURF::WOODBURNTue Apr 08 1997 12:3527
	As mentioned in .6, the workaround to this problem is to
	disable XKB by adding the -kb option to /var/X11/Xserver.conf.
	Here are instructions on how to do that.

	1.  Look for the following lines at the end of the file.

	      ! you specify command line arguments here
              args <
                      -pn
              >

	2.  Add the -kb after the -pn, like this:

	      ! you specify command line arguments here
              args <
                      -pn -kb
              >

	3.  Restart the X server to pick up the change.

	      # /sbin/init.d/xlogin stop
	      # /sbin/init.d/xlogin start

	Tom