Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: Xsun fails compile on SunOS4.1.1
Keywords: Windows
Message-ID: <1308@brchh104.bnr.ca>
Date: 16 Jan 91 19:42:18 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 36
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v10n17
X-Sun-Spots-Digest: Volume 10, Issue 17, message 11
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

>I just tried to build Xsun on a SparcStation 2 running SunOS4.1.1.  With
>the new keyboards, Sun has changed the value of the constant HOLE from
>0xA2 to 0x302,

No, with the new SunOS 4.1[.x] *operating system*, Sun has changed the
value of the constant.  (Yes, I know this for a fact - I'm the guy who
changed the value....)

>while the element kiockey.type remains unsigned char.  An
>assignment or comparison of these twho is therefore invalid.

Yup.

>Has anyone fixed this problem yet?  I would much rather not have to hack
>the sunKbd.c routine myself.

The good news is that the whole reason that grot is being done is that the
pre-4.1 driver lied, and claimed that a Type 4 keyboard was actually a
Type 3 keyboard.  The new driver doesn't do so, so the fix should simply
be to ensure that TYPE4KEYBOARDOVERRIDE isn't defined when compiling with
the new 4.1[.x] driver, thus removing that code entirely.

You can try something such as replacing the code that defines
TYPE4KEYBOARDOVERRIDE with

/*
 * The Sun 386i has system include files that preclude this pre SunOS 4.1
 * test for the presence of a type 4 keyboard however it really doesn't
 * matter since no 386i has ever been shipped with a type 3 keyboard.
 * In addition, the same is true of the 4.1 driver, but it really
 * doesn't matter there, either, because the 4.1 driver tells you whether
 * you have a Type 3 or a Type 4.
 */
#if !defined(i386) && HOLE != 0x302
#define TYPE4KEYBOARDOVERRIDE
#endif