How do I Deternmie local/phrelay Event Souce

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

I have an application which controls some fairly large and potentially
deadly industrial equipment. We would like to provide our customers
the ability to access the application via phindows and phrelay but are
concerned with the ablity to perfrom certain maintenance functions
from a non-local location.

What I would like to be able to do is filter the source of key and
mouse events such that they are handled differently depending on
the source. i.e. ignore the “close the million pound clamp” command
if it came from a non-local source. How does on determine if the
originator of an event is phrelay?

If there is no way to do this - is there a way to liimit phindows to
only certain nodes - regardless of password, etc. or prevent it from
taking over the mouse and keyboard. In other words are there any
other security/configuration options available?


We would love to do filtering method bacuse it allows us to deny
access on a much finer level than the “hide the machine” approach.


TIA,
Bill Derby

2

Hi Bill!

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

I have an application which controls some fairly large and potentially
deadly industrial equipment. We would like to provide our customers
the ability to access the application via phindows and phrelay but are
concerned with the ablity to perfrom certain maintenance functions
from a non-local location.

What I would like to be able to do is filter the source of key and
mouse events such that they are handled differently depending on
the source. i.e. ignore the “close the million pound clamp” command
if it came from a non-local source. How does on determine if the
originator of an event is phrelay?

Check the emitter field of the event structure in a filter
callback. You’d have to do that on the user side of the device
region, because the device region itself collects and reemits all
input-type events before they get to the part of Photon event
space where your applications would normally live.

If this is all greek, check out the Photon architecture appendix
to the RTP Photon programmer’s guide – it’s a really rather good
primer to this stuff in its current incarnation. I know, I’ve
been writing course material in that part of the Photon world for
about a month now… :slight_smile:

If there is no way to do this - is there a way to liimit phindows to
only certain nodes - regardless of password, etc. or prevent it from
taking over the mouse and keyboard. In other words are there any
other security/configuration options available?

Have a rummage around on QDN for the Phindows FAQ stuff that was
rolled into the knowledge base – it had some details about what
the limitations of security in Phindows were.


We would love to do filtering method bacuse it allows us to deny
access on a much finer level than the “hide the machine” approach.

Bill, I don’t think Phindows will give you this out of the box,
but you could write code that would put a filter region on the
user side of the device region, and then check the raw events as
they came in to see which ones had emitter fields corresponding
to the region maintained by Phindows.

That’s a pretty sketchy outline, but it should give you some
things to get started with.


Regards,


Norbert Black
QSSL Training Services

3

“William M. Derby Jr.” wrote:

I have an application which controls some fairly large and potentially
deadly industrial equipment. We would like to provide our customers
the ability to access the application via phindows and phrelay but are
concerned with the ablity to perfrom certain maintenance functions
from a non-local location.

My suggestion: analyze your main process’ fathers and grandfathers up to
‘Proc’. If you find a phrelay in the chain, it is a remote controlled
process (you can also analyse phrelay’s FDs then, to checkout, who’s
connected on the other side)

Nice thing …

HTH,

Karsten.

–

| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _ \ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld

4

On 8 Jan 2001 21:02:27 GMT, Norbert Black <nblack@qnx.com> wrote:

Hi Bill!

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:
I have an application which controls some fairly large and potentially
deadly industrial equipment. We would like to provide our customers
the ability to access the application via phindows and phrelay but are
concerned with the ablity to perfrom certain maintenance functions
from a non-local location.

What I would like to be able to do is filter the source of key and
mouse events such that they are handled differently depending on
the source. i.e. ignore the “close the million pound clamp” command
if it came from a non-local source. How does on determine if the
originator of an event is phrelay?

Check the emitter field of the event structure in a filter
callback. You’d have to do that on the user side of the device
region, because the device region itself collects and reemits all
input-type events before they get to the part of Photon event
space where your applications would normally live.

If this is all greek, check out the Photon architecture appendix
to the RTP Photon programmer’s guide – it’s a really rather good
primer to this stuff in its current incarnation. I know, I’ve
been writing course material in that part of the Photon world for
about a month now… > :slight_smile:

The only problem with this is that I’m not trying to filter ALL events

  • and all the context information for filtering would be in the app in
    the photon event space. I suppose I could grab the events and send
    them to the app as a private messages rather than through the device
    region. This would allow the app to treat the phrelay generated stuff
    differently. All I really need to know are the key and mouse button
    events so I could simply re-emit the rest…

The other response by Karsten Hoffmann suggested searching the parent
tree up to proc to see if phrelay were running. This is functionally
the same as the PhSysInfo_t approach outlined in the QDN stuff in
that it sort of solves the problem in that you know the prelay is
running - but you still don’t know whether the command was local or
remote - just that it could be remote…

If there is no way to do this - is there a way to liimit phindows to
only certain nodes - regardless of password, etc. or prevent it from
taking over the mouse and keyboard. In other words are there any
other security/configuration options available?

Have a rummage around on QDN for the Phindows FAQ stuff that was
rolled into the knowledge base – it had some details about what
the limitations of security in Phindows were.

Yes the QDN stuff covers limiting access via the standard password

prompt at the startup of the session. – i.e. adding phrelay % to the
phrelay. file. This does force the user to know the password

  • which guarrentees credentials - but it doesn’t prevent an accidental
    mistake by the remote operator. The lawyers would eat us for lunch on
    this if anyone got hurt. At the minimum we need a special - “By the
    way remote operator what you are about to do can cause potential
    harm” type of message - which requires a password to complete the
    action - we can’t ban the action outright because the local guy needs
    to be able to perfrom this stuff even if phrelay is running. i.e.
    remote guy logs in, goes to lunch and during lunch there is a part
    changover – result: line shutdown until the remote guy comes back
    and shutsdown phrelay…

We would love to do filtering method bacuse it allows us to deny
access on a much finer level than the “hide the machine” approach.


Bill, I don’t think Phindows will give you this out of the box,
but you could write code that would put a filter region on the
user side of the device region, and then check the raw events as
they came in to see which ones had emitter fields corresponding
to the region maintained by Phindows.

That’s a pretty sketchy outline, but it should give you some
things to get started with.


Regards,


Norbert Black
QSSL Training Services

5

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

On 8 Jan 2001 21:02:27 GMT, Norbert Black <> nblack@qnx.com> > wrote:

Hi Bill!

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:
I have an application which controls some fairly large and potentially
deadly industrial equipment. We would like to provide our customers
the ability to access the application via phindows and phrelay but are
concerned with the ablity to perfrom certain maintenance functions
from a non-local location.

What I would like to be able to do is filter the source of key and
mouse events such that they are handled differently depending on
the source. i.e. ignore the “close the million pound clamp” command
if it came from a non-local source. How does on determine if the
originator of an event is phrelay?

Check the emitter field of the event structure in a filter
callback. You’d have to do that on the user side of the device
region, because the device region itself collects and reemits all
input-type events before they get to the part of Photon event
space where your applications would normally live.

[snip]



The only problem with this is that I’m not trying to filter ALL events

  • and all the context information for filtering would be in the app in
    the photon event space.

Shouldn’t be a problem. You can set the filter cb on the region
to only be sensitive to certain types of events, and ignore the
rest. No need to reemit. You could have the region owned by the
app. in Photon, so there’d be no need to mirror the data
elsewhere.

The other response by Karsten Hoffmann suggested searching the parent
tree up to proc to see if phrelay were running. This is functionally
the same as the PhSysInfo_t approach outlined in the QDN stuff in
that it sort of solves the problem in that you know the prelay is
running - but you still don’t know whether the command was local or
remote - just that it could be remote…

As I said before, if you know phrelay is running, you can find
out what its RID is, and then screen for that in your filter cb,
because all events have an emitter field which tags where the
event came from.

There was an event logging program by Randy Martin on QUICS in
/usr/free (called “precord” if memory serves?). It was for 1.1x,
and was hard coded for virtual console 1, but it would give you a
start if you’ve not done work with regions and raw events before
this.


Norbert Black
QSSL Training Services

6

Couldn’t you just provide a command line argument to
the GUI program. If you start it localy you run “GUI”
If you start it via Phindows you start it with “GUI -safe”.
It could depend on the username.

That would mean possibly have two instances
of the GUI running at the same time. I don’t know
if that is what you intented. If not,. at startup of Phindows
ot could start a process that would send a message to
your GUI to turn it into safe mode.

On 8 Jan 2001 21:02:27 GMT, Norbert Black <> nblack@qnx.com> > wrote:

Hi Bill!

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:
I have an application which controls some fairly large and potentially
deadly industrial equipment. We would like to provide our customers
the ability to access the application via phindows and phrelay but are
concerned with the ablity to perfrom certain maintenance functions
from a non-local location.

What I would like to be able to do is filter the source of key and
mouse events such that they are handled differently depending on
the source. i.e. ignore the “close the million pound clamp” command
if it came from a non-local source. How does on determine if the
originator of an event is phrelay?

Check the emitter field of the event structure in a filter
callback. You’d have to do that on the user side of the device
region, because the device region itself collects and reemits all
input-type events before they get to the part of Photon event
space where your applications would normally live.

If this is all greek, check out the Photon architecture appendix
to the RTP Photon programmer’s guide – it’s a really rather good
primer to this stuff in its current incarnation. I know, I’ve
been writing course material in that part of the Photon world for
about a month now… > :slight_smile:

The only problem with this is that I’m not trying to filter ALL events

  • and all the context information for filtering would be in the app in
    the photon event space. I suppose I could grab the events and send
    them to the app as a private messages rather than through the device
    region. This would allow the app to treat the phrelay generated stuff
    differently. All I really need to know are the key and mouse button
    events so I could simply re-emit the rest…

The other response by Karsten Hoffmann suggested searching the parent
tree up to proc to see if phrelay were running. This is functionally
the same as the PhSysInfo_t approach outlined in the QDN stuff in
that it sort of solves the problem in that you know the prelay is
running - but you still don’t know whether the command was local or
remote - just that it could be remote…

If there is no way to do this - is there a way to liimit phindows to
only certain nodes - regardless of password, etc. or prevent it from
taking over the mouse and keyboard. In other words are there any
other security/configuration options available?

Have a rummage around on QDN for the Phindows FAQ stuff that was
rolled into the knowledge base – it had some details about what
the limitations of security in Phindows were.

Yes the QDN stuff covers limiting access via the standard password
prompt at the startup of the session. – i.e. adding phrelay % to the
phrelay. file. This does force the user to know the password

  • which guarrentees credentials - but it doesn’t prevent an accidental
    mistake by the remote operator. The lawyers would eat us for lunch on
    this if anyone got hurt. At the minimum we need a special - “By the
    way remote operator what you are about to do can cause potential
    harm” type of message - which requires a password to complete the
    action - we can’t ban the action outright because the local guy needs
    to be able to perfrom this stuff even if phrelay is running. i.e.
    remote guy logs in, goes to lunch and during lunch there is a part
    changover – result: line shutdown until the remote guy comes back
    and shutsdown phrelay…


    We would love to do filtering method bacuse it allows us to deny
    access on a much finer level than the “hide the machine” approach.


    Bill, I don’t think Phindows will give you this out of the box,
    but you could write code that would put a filter region on the
    user side of the device region, and then check the raw events as
    they came in to see which ones had emitter fields corresponding
    to the region maintained by Phindows.

That’s a pretty sketchy outline, but it should give you some
things to get started with.


Regards,


Norbert Black
QSSL Training Services

7

In article <3a5a1e37.1839449@inn.qnx.com>,
William M. Derby Jr. <derbyw@derbtronics.com> wrote:

[snip, since this part’s been answered…]

If there is no way to do this - is there a way to liimit phindows to
only certain nodes - regardless of password, etc. or prevent it from
taking over the mouse and keyboard. In other words are there any
other security/configuration options available?

The simple solution for this is to write your own program
that validates a connection (by ip or passwd or whatever) before
exec’ing into phrelay. I can give a simple sample if you like.

If you’re really keen :slight_smile: you could have it hang around and
encrypt/decrypt the data stream with its complement on the windows box…

–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.

8

Hi Mario!

On Tue, 9 Jan 2001 11:25:40 -0500, “Mario Charest”
mcharest@void_zinformatic.com> wrote:

Couldn’t you just provide a command line argument to
the GUI program. If you start it localy you run “GUI”
If you start it via Phindows you start it with “GUI -safe”.
It could depend on the username.

That would mean possibly have two instances
of the GUI running at the same time. I don’t know
if that is what you intented. If not,. at startup of Phindows
ot could start a process that would send a message to
your GUI to turn it into safe mode.

  • Mario

The problem occurs when someone uses Phindows to
duplicate the interface screen at the machine (via the -nX argument)
i.e. not starting it’s own photon session on the machine. In this
case, the remote screen can be used to perform anything available to
the local machine – including several functions which are potentially
nasty. So the trick is to only allow the operation to proceed if the
machines is in a “safe” mode or if the operation is initiated locally
where the guy has visual access to the machine. The means that the
interface code must dynamically determine the source of the command
(local/remote) as well as machine state to allow the operation to
proceed. If the setup works properly, the remote person can watch
operations being performed but cannot initate them.

I think Norberts suggestion is probably the best way to go with this.
Currently I have some code which uses PhQherySystemInfo to determine
that relay or phindows is running - this al least lets me prevent the
operation if there is a possiblity of remote control and puts me on
the “safe” side of problem.

Also I CAN use some security through obscurity by not creating
shortcuts for customers which contain the -n parameter. And by
requiring a password for phhrelay would further limit access but I
don’t really want to depend on this because it won’t prevent an
accidental action by a valid person. (myself included!)


–Bill

9

On 9 Jan 2001 16:24:17 GMT, Norbert Black <nblack@qnx.com> wrote:

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:
On 8 Jan 2001 21:02:27 GMT, Norbert Black <> nblack@qnx.com> > wrote:

Hi Bill!

…snip…

The only problem with this is that I’m not trying to filter ALL events

  • and all the context information for filtering would be in the app in
    the photon event space.

Shouldn’t be a problem. You can set the filter cb on the region
to only be sensitive to certain types of events, and ignore the
rest. No need to reemit. You could have the region owned by the
app. in Photon, so there’d be no need to mirror the data
elsewhere.

OK - my application is not actually a standard Photon (PHAB/widgets)
application but is based on using regions directly and implementing my
own “graphics library” which deals with the regions and child regions
directly. This region sits in front of the window manager (and all
other windows). the code that creates the base region is as follows:

----- code snippet begins
memset(&region, 0, sizeof(region));

region.events_sense = Ph_EV_PTR_MOTION_BUTTON |
Ph_EV_BUT_PRESS |
Ph_EV_BUT_RELEASE |
Ph_EV_BOUNDARY |
Ph_EV_EXPOSE |
Ph_EV_KEY;

region.events_opaque = Ph_EV_PTR_ALL |
Ph_EV_DRAW |
Ph_EV_BOUNDARY |
Ph_EV_KEY |
Ph_EV_EXPOSE;


rect.ul.x = Generic_Grf.min.x;
rect.ul.y = Generic_Grf.min.y;
rect.lr.x = Generic_Grf.max.x;
rect.lr.y = Generic_Grf.max.y;

region.parent = Ph_ROOT_RID;
region.origin.x = 0;
region.origin.y = 0;

rid = PhRegionOpen(Ph_REGION_PARENT |
Ph_REGION_EV_SENSE |
Ph_REGION_EV_OPAQUE |
Ph_REGION_ORIGIN |
Ph_REGION_RECT,
&region, &rect, NULL);


…etc…

and then assuming the base_event structure is allocated…

PhEventArm();

loop {
status = PhEventRead(pid, Generic_Grf.base_event,
sizeof(PhEvent_t) + 1000);

… process event…
}

-------- code ends

Now are you saying that if find the RID for phrelay, create another
region like that above and set phrelay as the region parent that I
will get messages from both regions (with the emitter set
appropriately in the case of the phrelay region) from the PhEventRead
in my app? - this would be great!

Is there and easy way to find phrelays’s RID --i.e. programmatically

The other response by Karsten Hoffmann suggested searching the parent
tree up to proc to see if phrelay were running. This is functionally
the same as the PhSysInfo_t approach outlined in the QDN stuff in
that it sort of solves the problem in that you know the prelay is
running - but you still don’t know whether the command was local or
remote - just that it could be remote…

As I said before, if you know phrelay is running, you can find
out what its RID is, and then screen for that in your filter cb,
because all events have an emitter field which tags where the
event came from.

There was an event logging program by Randy Martin on QUICS in
/usr/free (called “precord” if memory serves?). It was for 1.1x,
and was hard coded for virtual console 1, but it would give you a
start if you’ve not done work with regions and raw events before
this.

Actually my app runs in virtual console 1 anyway so that is not a
problem.

I’ll check it out – but isn’t the QNX4 usr/free area down for
repairs?


—Bill

Norbert Black
QSSL Training Services

10

On 9 Jan 2001 17:47:48 GMT, garry@qnx.com (Garry Turcotte) wrote:

In article <> 3a5a1e37.1839449@inn.qnx.com> >,
William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

[snip, since this part’s been answered…]


If there is no way to do this - is there a way to liimit phindows to
only certain nodes - regardless of password, etc. or prevent it from
taking over the mouse and keyboard. In other words are there any
other security/configuration options available?

The simple solution for this is to write your own program
that validates a connection (by ip or passwd or whatever) before
exec’ing into phrelay. I can give a simple sample if you like.

I’m assuming you mean having inetd run my “verifier” instead of
phrelay which (the verifier) would in turn run phrelay after checking
for options.

Actually It looks like I’ll be able to go the “filtering” route so I
won’t need to do this – this time :wink:

If you’re really keen > :slight_smile: > you could have it hang around and
encrypt/decrypt the data stream with its complement on the windows box…

Hmm – exactly how would that complement get implemented on the
Windows side. I can see how this would work on the QNX end - but how
do you get Phindows to connect through another program, or attach a
stream encryption/decryption module under say Windows 98?

Just Curious!
Bill


–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.

11

“William M. Derby Jr.” <derbyw@derbtronics.com> wrote in message
news:3a5b7054.486726@inn.qnx.com…

Hi Mario!

On Tue, 9 Jan 2001 11:25:40 -0500, “Mario Charest”
mcharest@void_zinformatic.com> wrote:

Couldn’t you just provide a command line argument to
the GUI program. If you start it localy you run “GUI”
If you start it via Phindows you start it with “GUI -safe”.
It could depend on the username.

That would mean possibly have two instances
of the GUI running at the same time. I don’t know
if that is what you intented. If not,. at startup of Phindows
ot could start a process that would send a message to
your GUI to turn it into safe mode.

  • Mario


    The problem occurs when someone uses Phindows to
    duplicate the interface screen at the machine (via the -nX argument)
    i.e. not starting it’s own photon session on the machine. In this
    case, the remote screen can be used to perform anything available to
    the local machine – including several functions which are potentially
    nasty. So the trick is to only allow the operation to proceed if the
    machines is in a “safe” mode or if the operation is initiated locally
    where the guy has visual access to the machine. The means that the
    interface code must dynamically determine the source of the command
    (local/remote) as well as machine state to allow the operation to
    proceed. If the setup works properly, the remote person can watch
    operations being performed but cannot initate them.

I think Norberts suggestion is probably the best way to go with this.
Currently I have some code which uses PhQherySystemInfo to determine
that relay or phindows is running - this al least lets me prevent the
operation if there is a possiblity of remote control and puts me on
the “safe” side of problem.

Also I CAN use some security through obscurity by not creating
shortcuts for customers which contain the -n parameter. And by
requiring a password for phhrelay would further limit access but I
don’t really want to depend on this because it won’t prevent an
accidental action by a valid person. (myself included!)

I see your point :wink:

Just that personaly my first reflex is to stay away from the “reflexion”.
I’v seen lots of problem with high refresh rate stuff overloading
a slow connection. But then again your program can adapt
to link speed as well :wink:

–Bill

12

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

Norbert Black <> nblack@qnx.com> > wrote:
William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:
The only problem with this is that I’m not trying to filter ALL events

  • and all the context information for filtering would be in the app in
    the photon event space.

Shouldn’t be a problem. You can set the filter cb on the region
to only be sensitive to certain types of events, and ignore the
rest. No need to reemit. You could have the region owned by the
app. in Photon, so there’d be no need to mirror the data
elsewhere.

OK - my application is not actually a standard Photon (PHAB/widgets)
application but is based on using regions directly and implementing my
own “graphics library” which deals with the regions and child regions
directly. This region sits in front of the window manager (and all
other windows). the code that creates the base region is as follows:

----- code snippet begins
[snipped snippet > :slight_smile: > ]



memset(&region, 0, sizeof(region));

region.events_sense = Ph_EV_PTR_MOTION_BUTTON |
Ph_EV_BUT_PRESS |
Ph_EV_BUT_RELEASE |
Ph_EV_BOUNDARY |
Ph_EV_EXPOSE |
Ph_EV_KEY;

region.events_opaque = Ph_EV_PTR_ALL |
Ph_EV_DRAW |
Ph_EV_BOUNDARY |
Ph_EV_KEY |
Ph_EV_EXPOSE;



Now are you saying that if find the RID for phrelay, create another
region like that above and set phrelay as the region parent

No, not set phrelay as the new region’s parent. You’d set the
Device region as the parent, and provide no “brother in front”
region. That would make the new region appear just user-wards
(if that’s a word…) of the Device region. The key is that you
want the new region to appear between the Device region and the
region owned by phrelay. If it’s not between them, it can’t
filter events passing from one to the other.


that I
will get messages from both regions (with the emitter set
appropriately in the case of the phrelay region) from the PhEventRead
in my app? - this would be great!

With the caveat about parenting/placement above, yes. Merry
Christmas! :slight_smile: Set your region to be sensitive to any types
of event that you care to watch for, and you’ll get those events.

Caveat – I’ve only ever worked on this using regions that are
widgets (and in this case you use a filter callback as the
mechanism to scoop up raw events), but the principles are
identical, I believe.

Is there and easy way to find phrelays’s RID --i.e. programmatically

I was afraid you were going to ask that… :slight_smile: I don’t know of a
way besides doing a system(“phin”) call and parsing the output.
I expect there’s some more subtle way, but whether it’s exposed
to the public, and what it might be are beyond my feeble ken at
this point. Some of the relevant people I could pester are off
at a show in Los Vegas at the moment, but hopefully they’ll see
this thread and chime in later in the week. If you don’t see a
response, try starting a separate thread on the topic Fridayish.


Norbert Black
QSSL Training Services

13

On 9 Jan 2001 22:16:01 GMT, Norbert Black <nblack@qnx.com> wrote:


<… rustle, rustle, SNIP…>

No, not set phrelay as the new region’s parent. You’d set the
Device region as the parent, and provide no “brother in front”
region. That would make the new region appear just user-wards
(if that’s a word…) of the Device region.

Ok this makes sense. I’m asuming that if phindows is started after my
“filter” region is in place it will be a child of the
kbd/pointer/input regions. So my filter region will remain in between
the phindows/relay stuff and the driver region regardless.


The key is that you
want the new region to appear between the Device region and the
region owned by phrelay. If it’s not between them, it can’t
filter events passing from one to the other.

OK – I’ve been looking at the PhT.h stuff and the Neutrino Help for
photon – but It is still not clear how one determines and therefore
sets the region as the child of the device region – how do I find
this. Doesn’t the parent chain go towards the root region (which is
the wrong direction) - is there a secret "PhGetBaseDeviceRid() call or
a perfectly well documented one that I was to stupid to find :wink:

(I can take it - grin)

Is there and easy way to find phrelays’s RID --i.e. programmatically

I was afraid you were going to ask that… > :slight_smile: > I don’t know of a
way besides doing a system(“phin”) call and parsing the output.

ohh YUKKKK – sigh

pragmatism will get the better of me after I get the bad taste out of
my mouth… :wink:

Thanks Norbert!

14

It never fails - As soon as you post something you find what you are
looking for…and then some…

<… rustle, rustle, SNIP…>

OK – I’ve been looking at the PhT.h stuff and the Neutrino Help for
photon – but It is still not clear how one determines and therefore
sets the region as the child of the device region – how do I find
this. Doesn’t the parent chain go towards the root region (which is
the wrong direction) - is there a secret "PhGetBaseDeviceRid() call or
a perfectly well documented one that I was to stupid to find > :wink:

(I can take it - grin)
whack, whack, whack… It’s the shame that hurts most…

PhQueryRids() can be used to search for the regions which intersect an
event emitted from some point - (my app comes to mind) The “Only
Thing ™” I need to know is “type” of the device region. The call
supports filtering the returned regions by type - is the “device
region” you speak of a Ph_GRAFX_REGION? I don’t see any other
types which make sense in this context?

Ok how does Phindows/Relay register… Choices seem to be
Ph_KBD_REGION
Ph_PTR_REGION
Ph_INPUTGROUP_REGION

The interesting thing is that if you know this you can get the list of
RID’s and then call PhRegionQuery to get the Region_t struct for
the RID which in turn using PhGetConnectionInfo gets you the node,
pid, etc…Neatly solving the other “problem” sans phin

Merry Christmas Indeed…

I can determine the types experimentally but does anyone know this
info off the top of their heads?

Bill

15

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

It never fails - As soon as you post something you find what you are
looking for…and then some…

:slight_smile: Been there, done that, have the brick marks on my forehead to
prove it…

… rustle, rustle, SNIP…
OK – I’ve been looking at the PhT.h stuff and the Neutrino Help for
photon – but It is still not clear how one determines and therefore
sets the region as the child of the device region – how do I find
this.

Don’t know where in particular to find it in the docs, but the
Photon course (p. 15-33) mentions two useful macros for regions
ids:
Ph_ROOT_RID (which turns out to be 0)
Ph_DEV_RID (which is 1)

Use the latter in the PtCreateWidget call to set up your region
as the parent argument.

Doesn’t the parent chain go towards the root region (which is
the wrong direction)

Parents are always root-wards of their children. I think that’s
what you meant to convey, right?

whack, whack, whack… It’s the shame that hurts most…

I don’t know – I find the extra time combing my hair over my
forehead to cover the scars a real nuisance too. :slight_smile:

PhQueryRids() can be used to search for the regions which intersect an
event emitted from some point - (my app comes to mind) The “Only
Thing ™” I need to know is “type” of the device region. The call
supports filtering the returned regions by type - is the “device
region” you speak of a Ph_GRAFX_REGION?

I don’t beleive it is, no. The purpose (or a purpose, anyway)
of the region is to intercept, “cook” and reemit input events so
that they have xy coordinates (a “rectangle set”, so to speak).

Now, the region that Phindows (well, phrelay, really) maintains
is a Ph_GRAFX_REGION if memory serves correctly.


Ok how does Phindows/Relay register… Choices seem to be
Ph_KBD_REGION
Ph_PTR_REGION
Ph_INPUTGROUP_REGION

I’m pretty sure all three of those would apply, but I’ve never
investigated this stuff at this level before, so… Hey, Garry
– can you say?

The interesting thing is that if you know this you can get the list of
RID’s and then call PhRegionQuery to get the Region_t struct for
the RID which in turn using PhGetConnectionInfo gets you the node,
pid, etc…Neatly solving the other “problem” sans phin

Merry Christmas Indeed…

I can determine the types experimentally but does anyone know this
info off the top of their heads?

I think my answer counts as a “not really, but…” – hopefully
it’s some help.


Norbert Black
QSSL Training Services

16

In article <3a5b809f.4658307@inn.qnx.com>,
William M. Derby Jr. <derbyw@derbtronics.com> wrote:

On 9 Jan 2001 17:47:48 GMT, > garry@qnx.com > (Garry Turcotte) wrote:

In article <> 3a5a1e37.1839449@inn.qnx.com> >,
William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

[snip, since this part’s been answered…]


If there is no way to do this - is there a way to liimit phindows to
only certain nodes - regardless of password, etc. or prevent it from
taking over the mouse and keyboard. In other words are there any
other security/configuration options available?

The simple solution for this is to write your own program
that validates a connection (by ip or passwd or whatever) before
exec’ing into phrelay. I can give a simple sample if you like.

I’m assuming you mean having inetd run my “verifier” instead of
phrelay which (the verifier) would in turn run phrelay after checking
for options.

Yup.

Actually It looks like I’ll be able to go the “filtering” route so I
won’t need to do this – this time > :wink:


If you’re really keen > :slight_smile: > you could have it hang around and
encrypt/decrypt the data stream with its complement on the windows box…

Hmm – exactly how would that complement get implemented on the
Windows side. I can see how this would work on the QNX end - but how
do you get Phindows to connect through another program, or attach a
stream encryption/decryption module under say Windows 98?

Just a simple tcp app, listen on the port phrelay uses
and pipe everything through to the remote machine.
phindows would think it was connecting local.

–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.

17

In article <93hu37$t6i$1@nntp.qnx.com>, Norbert Black <nblack@qnx.com> wrote:

William M. Derby Jr. <> derbyw@derbtronics.com> > wrote:

Now, the region that Phindows (well, phrelay, really) maintains
is a Ph_GRAFX_REGION if memory serves correctly.


Ok how does Phindows/Relay register… Choices seem to be
Ph_KBD_REGION
Ph_PTR_REGION
Ph_INPUTGROUP_REGION

I’m pretty sure all three of those would apply, but I’ve never
investigated this stuff at this level before, so… Hey, Garry
– can you say?

phrelay registers (at least) as a kbd/ptr/grafx region

The grafx capabilities of the phrelay region will not
have Ph_GCAP_LOCALHW set, and may set Ph_GCAP_PHINDOWS… :slight_smile:

–
Garry Turcotte (R&D)
QNX Software Systems, Ltd.

18

On 10 Jan 2001 15:11:35 GMT, Norbert Black <nblack@qnx.com> wrote:

Ph_ROOT_RID (which turns out to be 0)
Ph_DEV_RID (which is 1)

Use the latter in the PtCreateWidget call to set up your region
as the parent argument.

In my case it would just be a new region – no widgets here…> :wink:



Doesn’t the parent chain go towards the root region (which is
the wrong direction)

Parents are always root-wards of their children. I think that’s
what you meant to convey, right?
Yup – and the input and graphics regions are “the other way”

BTW is there a prefered orientation for talking about this?

i.e root is on the left or bottom or top…

PhQueryRids() can be used to search for the regions which intersect an
event emitted from some point - (my app comes to mind) The “Only
Thing ™” I need to know is “type” of the device region. The call
supports filtering the returned regions by type - is the “device
region” you speak of a Ph_GRAFX_REGION?

I don’t beleive it is, no. The purpose (or a purpose, anyway)
of the region is to intercept, “cook” and reemit input events so
that they have xy coordinates (a “rectangle set”, so to speak).

Now, the region that Phindows (well, phrelay, really) maintains
is a Ph_GRAFX_REGION if memory serves correctly.

Well, from this end (where guessing rules the land) I would think that
Relay would need to have a GRAFX region to handle the sending of the
display stuff to its counterpart (phditto or phindows) but that it
would also have to have the KBD & PTR regions to produce the
appropriate events. Frankly the “INPUTGROUP” thing is a bit of a
mystery to me – what exactly is its purpose?

Ok how does Phindows/Relay register… Choices seem to be
Ph_KBD_REGION
Ph_PTR_REGION
Ph_INPUTGROUP_REGION

I’m pretty sure all three of those would apply, but I’ve never
investigated this stuff at this level before, so… Hey, Garry
– can you say?

The interesting thing is that if you know this you can get the list of
RID’s and then call PhRegionQuery to get the Region_t struct for
the RID which in turn using PhGetConnectionInfo gets you the node,
pid, etc…Neatly solving the other “problem” sans phin

Merry Christmas Indeed…

I can determine the types experimentally but does anyone know this
info off the top of their heads?

Looks like it’s time to put on the white labcoat…

I think my answer counts as a “not really, but…” – hopefully
it’s some help.

Always a pleasure Norbert!

–Bill

19

William M. Derby Jr. <derbyw@derbtronics.com> wrote:

On 10 Jan 2001 15:11:35 GMT, Norbert Black <> nblack@qnx.com> > wrote:
BTW is there a prefered orientation for talking about this?

i.e root is on the left or bottom or top…

Not that I’ve ever seen. The course notes, for instance, use
both root@right and root@left depending on which way the event
we’re trying to follow is travelling – towards or away from the
user. We (I, really…) try to arrange it so that the event is
always travelling from left to right, since that’s the way most
of our customers read text.


Frankly the “INPUTGROUP” thing is a bit of a
mystery to me – what exactly is its purpose?

Erm… You know, I should know… I know
that an “input group” is a collection of physical
mouse/keyboard/touchscreen/whatever associated with a single
user. By grouping them, we allow for screening (lightbulb goes
on) - on where the events are coming from. D’oh!

You know, you could filter based on the input_group member of the
event. Remote connections can be forced into a new input group
(phditto takes a -i, for instance)…

There are bound to be more wrinkles to consider here, but its
another thing to work with towards a solution.


You know, if you get yourself a workable little “screening for
remote input” sample whomped up as a proof of concept, I’d be
delighted to have a copy… :slight_smile: We could get it up on QDN and I
could add it into the mix of sample code for the Photon courses
(albeit probably modified to work on a basis of widgets). Fame
(if not fortune) awaits? (AKA I’d be delighted to credit you in
the comments of whatever modified version goes into the course
sample distribution).


Anyway, back to wrangling with the stuff I should be solving
this morning.


Norbert Black
QSSL Training Services

20

On 10 Jan 2001 16:16:26 GMT, Norbert Black <nblack@qnx.com> wrote:

Frankly the “INPUTGROUP” thing is a bit of a
mystery to me – what exactly is its purpose?

Erm… You know, I should know… I know
that an “input group” is a collection of physical
mouse/keyboard/touchscreen/whatever associated with a single
user. By grouping them, we allow for screening (lightbulb goes
on) - on where the events are coming from. D’oh!

You know, you could filter based on the input_group member of the
event. Remote connections can be forced into a new input group
(phditto takes a -i, for instance)…

This doesn’t quite wok out. if you start phditto with a -i for an
input group that doesn’t exist – it just complains that it doesn’t
exist and refuses to start up… I then tries the -u option which is
supposed to create a new input group and… The “-u” option
appears broken. It doesn’t create the second pointer on my system as
the documentation states – matter of fact it seems to have no effect
at all…


There are bound to be more wrinkles to consider here, but its
another thing to work with towards a solution.


You know, if you get yourself a workable little “screening for
remote input” sample whomped up as a proof of concept, I’d be
delighted to have a copy… > :slight_smile: > We could get it up on QDN and I
could add it into the mix of sample code for the Photon courses
(albeit probably modified to work on a basis of widgets). Fame
(if not fortune) awaits? (AKA I’d be delighted to credit you in
the comments of whatever modified version goes into the course
sample distribution).

With that in mind I have created a variartion of the PhRegionOpen
example which puts region up and draws rectangles which follow the
mouse as it moves over the region. I have created the “filter” region
on the dev side and actually have the thing working. The example will
handle key and pointer events (ESC exits) and the color of the
rectangle will change delpending if you are local or remote.

There are some odd quirks though…

  1. The filter region must specify a region rect. but as long as the
    rect in non-zero the size doesn’t matter - i.e.; you get all PTR and
    KBD events…

  2. You must register for RAW events and you must NOT make the region
    OPAQUE to the RAW events. (i.e. suddenly ALL input is gobbled up and
    you must use another node to terminate the program.)
    My Idea was to change the input_group field of the event and re-emit
    it- but I don’t seem to be able to re-emit the event and have it do
    anything…is there some trick to re-emiting a raw event?

Because this didn’t work I came up with the following: Leave the
region Opaque which means you will recieve 2 events for each
actual event. The first is the raw event and the second is cooked one.
Because both events are directed at the same Queue, you will always
(??) get the raw event message first. This lets you examine the raw
event, determine if its local or remote and set a flag appropriatly.
When you get the second (cooked) event you can use the flag to
determine the nature of the event source. I actualy have a flag for
each event type and only reset it when you get a cooked message of
that type.

It works but is hokey – I have a fair distrust for solutions that
require race conditions to always work out…

  1. For some reason I get the local (Input) KBD and PTR events and
    phrelay KBD events but do NOT get phrelay PTR events – this is really
    bizarre… To get my stuff to work I had to make the remote/local flag
    always reset to REMOTE so that when cooked messages showed up with no
    corresponding raw event they would be handled correctly…
    Any clues here?

I put my example on my FTP site if you want to try it

ftp.derbtronics.com (anonymous)

Its called remote.c and there is a remote.read with the compiling
instructions