| From: | Rudi Chiarito |
| Date: | 15 Sep 2000 at 20:41:04 |
| Subject: | Re: AMIOPEN: Dev Questions |
On Mon, Sep 04, 2000 at 02:47:57AM -0700, Patrick Roberts wrote:
> Q: Are the threads different from Unix threads? If so, in what way?
> I'm planning to port the POSIX threads API (pthread_create etc.),
> so any hints would be helpful ;)
Yes, they're different indeed. The documentation that can be found at
<sys/kn/proc/api.html> should give you more insight. A port of the POSIX
thread API is in progress already. More news will follow.
> Q: How can shell commands be launched with options a from primary
> tool if shell environment doesn't exist?
You can use the kernel process management tools directly. See
<sys/kn/proc/api.html>. Aaron Digulla's ixemulng ixemul_exec.c uses
these tools to provide a *nix like exec replacement:
http://www.amigadev.net/cgi-bin/cvsweb.cgi/~checkout~/ixemulng/ixemul_exec.c?rev=1.3&content-type=text/plain
> Q: Is it possible to directly read the keyboard matrix ?
> (e.g. detect if three keys are pressed together?)
Welcome to the real world. :) There is no ultimate answer to that:
- 'No' when you use most industry standard keyboards (eg PS2). The
keyboard controller inside the computer talks to the controller inside
the keyboard which is the only one having access to the matrix. All
you get is a serial data stream representing pressed keys. Programming
is limited to repeat/delay rate and/or fancy LED switching. - 'Yes'
but not guaranteed when the keyboard is integrated into the main
unit therefore /possibly/ allowing direct access to the matrix.
- 'Don't know' if the computer is controlled by a touchpad.
- 'No' because you're not supposed to know what h/w you're running on.
To detect (multiple) pressed keys it is easier to claim the raw keyboard
device and generate a per-key-bit-vector... then again this implies
exclusive access to the keyboard anyway. Which you might not be able to
get in a given environment.
If the application depends on AVE key events do the same vector thingy
based on up/down events. Response/latency may vary.
It's hard to imagine getting something useful out of, say, pressing g+p+%
together. If one is interested in something like shift+ctrl+something
then it's up to the cooking table to return an appropriate key code.
> Q: How can gadget color, font, and texture properties be changed?
Look at the dev/ave/default.prp file. This assumes you are using the std
toolkit. It should be noted that the property system will be overhauled
in the near future.
> Q: Is it possible to change the mouse pointer (and how?)
Not currently, but in the next major update it is. Whether or not this
will be possible on a particular host OS is dependant on that OS, of
course.
> Q: Are any pixmap blit methods hardware accelerated?
Currently, none. However hardware accelerated pixmap drivers for certain
graphics cards are on the way. Plus several VHDL compaines are now
creating support silicon specifically for the AVE.
> Q: Is blitting a 15bpp pixmap to another 15bpp pixmap going through
> any color conversion?
Not if the pixmaps are the same type, no.
> Q: How can pixels be directly written to a pixmap frame buffer?
You're not supposed to do that, it's illegal! Unless you are creating
your own pixmap class, in that case of course you can go direct to the
pixel buffer, how else do you plot anything. ;)
You should be using the pixmap API to plot to a pixmap. Otherwise your
program won't make use of native/accelerated tools when available.
Although it's illegal to write directly to a pixmap buffer, you have an
option in some cases. You can allocate yourself memory for your internal
buffer, write to it as needed and then create a pixmap out of it, by
passing its pointer as the first argument to ave/avo/pix/*bit/open (check
<ave/avo/pix/api.html>). After that, though, it's not a good idea to keep
writing in the buffer bypassing the pixmap API.
> Q: Is there an example of, or how can the keycooked device
> be made to send events to a gadget/application (EV_KEYUP, EV_KEYDOWN)
By default, mouse events are received, while keyboard events are not.
That's because the keyboard is a non-sharable device and thus you need
your AVO to be set to receive key events, by making use of tokens. In
this case, it's the FAVO_KEYTOKEN token.
You need to make sure your AVO can have the keyboard focus transferred to
it, via setting the token mask in with:
ncall avo,settokenmask,(avo,FAVO_KEYTOKEN,FAVO_KEYTOKEN:-)
This sets the keyboard token bit in the AVO token mask.
Plus you need to ask for keyboard focus at some point, say within the
AVO's buttondown event method:
ncall avo,settoken,(avo,BFAVO_KEYTOKEN:-)
Then you'll receive a gainevent as the token is transfered to your AVO,
and then see all the key events coming in.
> Q: When will up-to-date elate C headers be available (esp. ave.h)
This is still being worked on. Part of the problem is that the AVE API
itself and to a larger extent the C API are still evolving due to
comments from people actually writing applications using it.
So, the answer is soon. There will be gradual updates to ave.h.
If you have specific comments, needs or problems, please let us know.
> Q: Is there an example, or how does the comms event work (EV_DROP)
Ha, the first person ever to ask that. :)
The short answer is no. The event was defined and reserved for later use.
Drag and drop will be fully available in the next major update.