Re: [AD] Linux keyboard patch, and to-do list

[Jason Wilkins <fenix@xxxxxxxxxx>]

On Fri, 2 Jul 1999, George Foot wrote:

> I don't see what you mean.  I/O ports are accessed at the
> assembler level through x86 in/out instructions; the driver will
> fill in a pointer to a list of ports it needs access to, and you
> have to arrange this.

I have a function called IOBase which will return a pointer to the
IOPorts.  I assume that you are then supposed to use in and out to access
these addresses.  I can't get the function to return anything but 0 right
now, so it may have been removed (they've been saying it may be taken out
for years now).  But, what I was assuming was that they remapped the IO
ports base address into your program's address space so you could fiddle
with them.  But now that I think about I don't think that io ports can be
remapped, so I don't know exact what IOBase returns.

This seems kinda strange to me however, maybe the IOBase function is to
handle multiple adaptors, allowing your in/out code to switch to a
different card if it has to.  In that case it would return the base
address of the current card in use.

I'm goint to have to write a small program to attempt to write an IO port
and see what happens.  What port do you think I could write and not crash
the machine if it works?

My plan of attack was to use the cloned graphics driver I get from the
BeOS to get me a pointer to the frame buffer and io ports.  But it appears
that the vbe/af driver wants me to get these itself and put them where it
wants them to be.

> supports both methods; or maybe it doesn't require you to ask
> permission before playing with ports.  I presume though that
> you've already come across this problem with your other graphics
> drivers -- unless the OS itself is setting the display mode for
> you?

ioperm and iopl and both linux specific according to the man pages. I'm
using a clone of the graphics driver provided by the OS to set modes.

> It's not quite like that.  The card itself will be mapped into a
> memory region already.  The driver will tell you where, and then
> you have to give the driver (and keep for your own use, in
> writing to the framebuffer later on) a pointer that your program
> can use to access that region.

Okay, giving the driver a pointer to the framebuffer would be no problem.
I can use mmap on the BeOS to get the framebuffer, but the act of
disconnecting the 'application server' (which is analogous to an X
server) so vbe/af can directly fiddle with the graphics card will mmap the
frame buffer automatically.

My only problem then is whether this also gains my program permissions to
fiddle with the io ports.  Am I right to guess that if I just ignore the
list of io ports and just assume that I have permission to fiddle with
them (I'd have to, the BeOS graphics driver has been cloned into my
address space, meaning that my code must be able to access them) that I
the driver would work?  I say this because I'm guessing the driver tells
you about what ports it need so you can set them up with correct
permissions.

Direct access to the BeOS graphics driver is pretty good, it allows you to
hook into several accelerated features.  I'm beginning to think that the
BeOS's BWindowScreen API is very much like VBE/AF.  It works by
disconnecting the application server from the screen, and then making a
copy of the graphics driver into your address space.  Now, your program
has access to several standard acceleration hooks and a lot of control.

The thing is that the standard hooks are rather limited.  There is a
screen->screen blit function, rectangle fill, invert, and line drawing,
but thats about it.

My guess is that if I loaded a VBE/AF driver and attempted to use it, that
it could take advantage of the same things that the copy of the BeOS
graphics driver can.  That being that in order for a clone of the Be
graphics driver to work, my program has to have been given permission to
fiddle with the graphics registers and I can give the VBE/AF driver the
same pointer to the frame buffer that the BeOS graphics driver gives me.

To make a long story short, I can let the BeOS graphics driver do all the
work to set things up, but then abandon that and use VBE/AF instead and
take advantage of features that the BeOS driver doesn't expose.

> This is best done through memory
> mapping -- you call an OS function (mmap on Linux), passing the
> physical address and size of the block, and it gives you a
> pointer within your own address space which is being mapped onto
> that physical space.

>  That's then your framebuffer pointer.
> Some drivers will need other regions as well, but the principle
> is just the same.

This is posix, and the BeOS supports it.  I would need to use this for any
drivers that need more than just the frame buffer to be mapped.  Are
those other areas needed for system bitmaps?  I don't know what system
bitmaps are yet, I was thinking they were for holding data, but could not
be displayed like video bitmaps.

Hmm, a wicked thought just accured to me.  Would it be possible to mmap
the frame buffer, but also map it to a file?  The result would be a file
that contained the exact contents of the frame buffer.  That would be an
interesting thing to try.

> In terms of djgpp, in nearptr mode, the vbeaf.c code just
> subtracts the linear address of the start of the data segment
> from the required linear address.  I expect in BeOS you'll need
> to use memory mapping functions though.

How many drivers will need more than just the frame buffer and what do
they use these other areas for?  The ability to support these drivers will
depend on if I can map these privileged areas to my program.  I'll
probably just have to try it and see if it works.  I'll try mmap first
(when I finally get around to it) and then if that fails I use the native
memory mapping functions.

> Shawn added an extension to the FreeBE/AF drivers which lets the
> application fill in a selector/offset pair, rather than an
> offset which is assumed to be in the data segment.  You don't
> need to support this if you don't want to; in any case you can
> just put DS as the selector and the same offset you would
> otherwise.

I don't know if I can support it.  I doubt the BeOS lets you play with far
pointers in anyway at all.

> -- 
> George

--
         The Phoenix - President of The Artistic Intuition Company
    Caelius * Zen-X * Mirror Reflex * Runica * X-Domain * Infinite Realms
                          http://www.io.com/~fenix