DarwiinRemote

Hey Jean-Pierre,

(you first name sounds french, definitively)

Yes I filled a bugradar, and it has been accepted.
Here is what is wrote on the "Help" forum:

> Thank you for investigating on this confusing problem!
> I know this is frustrating, and I can testify I spent many hours  
> trying to solve this problem by every mean. I even started to write  
> a kernel extension.
>
> I talked with some Apple developers and they acknowledged this  
> problem as a bug of the Bluetooth HID system, a bug I reported on  
> Apple's tracking system. There is no date for resolution, and I  
> don't think there will be a fix for 10.4, rather it might be  
> release in an update of 10.5. This is good news because we know  
> what the problem is (if anyone wants details, I explained the  
> problem in a previous message), but this is also not so good news,  
> because there is no resolution date.
>
> Another details that may disappoint some of us: at this moment, it  
> is not possible to write a HID device driver for the wiimote,  
> because the necessary kernel header can not be obtained from Apple.  
> The reason is that the API is not documented and that it is not  
> stable enough to be publicized right now. Again, maybe in the  
> future, and certainly after Leopard is released.


Cheers,
Cam


On 28 mars 07, at 01:06, jeanpierre@... wrote:

>
> hiya -
>
> what dreaded OS-level bug are you running into? have you filed a  
> radar at https://bugreport.apple.com?
>
> can't wait to check out your work in jasen's branch and OSCulator  
> once it is released :)
>
> cheers,
> jean-pierre
>
>
> On 3/27/07, Camille <tuscland@...> wrote:
> Hi all,
>
> As you may have seen, I have done some commits in Jasen's branch.
> My software, OSCulator, is going to be released this week, and with
> the code that is in Jasen's branch.
>
> Though not perfect, this is currently the best combination I came up
> with.  The connection to the Wiimote is very smooth (though we are
> still limited by the dreaded bug in Mac OS) and extension controllers
> are recognized every time.
>
> Classic Controller now works like a charm, and some IR code has been
> fixed.
>
> I made some changes, that will break the compatibility with Darwiin
> Remote.  These are not huge changes actually.  I can help you figure
> out what are the changes.  Basically, the setXXX method (like
> setMotionSensorEnabled) no more return a IOReturn, because they
> actually don't do communication with the Wiimote anymore.  There's
> only one exception where the design is not really good, where the
> setIRSensorEnabled actually does a couple of writes.
>
> I found that it was not useful to retry to do a write or to retry a
> connection attempt (the for loops in 0.4).  I left one loop in the
> sendCommand method, but I will remove it later.  Actually when the
> wiimote is badly connected, the l2capChannelClosed is called, and
> then is it time to close the connection.
>
>
> Best,
> Camille
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Darwiin-remote-developers mailing list
> Darwiin-remote-developers@...
> https://lists.sourceforge.net/lists/listinfo/darwiin-remote-developers
>

I updated DarwiinRemote based on your changes.  The biggest change I
noticed was that all the Wiimote values (accelerations, etc.) are now
unsigned shorts rather than unsigned bytes.

I do have an issue that DarwiinRemote crashes now when the Wiimote is
disconnected.  Because I don't know how to make the debugger work, I
haven't been able to track down what line in the source code is
causing this.  Perhaps it is related to your changes? (If someone
could point me to a tutorial on using the debugger, I'd appreciate
it.)

I think my next steps in development are:
1) Mii transfer.  I have Mike Cohen's code stuck in the framework, but
I need to modify DarwiinRemote to use it, and probably do some
clean-up/refactoring.

2) Quartz Composer views for the Classic Controller(CC).  Like I've
done for the Wiimote and the nunchuk, I'd like to add a view pane for
the CC.  Along with that I think I'd like to make the nunchuk and CC
info child windows or slide outs or somesuch from the main Wiimote
window.  Suggestions welcome.

3) Sound support.  I think this is going to be a big project.  Anyone
willing to tackle it?

On 3/27/07, Camille <tuscland@...> wrote:
>
> I made some changes, that will break the compatibility with Darwiin
> Remote.  These are not huge changes actually.  I can help you figure
> out what are the changes.  Basically, the setXXX method (like
> setMotionSensorEnabled) no more return a IOReturn, because they
> actually don't do communication with the Wiimote anymore.  There's
> only one exception where the design is not really good, where the
> setIRSensorEnabled actually does a couple of writes.

On 28 mars 07, at 14:39, Jasen Jacobsen wrote:

> I updated DarwiinRemote based on your changes.  The biggest change I
> noticed was that all the Wiimote values (accelerations, etc.) are now
> unsigned shorts rather than unsigned bytes.

Yes, for consistency with 9 bit acceleration, I changed them to this  
type.
Ultimately, I think the Wiimote framework should output 0 to 1 float  
values.


> I do have an issue that DarwiinRemote crashes now when the Wiimote is
> disconnected.  Because I don't know how to make the debugger work, I
> haven't been able to track down what line in the source code is
> causing this.  Perhaps it is related to your changes? (If someone
> could point me to a tutorial on using the debugger, I'd appreciate
> it.)

Build the executable with Debug build configuration.
To set breakpoints, click on the left of a line, a blue cursor appears.
Run the target in debugging mode (Command-Y).
In the debugger, the window show the state of the variable.

I often use some command line gdb commands like:

print-object:
po theNameOfAObjCObject

print:
p aCValue

you can even make some objective-c calls:
po [anObject performSomething]



> I think my next steps in development are:
> 1) Mii transfer.  I have Mike Cohen's code stuck in the framework, but
> I need to modify DarwiinRemote to use it, and probably do some
> clean-up/refactoring.
>
> 2) Quartz Composer views for the Classic Controller(CC).  Like I've
> done for the Wiimote and the nunchuk, I'd like to add a view pane for
> the CC.  Along with that I think I'd like to make the nunchuk and CC
> info child windows or slide outs or somesuch from the main Wiimote
> window.  Suggestions welcome.
>
> 3) Sound support.  I think this is going to be a big project.  Anyone
> willing to tackle it?

All of this sounds exciting!
I'll take a look at your DarwiinRemote repository and see if I see  
something easy to correct.


Best,
-cam

On 3/28/07, Jasen Jacobsen <jasenj1@...> wrote:
>
>
> I think my next steps in development are:
> 1) Mii transfer.  I have Mike Cohen's code stuck in the framework, but
> I need to modify DarwiinRemote to use it, and probably do some
> clean-up/refactoring.


Thanks. I've been experimenting with reading the entire 750 byte Mii data
block, since you need it to calculate the CRC when writing a Mii. In that
case, no more gotMii delegate method is needed and all I have to do for
getMii is:

- (void*)getMii:(int)slot
{
    return mii_block_buf + MII_SLOT_OFFSET(slot);
}

I still haven't been able to get sending Miis to work. It looks like I need
to wait for an acknowledge message after each write rather than simply
writing 16 byte segments, which doesn't work. I'm not sure what the
acknowledge message looks like for data writes. Has anyone attempted it?