Hi All,
if you are trying to re-compile XFree86 3.6.3 for QNX 6.1 … please
set the flag BOOTSTRAPCFLAGS.
That means the make cmd has to be: make World
BOOTSTRAPCFLAGS=’-Di386 -D__QNXNTO__’ >& your.log
(QNX6.1 supports different processors …)
Regards
Armin
Can you post your diffs (patches) to the xfree3.3.6 on sourceforge
rather than the whole source tar file?
I already have the xfree3.3.6 original tar file and don’t want to
waste the bandwidth. Also, with the diff, I can easily find out
the enhancement/fixes you made against xf3.3.6. One problem I had
was xf3.3.6 only supports serial mouse on NTO, I am wondering if
you’ve improved that.
Thanks!
frank
On Tue, 14 Aug 2001, Armin Steinhoff wrote:
Hi All,
if you are trying to re-compile XFree86 3.6.3 for QNX 6.1 … please
set the flag BOOTSTRAPCFLAGS.That means the make cmd has to be: make World
BOOTSTRAPCFLAGS=’-Di386 -D__QNXNTO__’ >& your.log
(QNX6.1 supports different processors …)
RegardsArmin
Frank Liu wrote:
Can you post your diffs (patches) to the xfree3.3.6 on sourceforge
rather than the whole source tar file?
There is nothing changed at the XFree86 site … only QNX6.0 and
QNX6.1 are different 
I already have the xfree3.3.6 original tar file and don’t want to
waste the bandwidth. Also, with the diff, I can easily find out
the enhancement/fixes you made against xf3.3.6.
Are there diffs at the XFree86.org site for 3.5 and 3.6 ??
One problem I had
was xf3.3.6 only supports serial mouse on NTO, I am wondering if
you’ve improved that.
The idea of Sourceforge are PROJECTS, that means the sources should
be available for downloading, too. So everyone who wants can join a
project. So everyone will be able to extend or improve the sources.
BTW, all sources are available on the pages I created
… drop me a mail if you need administrator rights for openqnx,
you are welcome
Thanks for your efforts,
Armin
Frank Liu wrote:
Can you post your diffs (patches) to the xfree3.3.6 on sourceforge
rather than the whole source tar file?There is nothing changed at the XFree86 site … only QNX6.0 and
QNX6.1 are different >I already have the xfree3.3.6 original tar file and don’t want to
waste the bandwidth. Also, with the diff, I can easily find out
the enhancement/fixes you made against xf3.3.6.Are there diffs at the XFree86.org site for 3.5 and 3.6 ??
One problem I had
was xf3.3.6 only supports serial mouse on NTO, I am wondering if
you’ve improved that.The idea of Sourceforge are PROJECTS, that means the sources should
be available for downloading, too. So everyone who wants can join a
project. So everyone will be able to extend or improve the sources.BTW, all sources are available on the pages I created
… drop me a mail if you need administrator rights for openqnx,
you are welcome >Thanks for your efforts,
Armin
on a personal note Armin, all this XFree86 verses XPhoton
really confuses me, to expand, on the one side i think it was you
that says (presumably your port above) runs faster apps
faster than the same app ./configure`d for XPhoton and that
is something i personally care about in relation to the ONE APP i need
and desperetly want to run while inside RTP.
that app is UAE (Unix Amiga Emulator, yes i know must call it by
other names these days but thats still the official name).
now this might get rather convolted as i try and explain
in my limited non coder way as to what i can get working,
what i need from UAE and the help of any willing people reading this thread
(well the thread if people can be bothered to reply in detail LOL)
but please try and get through it for my sake.
before i begin, i`d like to thank the 2 developers that have
gone to the trouble of creating a Photon and Photon-JIT
version for me many moons ago (you know who you are)
but allas due to whatever reasons (time,work commitments ect)
they have not been able to expand on the base UAE options
i.e no Piccasso4 screen modes or BSD socket emulation
(theres a patch for that bsd in linux source now btw).
the reason i want to run UAE inside RTP is simple,
i can then use this unrivaled on any platform IMPO
Amiga Thor Email/News client, use CED (cygnus Editor)
the my prefered SID2 (better than Dopus4/worker1.3.3).
while i could live without the BSD Socket Emulation
for the short term (i.e i`d not be able to poll/post
email/news while inside RTP) as i could re-boot to win98se
and do it there, id rather not have to as that kills
the RTP learning curve.
what i can NOT live without is a working Piccasso4 screen mode
while running on this AMD 500/128 ram/Voodoo3-2000 AND
a usable speed (Ph)UAE Thor/CED/SID2 at the same time.
i can currently have one or the other but not both 8(
now i realise that useing the XPhoton layer for any Gfx
does seem slow compared to native Photon and thats fine
as far as some apps go and im amazed that so many apps are being ported ( im not sure/convinced ./configure - make is clasifyed porting), but i most say that im
rather disapointed that given that RTP has been released
for a fare time now that more Dev people arn`t seeing fit
to port at least the Gfx parts of these (X) apps to
native Photon to gain a better speed.
i seem to remember that you ? and Igor ? were debating
weather RTP Ported XFree86 was better/faster than XPhoton,
now weather that was the case or not i dont know , but i
have this notion (write or wrong ) through these debates
that XFree86 was a seperate indipendent Gfx driver/API
in relation to XPhoton (much like Piccasso4 <>CGX3)
now here begins my confusion:
presumably your compileing your RTP XFree86 port on
lets assume RTP6.1
i have
QNX rtp 6.1.0 2001/06/25-15:31:48edt x86pc x86
XFree86 is a seperate package/API that uses linear frame buffer
were as XPhoton does not, hence the implication is that XFree86
should be at least a little faster in relation to UAE
…/configure (UAE-0.7.6).
now theres even a posibility that once XFree86 V4.0.*
is ported to RTP that we might be able to have a second
gfx card (S3Virge) and CGX3 installed and use that natively
inside UAE as theres a patch for that in the linux UAE8* JIT.
however theirs still one major wall before that can even be
attempted and that is while i can ./configure, Make, the older
UAE-0.7.6 the UAE-0.8.* all the way up to the new 0.8.17 will
no longer compile on RTP, seems that this so called Automake/
autoconf stuff to generate a cross-platform ./configure
isn`t so auto*matic after all 8(
the biggest downer is that just about all the best inovations
as regards UAE all rely on the UAE-0.8.8 code and above,
JIT, native Virge gfx , bsd Socket emulation 8(
perhaps some kind soul thats a wiz at this Auto* *.in scripting
can take a look at the latest linux UAE-0.8.17 and write
a fixed/functional RTP set of *.in files that Autoconf
can parse to make a working RTP6.1, even if it only
gets a working XPhoton/Xfree86 0.8.17 version its a good
base for others to start improving it for Native Photon
dont forget to submit it to the UAE maintainers for the next
general release 
.
http://amiga.nvg.org/uae/index.html this url is great
for chatting with the main UAE developers/links to the
newest source and folling back to the official site
to get a UAE-0.7.6 if you want to try that as i did.
http://amiga.nvg.org/uae/MESSAGES/19601.HTML gives reference the
bsdsocket emulation patched binary Linux version, i assume
theres source there to (iv not checked as im offline right now)
as i understand it the linux/RTP automake and autoconf are made to take
some generic *.in scripts and parse them into a working ./configure/make ?.
hers what i get with a clean full install of RTP 6.1
/usr/temp/uae-0.8.17
configure.in: 34: AM_CYGWIN32' is obsolete; use AC_CYGWIN32’
configure.in: 35: AM_MINGW32' is obsolete; use AC_MINGW32’
configure.in: 73: automake requires AM_CONFIG_HEADER’, not AC_CONFIG_HEADER' aclocal.m4: 614: AM_CYGWIN32’ is obsolete; use AC_CYGWIN32' aclocal.m4: 615: AM_MINGW32’ is obsolete; use AC_MINGW32' automake: configure.in: PACKAGE’ not defined in configure.in
automake: configure.in: VERSION' not defined in configure.in automake: configure.in: required file ./install-sh’ not found
automake: configure.in: required file ./mkinstalldirs' not found automake: configure.in: required file ./missing’ not found
automake: no `Makefile.am’ found or specified
automake seems to have several problems for whatever reason
presumably no ones updated the scripts for a long time
given the errors, and/or RTP autoconf is in some way different
to the versions the main linux peole are useing ?
its beyond me.
given that the prior UAE 0.7.* versions run and have no problem
as regards reading/mounting any filesystem its clear that the 0.8.* releases
were broken somehow, is it that this auto* configureing isnt as cross-platform as iv been lead to beleave or is it just that some curectable mistakes
have been made and are easy for a RTP`er to put right and submit
them to the main code tree so everyone can benifit in the next release ?.
they dont seem to use that configure.guess/configure.sub eather, is that
required to automake/conf reliably ? and would someone be willing
to update the newest UAE scripts to compile out of the box please ?.
remembering that the above is a fresh clean install of RTP6.1,
i cant seem to find a direct link to your Xfree86 port and i`m
not online that much these days to remember to look for it when
i get the chance (so an attachment upto 3megs would be uk)
so Xfree related headers/libs shouldnt be on this ?.
how come i can gunzip the older UAE-0.7.6
how come configure --enable-dga , make, produces a WORKING DGA binary,
DGA IS Xfree86 is it not ?
the uae docs imply that the DGA option should open a full screen
gfx display however thats not the case here ? i get a window with drag.
more confusing still, is the fact that now RTP6.1 these files in X11 /extensions
… XInput.h XKBstr.h Xext.h multibuf.h xf86dga.h
… XIproto.h XKM.h dpms.h record.h xf86dgastr.h
MITMisc.h XKB.h XKMformat.h dpmsstr.h recordstr.h xf86misc.h
Print.h XKBbells.h XShm.h lbxbuf.h saver.h xf86mscstr.h
Printstr.h XKBconfig.h XTest.h lbxbufstr.h saverproto.h xf86vmode.h
XI.h XKBfile.h Xag.h lbxdeltastr.h scrnsaver.h xf86vmstr.h
XIE.h XKBgeom.h Xagsrv.h lbximage.h security.h xtestext1.h
XIElib.h XKBproto.h Xagstr.h lbxopts.h securstr.h
XIEproto.h XKBrules.h Xdbe.h lbxstr.h shape.h
XIEprotost.h XKBsrv.h Xdbeproto.h lbxzlib.h sync.h
i got the impression that Xfree86 was seperate from X, i take it thats wrong.
now given that
…/configure --enable-dga now works and is presumably useing the above
new xf86dga.h in /usr/X11R6/include/X11/extensions then it follows that
(at least to me) that
…/configure --enable-dga --enable-vidmode is compiling useing the again
new as above xf86vmode.h ?.
so why when trying to run the ./configure --enable-dga --enable-vidmode
that the exe produces
Xlib: extension “XFree86-DGA” missing on display “127.1:0.0”
Unable to query video extension version
does that mean that standard RTP6.1 can generate an Xfree86 app but cant
run it because somethings broke in the newest RTP ?
one thing to note though, while the standard ./configure make
produces a binary thats just not quite fast enough to be useable
on this AMD500 due to Xphoton, i really thought that Xfree would be
at least slighty faster, assuming that the working DGA 0.7.6 version
is useing i assumed native (i.e non Xphoton) Photon or native Xfree
(for want of a better word), then it seems that even Xfree86 isn`t
any faster than Xphonton so far.
i suspect and hope that the reason i got the above missing on display
was because i need to install Armin`s Native Port and that will
override the RTP Base packages and things will start flying.
possible BAD bug in all Xphoton apps:
on a side note while i remember, heres a reproducable bug, weather its
ditto, XPhoton or something else i dont know but it needs fixing
if the intension is to keep useing XPhoton ported apps.
take a clean install of RTP6.1 (partion or hardfile doesnt matter)
goto qnxstart and grab worker1.3.3 (Dopus4 Clone)
i didnt know how to cleanly ./confiigure it so i just gunziped/tar -xvf
it to a /usr/temp dir
copyed the full X11 dir to the same dir as worker
…/configure
make
make install
thats gets you a pritty good working Xphoton sid2 like file util
(way better that that windows style file app as standard)
make the UAE-0.7.6 as above but you will need an amiga 3.1 ROM
image to test this bit, i beleave several QSSL people have amigas
around so it sound be farely easy to find one or grab a download
copy from the http://www.cloanto.com/amiga/amigaforever for a few UKP
and that has official encripted ROMS that should be just as good.
actully if we ever get a working UAE/Piccasso4 for RTP then with
the amigaforever download and a small shareware fee 25UKP to the
Thor people at Utima Thule Software you to could be useing the
greatest Email/news client anywere LOL.
so you have XPhoton worker running, place said Kick.rom in the same
dir as UAE, start UAE from a shell and you should see the window
with the animated kickstart in it.
now if you slay uae , thats fine, however if you happen
to simpley mouse click the top right Photon close gadget
then every open Xphoton app (worker1.3.3/UAE in my case will close down.
-X11 TransSocket Inet Connect: Cant connect ErrNo:261
-X11 TransSocket Inet Connect: Cant connect ErrNo:261
-X11 TransSocket Inet Connect: Cant connect ErrNo:261
-X11 TransSocket Inet Connect: Cant connect ErrNo:261
-X11 TransSocket Inet Connect: Cant connect ErrNo:261
-X11 TransSocket Inet Connect: Cant connect ErrNo:261
cant open Display!
repeates forever, now if you happened to say start worker
a few times after the Xphoton server shutdown heres weard.
ctrl/alt 2
login on that shell and restart ph
then photon pops up and all the Xphoton workers you started
suddenly spring to life from the other session, you`ve lost
all your work from the Xphoton apps that were started before
the crash but still fun when i saw it the first time LOL.
i did get ditto as supplyed with 6.1 to crash too but i cant remember
how i did that and dont have the time to redo it right now,
however i do remember that ditto or perhaps its Xphoton server or apps ?
has another issue.
presuming worker1.3.3 is running on the ditto machine,
that you also have a fresh install of RTP6.1 on a second
eathernet machine and have edited second machine to include inetd.
run a simple UAE hardfile (or floppy adf, didnt try an adf)
on the second machine or Xphoton worker1.3.3 should be enough
then ditto from machine1 to machine2 and try and see the remote
Xphoton windows, they all totally mess up in the local ditto
windows and with enough simple messing around you can bring
the ditto connection down (as i said i cant remember exactly yet)
but the messed up screen/ps2 mouse is a large bug in itself.
so is it a Xphoton bug thats bringing down ditto or ditto itself ?
when/will we get a better Xphoton/ditto in a reasonable time ?.
hopefully i`v given enough info to at least inspire some
readers to consider helping me and i suspect quite a few other
users a working 8.* UAE, heres hoping.
this Xfree<>Xphoton thing would be nice to understand too .
later my friends.
Paul May, Manchester, UK,