"Du hast ja Alles" - hmmm vielleicht, wenn ich einen Laptop habe.

  • @grt
    Der Miix wird mit Stift ausgeliefert. Dieser funktioniert mit dem oben erwähnten Treiber nur als dünner Finger.
    Es gibt Voodoo-Treiber mit Pen Support, aber ein kurzer Test hat keine Pen spezifischen Funktionen gebracht. Woran das liegt kann ich noch nicht sagen.
    Dass die generelle Touch Unterstützung funktioniert langt mir im Moment, denn die Funktionen, die ich brauche kann ich darauf aufbauend notfalls selbst realisieren. Das ist dann nur noch mühsam und aufwändig, aber nicht unmöglich.
    Jetzt kommt erst mal das LTE-Modem dran. Denn das ist das letzte KO Kriterium. Wenn ich das nicht zum Laufen bekomme ist, werde ich auch keine Zeit mehr in die Vervollkommnung des Restes investieren.

  • Toll geschrieben und einfach beeindruckend was mit dem nötigen technischen Fachwissens so alles machbar ist!


    bin allerdings zwischendurch bei „Es geht auch anders„ inhaltlich ausgestiegen xD

    iMac 15,1 - Gigabyte GA-Z77-DS3H Rev. 1.0
    i5 3750K :: PowerColor RedDevil RX480 8 GB :: 32 GB Ram DDR 3 :: macOS 11.1 @ Clover r5 & Windows 10 Pro
    MacBook Pro 15,4 - Terra Mobile 1550 :: 15,6" FullHD
    i5-8265U :: Intel UHD620 :: 8 GB RAM :: DW1560 :: macOS 10.15.5 @ Clover r5096

    MacBook Pro 8,1 - 13" Anfang 2011 :: MacBook Air 7,2 - 13" Anfang 2015


  • technisch unversiert bin ich einfach nur fasziniert :thumbsup:


    @Brumbaer in zwei Zeilen soviel Humor einzubauen ist m.E. unübertroffen, Erich Kästner, Karl Valentin, Loriot, Brumbaer, nichts mehr ...

    Grüße

    Arkturus

    "Ein Hackintosh ist wie ein Garten - es gibt immer was zu tun"

  • @Brumbaer hat sich dein Schreibstil schon zu Schulzeiten so entwickelt? Da hatten die Deutschlehrer ja richtig Spaß....

  • Es war ein mal ... da hat er in seiner Bärenhöhle von Winter zu Winter seine Schreibkunst weiterentwickelt, dann eines Tages im Frühling ist es aus ihm heraus gesprudelt und die Menschheit war so weit es anzunehmen, ... und wenn er nicht gestorben ist dann entwickelt er noch Heute. :D

  • @Brumbaer hat sich dein Schreibstil schon zu Schulzeiten so entwickelt? Da hatten die Deutschlehrer ja richtig Spaß....


    Nein, in der Schule waren meine Schwerpunkte Mathe und Physik.

  • Nach Hause telefonieren
    Wollen wir das nicht alle ?
    Na ja, vielleicht, aber ohne leuchtenden Finger, es sei denn wir wären süd-koreanischen Haustierklone.
    Eine ständige Internetverbindung all-überall ist was tolles. Ich habe mich an das LTE Modem im iPad so gewöhnt, dass kein Gerät ohne LTE Modem das iPad ersetzen kann.
    Das eingebaute LTE Modem war einer der Gründe für die Wahl des Miix.


    Alles ganz einfach
    Wo habe ich das schon gehört ?
    Egal - IORegistryExplorer zeigt unter den USB Geräten das Modem an.
    Typ L831-EAU Hersteller Fibocom - und jetzt kommt's - IORegistryExplorer zeigt an, dass "Freude schöner Götter Funken", Treiber geladen werden.


    Ein Gefühl, wie bei km 42 eines Marathonlaufes. Nicht, dass ich jemals einen Marathon gelaufen wäre oder es in Betracht ziehen würde oder es in Betracht ziehen würdew es in Betracht zu ziehen, aber so muss es sich anfühlen, körperlich und emotional erschöpft, aber das Ziel in Sicht, ein letztes Mobilisieren der Kräfte und dann ins Ziel.
    Habe ich auch verdient nach dem Stress mit dem Miix. Einen Tee gekocht, eine Box von nem iPad gesucht, den SIM-Karten-Schlitten-Auswurf-Stecker - Stecker und Auswurf passt nicht ? Doch, doch. Man muss was reinstecken, damit was raus kommt, wie beim Kaugummi-Automaten. Liebe Kinder, Kaugummi-Automaten sind ... googelt's halt.


    Ist denn schon Ostern
    Wo war ich ? Ach ja das Dingens gepackt und die SIM Karte aus dem iPad genommen. Jetzt muss man nur noch den Steckplatz am Miix finden. Wenn das Teil mit ausgeklapptem Ständer vor einem steht, sieht man ihn erst mal nicht. Ich sehe eh besser mit den Händen, also die Seiten abgetastet - nichts. Also gut Gerät von der Tastatur abgezogen, Ständer rangeklappt. Miix nach links, rechts, oben und unten gedreht und nichts. Wenn das so weiter geht, muss ich ins Handbuch schauen. "Nicht mit mir", denke ich, "ich der Mann, der ein Bit am Geruch erkennt, den noch kein Byte gebissen hat, der morgens mit dem Datenbus zur Arbeit fährt und abends mit dem Adressbus nach Hause kommt, der soll in ein Handbuch schauen ? Haaahhh, niemals". Die Schnellstartanleitung tut's auch.
    Es ist auch ganz einfach, man klappt den Ständer auf und dann sieht man dahinter zwar nicht den SIM Karten Slot, aber immerhin das Logo des Slots. Also mal getastet und gleich gefunden. Ich sach ja, ein Fachmann wie ich, findet so einen Slot ja sofort. Der braucht kein Handbuch.
    Die Karte geht etwas schwer rein. Vermutlich weil sie aus einer größeren Karte gestanzt wurde und etwas dicker ist, als die neuen Nanos. Selbstoptimierung macht auch vor SIM Karten nicht halt. Wahrscheinlich ernähren die sich auch nur von veganem Strom.


    Fasching ist draußen
    Auf den Straßen herrscht buntes Treiben, aber hier tut sich nichts. Also Windows gestartet und das Modem getestet und was soll ich sagen ? Es läuft - zumindest das Modem.
    Zurück zu MacOS. Offensichtlich wird ein Ethernettreiber geladen, es kommen nur keine Daten, vermutlich besteht keine LTE-Verbindung.


    Mühsam
    Die Suche nach Informationen über das Modem führt Widersprüchliches zu Tage. In der Produktliste taucht es erst gar nicht auf und die Handbücher, die Google findet, beschreiben unterschiedliche Versionen.
    Wahrscheinlich heißt es Handbuch, weil man trotz des Buches, alles von Hand rauskriegen muss.


    Klassisch
    Klassischerweise hat ein Modem zwei Komponenten. Die eine für die reine Datenübertragung und die andere für den Verbindungsaufbau. Die für Datenübertragung tut beim Mac so als wäre sie ein Ethernetcontroller und die andere als sei sie ein serielles AT Modem. Den AT Befehlssatz gibt es seid Ewigkeiten. Inzwischen wurde er natürlich, um ein paar Features z.B. für den Verbindungsaufbau über Handy Netz erweitert. Bei den Erweiterungen kocht zum Teil jeder Hersteller seinen eigenen Buchstabensalat.
    Bei der Suche nach Informationen über das L831-EAU bin ich auch über ein Handbuch zu dessen Interpretation des AT Chipsatzes gestolpert.


    Desinteresse
    Schaut man sich obigen Auszug aus dem IORegistryExplorer an, sieht man

    • HS03. Das ist der USB Port - interessiert uns nicht.
    • L831-EAU@14300000 ist das USB-Gerät. Gaaanz toll - aber interessiert uns nicht. Dann sehen wir zwei Treiber.
    • AppleUSBHostCompositeDevice ist ein Treiber für USB Geräte, die mehrere Funktionen in sich vereinen. Welche Funktion ein USB Gerät hat geben seine Klasse, Unterklasse und Protokoll an. Das Tripel sagt zum Beispiel Drucker. Und für diese Funktion gibt es dann ein Interface. Manchmal hat ein Gerät aber mehr als eine Funktion, z.B. Drucker und Scanner. Dann hat man ein Composite Device und Geräte Klasse, Unterklasse und Protokoll verweisen bezüglich der Funktion auf die Interfaces. Und es gibt ein Interface für die Druckfunktion und eins für die Scanfunktion, jeweils mit passender Klasse, Unterklasse und Protokoll. AppleUSBHostCompositeDevice verwaltet solche Mehrfach-Funktionsgeräte und ist im laufenden Betrieb eher unsichtbar. Kurzum interessiert hier nicht.
    • AppleUSBHostLegacyClient stellt die Kompatibilität mit älteren Programmen her. Interessiert hier auch nicht.

    Desdesinteresse
    Auf der selben Ebene gibt es noch Data (OFF)@1 und Fibocom L831-EAU (NCM)@0. Dies sind die zwei Interfaces mit ihren Treibern. Das Data Interface lädt einen Ethernettreiber. Das sieht gut aus, aber das andere, zeigt keinen seriellen Treiber, also klappt die normale Methode mit AT Befehlen über eine serielle Schnittstelle nicht.


    Bestandsaufnahme
    Da stellt sich uns die Frage, "was gibt's zu Mittag ?". Nein, also doch schon, aber eigentlich, wollte ich auf "Hat das Modem eine serielle Schnittstelle und wenn nein was hat es stattdessen ?" hinaus.


    Statt nur das Ergebnis zu präsentieren, zeige ich im Folgenden wie das Ergebnis zu Stande kam. Wenn man schon weiß wie es geht, ist es in einer Minute erledigt. Dank der Erklärung dauert es deutlich länger. Die, die USB Deskriptoren und der Aufbau von USB Geräten nicht interessiert oder ihn schon kennen, können gerne zu Was sagt uns das ? springen.


    USB Stocherer
    Wieder mal eine schöne Übersetzung. USB Prober ist eine App und Teil des Apple USBFamily Log Paketes. Es soll Hardware Entwickler beim Anbinden von USB Geräten und der USB Treiber Entwicklung unterstützen. Dass die neueste Version zum System 10.9.4 gehört, sagt viel über den aktuellen Stand der Unterstützung von Hardware Entwicklern. Ob die Unterstützung für große Firmen besser ist, weiß ich nicht.
    Ok, genug gejammert, der Miix liefert genug Gründe zum Jammern, da brauch ich nicht noch Apple für.
    Ach ja, das Paket findet man auf der Apple Webseite unter https://developer.apple.com/download/more/. Im Suchfeld USB eingeben. Ob man es mit jeder Art von Entwickleraccount runter laden kann oder ob es noch sonst wo zum Download angeboten wird weiß ich nicht.


    Was haben wir denn da ?
    Die USB Spezifikation legt fest, dass jedes USB Gerät über Descriptors definiert wird. Ein Descriptor beschreibt die Eigenschaften einer Komponente und ihre Unterkomponenten. Die Deskriptoren bilden so eine Hierarchie in Form einer Baumstruktur. Die Struktur der Deskriptoren spiegelt die Struktur der Komponenten eines USB Gerätes wieder. Am Ende des Textes ist eine Grafik, die die Organisation der Deskriptoren nicht als Baum, sondern als Schachtelbild zeigt.
    USB Prober liest die Deskriptoren und bereitet sie in von Menschen lesbarer Form auf:


    In der ersten Zeile erfahren wir, dass es sich um das fünfte USB Gerät handelt, über USB 2.0 (High Speed) kommuniziert und am Port 3 (die 3 in 0x14300000) hängt, der Klasse Verschiedenes angehört und das Gerät L831-EAU heißt.
    Uns interessiert das Gerät, nicht wo am Computer es angeschlossen ist, deshalb ignorieren wir die Port Informationen.


    Das Ende ist nah
    Endpoints sind die Punkte an denen die Pipes anknüpfen. Pipes sind die Datenübertragungs-Kanäle. Die Daten fließen durch die Pipes von einem Endpoint zum Computer oder vom Computer zu einem Endpoint.


    Es geht nicht ohne
    Die Geräteverwaltung hat einen eigenen Endpoint, den Endpoint 0. Das ist der Control Endpoint. Computer und USB kommunizieren nach einem strengen Protokoll. Der Computer sendet einen 8 Byte langen Request. Danach können noch Daten folgen, die vom Computer oder dem USB-Gerät stammen können. Es gibt vordefinierte Requests für alles Mögliche und man kann auch eigene Requests definieren. Zu den vordefinierten Requests gehören zum Beispiel das Wählen einer Konfiguration und das Abfragen der Deskriptoren. Ohne diese Fähigkeiten geht nichts, deshalb muss jedes USB Gerät einen Endpoint 0, einen Control Endpoint haben.


    Aber es geht auch anders
    Der Control Endpoint wird mit dem Gerät selbst und dessen Verwaltung assoziiert und sein Übertragungsprotokoll ist nicht wirklich effizient.


    Deshalb können Interfaces (kommt gleich) eigene Endpoints definieren.
    Diese Endpoints können nur gelesen oder beschrieben werden, aber im Gegensatz zum Endpoint 0 nicht beides.
    Soll ein Interface Daten empfangen und senden können, muss es zwei Endpoints bekommen, einen zum Senden und einen zum Empfangen.


    Endpoints werden durchnummeriert. Da die 0 schon vom Control Endpoint belegt ist, beginnen die Endpoints, die beschrieben werden, bei der 0x01 und Endpoints, die gelesen werden, bei 0x81.
    Die Datenübertragung erfolgt nicht mit Requests, sondern in einem von drei anderen Modi:

    • Bulk - Byte folgt auf Byte, Computer kontrolliert, z.B. Daten von oder zu einer Festplatte
    • Interrupt - Das Gerät schickt Daten unaufgefordert an den Computer. Falls das Gerät dem Computer was sagen muss. Z.B. bei einem Überwachungsgerät oder wenn das Gerät was macht und sich dann meldet wenn es fertig ist. In Wahrheit fragt der Computer regelmäßig nach, ob das Gerät Daten hat, die es loswerden will. Das passiert aber im verborgenen und sieht von außen so aus als wäre da ein Interrupt am Werke.
    • Isochronous - Daten werden als kontinuierlicher Datenstrom übertragen. Z.B. von einer Videocamera. Wie bei einem Hop-on Bus, kann mann jederzeit ein- oder aussteigen.
    • Wie gesagt ein USB-Gerät muss über keinen solchen Endpoint verfügen, aber es muss einen Control-Endpoint besitzen.

    Der L831-EAU hat laut USB Prober in der momentan ausgewählten Konfiguration 4 Endpoints inkl. des Endpoints 0. Der Endpoint wird vom Gerät zur Verfügung gestellt. Die anderen 3 Endpoints müssen von einem oder mehreren Interfaces zur Verfügung gestellt werden.
    Die Anzahl und Art der Interfaces und damit die Anzahl und Art der Endpoints hängt von der jeweiligen Konfiguration (Configuration) ab. Es ist selten, dass eine Gerät mehr als eine Konfiguration unterstützt. USB Prober weißt auch nur einen Configuration Descriptor aus. D.h. unser Gerät hat auch nur eine Konfiguration.
    Die schauen wir uns später an.
    Der Device Descriptor erzählt uns Allgemeines über unser USB Gerät. Die meisten der Einträge sollten selbst erklärend sein. Number of Configurations bestätigt uns, dass es nur eine Konfiguration gibt.
    Device Class, Subclass und Protocol verdienen besondere Erwähnung. USB verwendet Klassen, Unterklassen und Protokolle, um Geräte in Gruppen einzuteilen. Alle Geräte einer Gruppe haben bestimmte Eigenschaften. Typische Gruppen sind Drucker, Audio/Video oder Drahtlos. Unter http://www.usb.org/developers/defined_class/#BaseClassEFh findet man eine Auflistung.
    In unserem Falls ist die Klasse 239. Das ist wenig hilfreich, steht die 239 doch für Verschiedenes. Unterklasse 2 und Protokoll 1 bedeuten "es gibt einen Interface Association Descriptor, der mehr über die Geräte Funktion aussagt". Dieser ist Teil der Konfiguration, wir werden ihn deshalb später als Teil des Configuration Descriptors wiederfinden.


    Das Leben der anderen
    Den Configuration Descriptor schieben wir noch mal nach hinten. Und so kommen wir zu Device Qualifier Descriptor und Other Speed Configuration Descriptor. Beide gibt es nur bei High Speed (USB 2.0) Geräten. High Speed Geräte unterstützen zwei Geschwindigkeiten: Full- (USB 1.0) und High-Speed (USB 2.0). In der ersten Zeile stand, dass im Moment High Speed verwendet wird. Nun ist es möglich, dass sich die Deskriptoren im High- und Full-Speed Modus unterscheiden. Diese beiden Deskriptoren beschreiben das Gerät im "anderen", dem gerade nicht verwendeten Modus. Es ist uns egal was im Full-Speed Modus wäre, wir werden ihn nie verwenden, deshalb ignorieren wir die beiden Deskriptoren.


    Last, not least
    Jetzt können wir uns nicht länger vor dem Configuration Descriptor drücken.


    Der Configuration Descriptor trägt selbst wenig zur Erleuchtung bei, aber seine Unterdeskriptoren haben es in sich.
    Bei einem USB Gerät stellen die Interfaces die Funktionen zur Verfügung. Bei einer Drucker, Scanner, Fax Kombi würde man je ein Interface für die Druck, Scan- und Faxfunktion anlegen. Man kann auch Alles irgendwie in einem Interface verwurschteln, aber vorgesehen ist eine Aufteilung der Funktionen auf verschiedene Interfaces.
    Der Interface Association Descriptor gibt ergänzende Informationen über die Konfiguration und das Zusammenspiel der Interfaces. Er ist nur notwendig, wenn im Device Descriptor auf ihn verwiesen wird.
    Das erste Interface (First Interface) ist das Interface mit der Nummer 0. Insgesamt (Interface Count) gibt es zwei Interfaces. Der eine oder andere mag sich erinnern, dass der Device Descriptor sich nicht auf eine Funktion festnageln lassen wollte und auf den Interface Association Descriptor verwiesen hat. Und der sagt jetzt Klasse 2 (Kommunikationsgerät) , Unterklasse 13 (NCM - Network Control Model) und Protokoll 0 (No encapsulated commands / responses.).
    Also ein Modem, dass der NCM Unterklasse angehört und keine encapsulated commands/respones unterstützt.


    Die fünf, die zwei waren
    Anzahl der Interfaces ist laut Configuration Descriptor 2, aber wir sehen 5 Interfaces. Na ja es sind nur 2 Interfaces, Interface 0 und Interface 1, von denen gibt es aber 2 bzw. 3 Varianten. Wozu denn das, warum hat man nicht einfach zusätzliche Konfigurationen angelegt ?
    Eine Konfiguration, kann den Charakter des Gerätes komplett ändern und wenn man zwischen zwei Konfigurationen wechselt ist es so als ob man das Gerät abzieht und ein anderes Gerät anschließt. Alles auf Anfang. Schaltet man bei der Druck-, Scan-, Fax-Kombi die Konfiguration um, um z.B. die Drucker Emulation zu wechseln, brechen auch laufende Scans und Faxübertragungen ab und auch Scanner und Fax, werden zurückgesetzt.
    Das Umschalten auf ein Alternatives-Interface, betrifft nur dieses Interface und lässt den Rest des Gerätes unberührt. Das erlaubt ein relative glattes Umschalten einzelner Funktionen im laufenden Betrieb.


    Die zwei Alternativen für das Interface 0 sind sich ziemlich ähnlich. Alternate Setting gibt an um welche Alternative es sich handelt. Alternative 0 ist die, die nach einem Neustart automatisch gewählt wird. Beide Alternativen haben einen Interrupt Endpoint mit der Nummer 0x81. Da die Nummer mit 8 beginnt handelt es sich um einen Endpoint der gelesen wird. Interface Class, Subclass und Protocol definieren wieder die Art des Interfaces. Bei der ersten Alternative handelt es sich um die uns aus dem Interface Association Descriptor vertrauten Werte. Alternative 1 ist ein Kommunikationsgerät, Unterklasse MBIM (Mobile Broadband Interface Model) und Protokoll MBIM-Protokoll.
    Die Gruppenzugehörigkeit beeinflusst die verfügbaren Functional Descriptors. Diese beschreiben verschiedene Aspekte dieser speziellen Interface Art und interessieren uns in diesem Moment nicht.
    Lange Rede stark gekürzt. Interface 0 kontrolliert die Kommunikation nach NCM oder MBIM. Was auch immer das sein mag.


    Interface 1 hat 3 Varianten.
    Alternative 0 hat keine Endpoints, macht demzufolge Datenübertragungs-technisch nichts, also Datenübertragung aus. Die anderen beiden Varianten haben jeweils einen Lese- und Schreib-Endpoint vom Typ Bulk. Also massenweise Daten rein und raus - macht Sinn.
    Alle drei gehören der Datenübertragungsklasse, Abteilung Daten an. Interface 0 war Abteilung Kontrolle. In der Abteilung Daten sind keine Unterklassen definiert, weshalb Subclass bei allen dreien auf 0 steht. Das Protokoll der ersten beiden Alternativen ist Networktransport Block bei der letzten Alternative MBIM.
    Interface 3 bietet also drei Alternativen, Aus, NCM Daten und MBIM Daten.


    Einen hab ich noch
    Der Vollständigkeit halber schauen wir uns noch einen Endpoint Descriptor an. Wir sehen seine Nummer (Address), den Übertragungsmodus (Attributes), die maximale Größe eines Paketes (Max. Packet Size) und wie oft nach Daten geschaut werden soll, falls es sich um einen Interrupt Endpoint handelt (Polling Interval).
    Da die Endpoint Descriptors zu den Interfaces gehören, gibt es keinen Deskriptor für den Control Endpoint der gehört ja zum Gerät. Auf der anderen Seite, seine Adresse ist immer 0, sein Übertragungsmodus immer Control und abgefragt, wird er auch nicht. Also bleibt nur die maximale Paketgröße. Die findet sich tatsächlich oben im Device Descriptor als Device MaxPacketSize. Alles gut.


    Sag mir wo die Texte stehen, wo sind sie geblieben ?
    Texte haben unterschiedliche Längen und können in verschiedenen Sprachen vorliegen. Damit die einzelnen Deskriptoren eine feste Größe haben und man mit wenig Aufwand mehrere Sprachen unterstützen kann, werden die Texte nicht in den Deskriptoren gespeichert. Stattdessen wird nur mittels einer Nummer (index) auf einen String Deskriptor verwiesen. Dieser String Descriptor enthält dann den Text.
    USB Prober ersetzt die Nummern in den Deskriptoren freundlicherweise gleich durch die entsprechenden Texte.


    Was sagt uns das ?
    Das Gerät dient der Datenübertragung und unterstützt die Datenprotokolle NCM und MBIM.
    Zu jedem gibt es eine passendes Daten- und ein passendes Kontrollinterface. Beide Kontrollinterfaces haben jeweils nur einen Interrupt-Lese-Endpoint. Das ist also bestimmt keine serielle Schnittstelle.


    Also kein Umschalten der Konfiguration oder Umschalten auf ein alternatives Interface und schon ist alles wie wir es gerne hätten. Wir werden mit den Standardmethoden und AT Befehlen, nicht weiterkommen.
    Also zurück zum Anfang. Im IORegistry Explorer stand ja auch, dass kein serieller Treiber für das Kommunikations-Kontroll-Interface geladen wurde, sondern AppleUSBNCMControl.


    Denen, die finden für diese Erkenntnis hat sich der Exkurs in die Welt der Deskriptoren nicht gelohnt, sei gesagt: They will be back.

    Wenn das km 42 ist, dann liegt das Ziel hinter einer Kurve, denn zu sehen ist es noch nicht.

    PS Descriptor

  • Ich liebe diesen Schreibstil.

    Chris

  • Den Einwurf mit den Kaugummi-Automaten muss ich noch mal erwähnen, neben dem ganzen fachlichen vielleicht der wichtigste Hinweis....

  • Zitat von made my day

    Wenn das so weiter geht, muss ich ins Handbuch schauen. "Nicht mit mir", denke ich, "ich der Mann, der ein Bit am Geruch erkennt, den noch kein Byte gebissen hat, der morgens mit dem Datenbus zur Arbeit fährt und abends mit dem Adressbus nach Hause kommt, der soll in ein Handbuch schauen ? Haaahhh, niemals"


    toi toi toi weiterhin

    iMac 15,1 - Gigabyte GA-Z77-DS3H Rev. 1.0
    i5 3750K :: PowerColor RedDevil RX480 8 GB :: 32 GB Ram DDR 3 :: macOS 11.1 @ Clover r5 & Windows 10 Pro
    MacBook Pro 15,4 - Terra Mobile 1550 :: 15,6" FullHD
    i5-8265U :: Intel UHD620 :: 8 GB RAM :: DW1560 :: macOS 10.15.5 @ Clover r5096

    MacBook Pro 8,1 - 13" Anfang 2011 :: MacBook Air 7,2 - 13" Anfang 2015


  • Hallo Brumbaer!


    Ich habe eine Verständnisfrage zum Thema Touchscreen.


    VoodooI2CHID unterstützt mit Hilfe des macos HID Treibers:


    Klicken durch Zeigen auf eine Stelle
    Drag durch Klicken auf eine Stelle und Bewegen des Fingers
    RechstKlick durch Klicken und Gedrückt-Halten.
    Scrollen mit zwei Fingern.
    Doppelklick funktioniert etwas unzuverlässig, da es schwer ist zweimal kurz hintereinander die selbe Stelle zu treffen.


    Bei mir klappt aktuell nur Klick und Drag wirklich zuverlässig. Nutze den ApplePS2Controller.kext und hatte auch mal Voodoo getestet, aber da war das Touchpad dann etwas träge und den Touchscreen habe ich gar nicht getestet. Wenn ich jetzt die VoodooI2CHID testen möchte. Reicht es die ApplePS2... zu ersetzen oder ist zusätzlich eine andere Voodoo Kext nötig? Oder kann man das so Pauschal gar nicht beantworten?


    Falls du solche Fragen nicht in deinem Thread möchtest, bitte ich um Entschuldigung und Verschieben.


    Danke :)

    iMac 15,1 - Gigabyte GA-Z77-DS3H Rev. 1.0
    i5 3750K :: PowerColor RedDevil RX480 8 GB :: 32 GB Ram DDR 3 :: macOS 11.1 @ Clover r5 & Windows 10 Pro
    MacBook Pro 15,4 - Terra Mobile 1550 :: 15,6" FullHD
    i5-8265U :: Intel UHD620 :: 8 GB RAM :: DW1560 :: macOS 10.15.5 @ Clover r5096

    MacBook Pro 8,1 - 13" Anfang 2011 :: MacBook Air 7,2 - 13" Anfang 2015


  • Bin zwar nicht @Brumbaer und er ist hoffentlich nicht böse wenn ich antworte.


    Du benötigst immer denn VoodooI2C.kext und denn VoodooI2CHID.kext.
    Hier die Entwicklerseite dazu mit Hilfsanleitung.
    https://github.com/alexandred/VoodooI2C

  • Selbstoptimierung macht auch vor SIM Karten nicht halt. Wahrscheinlich ernähren die sich auch nur von veganem Strom.


    Pffeeww..... :D


    Mensch Brumbaer, siehst Du nicht, dass ich gerade Kaffee trinke? Beinahe die Tastatur unter Kaffee gesetzt. :thumbup:

    Liebe Grüße aus Berlin

  • AppleUSBNCMControl
    Ist das eine Drohung oder eine Versprechen, Erlösung oder Verdammnis, Peek oder Cloppenburg ?
    Bei dem Namen liegt die Verbindung nahe, dass der Treiber in AppleUSBNCMIrgendwas.kext zu finden ist.
    Es stellt sich heraus es gibt tatsächlich ein Kext und sein Irgendwas ist Nichts.
    "AppleUSBNCMNichts.kext, sehr lustig, ha, ha, ha, was haben wir wieder gelacht".
    Das AppleUSBNCM.kext hat Alles was man erwartet u.a. eine Info.plist und eine Programmdatei names AppleUSBNCM.


    Persönchen
    In der Info.plist schauen wir uns die IOKitPersonalities an, denn die sind der Weg zum Herzen des Kextes.

    Es gibt drei Persönchen, die einen von zwei Treibern laden. Entweder AppleUSBNCMControl oder AppleUSBData.
    Bei allen ist die IOProviderClass IOUSBHostInterface. D.h. sie hängen sich an ein USB-interface. An welches legen bInterfaceClass, bInterfaceSubClass und bInterfaceProtocol fest. Sie entsprechen der Klasse, Unterklasse und dem Protokoll im USB-Interface-Decriptor.


    Wer mit wem
    Nach einem Neustart wird die Konfiguration des USB Gerätes auf 1 gesetzt und alle Interface Alternativen 0 ausgewählt. Davon ausgehend, dass niemand was daran geändert hat, hätten wir bel L831-EAU
    Interface 0 mit Klasse 2, Unterklasse 13 und Protokoll 0.
    Interface 1 mit Klasse 10, Unterklasse 0 und Protokoll 1.


    AppleUSBNCMControl testet auf Klasse 2, Unterklasse 13 und Protokoll * (egal) und hängt sich deshalb an Interface 0.
    AppleUSBNCMData0 testet auf Klasse 10, Unterklasse 0 und Protokoll 1 und hängt sich deshalb an Interface 1.
    AppleUSBNCMData13 testet auf Klasse 10, Unterklasse 13 und Protokoll 1 und hängt sich deshalb an kein Interface, denn wir haben keins mit solch einem Tripel.


    Dazu hätte wir die Info.plist nicht aufmachen müssen, das zeigt uns auch der IORegistryExplorer. Allerdings kann uns der IORegistryExplorer nicht zeigen, was nicht geladen wurde.
    Der Eintrag für AppleUSBNCMControl hat kein CFBundleIdentifier Feld, also ist der Treiber in der Programmdatei dieses Kextes gespeichert.


    Not Cool Man
    könnte sein, mit NCM ist an dieser Stelle aber vermutlich Network Control Model gemeint. NCM ist eine Unterklasse der USB CDC (Communication Device Class) Klasse. Auf USB.org kann man die entsprechenden Spezifikationen downloaden.
    In Kürze NCM unterscheidet Daten und Kontroll-Funktionen (Interfaces). Die Daten Funktionen empfangen und senden Pakete. Diese Pakete bestehen aus den Paketen, so wie sie über das Ethernet verschickt werden würden, ergänzt um Informationen, die dem Modem mitteilen, was und wieviel es da bekommt. Wenn man Pakete in Pakete packt, so nennt man das einbetten.


    Wie man sich einbettet, so ....
    Der Kontroll-Kanal kann ein Embedded Request and Response Protocol unterstützen.
    Man schickt einen besonderen Request an den Control-Endpoint (An letztes Mal erinnern: Control Endpoint, Requests - Befehl mit optionalen Daten vom oder zum USB Gerät, schon wieder vergessen ?). Die Daten des Requests sind aber keine Daten, sondern ein Befehl, eine Aufforderung (Request) an das Modem. D.h. der Request an das Modem ist in den Daten des Requests an das USB-Gerät eingebettet.
    Hat das Modem den Befehl ausgeführt, so schickt es von einem Interrupt-Endpoint eine Nachricht. Empfängt der Treiber die Nachricht schickt er einen Request an den Control-Endpoint, er möchte doch mit den Daten - meist die Antwort (Response) auf einen Request an das Modem - rausrücken. Was der dann auch tut indem er sie in die Daten des Requests einbettet.
    Über den Interrupt-Endpoint wird auch eine Nachricht geschickt, wenn das Modem etwas, z.B. dass sich die Empfangsstärke geändert hat, mitzuteilen hat.
    Wir erinnern uns an letztes mal, die Interface Deskriptoren für Interface 0 ? Nur einen Endpoint, einen Lese-Interrupt-Endpoint. Also genau das was man für dieses Verfahren braucht.
    Dann wollen wir das Ding doch mal eintüten oder besser einbetten.


    Schwierige Entscheidung
    Nun kann man entweder einen neuen Treiber schreiben oder das was Apple anbietet verwenden. Wäre schon schön, wenn man das nicht neu schreiben müsste,
    Mac Treiber werden in C++ geschrieben und die Treiber sind C++ Klassen, die von der Klasse IOService erben.
    Im Idealfall hat man eine Headerdatei mit der Klassendefinition. Natürlich gibt es keine Headerfiles oder sonst eineDokumentation zu AppleUSBNCM. Apple stellt allerdings die Quellen zu AppleUSBCDC der Superklasse von AppleUSBNCM, zur Verfügung. Allerdings in der Version 4.5. Inzwischen sind wir bei 5.0 und die verwendeten USB Interface- und Device-Klassen haben sich geändert.
    Aber wir haben ja eine ausführbare Datei, die unsere Klasse enthält. Man kann nun aus der ausführbaren Datei die Informationen gewinnen, die man zur Erstellung einer Headerdatei benötigt.
    Einige recht einfach, andere mit Aufwand.
    Denen, die interessiert wie das geht, sei gesagt, dass das den Rahmen dieser Berschreibung sprengen würde, es ist genug Stoff für eine eigene Artikelserie. Es sei nur gesagt, dass Hopper eine große Hilfe dabei ist und dass er einen Python Interpreter enthält mit dem einige Abläufe automatisieren kann.
    Bei meinen Reisen durch AppleUSBNCM kam ich an eine Stelle an der ich einen Funktionsnamen gebraucht hätte, den Hopper auch brav ausgab, der aber nicht über Python abzufragen war. Eine Anfrage beim Entwickler bescherte mir 3 Tage später eine Hopper Version mit der das möglich war - wow, besser, WOW.


    So nicht
    Nachdem die AppleUSBNCM und AppleUSBCDC (Superklasse von AppleUSBNCM) soweit analysiert waren, dass ich wusste, was sie warum taten, versuchte ich eine Kommunikation mit dem Modem herzustellen.
    Ich konnte zwar die Embedded Commands senden, aber es gab nie eine Rückmeldung vom Interrupt Endpoint.
    Also habe ich einen neuen Treiber geschrieben. für den Fall, dass ich bei der Analyse von AppleUSBNCM etwas übersehen habe. Nein, habe ich
    wohl nicht.
    Also nochmals in die USB Deskriptoren geschaut, ob es denn einen Hinweis auf eine andere Zugriffsvariante gibt, und siehe da: Es gibt keinen.


    Wer lesen kann, ist klar im Vorteil
    Wir hatten gesehen, dass unser Control Interface (USB Interface 0, Alternative 0) vom Typ Klasse 2, Unterklasse 13 und Protokoll 0 war.
    Klasse war Kommunikation, Unterklasse NCM und Protokoll laut Spec No encapsulated commands / responses.
    Tufftäääh, Tufftäääh, Tufftäääh. Da steht laut und deutlich, na eher kontrastreich und gut leserlich No encapsulated commands / responses.
    Das Ding kann gar keine Embedded Commands/Responses also wird der Embedded Commands/Responses Treiber (AppleUSBNCMControl) zwar geladen, aber das Gerät unterstützt die Funktion nicht. Kann also nicht gehen. Hätte ich auch gleich lesen können. Obwohl, ich nehme an, dass ich es gelesen hatte, aber es ist halt nicht hängengeblieben.
    Es ist ärgerlich, die Zeit für die Analyse des Apple Treibers und das Schreiben eines eigenen Treibers verschwendet zu haben. Aber eigentlich spielt es keine Rolle, denn irgendwann würde ich es ja doch tun müssen.


    Wat nu, sprach die Kuh
    Na ja wenn man nicht weiter weiß schaut man, wie es die machen, die wissen wie es geht. In unserem Fall sind das die Windowers.
    Es gibt Tools mit denen kann man die Kommunikation zwischen Computer und Geräten überwachen. Auf dem Mac gibt es z.B. Wireshark um sich Netzwerkpakete anzuschauen und zu analysieren.


    Trüffelschweine
    Hier geht es darum ein Tool zu finden, das den USB Verkehr unter Windows überwacht und ausgibt. Solche Tools nennt man oft Sniffer, also USB Sniffer gegoogelt. Und man findet auch ein paar. Sie sind nicht billig, aber meist gibt es eine Demo Version - einen Monat Prüfung bevor man sich ewig bindet. Ein Monat sollte langen.
    Verschiedene ausprobiert und alle bringen Windows beim Booten zum Absturz. Na super. "Na, super" mit sarkastischem Unterton sagt man ja nicht mehr. Heute sagt man ja: Na, Diesel.
    ie Sniffer arbeiten nach dem selben Prinzip, sie hängen einen Schnüffel-Treiber in den USB Treiberstapel. Während der Schnüffeltreiber sich in den USB Stack wühlt, wie das Trüffelschwein seine Nase in die feuchte Erde, funktioniert USB nicht. Dummerweise ist mein Windows auf einer USB Platte und das Trüffelschwein zieht dem Windows die Platte weg und Windows landet mit dem Schwein Nase an Nase im Dreck.


    Neues Fenster
    Das Miix hat für Massenspeicher genau einen M.2 Slot. Das macht die Wahl des Ortes für die Windows-Installation leicht, mit auf die M.2. An einem runden Tisch ist immer noch in Platz, alle müssen nur etwas zusammenrücken. Dankbarer-weise geht das auch bei M.2 SSDs, obwohl die nicht rund sind. Das Festplattendienstprogramm geöffnet und 128GB von der HFS+ Partition abgezwackt.
    Wie pflegen die Helden zu sagen, "heute ist ein guter Tag, mal wieder die EFI Partition auf einen USB Stick zu kopieren", denn "Kopierst du in der Zeit, bootest du in der Not".
    Dann WIndows von eine USB Stick installiert. Die Seriennummer des Miix hat das Windows ungefragt übernommen.
    Und Windows geht einwandfrei, Sniffer installiert, geht auch. Nur macos geht nicht mehr. Nicht mal an Clover komme ich ran. Na, Diesel.


    Eiskalt
    Da läuft's einem kalt den Rücken runter. Aber mit BOOTICE bekommt man schnell warme Füße.
    Mit BOOTICE kann man die EFI Booteinträge manipulieren. Das Programm hat ein etwas altmodisches Aussehen, erfüllt aber seinen Zweck. Man kann alle notwendigen Schritte mit BOOTICE erledigen.


    Zuerst mountet man die EFI Partition (Reiter Physical Disk, Button Parts Management. Partition anwählen, Button Assign Drive Letter).
    Dann fügt man einen Eintrag für \EFI\BOOT\BOOTX64.efi hinzu (Reiter UEFI, Button Edit boot entries, Button Add, Datei auswählen).
    Dann bewegt man den Eintrag an den Anfang der Liste (Button Up),
    und speichert die Änderung (Button Save current boot entry).


    Programm beenden, Neustart, fettig.


    Und das nächste mal wird geschnüffelt.

  • Windows-Phone
    Irgendwie schon, aber Windows-Modem trifft es besser.
    Verbindung mit dem Netz hergestellt, den Schnüffler an der Nase gezogen, damit er anfängt seinem Namen Ehre zu machen, und schon "geht dat los".
    Wer zu spät kommt, den bestraft das Leben. In diesem Falle ist es zu spät für Screenshots, denn die Lizenz für die Testversion des Sniffers ist abgelaufen. Deshalb gleich weiter zu den Ergebnissen.

    • Eintracht - Hamburg 3:0
    • Hannover - Hertha 3:1
    • USB - Modem Encapsulated commands und responses.


    Das Ergebnis ist überraschend, man hätte meinen sollen, dass Hertha gewinnt und dass das mit dem Encapsulated commands and responses nicht funktioniert.
    Es gibt aber einen Grund warum die EC&R hier funktionieren.


    MBIM
    steht nicht für eine mobile Glocke, sondern für Mobile Broadband Interface Model. Der eine oder der andere (mehr als zwei werden es kaum sein) wird sich vielleicht erinnern, dass es unterschiedliche USB-Interface-Deskriptoren in Abhängigkeit vom Alternate Setting gab. Eine Variante trug NCM im Namen, die andere MBIM.
    MBIM ist eine Spezifikation zur Kommunikation mit USB-Breitband-Modems. Sie unterscheidet sich in für uns zwei wichtigen Dingen von NCM.

    • Das Modem muss über Modem Encapsulated commands und responses gesteuert werden können.
    • Die Daten entsprechen nicht Ethernet-Paketen, sondern Internet-Paketen. Es gibt Internet-Pakete mit 4 Byte langen IPs (IPv4) und welche mit 16 Byte langen IPs (IPv6), das soll uns an der Stelle aber nicht belasten.


    Á la carte
    Was hätten wir den gerne ?
    Da schauen wir erst mal in die Karte, was mich dazu bringt eine Prepaid Karte für den Miix zu kaufen, denn die Bastelei wird wohl noch etwas dauern und mein iPad braucht seine Karte.
    Prepaid ist ok und schon habe ich so eine neue, schlanke und ranke Karte. Wenn das Miix in Betrieb geht, kann ich sie durch die andere Karte ersetzen.
    Ziel ist es das L831-EAU auf MBIM umzuschalten und dann erst die Kommunikation zu starten.


    In Memoriam

    Das ist die "Treiber" Struktur. Als erstes knöpfen wir uns AppleUSBNCMControl vor. Einen Ersatz-Treiber hatte ich ja schon geschrieben, nur hat er nicht funktioniert.
    Eigentlich sollte er funktionieren, also nur die Umschaltung auf MBIM hinzugefügt. Neue Sim Karte rein, Neustart und das Modem antwortet.
    Wieder einmal eine Spec runtergeladen und nachgeschaut, welche Befehle das Modem laut Spec unterstützen muss. Hatte ich erwähnt, dass Vorschau keine gute Wahl zum Anschauen von großen PDFs ist. Falls nicht: Vorschau ist eine miese Wahl zum Anschauen großer PDFs.
    Die Liste mit den unter Windows übertragenen Befehlen abgeglichen und eine Initialisierungssequenz abgeschickt.
    Sieht ganz gut aus, bis mit der Sim Karte kommuniziert werden soll, dann überträgt das Moden nur eine Fehlermeldung.


    Die Fahrscheine bitte
    Das Modem findet keine Sim Karte. Ich finde sie hingegen sofort, sie steckt im Kartenslot. Also Windows gebootet und auch dort wird die Karte nicht gefunden. Ich wollte schon auf Windows schimpfen, bis mir einfiel, dass es mit meinem Treiber auch nicht geht. Karte rein, Karte raus, kein Unterschied. Lustig, die Karte rastet ein und um sie auszuwerfen drückt man sie erst tiefer rein. Das war bei der anderen Karte nicht so. Da sieht man mal wieder, dass diese halbe Hemden nicht die Fussstapfen von uns King Size Katzen füllen können. Die andere Karte hat wohl die Kontakt Pins ein wenig zurückgebogen und nun kommen die Pins nicht mehr an die Kontakte der schlanken Karte. Ein Fetzen Papier behebt das Problem, bis ich dazu komme, den Miix zu öffnen und die Pins zurück zu biegen.


    Contact
    Lange darauf hingearbeitet und trotzdem kommt der Erstkontakt mit dem Handy-Netz irgendwie überraschend.
    Nun besteht die Hoffnung die bestehende Verbindung in den NCM Modus rüberzuretten, damit ich nicht auch noch den Daten-Treiber neu schreiben muss.
    Geht nicht. Hätte ich die Spec aufmerksamer gelesen hätte ich es erst gar nicht probiert, das steht nämlich drin, dass es nicht geht. Wenn man zwischen den Modi umschaltet, wird alles zurückgesetzt und Control Interface auf MBIM und Daten Interface auf NCM geht schon gar nicht.


    IOEthernetController
    Macos ist gutgläubig. Wenn es aussieht wie ein Ethernet-Controller und redet wie ein Ethernet-Controller, dann denkt macos es ist ein Ethernet-Controller und lädt die zugehörigen Treiber für die Einbindung in das System.
    Die Klasse IOEthernetController ist leidlich dokumentiert und es gibt ein paar Beispieldateien. Das lässt einen den Treiber schneller schreiben, fördert aber nicht unbedingt das Verständnis.
    IOEthernetController dient letztendlich dazu Ethernet-Daten-Pakete zu empfangen und zu verschicken. Wie vorher erwähnt, hat bzw. will MBIM, aber Internet-Daten-Pakete. Es mag sein, dass es möglich ist IOEthernetController zu umgehen, aber ich habe leider keine Möglichkeit gefunden.
    MBIM und IOEthernetController sind eher eine von den Ehen bei denen man von vorne herein vermutet, dass es sich um eine Zweckehe handelt.


    Was will uns der Künstler damit sagen ?
    Laut OSI-Schichten-Modell ist die Internet-Datenpaket-Übertragung Teil des Layers 3, des Network Layers. Die Ethernet-Datenpaket-Übertragung Teil des Layers 2, des Data Link Layers. Das macht es nicht klarer, oder ?
    Im Layer 3 wird definiert, was von wo nach wo soll. In unserem Falle sollen von der IP 123.456.789.6 zur IP 123.456.789.77 übertragen werden. Wie die Daten, Adressen und Hilfsinformationen formatiert werden sollen, gibt die jeweilige Spezifikation vor. In unserem Fall als IPv4- oder IPv6-Paket.
    Der Layer 2 präzisiert, wie das geschehen soll. In unserem Fall laut Ethernet-Protokoll. Dummerweise überträgt Ethernet aber keine Daten zwischen Geräten mit IPs. Das Ethernetprotokoll verwendet die Ethernet Hardware Address (EHA) statt der IP um die Geräte zu identifizieren. Ein anderer Name für Ethernet Hardware Address ist MAC Adresse. Das MAC kommt von einem Sublayer des Data Link Layers indem die Adresse Verwendung findet.
    Soll ein Internet-Paket über Ethernet übertragen werden, muss man zuerst die EAH finden, die zur jeweiligen IP gehört und dann das Internet-Paket als Payload (Daten) in ein Ethernet-Paket packen. Dazu wird dem Internet-Paket ein Header vorangestellt und eine Prüfsumme hintenangestellt.


    Früher war Alles besser
    Früher bei NCM war das alles super. Denn NCM arbeitet mit Ethernet-Paketen. Bekommt unser Pseudo Ethernet-Controller ein Ethernet-Paket, so muss er es nur an das Modem weiterschicken.
    Aber MBIM hat mit Ethernet und dessen Paketen nichts am Hut. Versucht ein Treiber die EHA zu einer IP zu finden, so antwortet normalerweise der Router. Da der Router aber nichts von unserem USB Gerät weiß, hält er sich raus. Also habe ich dem Treiber eine Funktion spendiert, die Anfragen nach der EHA zur IP des Modems beantwortet. Der Interessierte schickt eine Anfrage über das Ethernet. Diese erfolgt laut ARP (Address Resolution Protocol) Protokoll. Und der Treiber schickt eine Antwort laut des selben Protokolls. Jetzt kann jedes Ethernet Gerät das Modem anhand dessen IP finden, schon mal sehr hilfreich.


    Zahlenspiele
    Die IP des Modems wird vom Netzwerkprovider zugewiesen, aber im Netzwerk-Kontrollfeld erscheint die IP nicht. Es gibt laut ARP Protokoll eine Möglichkeit, seine IP in die Welt herauszuschreien, damit alle Geräte die IP zu einer EHA oder umgekehrt kennen. Leider lässt sich das Netzwerk-Kontrollfeld von dem Geschrei nicht einschüchtern und ignoriert diese ARP-Pakete.
    Das Netzwerk-Kontrollfeld sieht allerdings die Option vor die IP Adresse über DHCP zu beziehen. Also hat der Treiber eine weitere Funktion bekommen. Er mimt einen DHCP Server und gibt die IP Adresse, Gateway Adresse und DNS Server Adresse des Modems an das Netzwerk-Kontrollfeld weiter. Meine Güte bei den vielen Rollen, die der Treiber übernimmt, bekommt er noch eine Identitätskrise.
    Jetzt wo ich das schreibe frage ich mich, ob es nicht einfacher gewesen wäre, im Netzwerk-Kontrollfeld eine beliebige IP zu setzen und den Treiber eine Adressumwandlung vornehmen zu lassen. Die guten Ideen hat man immer zu spät.


    Geht's ?
    Na ja, kommt ein Paket von macos muss man das Internet-Paket aus den Ethernet-Paketen herauslösen und an das Modem schicken. Im umgekehrten Fall muss man ein Ethernet-Paket aus den Internet-Paketen machen und an macos weiterleiten.
    Es lässt viel Spielraum für Fehler, aber mit Geduld, Spucke, den Specs und Wireshark, geht's dann doch.



    Und jetzt ?
    Gute Frage. Das Modem funktioniert.
    Es kommt als Ethernetkarte daher, weshalb es immer vor dem WLAN bevorzugt wird. Eine automatische Umschaltung erfolgt nicht. Will man es nicht muss man es ausschalten. Da gilt es herauszufinden, wie man es als WWAN kennzeichnet so dass es auch das Netzwerk-Kontrollfeld als solches erkennt.
    Aber das ist eher nervig als spannend.


    Punkt ist, dass Modem und Touch funktionieren, aber noch Raum für Verbesserungen lassen. Aber wie sooft, ist der interessante Teil, das Zum-Laufen-Bríngen, das Falten-Rausbügeln ist dann mühselig.
    Ich könnte mir natürlich auch erst anschauen ob man die Kameras zum Laufen bringt.


    Ich denke ich werde eine Pause einlegen und dann Touch und Modem überarbeiten, und dann erst die Kameras anschauen, falls mir bis dahin nichts besseres einfällt oder mir ein interessanterer 2 in 1 unterkommt.
    Denn irgendwie ist der Funken zum Miix nicht wirklich übergesprungen. Vielleicht kennen wir uns einfach zu gut.

  • Ich finde es nach wie vor extrem krass wie tief Du in der Materie steckst und was Du daraus machst. Einfach nur alle Daumen hoch dafür :D

  • Du schreibst großartig, und manches verstehe ich sogar. Möglicherweise kann ich hier helfen:

    Es kommt als Ethernetkarte daher, weshalb es immer vor dem WLAN bevorzugt wird.


    Gehe in die Systemeinstellungen, dort auf Netzwerk. Hier jetzt unten auf das "Zahnrädchen", dort auf "Reihenfolge der Dienste festlegen …".

    ASUS PRIME X299-DELUXE i9-9940X • DDR4 64GB • SSD 960 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon RX Vega 64 • BMD Intensity Pro 4K

    ASUS WS X299 SAGE/10G i9-10980XE • DDR4 64GB • SSD 970 PRO 1TB • Thunderbolt3 Titan Ridge • 2x AMD Radeon VII • BMD DeckLink 4K Extreme 12G


    Ordnung ist die primitivste Form von Chaos. (Hans-Jürgen Quadbeck-Seeger)

  • @apfelnico
    Danke, ich hatte das Menü bestimmt 100 mal offen, aber die Option nie wahrgenommen.

  • Alter Fuchs, bist du gscheit ...
    Vor so viel Wissen und Arbeit kann man nur den Hut ziehen.


    Herrlich wie du deine Artikel schreibst und deine Lösungen erläuterst. Bei manchen Sachen wie z.B. der ACPI Spezifikation steig ich aus fehlendem Hintergrundwissen leider aus. Dafür bin ich bei anderen Sachen wie bei der letzten MBIM Geschichte voll dabei. :thumbup:


    Wie genau du die Treiber schreibst/modifizierst, wäre manchmal noch interessant.

  • Programmiersprache für macos Treiber ist C++. Die IDE natürlich XCode.


    Die Apple eigene Dokumentation gibt genug Hinweise darauf, wie man einen Mac-Treiber schreibt, bzw. wie er aufgebaut ist und welche Anforderungen er erfüllen muss.
    Zusätzlich gibt es Bücher darüber und über macos Interna.


    Falls man noch nicht programmieren kann, ist ein Treiber womöglich als Einstieg nicht die beste Wahl.