I tried running devi-rpxlite and discovered that there is a dependency on
libph.so.2. This is a bad sign, unless I’ve completely misunderstood the
whole Input DDK rationale. I always assumed that when people develop
against the devi* APIs that they are effectively in a Photon-free
environment. That seems to be the indication from all of the
documentation that I’ve read. There is really no point in working at a
lower level than Photon if Photon libraries are required. So, what gives?
Is this a special case, or can I expect this behavior on other platforms
with other drivers?
Actually I don’t understand your question. devi-rpxlite is a input driver
for the Photon. What’s bad if it is linked to native photon library? What is
a disadvantage in this fact? Indeed, input API uses photon library only for
the communication with Photon. If you are developing driver which doesn’t
want to know anything about Photon, just don’t use those input library
modules that need Photon and forget about it. Using standard input driver in
resource manager mode (-Pr command line arguments) is not a typical way, so
we don’t care about dependency on Photon libraries.
I tried running devi-rpxlite and discovered that there is a dependency on
libph.so.2. This is a bad sign, unless I’ve completely misunderstood the
whole Input DDK rationale. I always assumed that when people develop
against the devi* APIs that they are effectively in a Photon-free
environment. That seems to be the indication from all of the
documentation that I’ve read. There is really no point in working at a
lower level than Photon if Photon libraries are required. So, what gives?
Is this a special case, or can I expect this behavior on other platforms
with other drivers?
Well, that kinda makes sense, although I don’t like the answer.
Apparently, you guys can keep the devg* drivers independent of Photon
dependencies (according to what I can learn with objdump). Its seems to
me like you could keep devi* drivers independent as well. I guess my
point is that having a dependency that goes in the opposite direction can
be confusing. If you offer a non-Photon resource manager interface to an
input driver, you should honor that commitment by not requiring Photon
libraries. I’ve been impressed over the years with what you QNX guys have
accomplished, so I guess that’s why I expect everything to be perfect
Hopefully, you can at least think about what I’m suggesting here. Or
maybe you could enlighten me as to the reason for the libph.so.2
dependency rather than a separate .so file which both devi* drivers and
Photon could share?
This is a sort of compromise. We can make devi-hirun free of libph
dependency and pay for that with some increase of its size. In this case you
get an essential benefit in rare cases, but have some (maybe not a big) loss
for most of customers. It is usually not easy to make a choice. However, I
can promise you we would think about that possibility.
Well, that kinda makes sense, although I don’t like the answer.
Apparently, you guys can keep the devg* drivers independent of Photon
dependencies (according to what I can learn with objdump). Its seems to
me like you could keep devi* drivers independent as well. I guess my
point is that having a dependency that goes in the opposite direction can
be confusing. If you offer a non-Photon resource manager interface to an
input driver, you should honor that commitment by not requiring Photon
libraries. I’ve been impressed over the years with what you QNX guys have
accomplished, so I guess that’s why I expect everything to be perfect >
Hopefully, you can at least think about what I’m suggesting here. Or
maybe you could enlighten me as to the reason for the libph.so.2
dependency rather than a separate .so file which both devi* drivers and
Photon could share?
