[Gambas-user] Joystick interface class (optimising and ioctl)

[Jean-Francois Perreault]

Benoit Minisini wrote:

>You can use a dynamic array: DIM b AS NEW Byte[](8)
>and use the b.Read() method.
>
>  
>
but aren't those dynamic array much slower to read/write than native 
arrays ?

yes and no  I just run a quick benchmark while the execution is almost 
1000% quicker (0.000001 instead of the previous 0.000024)
but the cpu usage was less 0.01% previously when treating 300 events per 
seconds
it is now around 20% when treating about 70 events per seconds and over 
60% when doing around 250 events per second

while latency went down , cpu usage went way up maybe if I put a wait 
0.00001 in there ....

(as a side note DIM b AS NEW Byte[](8) gives me a syntax error , but DIM 
b AS NEW Byte[] does not
so I also b.reside(8) , but I guess DIM b AS NEW Byte[](8) should work 
because when I type
DIM b AS NEW Byte[]( there's a tooltip that appears and say "Byte[] ( 
[Size AS Interger ] )"
I'm running 1.0.2  and I recall reading something in the 1.0.3 changelog 
about that ...
oh there it is
*1.0.2 - 12 Jan 2005*
*Interpreter*

    * BUG: The [] operator has been fixed for Byte and Short arrays)

>File_Read is called if there is something to read on the opened file.
>
>  
>
you mean as soon as file_read terminate if there is still something to 
read it will fire again immediately (or after a few milliseconds if it 
is being polled?)

>>next , to complete my joystick interface class I need to implement
>>something called ioctls
>>please wait I need to read up on that ... ;)
>>
>>    
>>
>
>You can't do ioctl() with Gambas at the moment.
>
>  
>
can there be a simple pass-through module ?

like a ioctl function that would be like this

ioctl (File AS File , iRequestCode AS Integer , bContent AS Byte[], 
kForInput as Boolean)

kForInput would be necessary since gambas cannot know if the 
driver-dependant iRequestCode is for input or output

bContent could only accept a native byte array , I guess that would make 
the component simpler ,
but I don't know how you can pass an entire native byte array as a 
parrameter ?!

so the component would call ioctl with iRequestCode as second parameter 
"as is" and pass an intermediary byte array with as many byte as there 
are elements in bContent and if kForInput is true then after ioctl is 
called fill bContent with the content of the buffer byte array and if 
kForInput is false  when fill the buffer byte array with the content of 
bContent and pass it to ioctl

but it the ioctl user gets iRequestCode then if kForInput is false ioctl 
could overflow the internal buffer byte array to there should be some 
security for that (make the buffer byte array never less than 256 bytes 
maybe ? the thing is that gambas can't keep a table of all the known 
request code because that would be too much trouble to maintain and it 
would never have the request code you need for dealing with the 
never-seen-before driver)

I suppose that you could get rid of kForInput if you always pass a big 
enough buffer byte array and determine if any bits changed in the array 
after calling ioctl you would then know if it was for in or out , except 
if it was for out and the driver didn't change anything

>Components are written in C/C++ at the moment, so they can do what they want. 
>A component to get joystick event should be written in C, not in Gambas, 
>because of the ioctl() stuff, and because of the number of events generated. 
>Note that the sdl component will have joystick management too in it, thanks 
>to the sdl library.
>
well actually now my joystick class is fast and usable , the ioctl 
aren't that necessary , I just wanted to implement them for completeness 
but all they are is


JSIOCGAXES           get the number of axes (you can already determine 
that by listening to INIT events ,
JSIOCGBUTTONS        each axis and each button generate a INIT event at 
initialisation)
JSIOCGNAME(len)      get the Name string of the joystick (you can get it 
with lsusb and dmesg but I consider that unclean)
JSIOCGVERSION        get the driver version (not actually useful , 
except for reusing to deal with
                     pre-version 1 interfaces , you could guess that 
with the kernel version anyway)

JSIOCSCORR           those two last are special , they serve to 
calibrate the joystick (which should )
JSIOCGCORR           not be needed , the joystick should be 
autocalibrated by the driver and the interface
                     for it is a bit strange , the joystick-api 
documentation says that those two request
                     code can change from version to version and only 
the application jscal , that come from
                     the same guys who made the joystick driver is 
garanteed to work with this , but I would
                     have had included it too for completeness

also in my previous message , about the pointers and all , do you think 
any of it makes sense ?
just a copymemory-alike function could be useful to deal with endianess 
and other bitwise operations
don't you think ? (but if you say I'm completely ludicrous just to talk 
about such a thing I'd believe you at this point ;) )


-Jean-Francois Perreault