DE19835647A1 - Computersystem und Verfahren zum Lesen von HID-Dateneinheiten - Google Patents

Description

Die Erfindung betrifft Treiber, die in Verbindung mit Mensch-Maschine-Schnittstelleneinrichtungen arbeiten, und Verfahren zum Lesen von und Schreiben in solche Treiber und Schnittstellen.

Ein universeller, serieller Bus (USB) ist eine Datenübertra­ gungsarchitektur, die einem Personal Computer die Fähigkeit verleiht, sich mit zahlreichen Einrichtungen über ein ein­ faches Vierdrahtkabel zu verbinden. USB-Protokolle können Einrichtungen hochfahren oder auch dann konfigurieren, wenn sie während der Laufzeit eingesteckt werden. Diese Einrich­ tungen werden in verschiedene Geräteklassen aufgeteilt. Jede Geräteklasse definiert ein gemeinsames Verhalten und Proto­ kolle für die Einrichtungen, die ähnlichen Funktionen die­ nen.

Die im folgenden beschriebene Erfindung wird in Verbindung mit der Klasse der Mensch-Maschine-Schnittstelleneinrichtun­ gen (HID; human interface device) eingesetzt. Die HID-Klasse besteht hauptsächlich aus Einrichtungen (die hier als HID- Einrichtungen oder Einrichtungen der HID-Klasse bezeichnet sind), die von Menschen dazu verwendet werden, den Betrieb von Rechnersystemen zu steuern. Typische Beispiele von Ein­ richtungen der HID-Klasse sind:

• - Tastaturen und Zeigeeinrichtungen, z. B. übliche Mausein­ richtungen, Rollkugeln und Joysticks;
• - Einstellmittel oder Steuerelemente eines Bedienfeldes - z. B. Knöpfe, Schalter, Tasten und Schieber;
• - Einstellmittel oder Steuerelemente, die man an Vorrichtun­ gen, wie Telefonen, Videorekordern, Fernbedienungen, Spiel- der Simulationseinrichtungen findet - z. B.: Daten­ handschuhe, Drosseln, Steuerräder und Ruderpaddel;
• - Einrichtungen, die nicht zwingend die Zwischenschaltung des Menschen benötigen, die jedoch Daten in einem ähnli­ chen Format wie die Einrichtungen der HID-Klasse vorsehen, z. B. Strichcodeleser, Thermometer oder Voltmeter.

Die aktuelle HID-Spezifikation, auf die hier Bezug genommen wird, wurde von einem Verein zusammengestellt, der USB-IF heißt und in Hillsboro, Oregon liegt, und sie ist von dieser Organisation erhältlich. Auf diese Spezifikation kann auch über das Internet unter der Adresse "www.usb.org" zugegrif­ fen werden. Die HID-Spezifikation wird sich wahrscheinlich noch entwickeln, obwohl ihre wesentlichsten Eigenschaften heute schon weitgehend definiert und akzeptiert sind.

Eine wohldefinierte und akzeptierte Eigenschaft der HID-Ein­ richtungen, auf die sich die Erfindung hauptsächlich be­ zieht, besteht darin, daß solche Einrichtungen Daten in Da­ tenpaketen senden und empfangen, die "Reporte" oder "Be­ richte" genannt werden. Den Einrichtungen wird ein großes Maß an Flexibilität zur Formatierung solcher Reporte zuge­ standen.

Reporte enthalten zwei verschiedene Datenarten, die von HID- Einrichtungen erzeugt werden: Tasten und Werte - die hier allgemein als Dateneinheiten bezeichnet werden. Jede Daten­ einheit wird von einer Steuereinrichtung, wie einer Taste, einem Schieber, einer einzelnen Achse eines Joysticks etc., erzeugt. Eine Dateneinheit des Tastentyps ist binär und hat einen von zwei Werten: 0 der 1. Tasten-Dateneinheiten werden von solchen Einrichtungen, wie Tasten oder Schaltern, er­ zeugt. Eine Dateneinheit des Wertetyps hat einen Wertebe­ reich, der üblicherweise eine analoge Position eines konti­ nuierlich veränderbaren Steuerelements angibt, z. B. eines Schiebers, einer Joystickachse oder einer Drossel. Obwohl HID-Einrichtungen üblicherweise Eingangsdateneinheiten er­ zeugen, können von HID-Einrichtungen auch Reporte empfangen werden, so daß Rechner LEDs, Lautsprecher oder andere Aus­ gabegeräte eine HID-Einrichtung steuern können.

Jedes Steuerelement hat eine zugehörige "Verwendung", die vom Hersteller der HID-Einrichtung spezifiziert wird. Die Verwendungen liefern den auf den Rechnern laufenden Anwen­ dungsprogrammen Informationen über Parameter, die von ver­ schiedenen Steuerelementen gemessen werden, und darüber, was mit den von den Steuerelementen erzeugten Dateneinheiten geschehen soll - z. B. mit X-, Y- und Z-Eingangssignalen. Die HID-Spezifikation selbst umfaßt Verwendungsdefinitionen für eine Anzahl verschiedener Einrichtungen, wie Tastaturen, Joysticks, Schieber und andere Einrichtungen.

Eine HID-Verwendung umfaßt zwei Komponenten: eine Verwen­ dungsseite und einen Verwendungsindex. Die Verwendungsseite entspricht einer bestimmten Einrichtung. Die wahrscheinlich üblichsten Verwendungsseiten sind die Seite "Schreibtisch" und die Seite "Tastatur". Verwendungsindices entsprechen bestimmten Steuerelementen innerhalb der Seite, wie Joys­ ticktasten, Achsen, Schiebern, Tastaturtasten etc.

In der Praxis bezeichnet der Begriff "Verwendung" manchmal einen Verwendungsindex. In diesem Dokument bezeichnet "Ver­ wendung" jedoch grundsätzlich ein Wertepaar, das eine Ver­ wendungsseite und einen Verwendungsindex umfaßt. Der Begriff "Verwendungsspezifikation" wird dazu verwendet, eine der beide Komponenten einer Verwendung allgemeiner zu be­ zeichnen.

Wie bereits erwähnt, variiert die Anordnung und Formatierung der HID-Reporte erheblich von Einrichtung zu Einrichtung. Im allgemeinen enthält jeder Report mehrere Dateneinheiten, die in einer beliebigen Reihenfolge auftreten, welche von der Einrichtung spezifiziert wird, wobei jede Einheit eine willkürliche Anzahl Bits und eine willkürliche Ausrichtung innerhalb eines Reports umfaßt. Ferner können Dateneinheiten selbst in verschiedenen Formaten mitgeteilt werden, z. B. als Bitfeldformate und als Indexbereichsformate.

Eine Einrichtung kann ihre Dateneinheiten auch in zwei oder mehr Reporte aufteilen, wobei in diesem Fall jeder Report mit einer Reportidentifikation (Report-ID) beginnt. Die Reporte selbst haben verschiedene, ungleiche Längen und wer­ den von der HID-Einrichtung nur dann erzeugt, wenn sich ein in dem Report enthaltenes Datenelement ändert.

Zusätzlich kann eine Einrichtung verschiedene Steuerelemente in verschiedenen "Sammlungen" zusammenfassen, wobei jede Sammlung ihre eigene spezielle Verwendung hat. Sammlungen können verschiedene Reporte umfassen. Sammlungen können auch untereinander verschachtelt sein. Datenelemente, die dersel­ ben Verwendung entsprechen, können in verschiedenen Sammlun­ gen mitgeteilt werden.

Jede HID-Einrichtung erzeugt einen HID-Reportdeskriptor, der die von dieser Einrichtung erzeugten Reporte spezifiziert. Für jeden Report beschreibt der Reportdeskriptor die Anord­ nung und Formatierung der in dem Report enthaltenen Daten­ elemente sowie die zu jedem Datenelement gehörenden Verwen­ dungen.

Die HID-Reportdeskriptoren werden mit einem hochentwickelten Protokoll codiert. Jedes Anwendungsprogramm, daß HID-Report­ daten verwendet, muß zunächst den zugehörigen Reportdeskrip­ tor analysieren, um zu ermitteln, wie die einzelnen Reporte interpretiert werden können und wie die Datenelemente inner­ halb der Reporte gefunden werden können. Das Analysieren des Reportdeskriptors ist eine extrem komplizierte Aufgabe.

Das oben beschriebenen HID-Protokoll ist in Bezug auf die Bandbreite sehr effizient. Zusätzlich kann es in HID-Ein­ richtungen relativ leicht realisiert werden. Das Verfahren stellt die Entwickler von Anwendungsprogrammen jedoch vor einige Schwierigkeiten. Diese Schwierigkeiten beziehen sich hauptsächlich auf die Flexibilität, die den HID-Reporten zu­ gestanden wird, und die Komplexität der HID-Reportdeskripto­ ren.

Das Schreiben eines Anwendungsprogramms für eine einzelne bekannte HID-Einrichtung ist nicht schwierig. In diesem Fall kennt der Entwickler im voraus genau die Art aller verfüg­ baren Datenelemente, und er weiß, wie sie innerhalb der HID- Reporte angeordnet und formatiert sind.

Schwierigkeiten entstehen jedoch, wenn man versucht, ein Programm zu schreiben, das in Verbindung mit verschiedenen Peripherieeinrichtungen verwendet werden soll, von denen theoretisch alle ihre Reporte auf verschiedene und nicht vorhersehbare Weise realisieren. Ein Peripheriegerät kann z. B. nur einen einzigen Report verwenden, während ein ande­ res seine Datenelemente auf zwei oder drei Reporte aufteilen kann. Eine Tastatur kann Tastenanschläge als Bitfelder mit­ teilen, während eine andere ein Indexfeld verwenden kann. Ein Joystick kann lediglich sehr einfache Steuerelemente aufweisen, während ein anderer höher entwickelte Einstell­ möglichkeiten hat, wie ein Hutschalter und ein T-Schalter eines Flugzeuges. Selbst die Größen der Reporte unterschei­ den sich von Peripherieeinrichtung zu Peripherieeinrichtung, weshalb es schwierig ist, die erforderlichen Puffergrößen zu ermitteln. Genauso können auch die Sammlungen in verschiedenen Peripherieeinrichtungen auf sehr unterschied­ liche Weise realisiert sein.

Obwohl all diese Informationen über den Reportdeskriptor zur Verfügung stehen, ist das Analysieren der Information ziem­ lich schwierig - und das Puffern und Analysieren der tat­ sächlichen Reporte ist ähnlich kompliziert, wenn so viele Formate berücksichtigt werden müssen.

Obwohl die HID-Technologie das Potential hat, zahlreiche Einrichtungen oder Peripheriegeräte zu einem gegebenen An­ wendungsprogramm kompatibel zu machen, kann diese Kompatibi­ lität heute nur mit einer ganz erheblichen Investition bei der Entwicklung des Anwendungsprogramms realisiert werden, damit sich das Anwendungsprogramm an die verschiedenen For­ mate anpassen kann, die von den HID-Peripheriegeräten vor­ gesehen werden.

Die Erfindung sieht ein Verfahren und eine Architektur vor, welche es Klientprogrammen ermöglichen, HID-Dateneinheiten auf eine konsistente Weise zu empfangen, und zwar unabhängig von den erzeugenden HID-Einrichtungen und ohne daß die Klientprogramme eine komplizierte Analyse durchführen müß­ ten. Bei einem Ausführungsbeispiel umfaßt die Architektur eine Transportschicht, aus der HID-Reporte und Report­ deskriptoren entnommen und in die sie geschrieben werden können. Ein Treiber der HID-Klasse ist oberhalb der Transportschicht realisiert. Klientprogramme, einschließlich Anwendungsprogrammen und Betriebssystemkomponenten, sind mit HID-Einrichtungen über den Treiber der HID-Klasse verbunden.

Gemäß eines Aspekts der Erfindung fügt der Treiber der HID- Klasse Report-IDs an alle Reporte an, die nicht bereits Report-IDs enthalten. Dieser Schritt macht die HID-Reporte konsistent, einfacher zu lesen und zu analysieren. Zu­ sätzlich ermittelt der Treiber der HID-Klasse den größten von einer HID-Einrichtung erzeugten Report und füllt alle anderen Reporte von dieser HID-Einrichtung auf, so daß alle Reporte von einer gegebenen Einrichtung die gleiche Länge haben. Dies trägt wiederum zu Konsistenz bei und macht es für die Anwendungen einfacher, Reporte zu puffern und zu analysieren. Gemäß eines weiteren Aspekts der Erfindung er­ möglicht es eine Gruppe aus Schnittstellen Klientprogrammen, Dateneinheiten anzufordern, die nur durch ihre Verwendungen spezifiziert sind.

Während einer Initialisierungsphase ruft das Klientprogramm einen Reportdeskriptor von dem Treiber über einen normalen Datei-I/O-Aufruf ab. Es übergibt dann diesen Repordeskriptor an einen Parser (Syntaxanalysierer), der den Reportdeskrip­ tor analysiert und eine Datenstruktur zurückgibt, die eine analysierte Reportbeschreibung enthält. Bei dem Versuch, HID-Dateneinheiten zu lesen, ruft das Klientprogramm zu­ nächst einen HID-Report von dem Treiber ab. Dann ruft es eine Schnittstellenfunktion mit Argumenten auf, die den HID- Report, die Datenstruktur, welche die analysierte Report­ beschreibung enthält, und eine Verwendungsspezifikation (wie eine Verwendungsseite und einen Verwendungsindex) umfassen. Die Schnittstellenfunktion sucht den HID-Report nach Dateneinheiten ab, die zu der spezifizierten Verwendung gehören, wobei die analysierte Reportbeschreibung als ein Index verwendet wird, der in den HID-Report weist, und sie gibt die Dateneinheit an den anfragenden Klient zurück, wenn die Dateneinheit in dem Report gefunden wurde. Optional kann in den Argumenten der Schnittstellenfunktion ein Samm­ lungsidentifikator spezifiziert werden, wobei in diesem Fall die Schnittstellenfunktion die Datenwerte auf solche Werte in einer HID-Sammlung begrenzt, die von dem Sammlungsidenti­ fikator spezifiziert wurden.

Die Erfindung ist im folgenden anhand bevorzugter Ausfüh­ rungsformen in bezug auf die Zeichnungen näher erläutert. In den Figuren zeigt:

Fig. 1 ein Blockdiagramm einer beispielhaften Be­ triebsumgebung für die Erfindung;

Fig. 2 zeigt ein Blockdiagramm eines HID-Datenübertra­ gungssystems und einer Architektur gemäß der Erfindung;

Fig. 3 zeigt ein Blockdiagramm, das die HID-Reportnor­ mierung gemäß der Erfindung darstellt; und

Fig. 4 zeigt ein Blockdiagramm, das Parser-Schnitt­ stellenfunktionen gemäß der Erfindung dar­ stellt.

Fig. 1 und die folgenden Erläuterungen sollen eine kurze allgemeine Beschreibung einer Rechenumgebung liefern, in der die Erfindung realisiert werden kann. Obwohl dies nicht er­ forderlich ist, wird die Erfindung allgemein im Kontext rechnerausführbarer Befehle beschrieben, wie Programmodulen, die von einem Personal Computer ausgeführt werden. Program­ module umfassen im allgemeinen Routinen, Programme, Objekte, Komponenten, Datenstrukturen, Schnittstellen, Schnittstel­ lenfunktionen etc., die in einem rechnerlesbaren Speicher gespeichert sind. Wenn sie ausgeführt werden, führen diese Module bestimmte Aufgaben aus, implementieren bestimmte ab­ strakte Datentypen und bieten oder implementieren verschie­ dene Schnittstellen und Schnittstellenfunktionen. Der Fach­ mann wird darüberhinaus verstehen, daß die Erfindung noch bei anderen Rechnersystemkonfigurationen angewendet werden kann, einschließlich handgehaltener Einrichtungen, Mehrpro­ zessorsystemen, mikroprozessorgestützter oder programmier­ barer Verbraucherelektronik, Netz-PCs, Minicomputern, Main­ framecomputer und dergleichen. Die Erfindung kann auch in verteilten Rechnerumgebungen eingesetzt werden, in denen Aufgaben von voneinander entfernten Verarbeitungseinrichtun­ gen ausgeführt werden, die über ein Datenübertragungsnetz verbunden sind. In einer verteilten Rechnerumgebung können Programmodule sowohl in lokale (zentrale) als auch in ent­ fernte (dezentrale) Speichereinrichtungen geladen werden.

Das in Fig. 1 gezeigte beispielhafte System zum Umsetzen der Erfindung umfaßt eine Allzweck-Recheneinrichtung in der Form eines üblichen Personal Computers oder Computersystems 20 mit einer Verarbeitungseinheit 21, einem Systemspeicher 22 und einem Systembus 23, der verschiedene Systemkomponen­ ten, einschließlich des Systemspeichers, mit der Ver­ arbeitungseinheit 21 verbindet. Der Systembus 23 kann eine von verschiedene Arten von Busstrukturen aufweisen, ein­ schließlich einen Speicherbus oder eine Speicher-Steuerein­ richtung, einen Peripheriebus und einen lokalen Bus mit einer von vielen Busarchitekturen. Der Systemspeicher umfaßt einen Festspeicher (ROM) 24 und einen Arbeitsspeicher (RAM) 25. Ein Basis-Ein-Ausgabesystem (BIOS) 26, das die Basis­ routinen enthält, welche die Übertragung von Information zwischen den Elementen innerhalb des Personal Computers 20 unterstützen, z. B. während des Hochfahrens, ist im ROM 24 gespeichert. Der Personal Computer 20 umfaßt ferner ein Festplattenlaufwerk 27 zum Lesen von und Schreiben auf eine Festplatte (nicht gezeigt), ein Mangetplattenlaufwerk 28 zum Lesen von und Schreiben auf eine entfernbare Magnetplatte 29 und ein optisches Plattenlaufwerk 30 zum Lesen von und Schreiben auf eine entfernbare optische Platte 31, wie eine CD-ROM oder ein anderes optisches Medium. Das Festplatten­ laufwerk 27, das Magnetplattenlaufwerk 28 und das optische Plattenlaufwerk 30 sind über eine Festplattenlaufwerk- Schnittstelle 32, eine Magnetplattenlaufwerk-Schnittstelle 33 bzw. eine optische Laufwerk-Schnittstelle 34 mit dem Sys­ tembus 23 verbunden. Die Laufwerke und ihre zugehörigen com­ puterlesbaren Medien bilden einen nichtflüchtigen Speicher für computerlesbare Befehle, Datenstrukturen, Programmodule und andere Daten für den Personal Computer 20. Obwohl die hier beschriebene beispielhafte Umgebung eine Festplatte, eine entfernbare Magnetplatte 29 und eine entfernbare optische Platte 31 verwendet, wurde der Fachmann auf diesem Gebiet verstehen, daß in der beispielhaften Betriebsumgebung auch andere Arten computerlesbarer Medien verwendet werden können, die Daten speichern können, auf die ein Computer zu­ greifen kann, wie Magnetkassetten, Blitzspeicher-Karten (Flash-Speicherkarte), digitale Bildplatten, Bernoulli-Kas­ setten, Arbeitsspeicher (RAM), Festspeicher (ROM) und dergleichen.

Auf der Festplatte, der Magnetplatte 29, der optischen Plat­ te 31, dem ROM 24 oder dem RAM 25 können mehrere Program­ module gespeichert werden, einschließlich eines Betriebssy­ stems 35, eines oder mehrerer Anwendungsprogramme 36, ande­ rer Programmodule 37 und Programmdaten 38. Der Benutzer kann Befehle und Informationen in dem Personal Computer über Ein­ gabeeinrichtungen, wie eine Tastatur 40 und eine Lenkvor­ richtung 42, eingeben. Andere Eingabeeinrichtungen (nicht gezeigt) können ein Mikrophon, einen Joystick, ein Spielpad, eine Satellitenschüssel, einen Scanner oder dergleichen um­ fassen. Diese und andere Eingabevorrichtungen sind mit der Verarbeitungseinheit 21 häufig über eine serielle Port­ schnittstelle 46 verbunden, die mit dem Systembus gekoppelt ist, sie können jedoch auch über eine andere Schnittstelle angeschlossen sein, wie einen parallelen Port, einen Game- Port oder einen universellen, seriellen Bus (USB). Ein Moni­ tor 47 oder eine andere Art Anzeigeeinrichtung ist ebenfalls über eine Schnittstelle mit dem Systembus 23 verbunden, z. B. über einen Videoadapter 48. Zusätzlich zu dem Monitor weisen Personal- Computer üblicherweise andere Peripherieausgabege­ räte (nicht gezeigt) auf, wie Lautsprecher und Drucker.

Der Personal Computer 20 kann in einer vernetzten Umgebung arbeiten, die logische Verbindungen zu einem oder mehreren entfernten Computern nutzt, wie dem entfernten Computer 49. Der entfernte Computer 49 kann ein anderer Personal-Compu­ ter, ein Server, eine Leitwegsteuereinrichtung (Router), ein Netzwerk-PC, ein gleichrangiges Gerät oder ein anderer übli­ cher Netzknoten sein, und er umfaßt üblicherweise viele oder alle der oben in bezug auf den Personal-Computer 20 be­ schriebenen Elemente, obwohl in Fig. 1 nur eine Speicher­ vorrichtung 50 abgebildet ist. Die in Fig. 1 gezeigten logischen Verbindungen umfassen ein lokales Netz (LAN) 51 und ein Fernnetz (WAN) 52. Solche Netzumgebungen sind in Büros, unternehmensweiten Computernetzen, Intranetzen und dem Internet allgemein üblich.

Wenn der Personal-Computer 20 in einer LAN-Netzumgebung ein­ gesetzt wird, ist er mit dem lokalen Netz 51 über eine Netz­ schnittstelle oder einen Adapter 53 verbunden. Wenn er in einer WAN-Netzumgebung eingesetzt wird, umfaßt der Personal Computer 20 üblicherweise ein Modem 54 oder eine andere Vor­ richtung zum Aufbauen von Datenübertragungen über das Fern­ netz 52, z. B. das Internet. Das Modem 54, das in dem oder außerhalb des Computers liegen kann, ist mit dem Systembus 23 über die serielle Portschnittstelle 46 verbunden. In einer Netzumgebung können Programmodule, die in bezug auf den Personal Computer 20 dargestellt sind, oder deren Teile in der entfernten Speichervorrichtung gespeichert sein. Man wird verstehen, daß die gezeigten Netzverbindungen lediglich Beispiele sind und daß auch andere Vorrichtungen zum Ein­ richten eines Übertragungsweges zwischen den Computern ein­ gesetzt werden können.

Der gezeigte Computer verwendet ein Betriebssystem, z. B. aus der Windows-Betriebssystemreihe, die von der Microsoft Cor­ poration erhältlich ist. Die im folgenden beschriebene Funk­ tionsweise wird mit üblichen Programmiertechniken reali­ siert, welche die Verwendung von OLE- und COM-Schnittstellen umfaßt, die z. B. von Kraig Brockschmidt: Inside OLE2; Micro­ soft Press, 1994 beschrieben wurde und auf die Bezug genom­ men wird.

Allgemeine Architektur

Fig. 2 zeigt Komponenten, die innerhalb des Computers 20 realisiert sind, um eine Datenübertragung zwischen HID-Ein­ richtungen 100 und Klientprogrammen, wie dem gezeigten Klientprogramm 102, vorzusehen. Der Begriff "HID-Einrich­ tung" bezeichnet hier jede Einrichtung, die mit Hilfe des HID-Protokolls in seiner aktuellen oder einer überarbeiteten Fassung mit Rechnerkomponenten kommuniziert. Ein Klient­ programm ist ein Programm oder eine Programmkomponente, ein­ schließlich Komponenten des Betriebssystems, die HID-Daten­ einheiten verwendet.

Wie in Fig. 2 gezeigt, sieht eine Transportschicht oder ein Treiberstapel 104, die ein oder mehrere USB-Geräte oder Treiber umfaßt, Datenübertragungen zu HID-Einrichtungen gemäß USB-Normen und -Protokollen auf einer niedrigen Ebene vor. Ein Treiber der HID-Klasse 106 ist über der Transport­ schicht 104 realisiert und erzeugt die funktionsbezogenen Geräteobjekte, welche die physischen Geräteobjekte steuern, die von der Transportschicht (wie dem USB-Gerätetreibersta­ pel) aufgelistet werden. Der Treiberstapel 104 sieht HID- Reporte sowie HID-Reportdeskriptoren vor, welche die HID- Reporte beschreiben. Die HID-Reporte haben, wie im ersten Abschnitt dieser Anmeldung beschrieben, unterschiedliche Größen und enthalten Datenelemente, die den Steuerelementen entsprechen, die von den HID-Einrichtungen vorgesehen wer­ den. Die HID-Reportdeskriptoren spezifizieren die Anordnung, Formatierung und Verwendungsspezifikationen der Datenein­ heiten innerhalb der HID-Reporte. Der Treiber der HID-Klasse 106 ist so konfiguriert, daß er die HID-Reporte und die HID- Reportdeskriptoren anfordert und von dem USB-Gerätetreiber empfängt.

Betriebssystemklienten können die Treiber der HID-Klasse aufrufen, um HID-Reporte und Reportdeskriptoren von HID-Ein­ richtungen sowie andere Datenarten, die von HID-Einrichtun­ gen vorgesehen werden, zu lesen. Diese Komponenten können auch auf HID-Einrichtungen schreiben, indem sie geeignet formatierte Reporte vorsehen. Anwendungsprogrammklienten können ferner mit HID-Einrichtungen über den Treiber der HID-Klasse kommunizieren, allerdings nur indirekt - Anwen­ dungsprogramme kommunizieren in Wirklichkeit mit HID-Ein­ richtungen, indem sie Datei-I/O-Aufrufe über das Betriebs­ system des Rechners machen, das seinerseits direkt mit den Treibern der HID-Klasse kommuniziert.

Reportnormierung

Der Treiber der HID-Klasse 106 wird grundsätzlich mit kon­ ventionellen Techniken realisiert, abgesehen von der er­ heblichen Verbesserung, daß alle HID-Reporte normiert wer­ den, bevor sie an die Klientprogramme weitergegeben werden. Eine Art der Durchführung dieser Normierung besteht darin, jedem Report, der nicht bereits eine Report-ID aufweist, eine HID-Report-ID hinzuzufügen. Gemäß der HID-Spezifikation müssen Reporte nur dann Report-IDs aufweisen, wenn es mehr als einen Report gibt, der von einer Einrichtung stammt; wenn es von einer Einrichtung nur einen Report gibt, ist die Report ID optional.

In einem weiteren Schritt zum Normieren der HID-Berichte verleiht der Treiber allen Reporten von einer gegebenen HID- Einrichtung die gleiche Größe. Im einzelnen ermittelt der Treiber die Größe des größten Reports, der von einer bestim­ mten Einrichtung erzeugt wurde (zusätzlich möglicherweise zugefügter Report-IDs), und er füllt alle Reporte von dieser Einrichtung auf, so daß ihre Größe gleich der Größe des größten Reports ist.

Die Erfindung schlägt somit ein Verfahren vor, daß von einem Treiber der HID-Klasse durchgeführt wird und HID-Reporte an anfragende Klientprogramme erst nach deren Normierung zu­ rückgibt. Dieses Verfahren umfaßt die Schritte: Empfangen von HID-Reporten von einer HID-Einrichtung und anschließen­ des Normieren der Reporte durch Auffüllen der Reporte (mit Bytes, die beliebige Werte haben können), um sie gleich groß zu machen.

Dieser Prozeß ist in Fig. 3 gezeigt. Mehrere verschiedene Reporte 108, die alle eine andere Länge haben, werden von einer bestimmten HID-Einrichtung abgerufen. Bevor sie zu den anfragenden Programmen weitergegeben werden, füllt der Treiber der HID-Klasse 108 sie auf, so daß sie alle dieselbe Länge haben. Die normierten Reporte werden in Fig. 3 durch das Bezugszeichen 109 bezeichnet - wobei der aufgefüllte Teil durch gestrichelte Linien angedeutet ist. Ahnlich wird ein einzelner Report 110 von einer anderen Einrichtung ab­ gerufen. Der Report 110 weist, so wie er von dem Transportstapel wiedergewonnen wurde, keine Report-ID auf. Der Treiber der HID-Klasse 106 fügt daher eine Report-ID als das erste Bite des Reports hinzu, so daß sich ein normierter Report 111 ergibt.

Das Normieren der Reporte bietet wichtige Vorteile. Einer der wichtigsten Vorteile ist, daß dadurch Anwendungs­ programme sicherstellen können, daß bei jedem Lesen von dem Treiber 106 ein und nur ein HID-Report zurückgegeben wird. Man betrachte z. B. den Fall, der sich ergibt, wenn eine HID- Einrichtung zwei HID-Reporte unterschiedlicher Länge er­ zeugt. Jeder dieser Berichte kann zu jeder beliebigen Zeit erzeugt werden; ein anfragender Klient weiß nicht, welcher der beiden Reporte als nächster kommt. Wenn zum Lesen des nächsten Reports eine Datei-Ein/Ausgabe (I/O) durchgeführt wird, weiß der Klient (ohne Normierung) nicht, wieviel Byte er lesen sollte. Es ist daher wahrscheinlich, daß entweder zwei Lesevorgänge notwendig sind oder daß beim ersten Lesevorgang ein Teil des nächsten Reports gelesen wird. Dieses Problem ergibt sich bei der oben beschriebenen Nor­ mierung nicht, weil alle Reporte dieselbe Länge haben. Ein Klient kann sich dafür entscheiden, entweder einen gesamten Report oder ein ganzzahliges Vielfaches einer Reportlänge zu lesen.

Wenn man sicherstellt, daß alle Reporte mit einer Report-ID beginnen, kann ein Klient ähnlich erwarten, daß die nachfol­ genden Daten immer bei einer bestimmten Stelle beginnen.

Obwohl die Normierungsprozedur hier mit Bezug auf Leseopera­ tionen beschrieben wurde, wird sie auch bei Schreiboperatio­ nen eingesetzt. Wenn auf eine HID-Einrichtung geschrieben wird, sieht ein anfragender Klient Reporte vor, die alle die gleiche Größe haben und Datenelemente enthalten, welche auf die HID-Einrichtung geschrieben werden sollen. Bevor der Treiber auf die Einrichtung schreibt, entfernt er die zusätzliche Länge aus einem normierten Bericht sowie die Re­ port-ID, wenn die Einrichtung keine solche ID erwartet. Wie­ derum ermöglicht dies Klientprogrammen Reporte und entspre­ chende Puffer mit gleicher Größe einzusetzen.

Vereinfachte Datengewinnung von Dateneinheiten

Das System der Fig. 2 umfaßt eine Parserkomponente 130, die Parser- oder Analysedienste für Klientprogramme vorsieht. Der Parser 130 wird mit einer dynamischen Bibliothek DLL (dynamically loadable library) realisiert. Der Parser und seine zugehörigen Funktionen werden mittels Befehlen definiert und realisiert, die in einem Computerspeicher lie­ gen und von dem Prozessor des Computers ausgeführt werden.

Die für die Erfindung wichtigsten Aspekte der Schnittstellen und Schnittstellenfunktionen eines beispielhaften Parsers gemäß der Erfindung sind mit Bezug auf Fig. 4 beschrieben.

Fig. 4 zeigt ein Klientprogramm 102 und einen Parser (Syn­ taxanalysierer) 130. Der Parser 130 definiert und bietet mehrere Schnittstellenfunktionen an, die über übliche Mittel von dem Klientprogramm 102 aufrufbar sind. Diese Funktionen sind in Fig. 4 durch Kreise dargestellt, die über Linien mit dem Parserblock 130 verbunden sind. Die Funktionen um­ fassen eine Deskriptoranalysefunktion 132, eine oder mehrere Dateneinheiten-Wiedergewinnungsfunktionen 133 und eine Samm­ lungsidentifkationsfunktion 134. Die Funktionen werden mit üblichen Programmiertechniken realisiert, z. B. durch Programmieren der Funktionen in einer höheren, kompilierten Sprache, wie C. Jede Funktion empfängt ein oder mehrere Argumente und gibt einen oder mehrere Werte oder Datenein­ heiten an das aufrufende Programm zurück. Fig. 4 zeigt die Argumente, die für die Erfindung am relevantesten sind.

Die Deskriptoranalysefunktion 132 empfängt Funktionsargumen­ te, die einen tatsächlichen HID-Reportdeskriptor umfassen, der von einem Treiber der HID-Klasse 106 erhalten wurde. Abhängig von dem Aufruf mit diesem Argument analysiert die Deskriptoranalysefunktion 132 den Reportdeskriptor und er­ zeugt eine Datenstruktur, die einen analysierten Report­ deskriptor enthält. Die Datenstruktur wird an das Klient­ programm zurückgegeben, vorzugsweise durch Weitergeben eines Zeigers an die Datenstruktur.

Im allgemeinen ist die Datenstruktur eine erweiterte Version des rohen Reportdeskriptors. Die Datenstruktur ist im all­ gemeinen als eine Anordnung aus Beschreibungen von Datenein­ heiten aufgebaut, die einzelnen Tasten-Steuerelemente, Wert- Einstellmitteln oder regelmäßig angeordneten Dateneinheiten entsprechen. Die Beschreibungen der Dateneinheiten, die je­ weils einer bestimmten Dateneinheit entsprechen, geben an, in welchem Report die Dateneinheit vorhanden ist, sowie ihre Position und Größe in dem Report und ihre HID-Eigenschaften (einschließlich der physischen Min/Max, logischen Min/Max, Einheiten etc.). Weitere Information in der Beschreibung einer Dateneinheit umfaßt die Verwendung (Seite und Index) der entsprechenden Dateneinheit, ob sie einer Taste oder einem Wert entspricht, ob sie als eine einzelne Datenein­ heit, ein Bitfeld oder Teil einer Matrix mitgeteilt wird, ob die Einheit Teil einer Sammlung ist, und wenn ja, welcher Sammlung, etc.

Die analysierte Reportbeschreibung gibt auch die maximale Länge der Reporte an, die von einer bestimmten Einrichtung erzeugt wurden und ob Report-IDs an die jeweiligen Reporte angefügt werden sollen. Diese Information wird von dem Treiber der HID-Klasse 106 bei der Durchführung seiner Nor­ mierungsschritte verwendet.

Kurz gesagt erhält jedes Element der Datenstruktur eine vollständigen Beschreibung eines Steuerelementes oder einer Anordnung aus Steuerelementen. Dies steht in direktem Gegensatz zu dem rohen Reportdeskriptor, bei dem sich die Beschreibungen der Steuerelemente weitgehend auf den Kontext verlassen, in dem sie auftreten (wegen des möglichen Vorhan­ denseins von globalen Variablen und Zustands-Speicher/Wie­ derherstellungs-Befehlen), was eine ausführliche Analyse erfordert, um verständliche Beschreibungen gegebener Daten­ einheiten zu extrahieren. Die genaue Anordnung und das Pro­ tokoll, die bei der von der Deskriptoranalysefunktion 132 zurückgegebenen Datenstruktur verwendet werden, ist nicht entscheidend, abgesehen davon, daß sie die erforderliche Information über die Reporte unkompliziert und verständlich wiedergibt.

Ferner hat die spezielle Struktur, die in der analysierten Reportbeschreibung verwendet wird, nur für den Parser selbst eine Bedeutung. Obwohl die Reportbeschreibung von der Des­ kriptoranalysefunktion 132 an den anfragenden Klienten zu­ rückgegeben wird, umfassen die Schritte zum Wiedergewinnen der Dateneinheiten gemäß der Erfindung weitere Funktionen, die von dem Parser 130 ausgeführt werden und für die der Parser die analysierte Reportbeschreibung verwendet. Bei der Erfindung muß das aufrufende Klientprogramm die analysierten Reportbeschreibungen nie verwenden, außer um sie als Argu­ mente in Dateneinheit-Wiedergewinnungsfunktionen vorzusehen.

Die Dateneinheit-Wiedegewinnungsfunktionen 133 werden von Klientprogrammen 130 aufgerufen, um Dateneinheiten wieder­ zugewinnen, die bestimmten Verwendungen entsprechen. Jede Dateneinheit-Wiedergewinnungsfunktion 133 empfängt Argumen­ te, einschließlich folgender Argumente:

• - eine analysierte Reportbeschreibung (die mit der Des­ kriptoranalysefunktion 132 erhalten wird);
• - einen HID-Bericht (der von dem Treiber der HID-Klasse 106 erhalten wird);
• - eine HID-Verwendungsspezifikation; und
• - eine optionale Sammlungs-ID, welche eine HID-Sammlung spezifiziert, auf die sich der Reportdeskriptor be­ zieht.

Abhängig von diesen Argumenten untersucht eine Dateneinheit- Wiedergewinnungsfunktion den bezeichneten HID-Report, findet eine oder mehrere Dateneinheiten, welche dieselbe Verwen­ dungsspezifikation haben wie die in den Argumenten, und gibt die Dateneinheit(en) an den anfragenden Klient zurück. Die analysierte Reportbeschreibung wird dazu verwendet, Daten­ einheiten zu lokalisieren, die den gegebenen Verwendungs­ spezifikationen entsprechen. Wenn eine Sammlungs-ID in die­ sen Argumenten enthalten ist, grenzt die Dateneinheit-Wie­ dergewinnungsfunktion die zurückgegebenen Dateneinheiten auf solche in der spezifizierten Sammlung ein.

Ein Beispiel einer Dateneinheit-Wiedergewinnungs-Schnitt­ stellenfunktion wird als "HidP_GetUsages" bezeichnet. Dies ist ein Beispiel einer Tasten-Wiedergewinnungsfunktion. Die HID-Verwendungsspezifikation in diesem Beispiel umfaßt nur eine Verwendungsseite. Die Funktion sucht den HID-Report nach Dateneinheiten ab, welche einem Verwendungsindex inner­ halb der gegebenen Verwendungsseite entsprechen, und gibt eine Anordnung aus Verwendungsindices zurück, die HID-Tasten entsprechen, welche gedrückt wurden - und zwar unabhängig davon, ob der HID-Report Indexfelder oder Bitfelder enthält.

"HidP-GetUsageValue" ist ein anderes Beispiel für eine Da­ teneinheit-Wiedergewinnungsfunktion. Bei dieser Funktion be­ steht die Verwendungsspezifikation sowohl aus einer Verwen­ dungsseite als auch aus einem Verwendungsindex. Die Funktion sucht innerhalb des bezeichneten HID-Reports nach einer Da­ teneinheit, welche der spezifizierten Verwendungsseite und dem Verwendungsindex entspricht, und gibt diese Dateneinheit (in diesem Fall einen Mehrbitwert) zurück, wenn sie in dem Report gefunden wurde.

"HidP-GetUsageValueArray" ist noch ein weiteres Beispiel für eine Dateneinheit-Wiedergewinnungsfunktion. Diese Funktion empfängt Argumente, einschließlich einer Verwendungsseite und eines Verwendungsindex, und gibt eine Anordnung aus ent­ sprechenden Dateneinheiten des Wert-Typs zurück. Diese Funktion wird in Verbindung mit den Verwendungen eingesetzt, die mehrere Dateneinheiten einer einzelnen Verwendung ent­ halten.

Man beachte, daß alle diese Dateneinheiten-Wiedergewinnungs­ funktionen so gewählt sind, daß sie normierte HID-Berichte erwarten. Die analysierte Reportbeschreibung, die an die Dateneinheit-Wiedergewinnungsfunktion weitergegeben wird, stützt sich auf normierte Reporte. Man beachte auch, daß jede Dateneinheit-Wiedergewinnungsfunktion eine von zwei verschiedenen Optionen zurückgibt: Dateneinheit(en) oder einen Fehlercode, der anzeigt, ob ein Steuerelement inner­ halb der empfangenen Verwendungsspezifikation bei der Ein­ richtung existiert, welche den bezeichneten Report erzeugt hatte. Genauer gesagt gibt der Fehlercode entweder an, daß eine Steuerung bei der spezifizierten Verwendung für die fragliche Einrichtung nicht vorhanden ist, oder daß die Steuerung bei der Einrichtung vorhanden ist, jedoch in dem vorgelegten Report fehlt (möglicherweise ist sie in nachfol­ genden Reporten vorhanden).

Schnittstellenfunktionen, die von dem Parser 130 vorgesehen werden, umfassen ferner eine Sammlungsidentifikation 134. Diese Funktion wird vorgesehen, um Anwendungsprogrammen das Arbeiten mit HID-Sammlungen zu erleichtern. Wie oben er­ wähnt, sind Sammlungs-IDs optionale Parameter für die Daten­ einheit-Wiedergewinnungsfunktion. Die Sammlungs-IDs werden über die Sammlungsidentifikationsfunktion 134 erhalten.

Die Sammlungsidentifikationsfunktion 134 empfängt ein Argu­ ment, das eine analysierte Reportbeschreibung umfaßt, die zuvor mit der Deskriptoranalysefunktion 132 erhalten wurde. Gestützt auf diese Beschreibung gibt die Funktion eine An­ ordnung aus Datenstrukturen zurück, welche HID-Sammlungen, deren HID-Verwendungen und ihre Beziehungen spezifizieren. Die Reihenfolge der Sammlungen in der Anordnung gibt für jede Sammlung eindeutige Sammlungs-IDs an. Jede Datenstruk­ tur in der Anordnung stellt eine Sammlung dar und spezifiziert deren Verwendung sowie einen Index zu ver­ wandten Sammlungen in der Anordnung. Die Datenstruktur be­ zeichnet z. B. eine Stammsammlung (wenn es eine gibt), einen nächsten Nachkommen in einer verknüpften Liste aus Nachkom­ men und ein erstes Kind in einer verknüpften Liste aus Kindern. Dadurch kann ein Klient leicht die Struktur ver­ schachtelter Sammlungen ermitteln und seinerseits zusätzliche Bedeutungen in Erfahrung bringen, die zu ver­ schiedenen Steuerelementen gehören - wenn es doppelte Daten­ einheiten gibt, können sie gestützt auf die Sammlungen unterschieden werden, zu denen sie gehören. Als ein konkretes Beispiel einer Sammlungsidentifikationsfunktion seien die Funktion "HidP_GetLinkCollectionNodes" und die Struktur "HIDP_LINK_COLLECTION_NODE" genannt.

Diese Funktionen vereinfachen erheblich den Prozeß zum Wie­ dergewinnen von Datenelementen aus HID-Einrichtungen. Ein Verfahren zum Lesen von HID-Daten gemäß der Erfindung umfaßt einen Anfangsschritt, bei dem ein HID-Reportdeskriptor er­ halten wird und dieser über die Deskriptoranalysefunktion 132 an den Parser 130 weitergegeben wird. Der Parser analy­ siert (parsed) den Deskriptor und gibt eine analysierte Reportbeschreibung gestützt auf den Reportdeskriptor zurück. Diese Schritte werden während einer Initialisierungssequenz durchgeführt.

Zum Lesen von Daten von der HID-Einrichtung erhält das Klientprogramm einen HID-Report von dem Treiber der HID- Klasse 106 und ruft eine Dateneinheit-Wiedergewin­ nungsfunktion 133 mit Argumenten auf, die den HID-Report, die analysierte Reportbeschreibung, eine Verwendungs­ spezifikation und eine optionale Sammlungs-ID umfassen. Die Dateneinheit-Wiedergewinnungsfunktion (die vom Parser 130 realisiert wird) sucht den angegebenen HID-Report nach einem oder mehreren Datenelementen ab, welche dieselbe Ver­ wendungsspezifikation haben, die in den Argumenten der Funktion angegeben sind, und gibt diese Elemente an das aufrufende Klientprogramm zurück. Wenn eine Sammlungs-ID spezifiziert ist, wird die Suche auf die angegebene Sammlung der Datenelemente begrenzt. Dieser Prozeß wird für nachfol­ gende HID-Reporte wiederholt, um weitere Eingangsdaten zu lesen.

Das Schreiben wird auf ähnliche Weise durchgeführt. Der Par­ ser umfaßt eine oder mehrere Datenelement-Schreibschnitt­ stellenfunktionen, welche Reporte zum Schreiben auf HID-Ein­ richtungen vorbereiten. Jede Dateneinheit-Schreibfunktion hat Argumente, welche eine Dateneinheit (oder mehrere Daten­ einheiten), eine analysierte Reportbeschreibung, einen HID- Report, eine Verwendungsspezifikation und eine optionale Sammlungs-ID umfassen. Am Anfang wird der HID-Report auf lauter Nullen initialisiert. Die Datenelement-Schreib­ funktion ermittelt die geeignete Stelle in dem Report und positioniert und formatiert die Datenelemente gestützt auf die angegebene Verwendung richtig in dem Report. Wenn eine Sammlungs-ID spezifiziert ist, werden die Datenelemente für diese Sammlung richtig positioniert. Die Datenelement- Schreibfunktion schreibt auch die richtige Report-ID in den Report, der dem Report entspricht, in dem die angegebene Verwendung liegt. Die Funktion gibt dann den Report an das anfragende Klientprogramm zurück, das seinerseits den Report über den Treiber 106 in eine HID-Einrichtung schreibt. Wenn mehrere Verwendungen geschrieben werden sollen, kann der Klient die Datenelement-Schreibfunktion mehrmals mit demsel­ ben Report aufrufen (und verschiedene Verwendungen angeben), bevor der Report in die HID-Einrichtung geschrieben wird - solange alle spezifizierten Verwendungen in demselben Report liegen. Ein Fehlercode wird zurückgeben, wenn eine der Ver­ wendungen zu einem anderen Report gehört. Zusätzlich wird ein Fehlercode zurückgegeben, wenn die angegebene Verwendung in einem Report nicht vorhanden ist oder wenn Beschränkungen des HID-Reportformats es verbieten, in den vorgelegten Report weitere spezifizierte Verwendungen zu schreiben.

Schlußfolgerung

Die Erfindung bietet eine erhebliche Verbesserung im Ver­ gleich zum Stand der Technik. In der Vergangenheit waren Anwendungsprogramme für das Verschlüsseln von HID-Report­ daten verantwortlich. Da sich Reporte von unterschiedlichen Geräten sehr voneinander unterscheiden, war dies eine sehr schwierige Aufgabe. Mit der Erfindung wird jedoch die Ar­ beit, die zum Unterstützen verschiedener HID-Einrichtungen notwendig ist, erheblich vermindert. Sobald die Initialisie­ rung abgeschlossen ist, muß ein anfragender Klient wenig mehr als eine HID-Verwendung spezifizieren - die Datenele­ ment-Wiedergewinnungsfunktionen analysieren die HID-Reporte und geben die angeforderte Verwendung ohne weitere Arbeit durch den Klienten zurück. Der Klient verwendet denselben Wiedergewinnungsmechanismus, wenn Datenelemente in den HID- Reporten als Indexfelder oder Bitfelder definiert werden.

Die Vorteile dieser Funktionsweise sind erheblich. Man nehme an, daß ein relativ einfaches Spielprogramm nur die X- und Y-Werte eines Joysticks verwendet. In der Vergangenheit konnte das Spiel entweder mit einer einzigen Art eines HID- Joysticks konfiguriert werden, oder es konnte mit einer sehr komplizierten Parserkomponente aufgebaut werden, um zu be­ stimmen, wie die X- und Y-Werte von jedem HID-Joystick er­ mittelt werden sollen. Mit der Erfindung holt sich das Spiel jedoch einfach die Reporte und fordert dann X- und Y-Joy­ stickverwendungen von einer Datenelement-Wiedergewinnungs­ funktion an. Aus der Perspektive des Programms sind die fol­ genden variablen Faktoren irrelevant. Die Anzahl der Repor­ te, die von dem Joystick erzeugt werden; die Größe der Re­ porte; ob diese Reporte Report-IDs enthalten; und die Anord­ nung und Formatierung der Datenelemente innerhalb der Re­ port. Das Spielprogramm kann alle diese Faktoren ignorieren und funktioniert dennoch mit jedem HID-Joystick, der X- und Y-Joystickelemente aufweist. Dies gilt sogar dann, wenn der Joystick mehrere zusätzliche Steuereinrichtungen hat, die von dem Spielprogramm nicht verwendet werden. Neue Joysticks mit zusätzlichen Steuerelementen mit neuen Verwendungen kön­ nen noch immer mit dem Spielprogramm arbeiten (auch dann, wenn die neuen Steuerelemente nicht verwendet werden).

Ferner sieht die Erfindung eine einfache und bequeme Weise vor, wie die Anwendungsprogramme mit neuen Einrichtungen arbeiten können, die weniger Steuereinrichtungen haben, als das Programm optimal nutzen kann. Wenn eine solche Einrich­ tung angeschlossen wird, geben die Datenelement-Wiedergewin­ nungsfunktionen immer dann einen Fehlerwert zurück, wenn ein Datenelement angefordert wird, das einer Verwendung ent­ spricht, die bei der Einrichtung nicht existiert. Das Anwen­ dungsprogramm kann dann Schritte unternehmen, um äquivalente Funktionsweisen mit anderen Mitteln vorzusehen.

Ähnlich schafft die Reportnormierung erhebliche Vorteile sowohl für Klientprogramme als auch für den Parser. Durch die Reportnormierung können Klienten leicht einzelne Reporte lesen. Zusätzlich macht diese Größennormierung es einfacher, an Parser-Funktionen weiterzugeben. Das durchgängige Hinzu­ fügen von Report-IDs zu den Reporten macht es einfacher, Datenelemente innerhalb der Reporte zu Indexieren - Daten beginnen immer bei dem zweiten Byte des Reports.

Ein weiterer Vorteil der Erfindung besteht darin, daß Samm­ lungsbeschreibungen für Klientprogramme in einem einfach entschlüsselbaren Feldformat zur Verfügung stehen. Dies er­ möglicht es den Klienten, einfache Listen der Sammlungs­ knoten zusammen mit ihren jeweiligen Verwendungen zu erhal­ ten. Dadurch können die Klienten wiederum optional Sammlun­ gen für die Datenelement-Wiedergewinnungsfunktion spezifizieren, um die angeforderten Datenelemente genauer zu beschreiben.

Obwohl die Erfindung in bezug auf bestimmte strukturelle Merkmale und/oder Verfahrensschritte beschrieben wurde, muß man verstehen, daß die in den folgenden Ansprüchen definier­ te Beschreibung nicht notwendig auf diese speziellen Merkma­ le und Schritte beschränkt ist. Die in der vorstehenden Be­ schreibung, den Ansprüchen und der Zeichnung offenbarten Merkmale können sowohl einzeln als auch in beliebiger Kom­ bination für die Verwirklichung der Erfindungen in ihren verschiedenen Ausgestaltungen von Bedeutung sein. Die spezi­ fischen Merkmale und Schritte sind lediglich Beispiele zur Realisierung.

Claims (53)

1. Computersystem mit
einem Gerätetreiber, der HID-Reporte, die Datenein­ heiten enthalten, und einen HID-Reportdeskriptor vorsieht, der die HID-Reporte und die Anordnung, Formatierung und Verwendungsspezifikationen inner­ halb der HID-Reporte beschreibt;
einem Treiber der HID-Klasse, der so konfiguriert ist, daß er die HID-Reporte und den HID-Reportdes­ kriptor von dem Gerätetreiber anfordert und emp­ fängt; und
einer ersten Schnittstellenfunktion, die von einem Klientprogramm aufrufbar ist, wobei die erste Schnittstellenfunktion eine Verwendungsspezifikation von dem Klientprogramm empfängt und, abhängig davon, eine oder mehrere Dateneinheiten von einem spezif­ zierten HID-Report, welche dieselben Verwendungsspe­ zifikationen wie die von dem Klientprogramm empfan­ gen haben, findet und zurückbringt.

2. Computersystem nach Anspruch 1, bei dem die erste Schnittstellenfunktion zusätzlich den spezifizierten HID-Report von dem Klientprogramm empfängt.

3. Computersystem nach Anspruch 1, bei dem die erste Schnittstellenfunktion zusätzlich den spezifizierten HID-Report und eine Datenstruktur von dem Klientpro­ gramm empfängt, wobei die Datenstruktur eine analy­ sierte Reportbeschreibung gestützt auf den HID-Re­ portdeskriptor enthält.

4. Computersystem nach einem der vorangehenden Ansprü­ che, bei dem die erste Schnittstellenfunktion zu­ sätzlich einen Sammlungsidentifikator empfängt und abhängig davon, die Datenelemente auf solche Elemente in einer HID-Sammlung begrenzt, die der Sammlungsidentifikator spezifiziert.

5. Computersystem nach einem der vorangehenden Ansprü­ che mit einer zweiten Schnittstellenfunktion, die den HID-Reportdeskriptor empfängt und abhängig davon eine Datenstruktur zurückgibt, die eine analysierte Reportbeschreibung enthält, wobei die erste Schnitt­ stellenfunktion zusätzlich die Datenstruktur emp­ fängt und diese Datenstruktur zum Auffinden der Dateneinheiten verwendet.

6. Computersystem nach Anspruch 5, bei dem die zweite Schnittstellenfunktion den HID-Reportdeskriptor von dem Klientprogramm empfängt.

7. Computersystem nach einem der vorangehenden Ansprü­ che, bei dem die erste Schnittstellenfunktion einen ersten Fehlercode zurückgibt, wenn es keine Daten­ einheit mit der empfangenen Verwendungsspezifikation in dem spezifizierten HID-Report gibt, wobei der spezifizierte HID-Report von einer bestimmten Ein­ richtung erzeugt worden ist und der Fehlercode an­ gibt, ob ein Steuerelement mit der empfangenen Ver­ wendungsspezifikation auf dieser Einrichtung vorhan­ den ist.

8. Computersystem nach einem der vorangehenden Ansprü­ che, bei dem der Treiber der HID-Klasse ferner so konfiguriert ist, daß er HID-Reporte von einer be­ stimmten HID-Einrichtung normiert, indem er sie gleich groß macht.

9. Computersystem nach einem der vorangehenden Ansprü­ che, bei der Treiber der HID-Klasse so konfiguriert ist, daß er HID-Reporte normiert, indem er jedem HID-Report, der nicht bereits eine Report-ID ent­ hält, eine Report-ID hinzufügt.

10. Computersystem nach einem der vorangehenden Ansprü­ che, bei dem die empfangene Verwendungsspezifikation eine Verwendungsseite identifiziert, wobei die zu­ rückgegebenen Dateneinheiten eine Anordnung aus Ver­ wendungsindices umfassen, die HID-Tasten entspre­ chen, die gedrückt werden, und zwar unabhängig da­ von, ob der spezifizierte HID-Report Indexfelder oder Bitfelder enthält.

11. Computersystem nach einem der vorangehenden Ansprü­ che, bei dem die zurückgegebenen Dateneinheiten meh­ rere HID-Werte umfassen.

12. Computersystem nach einem der vorangehenden Ansprü­ che, mit einer weiteren Schnittstellenfunktion, die eine Anordnung aus Datenstrukturen zurückgibt, wel­ che HID-Sammlungen und deren Beziehungen zueinander gestützt auf den HID-Reportdeskriptor angeben.

13. Computersystem nach Anspruch 12, bei dem die erste Schnittstellenfunktion zusätzlich einen Sammlungs­ identifikator empfängt und abhängig davon Datenele­ mente in einer HID-Sammlung findet, die von dem Sammlungsidentifikator spezifiziert sind.

14. Computersystem nach einem der vorangehenden Ansprü­ che, bei dem der Gerätetreiber auch HID-Report in HID-Einrichtungen schreibt, und mit einer weiteren Schnittstellenfunktion, die eine Dateneinheit und eine Verwendungsspezifikation annimmt und abhängig davon die Dateneinheit in einem HID-Report, der in eine HID-Einrichtung geschrieben wird, positioniert und formatiert.

15. Computerlesbares Speichermedium enthaltend von einem Computer ausführbare Befehle, die eine erste Schnittstellenfunktion in einem Computersystem defi­ nieren, mit einer HID-Einrichtung, die HID-Reporte vorsieht, welche Dateneinheiten und einen HID-Re­ portdeskriptor zum Beschreiben der HID-Reporte und der Anordnung, Formatierung und Verwendungsspezi­ fikationen der Datenelemente innerhalb der HID- Reporte enthalten; wobei die erste Schnittstellen­ funktion einen HID-Report und eine Verwendungsspe­ zifikation von einem Klientprogramm empfängt und abhängig davon eine oder mehrere Dateneinheiten aus dem HID-Report, welche dieselben Verwendungsspezi­ fikationen wie die von dem Klientprogramm empfange­ nen haben, findet und zurückgibt.

16. Computerlesbares Speichermedium nach Anspruch 15, bei dem die erste Schnittstellenfunktion zusätzlich eine analysierte Reportbeschreibung gestützt auf den HID-Reportdeskriptor von dem Klientprogramm emp­ fängt.

17. Computerlesbares Speichermedium nach Anspruch 15 oder 16, bei dem die erste Schnittstellenfunktion zusätzlich einen Sammlungsidentifikator empfängt und abhängig davon die zurückgegebenen Datenelemente auf solche Elemente in einer HID-Sammlung beschränkt, die von dem Sammlungsidentifikator spezifiziert sind.

18. Computerlesbares Speichermedium nach einem der An­ sprüche 15 bis 17, bei dem die Befehle eine zweite Schnittstellenfunktion definieren, die den HID-Re­ portdeskriptor empfängt und abhängig davon eine ana­ lysierte Reportbeschreibung zurückgibt, wobei die erste Schnittstellenfunktion zusätzlich die analy­ sierte Reportbeschreibung empfängt und diese analy­ sierte Reportbeschreibung zum Finden der Datenele­ mente verwendet.

19. Computerlesbares Speichermedium nach einem der An­ sprüche 15 bis 18, bei dem die erste Schnittstellen­ funktion einen Fehlercode zurückgibt, wenn es kein Datenelement mit der empfangenen Verwendungsspezifi­ kation in dem empfangenen HID-Report gibt, wobei der spezifizierte HID-Report von einer bestimmten Ein­ richtung erzeugt wurde, und wobei der Fehlercode anzeigt, ob ein Steuerelement mit der empfangenen Verwendungsspezifikation in dieser Einrichtung vor­ handen ist.

20. Computerlesbares Speichermedium nach einem der An­ sprüche 15 bis 19, bei dem die Befehle eine zweite Schnittstellenfunktion definieren, welche den HID- Reportdeskriptor empfängt und abhängig davon eine Datenstruktur zurückgibt, die eine analysierte Re­ portbeschreibung enthält, wobei die erste Schnitt­ stellenfunktion zusätzlich die Datenstruktur emp­ fängt und die Datenstruktur zum Finden der Datenein­ heiten verwendet.

21. Computerlesbares Speichermedium nach einem der An­ sprüche 15 bis 20, bei dem die empfangene Verwen­ dungsspezifikation eine Verwendungsseite identifi­ ziert und die zurückgegebenen Dateneinheiten eine Anordnung aus Verwendungsindices umfassen, die HID- Tasten entsprechen, die gedrückt werden, und zwar unabhängig davon, ob der HID-Report Indexfelder oder Bitfelder enthält.

22. Computerlesbares Speichermedium nach einem der An­ sprüche 15 bis 21, bei dem die zurückgegebenen Da­ teneinheiten mehrere HID-Werte umfassen.

23. Computerlesbares Speichermedium nach einem der An­ sprüche 15 bis 22, bei dem die Befehle eine weitere Schnittstellenfunktion definieren, die eine Anord­ nung aus Datenstrukturen zurückgibt, welche gestützt auf einen HID-Reportdeskriptor HID-Sammlungen und ihre Beziehungen zueinander spezifizieren.

24. Computerlesbares Speichermedium nach einem der An­ sprüche 15 bis 23, bei dem die Befehle eine weitere Schnittstellenfunktion definieren, die eine Daten­ einheit und eine Verwendungsspezifikation annimmt und abhängig davon die Dateneinheit in einem HID- Report zum Schreiben in eine HID-Einrichtung posi­ tioniert und formatiert.

25. Verfahren zum Lesen von HID-Dateneinheiten mit fol­ genden Verfahrensschritten:
Erhalten eines HID-Reportdeskriptors, der zugehörige HID-Reporte und die Anordnung, Formatierung und Ver­ wendungsspezifikationen der Dateneinheiten innerhalb dieser HID-Reporte beschreibt;
Übergeben des HID-Reportdeskriptors über eine Schnittstelle an einen Parser;
Analysieren des HID-Reportdeskriptors mit dem Parser und Zurückgeben einer analysierten Reportbeschrei­ bung gestützt auf den HID-Reportdeskriptor;
Erhalten eines HID-Reports, der Dateneinheiten ent­ hält, die von dem HID-Deskriptor beschrieben werden;
Aufrufen einer ersten Schnittstellenfunktion mit Argumenten, die den HID-Report, die analysierte Re­ portbeschreibung und eine Verwendungsspezifikation umfassen;
wobei die ersten Schnittstellenfunktion eine oder mehrere Dateneinheiten von dem HID-Report zurück­ gibt, welche die Verwendungsspezifikationen haben, die in den Argumenten der ersten Schnittstellen­ funktion spezifiziert sind.

26. Verfahren nach Anspruch 25, bei dem die erste Schnittstellenfunktion einen Fehlercode zurückgibt, wenn sie das eine oder die mehreren Datenelemente in dem HID-Report nicht finden kann, wobei der Fehler­ code angibt, ob ein Steuerelement mit der Verwen­ dungsspezifikation in dem von dem HID-Reportdeskrip­ tor beschriebenen Report vorhanden ist.

27. Verfahren nach Anspruch 25 oder 26, bei dem HID-Re­ porte von einer bestimmten HID-Einrichtung normiert werden, indem sie gleich groß gemacht werden.

28. Verfahren nach einem der Ansprüche 25 bis 27, bei dem HID-Reporte durch Hinzufügen einer Report-ID zu jedem HID-Report, der nicht bereits eine Report-ID aufweist, normiert werden.

29. Verfahren nach einem der Ansprüche 25 bis 28, bei dem die Argumente der ersten Schnittstellenfunktion einen Sammlungsidentifikator umfassen, wobei die zurückgegebenen Dateneinheiten auf die Einheiten in einer HID-Sammlung begrenzt werden, die von dem Sammlungsidentifikator spezifiziert werden.

30. Verfahren nach einem der Ansprüche 25 bis 29 mit folgenden weiteren Verfahrensschritten:
Aufrufen einer zweiten Schnittstellenfunktion mit einem Argument, das die analysierte Reportbeschrei­ bung umfaßt;
Zurückgeben einer Anordnung aus Datenstrukturen, welche HID-Sammlungen und ihre Beziehungen zuein­ ander spezifizieren, durch die zweite Schnittstel­ lenfunktion.

31. Verfahren nach einem der Ansprüche 25 bis 30, bei dem die Verwendungsspezifikation eine Verwendungs­ seite ist und die zurückgegebenen Dateneinheiten mehrere HID-Werte umfassen.

32. Verfahren nach einem der Ansprüche 35 bis 30, bei dem die Verwendungsspezifikation eine Verwendungs­ seite ist und die zurückgegebenen Dateneinheiten eine Anordnung aus Verwendungsindices umfassen, die HID-Tasten entsprechen, die gedrückt werden, und zwar unabhängig davon, ob der HID-Report Indexfelder oder Bitfelder enthält.

33. Computerlesbares Speichermedium enthaltend von einem Computer ausführbare Befehle, die einen Gruppe aus Schnittstellenfunktionen definieren, die in einem Computersystem aufrufbar sind, das einen HID-Ein­ richtung aufweist, die HID-Reporte enthaltend Daten­ einheiten und einen HID-Reportdeskriptor aufweist, welcher die HID-Reporte und Anordnung, Formatierung und Verwendungsspezifikationen der Dateneinheiten innerhalb der HID-Reporte beschreibt, wobei die Gruppe aus Schnittstellenfunktionen durch folgende Befehle definiert ist:
eine Deskriptoranalysefunktion, die ein Funktions­ argument umfassend einen HID-Reportdeskriptor emp­ fängt und abhängig davon den HID-Reportdeskriptor analysiert und eine analysierte Reportbeschreibung gestützt auf den HID-Reportdeskriptor zurückgibt;
eine oder mehrere Dateneinheit-Wiedergewinnungs­ funktionen, welche Funktionsargumente umfassend einen HID-Report, die analysierte Reportbeschreibung und eine Verwendungsspezifikation empfangen; wobei die eine oder mehreren Dateneinheit-Wiedergewin­ nungsfunktionen eine oder mehrere Dateneinheiten aus dem HID-Report wiedergewinnen und zurückgeben, wel­ che die Verwendungsspezifikationen haben, die in den Argumenten für die Dateneinheit-Wiedergewin­ nungsfunktionen angegeben sind.

34. Computerlesbares Speichermedium nach Anspruch 33, bei dem die Dateneinheit-Wiedergewinnungsfunktionen eine Tastenwiedergewinnungsfunktion umfassen, wobei die Verwendungsspezifikation eine Verwendungsseite umfaßt; wobei die Tastenwiedergewinnungsfunktion eine Anordnung aus Verwendungsindices zurückgibt, welche HID-Tasten entsprechen, die gedrückt werden, und zwar unabhängig davon, ob der HID-Report Index­ felder oder Bitfelder enthält.

35. Computerlesbares Speichermedium nach Anspruch 33 oder 34, bei dem die Dateneinheit-Wiedergewinnungs­ funktionen eine Wertwiedergewinnungsfunktion umfas­ sen, wobei die Verwendungsspezifikation eine Verwen­ dungsseite und einen Verwendungsindex aufweist; und wobei die Wertwiedergewinnungsfunktion einen HID- Wert zurückgibt, welcher der Verwendungs­ spezifikation entspricht.

36. Computerlesbares Speichermedium nach einem der An­ sprüche 33 bis 35, bei dem die Dateneinheit-Wieder­ gewinnungsfunktion eine Anordnung aus HID-Werten zu­ rückgibt, welche der Verwendungsspezifikation ent­ sprechen.

37. Computerlesbares Speichermedium nach Anspruch 33, bei dem die Dateneinheit-Wiedergewinnungsfunktionen folgende Merkmale aufweisen:
eine Tastenwiedergewinnungsfunktion, welche eine Anordnung aus Verwendungsindices zurückgibt, die HID-Tasten entsprechen, die gedrückt werden, und zwar unabhängig davon, ob der HID-Report Indexfelder oder Bitfelder enthält;
eine Wertwiedergewinnungsfunktion, die einen oder mehrere HID-Werte zurückgibt.

38. Computerlesbares Speichermedium nach einem der An­ sprüche 33 bis 37, bei dem die Gruppe aus Schnitt­ stellenfunktionen, die von den computerausführbaren Befehlen definiert werden, ferner eine Sammlungs­ identifikationsfunktion definieren, die Funktions­ argumente einschließlich der analysierten Reportbe­ schreibung empfängt und abhängig davon eine Anord­ nung aus Datenstrukturen zurückgibt, welche HID- Sammlungen und deren Beziehungen zueinander spe­ zifizieren.

39. Computerlesbares Speichermedium nach Anspruch 38, bei dem die von den Dateneinheit-Wiedergewinnungs­ funktionen empfangenen Argumente einen optionalen Sammlungsidentifikator umfassen;
die Dateneinheit-Wiedergewinnungsfunktion die zu­ rückgegebenen Dateneinheiten auf solche Einheiten in einer HID-Sammlung begrenzen, die von dem Sammlungs­ identifikator spezifiziert werden, wenn ein solcher Sammlungsidentifikator vorgesehen wird.

40. Computerlesbares Speichermedium nach einem der An­ sprüche 33 bis 39, bei dem die Gruppe aus Schnitt­ stellenfunktionen, die von den computerausführbaren Befehlen definiert werden, ferner eine oder mehrere Dateneinheiten-Schreibfunktionen definiert, welche Funktionsargumente einschließlich einer oder mehrerer Dateneinheiten und einer Verwendungs­ spezifikation empfangen, wobei die eine oder mehreren Dateneinheiten-Schreibfunktionen die Daten­ einheiten in einem HID-Report positionieren und for­ matieren, der in eine HID-Einrichtung geschrieben werden soll.

41. Computerlesbares Speichermedium nach einem der An­ sprüche 33 bis 40, bei dem die Dateneinheit-Wieder­ gewinnungsfunktionen so definiert sind, daß sie be­ züglich ihrer Größe normierte HID-Reporte empfangen.

42. Verfahren zum Zurückgeben von HID-Reporte an an­ fragende Klientprogramme mit einem Treiber der HID- Klasse, der HID-Reporte unterschiedlicher Größe von einer oder mehrere Einrichtungen empfängt, mit fol­ genden Verfahrensschritten:
Empfangen von HID-Reporten von HID-Einrichtungen;
Normieren der HID-Reporte von einer HID-Einrichtung durch Angleichen der Größen der HID-Reporte;
Zurückgeben der HID-Reporte an die anfragenden Klientprogramme.

43. Verfahren nach Anspruch 42, bei dem die gleiche Grö­ ße wenigstens so groß wie der größte HID-Report ist, der von der HID-Einrichtung erzeugt wird.

44. Verfahren nach Anspruch 42 oder 43, bei dem das Nor­ mieren die Hinzufügung einer Report-ID zu jedem HID- Report umfaßt, der nicht bereits eine Report-ID auf­ weist.

45. Verfahren nach Anspruch 43 und 44, bei dem die glei­ che Größe gleich der Größe des größten HID-Reports, der von der HID-Einrichtung erzeugt wird, ein­ schließlich einer möglicherweise hinzugefügten Re­ port-ID ist.

46. Computersystem mit
einem HID-Treiber, der HID-Reporte unterschiedlicher Größe von einer oder mehreren HID-Einrichtungen vor­ sieht;
einem Treiber der HID-Klasse, der so konfiguriert ist, daß er die HID-Reporte von dem HID-Treiber an­ fordert und empfängt und die HID-Reporte abhängig von Anfragen von Klientprogrammen zurückgibt;
wobei der Treiber der HID-Klasse HID-Reporte von einer bestimmten HID-Einrichtung normiert, indem er sie gleich groß macht.

47. Computersystem nach Anspruch 46, bei dem die gleiche Größe wenigstens so groß wie der größte HID-Report ist, der von der HID-Einrichtung erzeugt wird.

48. Computersystem nach einem der Ansprüche 46 oder 47, bei dem das Normieren die Hinzufügung einer Report- ID zu jedem HID-Report umfaßt, der nicht bereits eine Report-ID aufweist.

49. Computersystem nach Anspruch 47 und 48, bei dem die gleiche Größe gleich der Größe des größten HID-Re­ ports, der von der HID-Einrichtung erzeugt wird, einschließlich einer möglicherweise hinzugefügten Report-ID ist.

50. Computerlesbares Speichermedium enthaltend Befehle, die einen Treiber der HID-Klasse realisieren, wobei die Befehle von einem Computer ausführbar sind, um folgende Schritte durchzuführen:
Empfangen von HID-Reporten von einer oder mehreren HID-Einrichtungen;
Hinzufügen einer Report-ID zu jedem HID-Report, der nicht bereits eine Report-ID aufweist;
Normieren der HID-Reporte von einer bestimmten HID- Einrichtung durch Angleichen ihrer Größe;
Zurückgeben der normierten HID-Reporte an anfragende Klientprogramme.

51. Computerlesbares Speichermedium nach Anspruch 50, bei dem die gleiche Größe wenigstens so groß wie der größte HID-Report ist, der von der HID-Einrichtung erzeugt wird.

52. Computerlesbares Speichermedium nach Anspruch 50 oder 52, bei dem das Normieren die Hinzufügung einer Report-ID zu jedem HID-Report umfaßt, der nicht be­ reits eine Report-ID aufweist.

53. Computerlesbares Speichermedium nach einem der An­ sprüche 50-52 bei dem die gleiche Größe gleich der Größe des größten HID-Reports, der von der HID-Ein­ richtung erzeugt wird, einschließlich einer möglicherweise hinzugefügten Report-ID ist.