> This is what I did. Sure, I should subscribe to the ML.
Please do. I'll CC to it in the meantime.
> Just to summarize the pb, demo programs coredump when reaching the X
> library (XCreateWindow) during or after the ggiSetMode call. I'd rather
> post the process stack to the ML.
Argl ... strange. I ran LibGGI sucessfully on Solaris and IRIX, so I wonder
what is different for BSD ...
Do you have MT-safe Xlibs ? if not, disable the threads support in LibGGI
and libGII.
> > We will try to help with anything you encounter. There are no silly
> > questions, just silly answers - o.k. ?
> So, here's the first one: how do I compile everything statically?
This is not yet possible. LibG** is inherently dynamic as we explicitly load
the target and rendering libs. This allows to keep dependencies low and
distribute binaries without regard to what is available on the target
system.
However we have prepared the linking system to allow for this case a few
months ago and it should be relatively easy to add, if yreally needed.
The new naming scheme for the lib entry points does in theory allow to just
link in the targets and replace the dlopen/dlsym calls with access to a
table.
> > > but libggi under X is actually uninteresting.
> It is for a newbye :)
Yes. And we recommend to start out that way, as the X target is well tested.
> > Kind of, though it is handy, as e.g. Mime-entries will work whether in X or
> > not and such things. I love running XGGI instead of XFree on the Linux
> > fbdev, though.
> How much performance do you loose? This is an issue for which I could
> not find any info on the Web site.
XGGI vs. XFree ? Not much as my KGIcon driver is accelerated for lines,
boxes and blitting. Accelerated text rendering is the main thing I
miss. All normal stuff is up to par AFAIK. We'd need to run some tests, but
I can't a s regular X usually locks up my machine ...
> > > > Before promising anything, I have to estimate the effort needed for the
> > > > job. I have pretty good knowledge about system/kernel programming but
> > > > not about graphics. So I must know if most of the work to do will
> > > > concern mostly low level programming.
> > I'd be very very glad, if you helped out on this. I am too busy even to run
> > the errands of LibGGI at the rate I should and I currently have no time to
> > play around with BSD for that reason.
> At least, I can try.
Thanks - you are very welcome. Especially, as BSD has a much saner console
system than Linux ... *gg*.
> > But I'd really like to help you, if you would want to try to port the
> > KGIcon machine layer to BSD which should automatically make the KGIcon
> > graphics drivers work.
> As far as I understand, KGI provides low level support to GGI
> highlevel graphic objects?
KGI is intended to be a standard for coding graphics drivers in a portable
way. The old KGIcon has been proven to be portable to at least 4 pretty
different environments: Linux with patches (old scrdrv approach), plain
Linux with fbdev interface, Linux running from usermode and the Mystery-OS I
may not talk about *g*.
> If all is ok, I'd like to port GGI to the embedded world.
Yes. This has been done before. GGI is designed exactly for that. You can
strip it down very much if size is an issue.
> Is there already something on the subject?
Yes. There have been several projects using it. AFAIK most of them are under
NDA, though.
> Seems difficult?
Not at all. I have done such a port myself and it was pretty
straightforward.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
