System Video Blanks with no Keyboard or Mouse Plugged in...

QNX Newsgroups (Archives) qdn.public.qnx4
#1

We are using a industrial pc platform with QNX 4.25 as a machine
controller. The intent is to operate the machine entirely from a
touchscreen panel. During assembly, configuration, and servicing, the
system needs to have a keyboard attached. The problem is that when we
disconnect the keyboard and mouse from the system, the video goes blank
at the point where Photon comes up (We are configured to boot directly
into Photon). We have video until the Photon gui is launched.

We have Photon auto login by setting in the ph.node file:

Photon -l"phlogin -Uroot" -g -s &

I have tried removing the line in the Input.node file that defines the
keyboard, leaving only the touchscreen driver. No effect.

I’m stuck. If I leave the -Uroot in the ph.node file, the video
blanks. If I take it out, I get the Photon Login screen, but can’t
enter a
user/password because the keyboard and mouse are not attached.

If I leave either the mouse or keyboard connected, it boots up all the
way and works!

Help would be appreciated!

Walter

#2

Another way of doing this is to define LOGNAME before
calling ph in the sysinit file. This will bypass phlogin
when Photon starts up.

“Walter R. Greene” wrote:

We are using a industrial pc platform with QNX 4.25 as a machine
controller. The intent is to operate the machine entirely from a
touchscreen panel. During assembly, configuration, and servicing, the
system needs to have a keyboard attached. The problem is that when we
disconnect the keyboard and mouse from the system, the video goes blank
at the point where Photon comes up (We are configured to boot directly
into Photon). We have video until the Photon gui is launched.

We have Photon auto login by setting in the ph.node file:

Photon -l"phlogin -Uroot" -g -s &

I have tried removing the line in the Input.node file that defines the
keyboard, leaving only the touchscreen driver. No effect.

I’m stuck. If I leave the -Uroot in the ph.node file, the video
blanks. If I take it out, I get the Photon Login screen, but can’t
enter a
user/password because the keyboard and mouse are not attached.

If I leave either the mouse or keyboard connected, it boots up all the
way and works!

Help would be appreciated!

Walter

#3

Previously, Stephen Thomas wrote in qdn.public.qnx4:

Dale Paus <> dpaus@crisys.com> > wrote in message
news:> 3A9D55B3.E384B75@crisys.com> …
Go to > http://www.qnx.com/products/prodrelease.html#Download > (July 11,
2000)

Scroll down to “QNX Windows 4.24” and read the last line.

So… when might we actually see it?

I think you are talking about “gr.phi”. I have been using it for
several years. It works quite well for me. Unfortunately, it was
only distributed with the Qwinph package, which has been in beta
for…um…about 3 years now…

Scitech is probably a better solution now, but technically I guess
Qwinph is still in beta so I suppose you could still download it…

I think that QSSL officially dropped Qwinph at least a year ago. It’s
sort of too bad. It was real close to working very well. QWindows was/is? a real slick environment. Very easy to work with and understand. Performance was good also.

–
David L. Hawley D.L. Hawley and Associates

#4

I tried this by setting the LOGNAME in sysinit.node like this:

export LOGNAME=root

and I changed the line in the ph.node file to:

Photon -g -s & // Removing the -l"phlogin -Uroot" argument

This resulted in the system booting to a blank screen with a cursor. The
mouse and the touchscreen will move the cursor properly.
Have I left out a step?

Thanks

Walter

Alex wrote:

Another way of doing this is to define LOGNAME before
calling ph in the sysinit file. This will bypass phlogin
when Photon starts up.

“Walter R. Greene” wrote:

We are using a industrial pc platform with QNX 4.25 as a machine
controller. The intent is to operate the machine entirely from a
touchscreen panel. During assembly, configuration, and servicing, the
system needs to have a keyboard attached. The problem is that when we
disconnect the keyboard and mouse from the system, the video goes blank
at the point where Photon comes up (We are configured to boot directly
into Photon). We have video until the Photon gui is launched.

We have Photon auto login by setting in the ph.node file:

Photon -l"phlogin -Uroot" -g -s &

I have tried removing the line in the Input.node file that defines the
keyboard, leaving only the touchscreen driver. No effect.

I’m stuck. If I leave the -Uroot in the ph.node file, the video
blanks. If I take it out, I get the Photon Login screen, but can’t
enter a
user/password because the keyboard and mouse are not attached.

If I leave either the mouse or keyboard connected, it boots up all the
way and works!

Help would be appreciated!

Walter

#5

By blank screen I hope you mean the grey background, the QNX button
at the left hand bottom and the task bar?
If so, it sounds like pdm has not been started.

I would revert to the original ph script. That script checks for
LOGNAME, so you shouldn’t have to make any changes to it.

“Walter R. Greene” wrote:

I tried this by setting the LOGNAME in sysinit.node like this:

export LOGNAME=root

and I changed the line in the ph.node file to:

Photon -g -s & // Removing the -l"phlogin -Uroot" argument

This resulted in the system booting to a blank screen with a cursor. The
mouse and the touchscreen will move the cursor properly.
Have I left out a step?

Thanks

#6

Actually, I meant blank as in no active video at all. The pointer cursor is
present but nothing else.
This occurred while I still had Keyboard and Mouse plugged in along with the
touch screen.

In the default sysinit.node file there was a test and invocation for the
ph.node file. I took this out and
put in the script reference: ‘ph’ as this was described in the help system
(Nothing about ph.node however :< ). The results I got seemed to work as
desired when the keyboard and mouse were installed, but when they were removed,
I got the gray screen with the QNX button bar. However, the touch screen
didn’t work in this configuration.

Just to keep an eye on the objective, I need to boot into Photon without a
login using a touchscreen as the only connected input device.
This would be normal mode. When servicing is required, a keyboard and mouse
may need to be connected.

Thanks

Walter

Alex wrote:

By blank screen I hope you mean the grey background, the QNX button
at the left hand bottom and the task bar?
If so, it sounds like pdm has not been started.

I would revert to the original ph script. That script checks for
LOGNAME, so you shouldn’t have to make any changes to it.

“Walter R. Greene” wrote:

I tried this by setting the LOGNAME in sysinit.node like this:

export LOGNAME=root

and I changed the line in the ph.node file to:

Photon -g -s & // Removing the -l"phlogin -Uroot" argument

This resulted in the system booting to a blank screen with a cursor. The
mouse and the touchscreen will move the cursor properly.
Have I left out a step?

Thanks

#7

“Walter R. Greene” wrote:

Actually, I meant blank as in no active video at all. The pointer cursor is
present but nothing else.
This occurred while I still had Keyboard and Mouse plugged in along with the
touch screen.

Ugh. Sounds like this is going backwards :frowning:
Sounds like Input is running, the modeswitcher ran or is still running,
but the graphics driver is not running.

In the default sysinit.node file there was a test and invocation for the
ph.node file. I took this out and
put in the script reference: ‘ph’ as this was described in the help system
(Nothing about ph.node however :< ). The results I got seemed to work as
desired when the keyboard and mouse were installed, but when they were removed,
I got the gray screen with the QNX button bar. However, the touch screen
didn’t work in this configuration.

Just to keep an eye on the objective, I need to boot into Photon without a
login using a touchscreen as the only connected input device.
This would be normal mode. When servicing is required, a keyboard and mouse
may need to be connected.

I’m running in this exact configuration, so it is possible.
(touch screen, no keyboard).

It is beginning to sound like there’s a hardware clash,
or an inconsistency between the hardware and the params supplied
to Input.
Maybe you should post the sysinit.node file, and
/etc/config/trap/crt.node file and /etc/config
/trap/Input.node files.

I would remove the mouse first, but keep the keyboard,
then re-run inputtrap to create a new Input.node file.

Try it in that config with and without the keyboard.
Could be the mouse & touch params to Input are clashing.
You may have to compile your own Input.node file to
make the mouse & touch work together.

I would get a “sin” and “sin ar” (from a text console via a
serial port or telnet or QNX networking) while this is happening,
and in the various configurations you mentioned.
This will give a picture of what’s running and what’s not.

#8

-----Original Message-----
From: Alex [mailto:acellarius@systems104.co.za]
Posted At: Thursday, March 08, 2001 11:48 AM
Posted To: qnx4
Conversation: System Video Blanks with no Keyboard or Mouse Plugged
in…
Subject: Re: System Video Blanks with no Keyboard or Mouse Plugged in…

I’m running in this exact configuration, so it is possible.
(touch screen, no keyboard).

I too, have run this exact configuration. In addition, I wrote a
little c utility that turns off the cursor, and put it in the
sysinit inside an “if” that checks the return code from inputtrap
testing for a mouse (using the proper exclusion parameters). If
there is no mouse connected the c utility is run, and turns off
the cursor, if there is a mouse the c utility is not run, and
the cursor remains.

Maybe you should post the sysinit.node file, and
/etc/config/trap/crt.node file and /etc/config
/trap/Input.node files.

Sounds like a good idea.

#9

I’m a confused by the existence of two input.node files, one in /etc/config/bin and
one in …/trap/
I’ve modified both to contain only the microtch driver. The one in …/bin is invoked
explicitly from ph.node
which is …/bin. I am inserting each of the files here for your inspection.

The symptoms for the configuration shown are a boot to the ‘Gray’ screen with the QNX
button bar, with the system going effectivly dead. The touch screen doesn’t work,
and it doesn’t matter if the keyboard is plugged in or not. The pointer appears in
the upper left hand corner of the screen.

The PC running the test setup is a dual boot setup where the filesystem is contained
within a DOS partition (hd0.1t6…)

==============================================================
/etc/config/sysinit.3:

#Image: /boot/sys/boot -v
#Image: /boot/sys/Proc32 -l 3
#Image: /boot/sys/Slib32
#Image: /boot/sys/Slib16
#Image: /bin/Fsys
#Image: /bin/Fsys.eide fsys -Ndsk0 -n0=hd0. -n5=cd0. eide -a1f0 -i14
#Image: /bin/mount -p /dev/hd0.1 /dev/hd0.1t6.77 /
#Image: /bin/mountimg -t6.77 /dev/hd0.1t6:fsys1.qnx
#Image: /bin/sinit TERM=qnxm
#export NODE=3
export KBD=en_US_101.kbd
export ABLANG=en
export CON_KBD=USA
export TZ=est05edt04,M4.1.0/2,M10.5.0/2
export LOGNAME=root
/bin/rtc -l hw
Dev &
emu87 &
Pipe &
/bin/Dev.ser -N/dev/ser1 3f8,4 &
Dev.ansi -Q -n1 &
reopen /dev/con1
kbd $CON_KBD
prefix -A /dev/console=/dev/con1
Dev.par &
Dev.pty -n16 &
/bin/mount -p /dev/hd0.0
/bin/Fsys.eide fsys -Ndsk1 -n0=hd1. -n5=cd1. eide -a170 -i15
/bin/Fsys.floppy -a3f0 -i6
/bin/Iso9660fsys /cd1.0=/dev/cd1.0 &

Define the default CD Rom

/bin/prefix -A /cd=//0/cd1.0
/bin/Net &
/bin/Net.tulip -l1 -pfc80 -i10 &
netmap -f
nameloc &
chkfsys /
Dosfsys a=/dev/fd0 c=/dev/hd0.1t6 &
if test -f /etc/config/bin/tcpip.$NODE
then
… /etc/config/bin/tcpip.$NODE
fi
#ph
if test -f /etc/config/bin/ph.$NODE
then
… /etc/config/bin/ph.$NODE
else
tinit -t /dev/con1 &
fi

=========================================
/etc/config/bin/Input.3 (Note Captial I)

Input microtch fd -d/dev/ser1 &

=========================================
/etc/config/bin/ph.3


\

setup standard environment variables

export PHOTON=/dev/photon
export PHOTON_PATH=/qnx4/photon
export PATH=$PATH:/qnx4/photon/bin:/qnx4/bin/photon
export PHFONT=/dev/phfont
export ABLPATH=/qnx4/photon/translations
export PHEXIT_DISABLE=phshutdown

if test ! -r /etc/config/trap/crt.$NODE ; then
print “Running crttrap, please wait…”
crttrap trap
let didcrttrap=1
fi

Photon -l"phlogin -Uroot" -g -s &
phfont &
crttrap start

if test -f /etc/config/bin/Input.$NODE
then
… /etc/config/bin/Input.$NODE
else
inputtrap start
fi

typeset -i i=0
while test ! $PHOTON -ef $PHOTON -a $i -lt 5; do
sleep 1
let i=i+1
done
unset i

phlogin will start up on the desktop at boot time.

Once logged in, the system will automatically bring up

the rest of the system using the standard “ph” script

exit 0

=========================================================
/etc/config/trap/crt.3

s3bios.ms -i0x114 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3dc
-HNqnx/crt -g800x600x16 -A0xA0000,0x10000 -WB1600 -WM0x0009,5,0,7,0x00100000
-cSW;#800,600,16,200,1DVRB,s3dc - S3 Trio 64 (S3 Incorporated. Trio64)
s3bios.ms -i0x101 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3
-HNqnx/crt -g640x480x8 -A0xA0000,0x10000 -WB640
-WM0x0009,5,0,7,0x00100000;#640,480,8,200,1CDVRB,s3 - S3 Trio 64 (S3 Incorporated.
Trio64)
vesabios.ms -i0x6;Pg.mono -HNqnx/crt -g640x200x1 -WM0x2000,2 -A0xB8000,0x8000 -WB80
-WV100000;#640,200,1,100,1DV,mono - Monochrome graphics
vesabios.ms -i0xF;Pg.mono -HNqnx/crt -g640x350x1 -A0xA0000,0x10000 -WB80
-WV100000;#640,350,1,100,1DV,mono - Monochrome graphics
vesabios.ms -i0x11;Pg.mono -HNqnx/crt -g640x480x1 -A0xA0000,0x10000 -WB80
-WV100000;#640,480,1,100,1DV,mono - Monochrome graphics
vesabios.ms -i0x13;Pg.svga -HNqnx/crt -g320x200x8 -A0xA0000,0x10000 -WB320
-WV100000;#320,200,8,100,1DV,svga - SVGA 256 color
vesabios.ms -i0x101;Pg.svga -HNqnx/crt -g640x480x8 -A0xA0000,0x10000 -WB640 -WV100000
-WG0x10000;#640,480,8,25,1DV,svga - SVGA 256 color
vesabios.ms -i0x103;Pg.svga -HNqnx/crt -g800x600x8 -A0xA0000,0x10000 -WB800 -WV100000
-WG0x10000;#800,600,8,25,1DV,svga - SVGA 256 color
vesabios.ms -i0x105;Pg.svga -HNqnx/crt -g1024x768x8 -A0xA0000,0x10000 -WB1024
-WV100000 -WG0x10000;#1024,768,8,25,1DV,svga - SVGA 256 color
vesabios.ms -i0xD;Pg.vga4 -HNqnx/crt -g320x200x4 -A0xA0000,0x10000
-WB40;#320,200,4,100,1DV,vga4 - VGA 16 color
vesabios.ms -i0xF;Pg.mono -HNqnx/crt -g640x350x1 -A0xA0000,0x10000 -WB80
-WV100000;#640,350,1,100,1DV,mono - Monochrome graphics
vesabios.ms -i0x10;Pg.vga4 -HNqnx/crt -g640x350x4 -A0xA0000,0x10000
-WB80;#640,350,4,100,1DV,vga4 - VGA 16 color
vesabios.ms -i0x11;Pg.mono -HNqnx/crt -g640x480x1 -A0xA0000,0x10000 -WB80
-WV100000;#640,480,1,100,1DV,mono - Monochrome graphics
vesabios.ms -i0x12;Pg.vga4 -HNqnx/crt -g640x480x4 -A0xA0000,0x10000
-WB80;#640,480,4,100,1DV,vga4 - VGA 16 color
vesabios.ms -i0x13;Pg.svga -HNqnx/crt -g320x200x8 -A0xA0000,0x10000
-WB320;#320,200,8,100,1DV,svga - VGA 256 color

Card 1, Bus 0, Dev/Func 40

Hydra.ms -S -i0x101 -s0x0000,0x0040 -cnone -nnone -r;Pg.flat -g640x480x8
-A0xF8000000,0x100000 -WB640;#640,480,8,100,1,flat - SVGA 256 color
Hydra.ms -S -i0x103 -s0x0000,0x0040 -r;Pg.flat -HC0x00000040 -PX -HNqnx/crt
-g800x600x8 -A0xF8000000,0x100000 -WB800;#800,600,8,100,1,flat - SVGA 256 color
Hydra.ms -S -i0x105 -s0x0000,0x0040 -r;Pg.flat -HC0x00000040 -PX -HNqnx/crt
-g1024x768x8 -A0xF8000000,0x100000 -WB1024;#1024,768,8,100,1,flat - SVGA 256 color
Hydra.ms -S -i0x110 -s0x0000,0x0040 -r;Pg.flatdc -HC0x00000040 -PX -HNqnx/crt
-g640x480x15 -A0xF8000000,0x100000 -WB1280;#640,480,15,100,1,flatdc - VGA hi-color
Hydra.ms -S -i0x111 -s0x0000,0x0040 -r;Pg.flatdc -HC0x00000040 -PX -HNqnx/crt
-g640x480x16 -A0xF8000000,0x100000 -WB1280;#640,480,16,100,1,flatdc - VGA hi-color
Hydra.ms -S -i0x113 -s0x0000,0x0040 -r;Pg.flatdc -HC0x00000040 -PX -HNqnx/crt
-g800x600x15 -A0xF8000000,0x100000 -WB1600;#800,600,15,100,1,flatdc - VGA hi-color
Hydra.ms -S -i0x114 -s0x0000,0x0040 -r;Pg.flatdc -HC0x00000040 -PX -HNqnx/crt
-g800x600x16 -A0xF8000000,0x100000 -WB1600;#800,600,16,100,1,flatdc - VGA hi-color
s3bios.ms -i0x101 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3
-HNqnx/crt -g640x480x8 -A0xA0000,0x10000 -WB640
-WM0x0009,5,0,7,0x00100000;#640,480,8,200,1CDVRB,s3 - S3 Trio 64 (S3 Incorporated.
Trio64)
s3bios.ms -i0x103 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3
-HNqnx/crt -g800x600x8 -A0xA0000,0x10000 -WB800
-WM0x0009,5,0,7,0x00100000;#800,600,8,200,1CDVRB,s3 - S3 Trio 64 (S3 Incorporated.
Trio64)
s3bios.ms -i0x105 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3
-HNqnx/crt -g1024x768x8 -A0xA0000,0x10000 -WB1024
-WM0x0009,5,0,7,0x00100000;#1024,768,8,200,1CDVRB,s3 - S3 Trio 64 (S3 Incorporated.
Trio64)
s3bios.ms -i0x110 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3dc
-HNqnx/crt -g640x480x15 -A0xA0000,0x10000 -WB1280 -WM0x0009,5,0,7,0x00100000
-cSW;#640,480,15,200,1CDVRB,s3dc - S3 Trio 64 (S3 Incorporated. Trio64)
s3bios.ms -i0x111 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3dc
-HNqnx/crt -g640x480x16 -A0xA0000,0x10000 -WB1280 -WM0x0009,5,0,7,0x00100000
-cSW;#640,480,16,200,1DVRB,s3dc - S3 Trio 64 (S3 Incorporated. Trio64)
s3bios.ms -i0x113 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3dc
-HNqnx/crt -g800x600x15 -A0xA0000,0x10000 -WB1600 -WM0x0009,5,0,7,0x00100000
-cSW;#800,600,15,200,1CDVRB,s3dc - S3 Trio 64 (S3 Incorporated. Trio64)
s3bios.ms -i0x114 -A0x000A0000 -S0x00010000 -M0x0009,5,0,7,0x00100000 -RL;Pg.s3dc
-HNqnx/crt -g800x600x16 -A0xA0000,0x10000 -WB1600 -WM0x0009,5,0,7,0x00100000
-cSW;#800,600,16,200,1DVRB,s3dc - S3 Trio 64 (S3 Incorporated. Trio64)
#!signature = 6575BF41

=======================================================================
/etc/config/trap/input.3 (Note lowercase ‘i’)

microtch fd -d/dev/ser1

=======================================================================

Alex wrote:

“Walter R. Greene” wrote:

Actually, I meant blank as in no active video at all. The pointer cursor is
present but nothing else.
This occurred while I still had Keyboard and Mouse plugged in along with the
touch screen.

Ugh. Sounds like this is going backwards > :frowning:
Sounds like Input is running, the modeswitcher ran or is still running,
but the graphics driver is not running.

In the default sysinit.node file there was a test and invocation for the
ph.node file. I took this out and
put in the script reference: ‘ph’ as this was described in the help system
(Nothing about ph.node however :< ). The results I got seemed to work as
desired when the keyboard and mouse were installed, but when they were removed,
I got the gray screen with the QNX button bar. However, the touch screen
didn’t work in this configuration.

Just to keep an eye on the objective, I need to boot into Photon without a
login using a touchscreen as the only connected input device.
This would be normal mode. When servicing is required, a keyboard and mouse
may need to be connected.

I’m running in this exact configuration, so it is possible.
(touch screen, no keyboard).

It is beginning to sound like there’s a hardware clash,
or an inconsistency between the hardware and the params supplied
to Input.
Maybe you should post the sysinit.node file, and
/etc/config/trap/crt.node file and /etc/config
/trap/Input.node files.

I would remove the mouse first, but keep the keyboard,
then re-run inputtrap to create a new Input.node file.

Try it in that config with and without the keyboard.
Could be the mouse & touch params to Input are clashing.
You may have to compile your own Input.node file to
make the mouse & touch work together.

I would get a “sin” and “sin ar” (from a text console via a
serial port or telnet or QNX networking) while this is happening,
and in the various configurations you mentioned.
This will give a picture of what’s running and what’s not.

#10

The input.node files only list the microtouch, so that’s why
neither keyboard nor mouse works.

I would delete these input.node files, and then start photon
with both mouse & keyboard & touch connected.

Then do a “sin ar” to see what the parameters are to Input.
If everything works, those parameters must go into
input.node.

If things don’t work, then one can start working on an incremental
basis, keeping what’s working in input.node, and adding the extra
params.

The fact that you have a grey screen with the QNX button means
pdm didn’t run for some reason. This is not necessarily bad.
At least the graphics part & modeswitching is running
correctly. One can get that going later once the input devices are
working.

#11

The mouse and keyboard ‘input’ parameters were removed as they are not
required, in an attempt to make the screen
operate correctly with just the touchscreen present. However, as per
your suggestion, I renamed the two input files and rebooted.
With the keyboard, mouse and touchscreen connected, the system came up.
The touchscreen did not operate (this is not a autodetectable resource),
but the keyboard and the mouse did. I infer that this happend because
the ph.node file contains a check for the existence of
Input.node and if not found runs ‘inputtrap start’. Checking with ‘sin
ar’ gives, as expected the arguments for the standard keyboard and ps2
mouse: kbd fd -d/dev/kbd ps2 -r kb -2 (listed twice for some reason).

Restoring Input.node (…/bin file) with just the microtch command in
place, and rebooting with they keyboard and mouse attached comes up
properly, but the keyboard and mouse both operate as well as the
touchscreen (I don’t know where the drivers are loaded, but they are
reported by ‘sin ar’ as above with the addition of the -R parameter:
kbd -R fd -d/dev/kbd ps2 -r kb -2

Next I unplugged the mouse, and it still came up. They keyboard and
touchscreen drivers were reported as arguments to Input by ‘sin ar’.
=> kbd -R fd -d/dev/kbd

I then unplugging the keyboard and rebooted. This was my point of
failure UNTIL I power cycled instead of issuing ‘shutdown’!!
I seem to be working now. ‘sin ar’ still reports a keyboard though
(where is it running inputtrap?).

Looks like I might be on my way…

Thanks for the help.

Walter

Alex wrote:

The input.node files only list the microtouch, so that’s why
neither keyboard nor mouse works.

I would delete these input.node files, and then start photon
with both mouse & keyboard & touch connected.

Then do a “sin ar” to see what the parameters are to Input.
If everything works, those parameters must go into
input.node.

If things don’t work, then one can start working on an incremental
basis, keeping what’s working in input.node, and adding the extra
params.

The fact that you have a grey screen with the QNX button means
pdm didn’t run for some reason. This is not necessarily bad.
At least the graphics part & modeswitching is running
correctly. One can get that going later once the input devices are
working.

#12

“Walter R. Greene” wrote:

The mouse and keyboard ‘input’ parameters were removed as they are not
required, in an attempt to make the screen
operate correctly with just the touchscreen present. However, as per
your suggestion, I renamed the two input files and rebooted.
With the keyboard, mouse and touchscreen connected, the system came up.
The touchscreen did not operate (this is not a autodetectable resource),
but the keyboard and the mouse did. I infer that this happend because
the ph.node file contains a check for the existence of
Input.node and if not found runs ‘inputtrap start’. Checking with ‘sin
ar’ gives, as expected the arguments for the standard keyboard and ps2
mouse: kbd fd -d/dev/kbd ps2 -r kb -2 (listed twice for some reason).

These must go into input.node, as well as the microtouch ones.
Not sure about the syntax, but I think you can list these
one by one each on a separate line in the input.node file.
If you put these into the input.node file that the ph.node
checks for, inputtrap start won’t be executed.

Restoring Input.node (…/bin file) with just the microtch command in
place, and rebooting with they keyboard and mouse attached comes up
properly, but the keyboard and mouse both operate as well as the
touchscreen (I don’t know where the drivers are loaded, but they are
reported by ‘sin ar’ as above with the addition of the -R parameter:
kbd -R fd -d/dev/kbd ps2 -r kb -2

Next I unplugged the mouse, and it still came up. They keyboard and
touchscreen drivers were reported as arguments to Input by ‘sin ar’.
=> kbd -R fd -d/dev/kbd

I then unplugging the keyboard and rebooted. This was my point of
failure UNTIL I power cycled instead of issuing ‘shutdown’!!

Most likely the pdm.cfg file got corrupted.
This can happens sometimes, depends on when power was removed.
I’m sure the knowledge base will have an entry on it.
(Search for pdm in the knowledge base).

I seem to be working now. ‘sin ar’ still reports a keyboard though
(where is it running inputtrap?).

Don’t know, but I think if you put it together will all 3 pieces
it should all play.