Activating keyboard after boot time

Is there anyway to activate the keyboard after a system has booted without
one?

We have a lot of systems out there that normally operate without a
keyboard. We occasionally want to attach a keyboard to check things out, but
we have to reboot the system with the keyboard attached. This may destroy
important information. Is there any way around this, without leaving a
keyboard attached all of the time?

Thanks,

Kevin

Kevin Miller <kevin.miller@transcore.com> wrote:

Is there anyway to activate the keyboard after a system has booted without
one?

We have a lot of systems out there that normally operate without a
keyboard. We occasionally want to attach a keyboard to check things out, but
we have to reboot the system with the keyboard attached. This may destroy
important information. Is there any way around this, without leaving a
keyboard attached all of the time?

After giving this a bit of thought, I’ve decided that if I needed to
do something like this, I would leave a login running on a serial
port instead, and use a laptop with a serial port instead of a keyboard
to login.

What you’re asking is possible, but you’d need a custom
application to watch for a keyboard to show up, enable the port
and init the keyboard, and then run a Dev.ansi against it.

If you use a serial port, you can do it with out of the box stuff.

This is odd, I’m using a VersaLogic SBC that is often booted up without
a keyboard or mouse attached and it never has a problem recognizing a
keyboard when its attached after bootup. It does have a problem with
the PS/2 mouse though, which it does not recognize.

The serial port access works real well and it is one of the solutions we
use. I was wondering if slaying and restarting Input would solve the
problem?
Then again, how would the system know when to slay and restart Input?
I know you can do this to get the mouse input back, never looked at the
keyboard.

<pete@qnx.com> wrote in message news:8og67o$a5b$1@inn.qnx.com

Kevin Miller <> kevin.miller@transcore.com> > wrote:
Is there anyway to activate the keyboard after a system has booted
without
one?

We have a lot of systems out there that normally operate without a
keyboard. We occasionally want to attach a keyboard to check things out,
but
we have to reboot the system with the keyboard attached. This may
destroy
important information. Is there any way around this, without leaving a
keyboard attached all of the time?

After giving this a bit of thought, I’ve decided that if I needed to
do something like this, I would leave a login running on a serial
port instead, and use a laptop with a serial port instead of a keyboard
to login.

What you’re asking is possible, but you’d need a custom
application to watch for a keyboard to show up, enable the port
and init the keyboard, and then run a Dev.ansi against it.

If you use a serial port, you can do it with out of the box stuff.

Ivan Bannon <ivan.bannon@rjginc.com> wrote:

This is odd, I’m using a VersaLogic SBC that is often booted up without
a keyboard or mouse attached and it never has a problem recognizing a
keyboard when its attached after bootup. It does have a problem with
the PS/2 mouse though, which it does not recognize.

This often depends on the BIOS and what it does when it doesn’t detect
a keyboard at startup. This varies from machine to machine.

I have seen the (friendly) behaviour that you describe – the machine
will just work fine if you plug the keyboard in later.

I have seen the (neutral) behaviour where it believes forever more that
the keyboard doesn’t exist.

And, I have seen the (hostile) behaviour where it prints out a message
stating that it encountered an error or problem detecting a keyboard,
followed by a request to hit any key to continue.

-David

P.S. For Americans:
:%s/behaviour/behavior/g

We have seen this problem before. The easiest solution is to buy PC’s with
AT keyboards :slight_smile:

However, most of our nodes that boot without a keyboard/monitor have PS/2
keyboards. We found that you if you put the line: “Input kb &” somewhere
near the top of the sysinit, the node will recognize a keyboard later even
if it was booted without one.

Don’t ask me why it works or if there are any side effects. Actually, if
someone at QSSL can explain why this works and what it’s doing, I’d be glad
to hear it.

Stephen Thomas
Sr. Control Systems Engineer
Olin Corporation

Kevin Miller <kevin.miller@transcore.com> wrote in message
news:8ofv4c$75d$1@inn.qnx.com

Is there anyway to activate the keyboard after a system has booted without
one?

We have a lot of systems out there that normally operate without a
keyboard. We occasionally want to attach a keyboard to check things out,
but
we have to reboot the system with the keyboard attached. This may destroy
important information. Is there any way around this, without leaving a
keyboard attached all of the time?

Thanks,

Kevin

Stephen Thomas <slthomas@corpdotolin.com> wrote:

We have seen this problem before. The easiest solution is to buy PC’s with
AT keyboards > :slight_smile:

However, most of our nodes that boot without a keyboard/monitor have PS/2
keyboards. We found that you if you put the line: “Input kb &” somewhere
near the top of the sysinit, the node will recognize a keyboard later even
if it was booted without one.

Don’t ask me why it works or if there are any side effects. Actually, if
someone at QSSL can explain why this works and what it’s doing, I’d be glad
to hear it.

It’s interesting to hear about this.

The `kb’ module of Input deals with the low level PS/2 interface.

One of the things that happens when you run Input is that it initializes
the PS/2 controller chip itself.

I’d guess that your BIOS looks to see if a keyboard is there, and if
not it shuts down the KB controller. Other BIOSES could leave it enabled
which would explain why other people report different behaviour from
other hardware.

It’s worth a try, but it wasn’t intentionally designed to do this. It’s
a side effect of the way Input works. It has to enable the controller
before it looks to see if any devices are attached.