“The Martins” <the.martins@freeuk.com> wrote in message
news:3A3EC744.23F8B27C@freeuk.com…
Igor Kovalenko wrote:
A wise thing for you would be to wait > 
RTP at this point does not support softmodems at all.
Not serious - as long as I can get updates via ANother OS.
I’ve got plenty of experience developing software
modems. Wireless ones, rather than line ones.
I hope it has drivers for AC97 controller chips though.
Well may be you can write a wireless modem/net driver or two then 
Many people miss wireless stuff.
USB support is not out
yet (although it is in beta), not to mention USB vebcams
This is a common cheap method of inputting video
digitally ATM.
I noticed some intention to support keyboards & printers;
things that don’t need to be realtime at all, and are only used
for debugging embedded devices. Unlike video, audio
handsets, VOIP…
Strikes me QNX is concentrating on things desktops
do rather than things embedded devices do. It won’t
win over desktops for web surfing; it should be aiming
for applications like internet videophones… where the
performance of desktops is chronically awful. Is
QNX trying to be a reliable OS for industrial control
or a small efficient RTOS for QoS consumer boxes?
Or everything to all men. Maybe it should stop trying
to be it’s own development environment.
Being self-hosted has many advantages. And won’t find many supporters of
this proposal here.
In fact QNX is concentrating on embedded stuff. They are not trying to
compete in desktop area. What they are trying to do is come up with a
desktop-suited x86-only distribution which would be good enough for people
to develop on it and have some fun. They are trying to make it cute and
self-advertizing.
Their product meanwhile supports other embedded targets, like PPC, MIPS,
SH, StrongARM, flash filesystems, etc.
Many embedded devices need to be USB-connectable
as endpoints rather than as root hubs.
Unfortunately no adequate standards exist for webcams
and each comes with a driver. Many other USB devices
are similar, above the USB link level. At this point
a CPU and OS portable driver is needed to support
devices like digital cameras connected to PDAs, mobile
phones, STBs etc. Perhaps Java has some answers.
They have generic UHCI and OHCI drivers in beta. The rest is in question
yet.
. And I’m afraid
that neither of your 2 soundcards are supported.
As far as I’m concerned, (and Intel etc) Soundblaster is
legacy hardware. I hope nobody developing applications
today would want to support it. The scatter-gather DMA
you get with AC97 controllers at last gives decent sample
I/O technology.
I’ve looked at the details of ELSA and the current version
of ELSA supports AC97, the VIA chipset etc.The version
shipped with QNX doesn’t. Needs a little tidying up, but
nothing serious.
I’m not sure ELSA has a clear model for supporting
generalised sample i/o devices that might be cards, might
be USB handsets, modems etc, and may not even
expose an audio API to applications; eg modems. One
wouldn’t want the whole of ELSA in a device that uses the
VT82C686 drivers for a modem…
Perhaps the QNX developers have something better?
No CR/RW software and there
won’t be until CAM support is implemented (also in the works).
Presumably QNX does not have a native CD filesystem,
relying on ISO9660 & UDF. Isn’t it possible to burn any
set of QNX files using Nero?
Trouble is not so much with filesystems. They have ISO9660+RockRidge+Joliet,
but read-only. No UDF though. It is easy to build a suitable image using
mkisofs, but harder part is to burn it, since drivers do not adequately
support pass-through mode.
How is it doing with 19GB disks?
fine.
UDMA66?
not yet. UDMA33 for now.
Graphics chips
with mpeg video acceleration?
don’t know
Is it installable on typical
off-the-shelf systems at all ATM?
you’re contradicting yourself, aren’t you?
OK most embedded systems
don’t have disks, unless you’re recording video on them.
But they are handy for developing.