Re: [MiNT] fVDI TTF issues

[Standa Opichal <opichals@seznam.cz>]

Hi!

On Sat, 21 Jun 2003, Johan Klockars wrote:

> > > Yes, I know, but I didn't find other way of how to use FreeType except
> > > porting it completely to kernel space.
> > 
> > You can always implement it as daemon or something like that that
> > communicate over a pipe or such thing.

Well, but the pipe handling is also done via the syscalls right? I've 
tried to look into the XaAES handler for this, but I still don't 
understand that perfectly. I know the pipe can be created before the 
interrupt handler is installed, but what about the later communication? I 
can't see a way :(. Sorry, but I'm still not that experienced in FreeMiNT 
kernel coding.

> Could a pipe be used to communicate with a kernel module?

Kernel module would probably use directly the kernel functions so that no 
pipe is necessary, or am I wrong?

> Anyway, if the fVDI kernel module was made to actually support a few
> of the normal file/device handling functions (some or all of open, close,
> read, write, ioctl, fselect), fast bidirectional communication with
> the FreeType engine running as a normal process would be possible.
> 
> > > BTW: What I/O functions should I use from within the kernel module so that
> > > they would perform in the kernel context itself?
> > 
> > As I said, from interrupt handler you can't call very much and especially
> 
> I don't think he's actually talking about running from inside an
> interrupt handler. The only stuff that would run from inside that in
> fVDI would be mouse and keyboard handling (including pointer movement).

? I actually thought that all VDI functions are happening during in an 
interrupt handler since the API is done via the trap instruction...
Could you explain if I'm wrong?

> > no I/O functions. This stuff must run as kernel thread or something like
> > that with it's own context or it must run in a process context (btw.
> 
> I've not looked into this, but is it OK for kernel threads to open
> devices and files then? fVDI will need to do something like that to
> eventually be able to handle the mouse and keyboard nicely under MiNT.

I would guess that the kernel itself should have the complete VFS 
abstraction accessible for its internals. Frank? Others?

> > > The other problem is that I will need to wait for the fvdi.prg to be
> > > initialized before I hook the VDI vector.
> > 
> > I think fvdi must be loaded before FreeMiNT? Otherwise it's not cleanly
> 
> Not currently.

I'm loading the fVDI from the rc.local script. But it is usable even if 
you execute it before in the AUTO folder (this is done in afros - see the 
ARAnyM downloads for more details).

> Anyway, if checking for an active fVDI is currently too difficult,
> that could easily be changed.

I would rather assume to get fVDI into the kernel space as soon as we can. 
But even after that we will need to check whether the module has been 
loaded to be able to hook the FreeType module properly. Or we can build it 
all in one with the fVDI core as most probably all users would like to 
use them both.

> The gcc compilable part (actually, only the assembly is a problem) has
> been almost solved twice now, but neither try got all the way. I recently
> received the conversion scripts (Perl, IIRC) from the second attempt,
> and will try to do something about that RSN(TM).

I'm really missing this. I don't like to play with the expand.o thing 
again and again. Simple make would be sooo cool, believe me ;)
If the other compiler compatibility would be an issue to delay this then I 
would prefer to drop it termporarilly. With this it seems that only you 
are able to compile the engine alone. I was able too some time, but it 
took me too much time to reach that. Please let's improve this!

> weeks. There are some other major changes in fVDI that are only half
> completed, though, which also need to be taken care of.

What about to think about more drivers simultaneously (printing and 
other things...). What about more detailed API for the FreeType module. 
I'm trying to do that as a independent thing and for that I will need to 
wrap the font renderring. This of course can be easily done later when we 
get it working.

FYI: I would be almost off-line in the most of the July probably....

best regards

STan