nanogui: Thread: Compiling nano-X (SVGAlib) under Linux Mandrake 8

I'm trying to do this, but find many errors:

1. drivers/kbd_ttyscan.c - ioctl_setpalette() and ioctl_getpalette()
don't exist.
2. drivers/kbd_ttyscan.c - during running of nano-X, it produces:

KDGKBMODE: Invalid argument
Cannot initialise keyboard

...also, the original kbd_ttyscan.c seems to have a typo in this error
message, as it doesn't match the ioctl call above it...

3. Numerous files: either they are missing <stdlib.h> ...for exit()...
or they are missing <string.h> ...for strcmp(), strlen()...  Some use
memset() and are missing its header file too.

4. Ghastly number of errors from the preprocessor during compilation of
things in "nwidget" directory; fixed that by not using nwidgets

I'm trying to compile 0.89pre7 with the SVGAlib (instead of
framebuffers) and can't seem to make it happen.  I was hoping that there
was several binaries for Linux available (so I could at least try it)
but they're not there.  I wondered about RPMs... Debian packages...
etc... Nobody's done these yet?

I also don't need Microsoft Windows compatability, so I compiled for
nanox only, and left the keyboard at "kbscan" or whatever it was.

If I missed some configuration data, let me know and I'll post more
data....

I'm compiling under:

# uname -a
Linux localhost.localdomain 2.4.3-20mdk #1 Sun Apr 15 23:03:10 CEST 2001
i586 unknown
# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)
# rpm -qa | grep svga
svgalib-1.4.3-0.pre.20001010.1mdk
svgalib-devel-1.4.3-0.pre.20001010.1mdk
#

First and foremost, what version are you trying to compile?

My answers follow:

On Thursday 28 June 2001 14:45, David Douthitt mentioned:
> I'm trying to do this, but find many errors:
>
> 1. drivers/kbd_ttyscan.c - ioctl_setpalette() and ioctl_getpalette() 
> don't exist.

This is in the VT switch code - These should be defined  in drivers/fb.h 
which should be included in scr_fb.c.  .89pre7 does indeed have this.

However, drivers/kdb_ttyscan.c should have a #ifdef around the VT switching 
code.  This compiles fine for me, though, so I don't know why the Makdrake 
compiler is getting angry.

> 2. drivers/kbd_ttyscan.c - during running of nano-X, it produces:
>
> KDGKBMODE: Invalid argument
> Cannot initialise keyboard

/dev/tty is not really a device. - Why have we seen this so much lately?  I 
just compiled .89pre7 and ran it on my Redhat 7.1 system with no problems.  
If so, then thats easily my mistake.  I might have made an idiot mistake in 
the code somewhere....... :(

> ...also, the original kbd_ttyscan.c seems to have a typo in this error
> message, as it doesn't match the ioctl call above it...
>
> 3. Numerous files: either they are missing <stdlib.h> ...for exit()...
> or they are missing <string.h> ...for strcmp(), strlen()...  Some use
> memset() and are missing its header file too.

Standard ANSI compliant stuff - One of these days we'll get that whole mess 
finally cleaned up.

> 4. Ghastly number of errors from the preprocessor during compilation of
> things in "nwidget" directory; fixed that by not using nwidgets

nwidgets should be disappearing soon.

Jordan

I really need a kick in the head.  What follows is easily one of the most  
braindead paragraphs I have ever done.  Corrections follow:

> 2. drivers/kbd_ttyscan.c - during running of nano-X, it produces:
>
> KDGKBMODE: Invalid argument
> Cannot initialise keyboard

> dev/tty is not really a device. - Why have we seen this so much lately?  I 
> just compiled .89pre7 and ran it on my Redhat 7.1 system with no problems.  
> f so, then thats easily my mistake.  I might have made an idiot mistake in 
> the code somewhere....... :(

What I meant to say was: the invalid argument means that /dev/tty is not the 
type of device we expected it to be.  That has been happening alot lately, 
and since I made some changes in that code recently, this might all be my 
fault.  It works fine on my machine running .89pre7, but the CVS version 
might be screwed up somehow.  Everyone who has had this problem, write in and 
let me know what version of Microwindows you are using.

Jordan

On Thu, 28 Jun 2001 16:08:37 -0600, Jordan Crouse ####@####.#### wrote:

> I really need a kick in the head.  What follows is easily one of the most  
> braindead paragraphs I have ever done.  Corrections follow:
> 
> > 2. drivers/kbd_ttyscan.c - during running of nano-X, it produces:
> >
> > KDGKBMODE: Invalid argument
> > Cannot initialise keyboard
> 
> > dev/tty is not really a device. - Why have we seen this so much lately?  I 
> > just compiled .89pre7 and ran it on my Redhat 7.1 system with no problems.  
> > f so, then thats easily my mistake.  I might have made an idiot mistake in 
> > the code somewhere....... :(
> 
> What I meant to say was: the invalid argument means that /dev/tty is not the 
> type of device we expected it to be.  That has been happening alot lately, 
> and since I made some changes in that code recently, this might all be my 
> fault.  It works fine on my machine running .89pre7, but the CVS version 
> might be screwed up somehow.  Everyone who has had this problem, write in and 
> let me know what version of Microwindows you are using.
> 
> Jordan

I had the same problem, and someone on this list pointed out that
this might have been a problem with /dev/tty, which was a great
help because it turned out I didn't have any getty's running upon boot,
only a "/bin/sh < /dev/console > /dev/console 2>/dev/console" was
present in /etc/inittab. (The system is HardHat Linux).
So, the solution was to add a line like:
1:2345:respawn:/bin/getty tty1
into inittab and reboot, and everyhing started working OK
(I also had to link my app with the server though).
The Microwindows version is 0.89pre7, with no updates.

Since the original /etc/inittab (with no getty's) comes from 
the standard HardHat distribution, this may be the reason
why other people are seeing the same error message -- 
/dev/tty is not configured in the system.



--
Sincerely,
Mikhail Ivanov

Jordan Crouse wrote:
> 
> First and foremost, what version are you trying to compile?

0.89pre7

I noticed that the directory in the tar.gz file is microwin; why not
microwin-0.89pre7?

> > 1. drivers/kbd_ttyscan.c - ioctl_setpalette() and ioctl_getpalette()
> > don't exist.
> 
> This is in the VT switch code - These should be defined  in drivers/fb.h
> which should be included in scr_fb.c.  .89pre7 does indeed have this.

That does work, but fails during linking.

> However, drivers/kdb_ttyscan.c should have a #ifdef around the VT switching
> code.  This compiles fine for me, though, so I don't know why the Makdrake
> compiler is getting angry.

ioctl_setpalette() and ioctl_getpalette don't have any #ifdef around
them.

> > 2. drivers/kbd_ttyscan.c - during running of nano-X, it produces:
> >
> > KDGKBMODE: Invalid argument
> > Cannot initialise keyboard
> 
> /dev/tty is not really a device. - Why have we seen this so much lately?  I
> just compiled .89pre7 and ran it on my Redhat 7.1 system with no problems.
> If so, then thats easily my mistake.  I might have made an idiot mistake in
> the code somewhere....... :(

# ls -l /dev/tty 
crw-rw-rw-    1 root     root       5,   0 Jun 28 11:12 /dev/tty

I noticed in the code that there is no attempt to discern the actual
error; it just prints this message.

I also noticed in the man page for ioctl this description:

SYNOPSIS
       #include <sys/ioctl.h>

       int ioctl(int d, int request, ...)

       [The "third" argument is traditionally char *argp, and will be so
named for this discussion.]


However, in the code, the usage is this:

static int fd; /* file descriptor for keyboard */
[...]
static int old_kbd_mode;
[...]

        if (ioctl(fd, KDGKBMODE, &old_kbd_mode) < 0) {
                perror("KDGKBMODE");
                goto err;
        }

[...with spelling error fixed...]

KDGKBMODE is defined in <linux/kd.h> as:

#define KDGKBMODE       0x4B44  /* gets current keyboard mode */
#define KDSKBMODE       0x4B45  /* sets current keyboard mode */

I wondered if changing old_kbd_mode thus wouldn't fix it, but it didn't:

static char old_kbd_mode;

...but that didn't fix it: and besides, wouldn't an oddball third
argument just generate a SegFault when you tried to write?  When I tried
it, nothing changed.

In working on this, it became apparent that the same error is generated
for the following defines:

#define KDGETLED        0x4B31  /* return current led state */
#define KDSETLED        0x4B32  /* set led state [lights, not flags] */

Removing all calls to ioctl using KDGETLED, KDSETLED, KDSKBMODE, and
KDGKBMODE removes the first error ("invalid argument") but not the
second ("Cannot initialise keyboard").  This doesn't seem to be coming
from any of the code in drivers/* so I guess I don't understand it.

Also, I'm using:

# rpm -qf /usr/include/linux/kd.h
kernel-headers-2.4.3-20mdk
# rpm -q kernel glibc            
kernel-2.4.3-20mdk
glibc-2.2.2-4mdk
# gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)
#

> > ...also, the original kbd_ttyscan.c seems to have a typo in this error
> > message, as it doesn't match the ioctl call above it...

Here's the original:


        /* Save previous settings*/
        if (ioctl(fd, KDGKBMODE, &old_kbd_mode) < 0) {
                perror("KDGKMODE");
                goto err;
        }


That is, KDGKMODE instead of KDGKBMODE ...

Jordan Crouse wrote:
> 
> First and foremost, what version are you trying to compile?

Just for completeness - and to repeat: 0.89pre7.

> My answers follow:
> 
> On Thursday 28 June 2001 14:45, David Douthitt mentioned:
> > I'm trying to do this, but find many errors:
> >
> > 1. drivers/kbd_ttyscan.c - ioctl_setpalette() and ioctl_getpalette()
> > don't exist.
> 
> This is in the VT switch code - These should be defined  in drivers/fb.h
> which should be included in scr_fb.c.  .89pre7 does indeed have this.
> 
> However, drivers/kdb_ttyscan.c should have a #ifdef around the VT switching
> code.  This compiles fine for me, though, so I don't know why the Makdrake
> compiler is getting angry.

I tried compiling again, this time on a different box with a different
kernel, different glibc (since the target environment is glibc
2.1....ooops):

$ rpm -q glibc 
glibc-2.1.3-22
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)

The kernel headers were 2.2.18 headers.

Here is the exact error:

/pub/nanoX/microwin/src/lib/libmwdrivers.a(kbd_ttyscan.o): In function
`switch_vt':
kbd_ttyscan.o(.text+0x5d5): undefined reference to `ioctl_getpalette'
kbd_ttyscan.o(.text+0x67e): undefined reference to `ioctl_setpalette'
collect2: ld returned 1 exit status
make[1]: *** [/pub/nanoX/microwin/src/bin/nano-X] Error 1

Here are some warnings:

hre_api.c: In function `safe_malloc':
hre_api.c:96: warning: implicit declaration of function `error'
hre_api.c: In function `recognizer_unload':
hre_api.c:212: warning: implicit declaration of function
`__recognizer_internal_finalize'

...and...

matrix.c: In function `NewVector':
matrix.c:54: warning: implicit declaration of function `exit_error'

Seemed like fewer errors here.

Here is a diff of my config against the default:

--- config.orig Sun Jan 21 22:11:07 2001
+++ config      Fri Jun 29 09:33:49 2001
@@ -55,10 +55,10 @@
 # Libraries to build: microwin, nano-X, nanowidget, object frameworks
 #
 ####################################################################
-MICROWIN                 = Y
+MICROWIN                 = N
 NANOX                    = Y
 SHAREDLIBS               = N
-NWIDGET                  = Y
+NWIDGET                  = N
 OBJFRAMEWORK             = N
 
 
@@ -67,7 +67,7 @@
 # Demos to build
 #
 ####################################################################
-MICROWINDEMO             = Y
+MICROWINDEMO             = N
 NANOXDEMO                = Y
 
 ####################################################################
@@ -230,14 +230,14 @@
 # set PORTRAIT_MODE to L or R for left or right orientation
 # set FBREVERSE to reverse bit orders in 1,2,4 bpp
 # set FBVGA=N for all systems without VGA hardware (for MIPS must=N)
-FRAMEBUFFER              = Y
-FBVGA                    = Y
-VTSWITCH                 = Y
+FRAMEBUFFER              = N
+FBVGA                    = N
+VTSWITCH                 = N
 PORTRAIT_MODE            = N
 FBREVERSE                = N
 
 # svgalib screen driver
-VGALIB                   = N
+VGALIB                   = Y
 
 # direct VGA hardware access screen driver
 HWVGA                    = N
@@ -251,8 +251,8 @@
 # HARRIERMOUSE for NEC Harrier
 # PSIONMOUSE for the Psion 5
 ####################################################################
-GPMMOUSE                 = Y
-SERMOUSE                 = N
+GPMMOUSE                 = N
+SERMOUSE                 = Y
 TPMOUSE                  = N
 TPHELIO                  = N
 ADSMOUSE                 = N

On Friday 29 June 2001 07:28, David Douthitt mentioned:
> Jordan Crouse wrote:
> > First and foremost, what version are you trying to compile?
>
> 0.89pre7
>
> I noticed that the directory in the tar.gz file is microwin; why not
> microwin-0.89pre7?

Because .89pre-7 is the version number.  Most projects keep the same 
directory structure throughout the life of the project, because that makes it 
easier on the developers and on the maintainers.  I usually extract the 
tarball and immediately rename it (but then again, I have easily a dozen 
copies of Microwindows on my machine).

> > > 1. drivers/kbd_ttyscan.c - ioctl_setpalette() and ioctl_getpalette()
> > > don't exist.
> >
> > This is in the VT switch code - These should be defined  in drivers/fb.h
> > which should be included in scr_fb.c.  .89pre7 does indeed have this.
>
> That does work, but fails during linking.

What graphics mode are you running in - X11 or framebuffer?

> > > 2. drivers/kbd_ttyscan.c - during running of nano-X, it produces:
> > >
> > > KDGKBMODE: Invalid argument
> > > Cannot initialise keyboard
>
> # ls -l /dev/tty
> crw-rw-rw-    1 root     root       5,   0 Jun 28 11:12 /dev/tty
>
> I noticed in the code that there is no attempt to discern the actual
> error; it just prints this message.

Thats actually the error - Invalid argument.  Check perror() in the man pages.

Ok, this is the error that you are getting.  For some reason, the argument 
that you are sending into the IOCTL is invalid (errno EINVAL).  This is a 
common error, since most ioctl handlers return a -EINVAL whenever there is an 
unexpected error (kind of like returning a -1 from a failed syscall).

In this situation, it means that the value that was passed in to KDGKBMODE 
was invalid - most likely because /dev/tty doesn't really handle the 
KDGKBMODE command.  Thats because /dev/tty is a odd device - It is the 
standard device that use used to read the keyboard, but traditionally it is 
just linked another keyboard device (usually /dev/console).   My assumption 
is that since /dev/tty is a true device on your system and not a link to a 
more common keyboard device, you are having these problems.   My suggestion 
would be to remove /dev/tty and replace it with a soft link to /dev/console, 
and then wait for .89pre8 which will give you the ability to set the desired 
TTY through an environment variable.

Jordan

On Fri, 29 Jun 2001, Jordan Crouse wrote:
> Because .89pre-7 is the version number.  Most projects keep the same 
> directory structure throughout the life of the project, because that makes it 
> easier on the developers and on the maintainers.  I usually extract the 
> tarball and immediately rename it (but then again, I have easily a dozen 
> copies of Microwindows on my machine).

I find it extremely irritating when I download a new version and 
accidentally extract it on top of the previous version (because they both 
expand into a directory with the same name), wiping out all of my changes
in the process. I did that a couple of times before I got into the habit
of always renaming it to include the version number immediately after
extracting it. I seem to recall complaining about this a couple of years
ago, but every version still extracts to a directory called "microwin"
for some reason.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

Jordan Crouse wrote:

> In this situation, it means that the value that was passed in to KDGKBMODE
> was invalid - most likely because /dev/tty doesn't really handle the
> KDGKBMODE command.  Thats because /dev/tty is a odd device - It is the
> standard device that use used to read the keyboard, but traditionally it is
> just linked another keyboard device (usually /dev/console).   My assumption
> is that since /dev/tty is a true device on your system and not a link to a
> more common keyboard device, you are having these problems.

I tried it, now I get this:

$ bin/nano-X
KDSETLED: Operation not permitted
KDSKBMODE: Operation not permitted
Cannot initialise keyboard
$

Then something occurred to me, and I think this may be relevant....

On the 2.4.3 system, I was using a vnc rxvt terminal to attempt running
microwin.  On the 2.2.16 system, I was using a slogin into the system to
do the same thing.

I tried running bin/nano-X by itself (a mistake??) on the system console
of the 2.4.3 system and then switched to a second virtual terminal. 
Then switched back and was stuck (no mouse movement either).  I killed
it from an X terminal, and now I can't switch virtual terms and have no
shell on that tty ( /dev/tty1 ).

Looks like its time to reboot - it needed it anyway :-)

More things I've noticed:

I selected SERMOUSE (serial mouse?) but perhaps I should have selected
PS2MOUSE - only where is that?  I'm not using gpm in the target
environment...

Also, should I have selected TTYKBD instead of SCANKBD?  Or should I use
PIPEKBD?  There's no description of which is what.

On Fri, 29 Jun 2001, David Douthitt wrote:
> I selected SERMOUSE (serial mouse?) but perhaps I should have selected
> PS2MOUSE - only where is that?  I'm not using gpm in the target
> environment...

That's an old argument. Until somebody gets around to writing some native
mouse drivers, you'll have to run GPM on the target and use the GPM mouse
driver.

> Also, should I have selected TTYKBD instead of SCANKBD?  Or should I use
> PIPEKBD?  There's no description of which is what.

No, SCANKBD is the new driver which was written to replace TTYKBD on
Linux.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/