Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: USB in Classic

Hi Tomas,

Date: Mon, 12 Jan 2004 17:30:03 +0100
From: Tomas Zahradnicky <email@hidden>
Subject: USB in Classic

I had to implement code that intercepts bar code reader and slows
down its events since it is too fast for some apps. Can someone
confirm that my method is safe?

- I installed USB notification to get notified when device
gets unplugged/plugged.
- I find the device, import the dispatch table (reader is like keyboard).
- I remember the current L2 interrupt handler.
- I install my own L2 interrupt handler. All that from my app.
- After a preprocess the incomming data I either call the old interrupt
with CallSecondaryInterruptHandler2 function or just return.
- I don't do anything weird from interrupt handler. 



- Is somewhere the USBKeyboardData documented? I treat it as:

   struct KeyData {
     UInt16 fKeyCount;
     struct {
       UInt8  fFlags;
       UInt8  fUsage;
     } fKey[32];
   };


From the os9 public API file "USB.h":

struct USBMouseData {
  UInt16              buttons;
  SInt16              XDelta;
  SInt16              YDelta;
};
typedef struct USBMouseData             USBMouseData;
typedef USBMouseData *                  USBMouseDataPtr;
struct USBKeyboardData {
  UInt16              keycount;
  UInt16              usbkeycode[32];
};
typedef struct USBKeyboardData          USBKeyboardData;
typedef USBKeyboardData *               USBKeyboardDataPtr;
union USBHIDData {
  USBKeyboardData     kbd;
  USBMouseData        mouse;
};
typedef union USBHIDData                USBHIDData;
typedef USBHIDData *                    USBHIDDataPtr;

So it looks like you're on the right track except from a quick look of the source code, to me it seems that instead of there being up to 32 instances of {UInt8 flags, UInt8 usage}, it -seemed- to me (based on code inspection only) that you should treat it instead as up to 32 instances of UInt16's, each of which can have values 0x00e0, 0x00e1, 0x00e2, if they represent zero or more modifier keys being down, followed by nonmodifier keys that would have values of 0xKKKK, etc. In other words, it seems that the HID data can be variable length, being longer if more modifier keys are down, along with more than just one nonmodifier key down. Again, just based on code inspection. I am sure this must be documented somewhere.


- Is it safe to asssume that my interrupt handler gets removed when
the device gets unplugged?

What happens if app crashes due to someone else's fault? Will system
nuke in the nonexistent interrupt handler?? [docs don't say anything
about it or I missed something?]

I'm not an expert in this area, but, assuming you're using the InstallInterruptFunctions os9 API (DriverServices.h) to install your handler, when I take a quick look at the os9 sources, I don't see any calls to (RemoveInterruptFunctions, DeleteInterruptSet, DeactivateInterruptSourceTree) in such places as the USB protocol stack or the Process Manager.

If you are using USBHIDInstallInterrupt in the keyboard HID driver's dispatch table, then, again, I don't see any automatic calling of, ie, USBHIDControlDevice(kHIDRemoveInterruptHandler,x); seems like you would have to call this yourself when you detect an unplug.

So, yes, these may well be problems.  Perhaps someone else can chime in.

Ben Koning
Classic Engineering





Thanks,

   Tomas
--
Ing. Tomas Zahradnicky, Jr.
Production Manager, 24U Software
Associate Member, Filemaker Solutions Alliance
mailto:email@hidden
http://www.24uSoftware.com

_______________________________________________
usb mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/usb
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.