[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Wiimote and I/O Questions

Hi,

my responses are below...


On 5/13/07, Luke Paireepinart <rabidpoobear@xxxxxxxxx> wrote: 

Hey, some people on the list seemed pretty excited about the ctypes
Wiimote code I was working on,
so I just wanted to let ya know that I'm done with finals (at last!) and
I'm going to start work on this code some more,
as well as getting it working on other platforms too, I hope.
But I had a question:
I'm using ctypes to interface with the kernel32.dll on Windows XP.  I
can use the CreateFile function to create a handle to a
file object that I can later pass to ReadFile to get the contents of the
file.  The HID devices are mounted as special paths in the filesystem
that I can open in order to communicate with them.  The Wii Remote
registers itself as an HID device, so I can talk to it in this way.
The only problem I can think of is that, as was mentioned in an earlier
discussion, what should happen when reading data?
Should it block, or what?
Someone mentioned that on other OSes, such as Linux and MacOS (and I
admit I'm ignorant of the details here)
that it's difficult to do overlapped input/output (which is where you
call the file read, and you immediately get control returned
to you, and then later when you want the result of the read, you call
GetOverlappedIOResult.)  and instead of doing that,
programmers for these OSes just use reads with a timeout.
Well, ironically, the ReadFile of the Windows kernel32.dll doesn't have
a timeout that you can specify, except regarding
communications devices, and I don't believe that an HID device fits into
this category (I think they mean if you have a handle
to a communications port, like COM1, etc).
Ideally I'd want the underlying Wii Remote communication code to work as
similarly as possible on all platforms.

Now, I could do the following (in Windows)
1. call ReadFile with overlapped I/O.
2. while I'm getting an ERROR_IO_PENDING from GetLastError, sleep.
3. if slept longer than timeout, call CancelIO on the file to terminate
the IO, and return.
4. if not slept longer than timeout, and not IO_PENDING, read in the data.

This would essentially behave the same way as a simple file read with a
timeout, except (IMHO) extremely needlessly complicated.

So, finally, I get to my questions:
1. Is it really so bad to just have it run in a thread and use
forever-blocking file reads (do these use a lot of the CPU?)



I think a thread is best here.  Then just post events into the pygame
event queue.

Before anyone cries out 'but threads are EVIL! and hard to use!!!!',
users won't see this thread.  It will just post events into the event
queue.

A thread has the advantage that it can run at a separate frequency
from the users main loop.

2. Does anyone know of a windows dll command that will read from a file
with a timeout?


Not needed if you use a thread.

3. Once the device path is known, could the pyWin32 module be of any
help in reading/writing to these files?


Not sure.  You shouldn't need it if your ctypes code works.

One more thing to note:
I would just use python's file() function to open the device, once its
pathname was known (which takes a bit of fiddling with the HID.dll)
but whenever I try this, Python doesn't find the file and raises an error:
IOError: [Errno 2] No such file or directory:
'\\\\?\\hid#hid_keyboard#2&10d82c60&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}'
(full traceback omitted because it's unimportant in this case. the error
is just raised on the statement f = file(detail.DevicePath) which
contains the above string.)

and a final question...
4.  Is there a special procedure to go about opening these types of
files, that, if followed, would let me just use Python and bypass
the whole CreateFile/WriteFile/ReadFile kernel stuff?


Not sure.  But if what you have works, then just use it.  It's easy to
abstract that part out for other platforms.
Something like this:

def open_file_read(...):
   if windows:
       ReadFile(...)
   elif BlaOS:
       open(...)


Feel free to direct me to a different mailing list.
Thanks for taking the time to read this,
-Luke