Dual Monitors&TouchScreens

Is it possible to use Two monitors with Two TouchScreen through Two serial
ports on one computer
under QNX4 Photon?

I have some recent experience with this. The answer is yet,
but there are a few gotch’s to look out for.

While you can run drivers that will support this, the
overall structure was designed short sitedly for only
one touch screen at a time. The major problems are

  1. /etc/config/absf/absf.# file, there is logically only
    room for one configuration file per node.

  2. The configuration program acalib is only oriented to
    one file.

  3. No way to offset the touch screens that I know of. This
    means that you can have two monitors pointing at the same
    place on the screen and both touch screens will work, but
    if you want to have two monitors showing different parts
    of the Photon space, this won’t work. The touch screens
    always jump to the origin of the current work space. This
    was not a problem in my application.

Here is my kludgy work around. Configure each touch screen
separately. After configured, copy the absf.# file to
something like absf.#.one and absf.#.two. When starting
the system you need to do something like the following:

cd /etc/config/absf
cp absf.#.one absf.#
Input … (First touch screen
cp absf.#.two absf.#
Input … (2nd touch screen


If this does not meet your needs I encourage you to
let QSSL know about it.


Previously, Leonid Khait wrote in comp.os.qnx:

Is it possible to use Two monitors with Two TouchScreen through Two serial
ports on one computer
under QNX4 Photon?


Mitchell Schoenbrun --------- maschoen@pobox.com

Mitchell Schoenbrun <maschoen@pobox.com> wrote:

  1. No way to offset the touch screens that I know of. This
    means that you can have two monitors pointing at the same
    place on the screen and both touch screens will work, but
    if you want to have two monitors showing different parts
    of the Photon space, this won’t work.

You could run two completely independent Photon servers. Of course,
then you wouldn’t be able to drag windows from one to the other. That
might not be a problem.

-David


QNX Training Services
dagibbs@qnx.com

“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010306113048.13315B@schoenbrun.com

I have some recent experience with this. The answer is yet,
but there are a few gotch’s to look out for.

While you can run drivers that will support this, the
overall structure was designed short sitedly for only
one touch screen at a time. The major problems are

  1. /etc/config/absf/absf.# file, there is logically only
    room for one configuration file per node.

You can pass a -f option to the abs filter of Input to change
the calibration file. /etc/config/absf/absf.# is only the default.

I can assure you that when Input was designed this was
considered, and the overall structure is designed to be as
flexible as possible without becoming insanely complex for
the high-runner (i.e. single touchscreen) case.

  1. The configuration program acalib is only oriented to
    one file.

True. I bet you can get the source to acalib pretty easily though.

I think expecting the standard calibration app to support a dual
touch screen setup is a bit much (given the incredibly diverse
amount of ways that it could be set up, and the number of users
who would actually require this capability).

  1. No way to offset the touch screens that I know of. This
    means that you can have two monitors pointing at the same
    place on the screen and both touch screens will work, but
    if you want to have two monitors showing different parts
    of the Photon space, this won’t work. The touch screens
    always jump to the origin of the current work space. This
    was not a problem in my application.

The -o option to the abs filter allows changing the origin of
the touchscreen space, the default is the origin of the first
graphics region it locates.

Here is my kludgy work around. Configure each touch screen
separately. After configured, copy the absf.# file to
something like absf.#.one and absf.#.two. When starting
the system you need to do something like the following:

cd /etc/config/absf
cp absf.#.one absf.#
Input … (First touch screen
cp absf.#.two absf.#
Input … (2nd touch screen

This is completely unnecessary, simply use the -f option to the
abs filter (as stated above).

Previously, John Doe wrote in comp.os.qnx:

You can pass a -f option to the abs filter of Input to change
the calibration file. /etc/config/absf/absf.# is only the default.

I guess I asked the wrong person at QSSL when I was
researching this. Yeah for -f.

I bet you can get the source to acalib pretty easily though.

I have.

The -o option to the abs filter allows changing the origin of
the touchscreen space, the default is the origin of the first
graphics region it locates.

Please explain a little further. What is “the abs filter”. Is
this part of Input?


Mitchell Schoenbrun --------- maschoen@pobox.com

Please explain a little further. What is “the abs filter”. Is
this part of Input?

Yes. Input is nothing but a framework that is capable of connecting
a set of “filters” together. When you specify a command line to Input
you specify a set of filters. They are connected from the left to the
right. To make the command line easier to deal with there are default
input filters and output filters that will be used for protocol filters.
When you select a touchscreen protocol filter, the abs (absolute
coordinate) filter will be selected by default as the output filter. For
this reason you don’t normally need to specify the abs keyword on the
command line. The exception to this is if you need to specify an
option to the abs filter (which is what you need to do if you want to
specify a different calib file, or change the origin of the absolute
coordinate system).

To get an idea of what types of filters are present inside Input, you
can do an “Input -l”, this will tell you what filters are present in the
executable, and what type of filter they are.

Previously, John Doe wrote in comp.os.qnx:

To get an idea of what types of filters are present inside Input, you
can do an “Input -l”, this will tell you what filters are present in the
executable, and what type of filter they are.

This helps a lot. Thanks.



Mitchell Schoenbrun --------- maschoen@pobox.com

“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.010312135206.21894F@schoenbrun.com

This helps a lot. Thanks.

Your most welcome.