I tried sending this query to the QNXFree86 folks, but I was told that
their QNX4 work is on the back burner and they’re focused on Neutrino.
I am a long-time UNIX hacker (since the '70’s), but have recently
started hacking QNX (4.25). I have joined an organization that had
been using the Metro X release that QNX sells.
I have a PC with a scitech/voodoo graphics card.
I decided to try to bring up a recent version of tcl/tk (8.3.2) under
Metro X, and was having trouble, and someone suggested the XFree86 server.
I brought up the XFree86 binaries that I found at:
http://www.teaser.fr/~jcmichot/QnXFree86/
I just installed core, server (335), and apps. At that point, I ran
xf86config, then startx and a server came up. No apps came up until I
realized that it needed a inetd running, after that, apps came up.
I am not sure I am running the server that best suits my hardware, I
found the configuration kind of confusing, the server came up, but that
doesn’t mean I made the best config choices.
Anyway, I soon ran across a few problems, I’d like to know which
are known, which are unknown, and if anyone has any insight about
them. If no one else sees these, I figure I may have blown the
install. If other folks do see these, I can’t imagine them using the
server for any production work.
- One major problem is that there seems to be a bug with flushing
the event queue. I brought up an xterm, and tried to compile tcltk.
During the run of the configure script, it just hung.
However, I jiggled the windows around on the screen, raising and
lowering two overlapping windows, and the configure started producing
output! So I’m guessing it’s an X event queue problem. I managed to get
all the way through the tcl/tk install, after many window raises.
This only seems to happen when running either (wat) cc or gcc (both! -
which makes me wary about blaming the X server, except that window
jiggling unsticks it). Is this a known problem?
- The second problem, also fairly big, is that the screen stays
black when the X server exits. This seems to be true both when it
exits cleanly and when it exits from a signal or other error.
I assume that some reset code needs to be called to put the screen
back in text mode.
In the absence of a fix for this, is there a program that I can run to
reset the video to text mode?
-
The server seems to freeze now and then, which makes for sub-optimal
realtime response. I have had it freeze at least once during fairly
quiet operation, but I can get it to freeze within seconds by running
“ico -dbl” or “ico -softdbl” . -
The server does not seem to support the X bell, so that when I
echo a ^G, nothing happens. This is less urgent, but it should work.
I’d like to know if these are known bugs, and what I can do about
them. I was very enthusiastic about finding the XFree86 port for QNX,
but I need deterministic behavior if I’m going to use it.
The QNXFree86 folks gave me the impression that at least for them, QNX4
is a dead end (again, my impression, not their words), that they are
focusing on Neutrino - is that common wisdom, or just a local preference?
Andy Tannenbaum