From: Bernard L. <le...@bo...> - 2004-02-11 16:30:56
|
PALFFY Daniel <dpa...@ra...> said: > > Hi! > > > Thanks for the testing. I've commited the fix to the iPod firewire > > driver now so once the public CVS server is updated (v1.6 has the fix) > > only the #define needs to be modified. > > Thanks. I've looked at your other changes. Some comments about keyboard.c: > The 3G HOLD_SWITCH_IS_ON macro has a typo - you meant &, not &&. > Otherwise, the hold botton works a little bit more complicated than > before. Hold on generates two interrupts - source/state: 0xX0/0xff; > 0xff/0x00, where X was 4, 8 or c depending on the current wheel state. > Hold off generates three: 0x20/0x20; 0xdf/0xff; 0x40/0xbf. The first > interrupt from hold on won't be easy to block since it's a perfectly valid > input from wheel motion, too. What does the apple firmware do? Typo fixed... thanks. As for the interrupts, the multiple interrupts are caused by incorrect processing in the keyboard driver. Could you try this patch: RCS file: /cvsroot/ipodlinux/linux/arch/armnommu/mach-ipod/keyboard.c,v retrieving revision 1.4 diff -u -r1.4 keyboard.c --- keyboard.c 11 Feb 2004 15:59:48 -0000 1.4 +++ keyboard.c 11 Feb 2004 16:25:56 -0000 @@ -63,7 +63,6 @@ /* get current keypad status */ state = inb(0xcf000030); - outb(~state, 0xcf000060); #ifdef CONFIG_VT kbd_pt_regs = regs; @@ -81,6 +80,8 @@ #ifdef IPOD_3G /* hold switch on 3g causes all outputs to go low */ /* we shouldn't interpret these as key presses */ + /* nor should we flip the interrupt levels */ + outb(state ^ 0x20, 0xcf000060); goto done; #endif } @@ -95,6 +96,8 @@ } } + outb(~state, 0xcf000060); + if ( source & 0x1 ) { if ( state & 0x1 ) { #if defined(DO_SCROLLBACK) > > On the server side I will see about updating the documentation shortly. > > But basically the host nodemgr.c needs to be patched (commenting out the > > do_irm_duties) and the eth1394.c driver replaced with the one from the > > ipodlinux CVS (this already contains the patch mentioned in the manual). > > eth1394.c doesn't seem to contain the patch from the manual. Thats right.... on the iPod side the broadcast _write_ and subsequent reply are fine but it needs to translate the incoming arp requests to look like coming from a broadcast address. On the PC side we need to make sure we don't write to broadcast addresses or the iPod pukes. I could just put that patch in eth1394.c on the iPod too, perhaps that would simplify things.... BTW The Darwin equivalent of eth1394 is open source so in theory it could be modified to be compatible with our hacked up version. Any OSX hackers out there up for a challenge? cheers, bern. |