Groups | Search | Server Info | Login | Register


Groups > comp.os.os2.programmer.misc > #1872

inoperative keyboard - analysis required

From Paul Edwards <mutazilah@gmail.com>
Newsgroups comp.os.os2.programmer.misc
Subject inoperative keyboard - analysis required
Date 2024-03-02 03:06 +0800
Organization A noiseless patient Spider
Message-ID <urt90a$1cvoe$1@dont-email.me> (permalink)

Show all headers | View raw


Hi. I raised issue 3605 with Arca over this.

https://mantis.arcanoae.com/view.php?id=3605


I told them the below program rendered the keyboard
inoperative, and they are of the opinion that it is
ok for an unprivileged program to be able to do that.

That's up to them I guess. So I was ready to close
the issue.

However, he claimed that I was using 16-bit functions,
which I believe to be untrue.

Furthermore he claimed that the "keyboard functions",
presumably meaning Kbd* that I see in the referenced
cp1.inf (same as what I have from the web) are 32-bit,
which I believe to be untrue.

Who is right?

However, regardless of any of that, he has an intriguing
insight.

"Your parameters have selected to turn off
the input queue."

What does this mean? What "input queue"? And how
did I turn it off? And he suggests that I could
have turned it back on.

As far as I know, all I did was set binary mode on
(even though it already seemed to be on), and then
attempt to turn it off (which should be putting it
back to normal).

The program below works fine in fullscreen mode,
but in VIO (window) mode it renders the keyboard
inoperative (after the program completes). Note
that when you run it, you just need to press a
letter, e.g. "a" and it will complete.

Can anyone shed any light?

Thanks. Paul.




wcl386 -bt=os2 -l=os2v2 pdptest.c os2386.lib


#include <stdio.h>

#define INCL_DOS
#include <os2.h>

int main(void)
{
     ULONG kbdfile;
     static USHORT fileAttr = 0;
     static ULONG newsize = 0;
     ULONG action;
     static ULONG openMode = OPEN_ACCESS_READONLY | OPEN_SHARE_DENYNONE;
     static ULONG openAction = OPEN_ACTION_OPEN_IF_EXISTS;
     ULONG datalen;
     ULONG parmlen;
     USHORT rc;
     BYTE bb;
     static BYTE oldbb;

     rc = DosOpen((PSZ)"KBD$",
                  &kbdfile,
                  &action,
                  newsize,
                  fileAttr,
                  openAction,
                  openMode,
                  0);
     if (rc != 0)
     {
         return (-1);
     }

     parmlen = 0;
     datalen = sizeof oldbb;
     /* get old input mode */
     DosDevIOCtl(kbdfile,
                 4,
                 0x71,
                 NULL,
                 0,
                 &parmlen,
                 &oldbb,
                 sizeof oldbb,
                 &datalen);

     printf("surprisingly, oldmode is already binary %x\n", (int)oldbb);

     printf("surprisingly, we need to set binary mode, even though it is 
already set\n");
     /* set binary mode */
     bb = 0x80;
     parmlen = sizeof bb;
     datalen = 0;
     DosDevIOCtl(kbdfile,
                 4,
                 0x51,
                 &bb,
                 sizeof bb,
                 &parmlen,
                 NULL,
                 0,
                 &datalen);

     printf("restoring old (binary) mode is identical and useless and 
behavior is same\n");
     printf("so setting text mode instead\n");
     oldbb = 0;
     parmlen = sizeof oldbb;
     datalen = 0;
     rc = DosDevIOCtl(kbdfile,
                      4,
                      0x51,
                      &oldbb,
                      sizeof oldbb,
                      &parmlen,
                      NULL,
                      0,
                      &datalen);
     DosClose(kbdfile);
     printf("surprisingly, keyboard is now inoperative and you need to 
use mouse to reboot\n");
     return (0);
}




Any program can affect the entire system, especially ones that call directly
into drivers using IOCtl calls. Additionally, the IOCtl functions you are
calling appear to be working correctly and as designed.

Regardless of what you are trying to do, these IOCtl functions are 
likely not
the way to do it. You should look at the keyboard functions in the Control
Program Guide and Reference (cp1.inf) in the toolkit.

There is also a lot of development information available from the EDM/2 site
which you can get to from the link on the Information for developers page:
https://www.arcanoae.com/wiki/information-for-developers/



The IOCtls you are using are 16 bit functions. The regular Control 
Program stuff
I pointed you to are the 32 bit functions.

The functions you are calling are working correctly as IBM designed, not 
me, and
are doing exactly what you requested. Your parameters have selected to 
turn off
the input queue. The system is still fully running and functional, but 
with the
input queue disabled as you requested. You could turn the input queue 
back on
with another call, or you could not turn it off at all. No reboot is 
required.
The system is simply doing what you asked.

Back to comp.os.os2.programmer.misc | Previous | NextNext in thread | Find similar


Thread

inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 03:06 +0800
  Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 15:57 -0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 09:17 +0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:37 -0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 15:08 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:04 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 12:34 +0800
              Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-03 13:42 +0800
                Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-04 18:47 +0800
    Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:48 +0800
      Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 10:54 +0800
        Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 11:43 +0800
          Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 23:22 -0800
            Re: inoperative keyboard - analysis required Paul Edwards <mutazilah@gmail.com> - 2024-03-02 16:05 +0800
              Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-02 19:07 -0800
      Re: inoperative keyboard - analysis required Dave Yeo <dave.r.yeo@gmail.com> - 2024-03-01 22:42 -0800

csiph-web