Offizieller Blog: What's to expect


lorion84 said:
PandoraSuechtig said:
(langer Text ohne viele Absätze)
Jaja, früher war alles noch besser. Da waren die Menschen bescheidener und nicht so ungeduldig...
Ich hatte nicht geschrieben früher war alles besser. Klar ist es jetzt besser, dass ich günstig eine HD kaufen kann, die 1Mio. früherer Disketten fasst...
Aber früher wurde Arbeit weit mehr geschätzt. Heute wird lieber über chinesische Billigarbeiter genörgelt, seid froh müsst ihr sie nicht selber in der Fabrik giessen!
Aber v.a. waren die Bedingungen für Homebrew besser. Unter seinesgleichen hat man eher Lob geerntet für kleine Fortschritte. Heute herscht zuviel Kommerzmentalität und Leute streiten sich wei beim "Kauf eines normalen Produktes" über "aber, ich will nicht auf xx verzichten, das hab ich hier doch auch und die pandora ist doch v.a. eine ...". Als Homebrew Entwickler wird ED sicher enttäuscht sein, dass die Käufer nicht v.a. aus eingefleischten Fans bestehen, die wissen, dass sie hier als Erstkäufer in etwas investieren, nicht einfach nur ein fertiges Highend Produkt kaufen.
Aber ja, die Hölle fängt an, sobald man ausliefert, dann kommt der Support und die Nörgler...
 
retn said:
Als das erste mal WLAN fertig war hieß es das es läuft, aber damals auch schon das es nicht gut läuft.

"Damals" ist das Schlüsselwort: seit damals hat sich da offenbar nichts getan. Solange wir das Gerät nicht in Händen halten, ist es so oder so egal, was funktioniert und was nicht. Für mich ist eine Pandora ohne WLAN weitgehend witzlos, die Spiele und Emus interessieren mich nur am Rande. Ich spiele auch jetzt nicht und außer einer extrem selten gestarteten UAE-Installation habe ich gegenwärtig auch keinerlei Emulatoren. Ich will einen Mini-Computer für arbeitsbezogene Sachen. Und da gehören Terminabgleiche und dergleichen über WLAN einfach dazu. Eine Verbindung, die ständig einfriert, klingt da nicht so toll.

Aber wie gesagt, solange es bei Auslieferung funktioniert oder wenigstens bald danach, ist es ja kein übermäßiges Problem. Ich finde nur bestürzend, dass offenbar über einen riesigen Zeitraum hinweg an dieser Baustelle nichts getan wurde.

Kernel-Treiber sind naturgemäß nichts, woran "die Community" so schnell etwas ändern kann. Ich bin schon ein paar Jährchen bei den verschiedenen Hacks auf Archos-Geräten dabei. In der "Community" finden sich regelmäßig noch nicht einmal Tester. Und wenn, dann muss man denen alles erklären, was sie tun sollen, so dass man dann auf die Hilfe auch wieder verzichten kann. Bei der Archos PMA habe ich, der ich alles andere als ein Programmier-Gott bin, höchstpersönlich mit einem immensen Arbeitsaufwand ein Treiberproblem im Harddisktreiber und durch geeignete Änderung in einem anderen Treiber sogar ein Hardwareproblem gelöst. Rückschauend waren die Patches eher trivialer Natur und nur für mich als vollkommen Ahnungslosen extrem schwierig, weil ich mit derlei keinerlei Erfahrung hatte. Das Problem bei der Archos PMA war nur, dass die Probleme niemals gelöst worden wären, wenn ich es nicht getan hätte. Es gibt einfach nur sehr wenige, die sich überhaupt an den Kernelsource herantrauen. Einen WLAN-Treiber schreibe ich jedenfalls nicht. Es ist etwas sehr anderes, einen existierenden Emulator-Sourcecode zu nehmen und unoptimiert auf der Pandora zum Laufen zu bringen (wir hören jedesmal, dass das alles noch völlig unoptimiert sei), als einen gut funktionierenden Kerneltreiber zu schreiben. Genaugenommen benötigt es für unoptimierte Emulatoren eigentlich nur einen Crosscompiler plus Geduld und Spucke. Den Emulator zu optimieren, ist auch schon eine andere Geschichte, allerdings eine, bei der sich durchaus tatkräftige Unterstützung finden lassen dürfte, wenn die Pandora ausgeliefert ist. Bei Kernel-Treibern bin ich ziemlich pessimistisch, was das Potential der "Community" angeht.

Anderes Thema: Hardware-Unterstützung für Video-Codecs? Ich habe von Anfang an meine Zweifel gehabt, dass das so einfach wird, wie es immer dargestellt wurde. Einfach, weil ich es auf den Archos-Geräten erlebt habe: da gab es bei den offenen/geöffneten Plattformen nie Sinnvolles, was von den DSPs Gebrauch gemacht hat. Das ist einfach eine Spezial-Wissenschaft und wenn nicht zufälligerweise jemand, der Codecs beruflich auf DSPs programmiert, hier bzw. bei den Beagleboard-Leuten reinschneit, wird es wohl eher auch nicht viel besser werden. Ich weiß jedenfalls, dass Archos da ein paar recht fähige Leute hat und sich trotzdem daran regelmäßig die Zähne ausbeißt. Die haben auf einer vergleichbaren Plattform (um nicht zusagen: auf demselben OMAP-Chip) jedenfalls nur 720p DivX und normales H.264 hinbekommen, obwohl CPU und DSP am Anschlag waren.
 
grond said:
"Damals" ist das Schlüsselwort: seit damals hat sich da offenbar nichts getan. Solange wir das Gerät nicht in Händen halten, ist es so oder so egal, was funktioniert und was nicht. Für mich ist eine Pandora ohne WLAN weitgehend witzlos, die Spiele und Emus interessieren mich nur am Rande. Ich spiele auch jetzt nicht und außer einer extrem selten gestarteten UAE-Installation habe ich gegenwärtig auch keinerlei Emulatoren. Ich will einen Mini-Computer für arbeitsbezogene Sachen. Und da gehören Terminabgleiche und dergleichen über WLAN einfach dazu. Eine Verbindung, die ständig einfriert, klingt da nicht so toll.
Ich denke mal das der Treiber eine weile lang getestet wurde und versucht wurde ihn noch besser hinzubekommen.
Nachdem das nicht geklappt hat musste sich DJWillis ja erstmal in das SDIO Zeug von Palm reinarbeiten.
Ausserdem darfst du dabei nicht vergessen das DJWillis das in seiner Freizeit macht...
Naja wen du das als Mini-Computer siehst ist das vielleicht auch einfach das falsche Gerät für dich?


Aber wie gesagt, solange es bei Auslieferung funktioniert oder wenigstens bald danach, ist es ja kein übermäßiges Problem. Ich finde nur bestürzend, dass offenbar über einen riesigen Zeitraum hinweg an dieser Baustelle nichts getan wurde.
Anderes Thema: Hardware-Unterstützung für Video-Codecs? Ich habe von Anfang an meine Zweifel gehabt, dass das so einfach wird, wie es immer dargestellt wurde. Einfach, weil ich es auf den Archos-Geräten erlebt habe: da gab es bei den offenen/geöffneten Plattformen nie Sinnvolles, was von den DSPs Gebrauch gemacht hat. Das ist einfach eine Spezial-Wissenschaft und wenn nicht zufälligerweise jemand, der Codecs beruflich auf DSPs programmiert, hier bzw. bei den Beagleboard-Leuten reinschneit, wird es wohl eher auch nicht viel besser werden. Ich weiß jedenfalls, dass Archos da ein paar recht fähige Leute hat und sich trotzdem daran regelmäßig die Zähne ausbeißt. Die haben auf einer vergleichbaren Plattform (um nicht zusagen: auf demselben OMAP-Chip) jedenfalls nur 720p DivX und normales H.264 hinbekommen, obwohl CPU und DSP am Anschlag waren.

Zu dem Block zwischendrin kann ich nur sagen, nicht jeder traut sich an die Kernel Entwicklung ran oder kann C.
Dafür entwickelt die Community dann halt andere sachen...

Ich bezweifel ehrlich gesagt auch das es einfach wird, aber wen es da bei Beagleboard was gutes gibt das man portieren kann denke ich das es nur eine Frage der Zeit ist und aktuell keine hohe Priorität hat.
Reicht dir 720p DivX und H.264 auf so einem kleinem Teil nicht?
Ich finde das sehr beeindruckend und auch vollkommen ausreichend...
 
grond said:
eworm said:
Wieso arbeitet ihr mit Backports? Ich hatte gehofft es gibt einen aktuellen Kernel
Das ist bei einem Embedded-Device völlig normal und anders kaum möglich. Der Kernel mit den OMAP-Anpassungen ist nun einmal eine bestimmte Version. Wenn Du nun einen aktuellen Kernel verwenden wolltest, müsstest Du alle OMAP-spezifischen Änderungen an die neue Kernelversion anpassen. Da ist es einfacher, einen benötigten Treiber eines neueren Kernels an den älteren Kernel anzupassen.
Ja... Das ist leider so... Aber ob es nicht anders möglich ist sei mal dahingestellt...
Oftmals kann man gerade Embedded-Entwicklern (aktuell prominentes Beispiel Google mit Android) vorwerfen, dass sie nicht genug in Richtung Mainline-Kernel arbeiten. Würden sie alle ihre Patches vernünftig aufarbeiten und an Linus bzw. die Maintainer der entsprechenden Subsysteme schicken könnte man halt schneller alles im Standardkernel haben. Erstmal ist das natürlich mehr Arbeit - dafür erspart man sich später einiges, nämlich wenn man merkt, dass der Zug eigentlich schon abgefahren ist.
Allerdings muss ich zugeben, dass ich den Szene um den OMAP nicht wirklich verfolge. Wie groß da die Bemühungen sind kann ich nicht sagen. Trotzdem würde ich mich freuen wenn wir auch auf der Pandora immer recht zeitnah aktuelle Kernel bekommen würden.
 
grond said:
eworm said:
Wieso arbeitet ihr mir Backports? Ich hatte gehofft es gibt einen aktuellen Kernel

Das ist bei einem Embedded-Device völlig normal und anders kaum möglich. Der Kernel mit den OMAP-Anpassungen ist nun einmal eine bestimmte Version. Wenn Du nun einen aktuellen Kernel verwenden wolltest, müsstest Du alle OMAP-spezifischen Änderungen an die neue Kernelversion anpassen. Da ist es einfacher, einen benötigten Treiber eines neueren Kernels an den älteren Kernel anzupassen.

OMAP ist inzwischen im Mainline drin. Notaz hat aber viele Pandora-Spezifische Hacks im Kernel. Die müssen erstmal auf den neuen übertragen werden.
 
Ich erwarte ja nicht, dass die Codecs gleich alle auf DSP und NEON optimiert sind, aber ich dachte ARM und andere bieten gewissen Source in dem Bereich frei an und hat nicht das Beagleboard solche Optimierungen intus? Damit will ich jetzt nicht ankreiden, dass es nicht schon mit dabei ist, sondern darauf hinweisen, dass der Code da ist und der Einbau recht schnell nach Release von jemanden erfolgen wird. Dazu wird nicht jeder einzelne Player explizit umgeschrieben, sondern die jeweiligen libraries angepasst (ffmpeg, libjpeg, lib***,...) und die player dann mit diesen übersetzt. Sobald eine library angepasst ist, beinhalten die player diese optimierungen automatisch.
Der Teil macht mir daher wenig Sorgen.
Wegen WLAN, schade, aber solange es sich nicht schlussendlich als HWfehler manifestiert, kann ich leben mit. Gut Ding braucht Weil.
Soundmixer? Na, dann halt mal vorläufig ohne Sahnehäubchen. ;)
 
wejp said:
retn said:
Seit wann arbeitet DJWillis an PND? DJWillis konzentriert sich auf den WLAN-Treiber und noch ein paar andere Sachen...
Lies doch einfach den zitierten Kommentar von MWeston (ein paar Beiträge über meinem). Dort steht genau das.

Michael kennt sich mit Programmierung leider nicht viel aus, er ist der Hardware-Experte.
Er kennt DJWillis als denjenigen, der immer das aktuelle Image erstellt, was auch richtig ist.
DJWillis hat mit PND nichts zu tun, er pulled lediglich den GIT in sein Image.

Die Verteilung ist wie folgt:

vimacs: Viele Scripts und Teile von PND
skeezix: Hauptsächlich PND
notaz: Lowlevel-Sachen und Kernel
DJWillis: WiFi, Einbinden von OpenGL ES und das allgemeine Image backen.
Ich: Einige Scripts, Aufgaben wie Keymapping, testen mit Debug-Output, etc.

Wir sind nicht ganz so doof, wie wir aussehen. Wir setzen die Prioritäten schon richtig.
Höchste Priorität hat das Pandora Grundgerüst. Das sind Treiber, Libraries und unter anderem auch das PND-System.

Die Teile müssen vom Grunddesign passen, sonst gibt es nach Veröffentlichung ein heilloses Chaos.
Wenn PND nicht funktioniert, werden alle Devs ihre Sachen anders veröffentlichen, was zur Folge hat, dass jedes Programm anders gestartet wird. Das wollen wir vermeiden, ist nicht besonders benutzerfreundlich für neue User.

Wenn aber das Grundgerüst am Anfang steht und nach und nach wird alles verbessert, bleibt alles kompatibel. Und das ist der Sinn der Sache.

DJWillis ist ein Top-Coder, deswegen kümmert er sich hauptsächlich um solche Geschichten. Viele andere Devs können zwar coden, aber wissen nicht, wie das mit SDIO etc. funktioniert, da sie normalerweise Apps oder Spiele für vorhandene OS schreiben.
Ausserdem was bringt dir ein Handheld wen du erstmal ein paar Wochen/Monate warten musst bis du darauf mal was anschauen/spielen kannst?
Das ist ja nicht der Fall. So wie ich das sehe, läuft ein X-Server schon recht lange auf dem Gerät. Das sehe ich durchaus ebenfalls als elementares Feature, nicht aber irgendwelche Optimierungen am Desktop oder an PND.

Die Optimierungen wurden deswegen ja auch noch nicht durchgeführt. PND schon, aus den zwei oben genannten Gründen.
Der Dingux hat im Gegensatz zu der Pandora schon ein fertiges OS...
Das ist nicht der Punkt. Betrachte von mir aus Dingux komplett losgelöst vom normalen Dingoo-OS.

Ein OS, wie bei Dingux, hatten wir auch ein paar Tage nach den Devboards laufen.
Hat Dingux 3D Hardware? Nein. Hat Dingux WiFi? Nein. Hat Dingux einen X Server mit Hardwarebeschleunigten Grafiktreibern? Nein.
Was bietet es denn? Einen Framebuffer (Standard), Sound (Standard), DPad und Buttons (Standard)... und das wars.

Ich kann mich erinnern, dass mein Dingux beim Runterfahren lange Zeit abgestürzt ist. Eine der ersten Versionen hat SD-Karten gefressen... war also von Anfang an ausgereift?

Dingux oder auch das OS auf dem WIZ ist verglichen mit einem normalen Desktop-OS ein Witz.

Klar ist es super, was Booboo da in wenigen Monaten geleistet hat, aber das, was Dingux kann, kann das Pandora OS auch schon lange.
Mal ehrlich, wlan ist ein absolutes Kernfeature, gerade auch für keute die ein wenig zocken und arbeiten wollen.
So ist es.

Das ist richtig, und deswegen ist es ja auch unsere größte Baustelle mit höchster Priorität.
Aber wie notaz ja schon richtig bemerkt hat, ist SDIO noch in der Entwicklung unter Linux, da es noch recht neu ist. Und da sitzen eine ganze Menge dran.

Natürlich wird es kommen, aber es kann eben ein bisschen dauern.
Wer helfen möchte, ist gerne willkommen.

Hast Du schonmal ein NEUES OpenSource-Gerät gesehen, bei dem alles von Anfang an funktioniert? Ich nicht, wenn ich ehrlich bin. Auch auf meinem Netbook und Notebook habe ich eine Weile warten müssen, bis alles ging. Am Netbook ging WiFi anfangs nicht, auf meinem Netbook läuft die interne Webcam immer noch nicht.
 
EvilDragon said:
Wir sind nicht ganz so doof, wie wir aussehen. Wir setzen die Prioritäten schon richtig.
Höchste Priorität hat das Pandora Grundgerüst. Das sind Treiber, Libraries und unter anderem auch das PND-System.
Das ist schön, wenn das so ist. Ich bin dennoch verwundert über den Zustand des WLAN-Treibers und das ist weniger als Vorwurf gedacht, sondern wirklich mehr Verwunderung. Falls sich später herausstellen sollte, dass die Performance durch ein Hardwareproblem so schlecht bleibt oder sogar gar nicht stabil möglich sein wird, habt ihr nämlich ein größeres Problem und es kann wohl niemand abstreiten, dass das im Bereich des Möglichen liegt. Natürlich hoffe ich, dass das nicht so sein wird.
Ein OS, wie bei Dingux, hatten wir auch ein paar Tage nach den Devboards laufen.
Hat Dingux 3D Hardware? Nein. Hat Dingux WiFi? Nein. Hat Dingux einen X Server mit Hardwarebeschleunigten Grafiktreibern? Nein.
Was bietet es denn? Einen Framebuffer (Standard), Sound (Standard), DPad und Buttons (Standard)... und das wars.
Du machst es dir hier sehr einfach und das ist nicht fair, weil es so nicht stimmt. Ich würde behaupten, dass die Arbeit die Booboo mit dem Kernel auf dem Dingoo hatte, weit über das hinaus geht, was nötig war, um einen rudimentären Kernel auf der Pandora ans laufen zu bekommen. Die Pandora ist schließlich zu großen Teilen mit dem Beagleboard identisch.
Das was Du dort als "Standard" abtust, ist mit nichten so einfach, wie es einem der nichts mit der Entwicklung zu tun hat, erscheinen mag.
Ich kann mich erinnern, dass mein Dingux beim Runterfahren lange Zeit abgestürzt ist. Eine der ersten Versionen hat SD-Karten gefressen... war also von Anfang an ausgereift?
Das habe ich nicht behauptet. Ich habe Dingux aus einem anderen Grund erwähnt, nämlich aus dem Grund, dass sich Booboo dort auf den Kernel konzentriert hat, weil die anderen Sachen "leicht" durch andere erledigt werden können. Genau das ist dann ja auch passiert. grond hat mit seiner Bemerkung schon völlig recht, dass sich nur wenige finden werden, die am Kernel arbeiten werden. Dagegen wird es relativ viele geben, die an der Oberfläche schrauben können. Wenn ihr das mit den Prioritäten doch anders verteilt habt, als es durch MWestons Aussage erschien, ist das zwar gut, eine Hardware in Massen ohne funktionierende Treiber zu produzieren halte ich aber für gewagt.
Dingux oder auch das OS auf dem WIZ ist verglichen mit einem normalen Desktop-OS ein Witz.

Klar ist es super, was Booboo da in wenigen Monaten geleistet hat, aber das, was Dingux kann, kann das Pandora OS auch schon lange.
Wie gesagt hinkt der Vergleich gewaltig, weil für die Pandora-Plattform schon viele Teile fertig bereitlagen, durch die Existenz des Beagleboards. Der Dingoo musste erstmal dazu gebracht werden überhaupt einen Linux-Kernel zu booten, dann musste ein geeigneter Bootloader für den Dingoo realisiert werden und am Kernel waren trotz der Patches von Ingenic noch diverse Arbeiten nötig, die über die von dir genannten Sachen hinausgehen.
 
EvilDragon said:
Natürlich wird es kommen, aber es kann eben ein bisschen dauern.
Wer helfen möchte, ist gerne willkommen.

Der da klingt so als hat er Ahnung. Würd mich interessieren, ob auch was dran ist:
torpor said:
I work on these sorts of driver issues for a living. If I'd managed to get a Pandora dev machine 6 months ago I'm pretty sure we'd have working WLan drivers. I know, I know, its not so easy .. but believe me, neither is getting IEGBE network drivers on Tolapai working, and thats been my day job.

That said, when I get my Pandora's, I'm going to help as much as I can. Its just a matter of having enough people out there with actual hardware to work on the problem - as soon as there is at least 50 of us with real Pandora's, many of these problems will fade away .. as we have seen, time and again so far, in cases like with squeezix and notaz and so on ..
 
retn said:
Ausserdem darfst du dabei nicht vergessen das DJWillis das in seiner Freizeit macht...

Das vergesse ich auch nicht, ich habe schon genügend OS-Kram in meiner Freizeit gemacht. Nur kann man halt schlecht planen, dass jemand etwas in seiner Freizeit macht, eben weil ihn niemand zwingen kann. Ehrlich gesagt finde ich als Linux-Enthusiast es überwiegend enttäuschend, was es an quelloffenen Systemen für Ultra-portable devices in der Praxis so gibt. Qtopia? Kalter Kaffee. Maemo? Könnte was werden, braucht aber noch. Android? Läuft nur auf ausgewählter Hardware, ansonsten sind tausend device-spezifische Anpassungen nötig. Angström? Was ich da an Codequalität gesehen habe, haut mich nicht um. Man kann zwar massenhaft Software auf den Dingern laufen lassen, aber nichts ist wirklich gut an 800x480 auf einem winzigen Screen angepasst. Nichts ist vernünftig und durchgehend an bei UMPCs übliche Bedienkonzepte angepasst. Linux halte ich auf dem Desktop schon lange für mindestens ebenbürtig, auf den UMPC-artigen Geräten ist noch sehr viel zu tun.

Naja wen du das als Mini-Computer siehst ist das vielleicht auch einfach das falsche Gerät für dich?

Wieso? Wo steht, dass eine solche Verwendung niemals vorgesehen war? Das Ding hat WLAN, einen Bildschirm, Tasten und läuft unter Linux. Damit ist für mich das ersehnte Feature-set komplett. Wenn WLAN nicht geht, lasse ich mir das nicht mit "für Spiele nicht so wichtig" wegdiskutieren...

Zu dem Block zwischendrin kann ich nur sagen, nicht jeder traut sich an die Kernel Entwicklung ran oder kann C.

Ja eben. Das ist ja das, was ich meine...

Reicht dir 720p DivX und H.264 auf so einem kleinem Teil nicht?

Mir ist das ehrlich gesagt vollkommen egal. Weißt Du, wieviele Archos Geräte ich besitze? :)

Ich habe nur sagen wollen, dass ich das ganz gut einschätzen zu können meine, wieviel Aufwand z.B. H.264-Unterstützung auf einem solchen Gerät macht. Ich könnte hier sicherlich eine ganze Zahl von Forenbeiträgen von mir zu dem Thema anführen, wo ich meine Zweifel geäußert habe und immer belehrt wurde, das sei alles schon unter Dach und Fach und überhaupt kein Problem. Ich glaube jedenfalls nicht, dass sich sobald irgendwelche Meister-DSP-Programmierer finden lassen, die mal eben einen H.264-Decoder auf dem DSP des OMAPs implementieren.

eworm said:
Allerdings muss ich zugeben, dass ich den Szene um den OMAP nicht wirklich verfolge. Wie groß da die Bemühungen sind kann ich nicht sagen.

Ich weiß von einem Archos-Entwickler, dass TI sich da bisher fürchterlich selbst im Weg gestanden hat. Die haben diesen tollen Chip aber keine Kerneltreiber dafür. Bei Archos kriegen sie die neuesten Chips früher als alle anderen, dafür müssen sie dann auch regelmäßig ihre eigenen Treiber implementieren. Die legen sie dann aber natürlich nicht unbedingt offen. Bei TI schwört man wohl heilige Eide, dass in Zukunft alles besser wird, darauf ist aber noch zu warten.

Trotzdem würde ich mich freuen wenn wir auch auf der Pandora immer recht zeitnah aktuelle Kernel bekommen würden.

Ich fürchte, das wird nicht so bald der Fall werden. Mir persönlich ist es übrigens auch schon seit langem egal, was für ein Kernel auf meinen Geräten läuft. Die Zeiten, in denen ich von der Uni mit einem Stapel Disketten voller 2.0.x-Kernelsourcen nach Hause geeilt bin, sind lang vorbei.

Ärgerlich bezüglich Kernelversionen war eigentlich in meiner Zeit der Linuxanwendung nur, dass z.B. unionfs niemals stabil war, bevor es nur noch für die 2.6-Kernelserie unterstützt wurde. Ärgerlich deshalb, weil wir auf der Archos PMA unionfs unter 2.4 benutzt haben. Auf meinem normalen Computer läuft sowieso alles, was ich will. Keine Ahnung, was der Distributor mir da für Kernel unterschiebt... :)


@Fusion_Power:

Das klingt wirklich gut! Insgesamt halte ich die potentiellen Pandora-Benutzer technisch für deutlich begabter als den durchschnittlichen Archos-Benutzer, so dass die hiesige "Community" (sorry, die Anführungsstriche kommen bei mir bei dem Wort automatisch) hoffentlich sehr viel mehr hochklassigen Output erzeugt als dort.
 
EvilDragon said:
Die Teile müssen vom Grunddesign passen, sonst gibt es nach Veröffentlichung ein heilloses Chaos.
Wenn PND nicht funktioniert, werden alle Devs ihre Sachen anders veröffentlichen, was zur Folge hat, dass jedes Programm anders gestartet wird. Das wollen wir vermeiden, ist nicht besonders benutzerfreundlich für neue User.

Wenn aber das Grundgerüst am Anfang steht und nach und nach wird alles verbessert, bleibt alles kompatibel. Und das ist der Sinn der Sache.

Dito. Das wollte ich auch gerade erläutern, als ich den Thread überflogen habe. Wenn am Anfang sowas nicht genormt wird, wird es nur im Chaos enden. PND ist definitiv eines der Dinge die eine hohe Priorität benötigen, auch schon wegen der Benutzerfreundlichkeit die dadurch entsteht.

Viele meckern hier, ohne dass sie sich mal etwas tiefer in die Materie einarbeiten. Und einigen, besonders denen die schon länger hinter dem Projekt stehen, sollte klar gewesen sein, dass die Pandora am Anfang nicht perfekt ist. Ich weiß gar nicht was der ganze Unmut soll. Freut euch doch dass es fast geschafft ist und das die Developer fleißig sind.

"Daumen hoch" an die Entwickler. Ich freue mich schon riesig auf meine kleine Pandora in meinen Händen :) *Von Dreamcast Emulator träum*
 
wejp said:
EvilDragon said:
Wir sind nicht ganz so doof, wie wir aussehen. Wir setzen die Prioritäten schon richtig.
Höchste Priorität hat das Pandora Grundgerüst. Das sind Treiber, Libraries und unter anderem auch das PND-System.
Das ist schön, wenn das so ist. Ich bin dennoch verwundert über den Zustand des WLAN-Treibers und das ist weniger als Vorwurf gedacht, sondern wirklich mehr Verwunderung. Falls sich später herausstellen sollte, dass die Performance durch ein Hardwareproblem so schlecht bleibt oder sogar gar nicht stabil möglich sein wird, habt ihr nämlich ein größeres Problem und es kann wohl niemand abstreiten, dass das im Bereich des Möglichen liegt. Natürlich hoffe ich, dass das nicht so sein wird.

notaz hat mit Michael rudimentäre Tests auf Minimal-Assembler-Basis gemacht, ein Hardware-Problem ist laut ihm, notaz und DJWillis so gut wie ausgeschlossen.

Nochmal: Der WiFi-Treiber geht - das Problem ist SDIO und das läuft auf noch keinem Linux-System korrekt, wie notaz selber schon erwähnt hat.
Da kommen täglich Patches, aber es wird dran gearbeitet.
Ein OS, wie bei Dingux, hatten wir auch ein paar Tage nach den Devboards laufen.
Hat Dingux 3D Hardware? Nein. Hat Dingux WiFi? Nein. Hat Dingux einen X Server mit Hardwarebeschleunigten Grafiktreibern? Nein.
Was bietet es denn? Einen Framebuffer (Standard), Sound (Standard), DPad und Buttons (Standard)... und das wars.
Du machst es dir hier sehr einfach und das ist nicht fair, weil es so nicht stimmt. Ich würde behaupten, dass die Arbeit die Booboo mit dem Kernel auf dem Dingoo hatte, weit über das hinaus geht, was nötig war, um einen rudimentären Kernel auf der Pandora ans laufen zu bekommen. Die Pandora ist schließlich zu großen Teilen mit dem Beagleboard identisch.


Ich denke es ist genau andersrum. Du siehst es sehr sehr einfach.
Mal kurz als Info, was notaz alles erledigt hat, damit alles ging:

a) Akku: Ladekontrolle, Abfrage des Status, etc. Alles nicht auf dem Beagleboard.
b) LCD (Timings, allgemeine Ansteuerung): Nichts mit Beagleboard.
c) WiFi / Bluetooth-Modul: Nicht auf dem Beagleboard.
d) Eigenes Tastatur- und Joystick-System (ink. Möglichkeit, DPAD als Tastatur und Joystick zu nutzen): Ebenfalls nicht auf dem Beagleboard.
e) Verstärker-Chip, etc. Auch alles nicht drin.

Viele weitere kleine Fixes, die ich schon wieder vergessen habe...
Eigentlich ist das einzige, was mit dem Beagleboard identisch ist, der SoC. Weder SDIO noch WiFi noch Bluetooth noch die LCD noch die Tastatur, etc. haben etwas mit dem Beagleboard zu tun.
Zudem hat notaz auch eine Menge Fixes dem Beagleboard zugetragen. Er hatte schon ein Devboard, bevor das Beagleboard erhältlich war...
Das was Du dort als "Standard" abtust, ist mit nichten so einfach, wie es einem der nichts mit der Entwicklung zu tun hat, erscheinen mag.

Habe ich nicht behauptet. Aber fast alles, was Booboo beim Dingoo machen musste, hat notaz bei der Pandora ebenfalls gemacht. Nur noch mit wesentlich komplexeren Teilen und Funktionen (wie erwähnt: Hardwarebeschleunigung, etc.)

Ein simples System ohne X, ohne Tastatur, mit DPAD, etc. lief schon seit über einem Jahr.

Auch notaz hat mir selber gesagt, dass der OMAP extrem unübersichtlich ist, weil er eben sehr komplex ist. Der GP2X und WIZ sind deutlich leichter und ein OS für diese kann man in kurzer Zeit anfertigen. Und ich denke, notaz weiß, wovon er spricht.

Den Dingoo stufe ich von der Hardware nicht komplexer als den WIZ ein - lasse mich aber gern eines besseren belehren.
grond hat mit seiner Bemerkung schon völlig recht, dass sich nur wenige finden werden, die am Kernel arbeiten werden. Dagegen wird es relativ viele geben, die an der Oberfläche schrauben können. Wenn ihr das mit den Prioritäten doch anders verteilt habt, als es durch MWestons Aussage erschien, ist das zwar gut, eine Hardware in Massen ohne funktionierende Treiber zu produzieren halte ich aber für gewagt.

Siehe OpenMoko, da war das ähnlich: Ein Telefon, welches 6 Monate nicht telefonieren konnte.

Mit notaz und DJWillis haben wir zwei Top-Leute am Grundsystem. Den Experten, den wir uns von TI gemietet haben (gegen Geld!) hätten wir uns sparen können. Nach zwei Monaten, in denen er an WiFi gearbeitet hat, ist nichts passiert. DJWillis hat den Treiber schließlich dann doch zum Laufen gebracht.

torpor hat sich selber auch schon gemeldet, mithelfen zu wollen. Von den 4000 Bestellungen sind viele Hacker und Devs dabei - wenn nur 10 am Kernel arbeiten, sind das fünfmal soviele wie vorher.
Dass sich da viel mehr viel schneller erledigen läßt, sollte klar sein :)
Wie gesagt hinkt der Vergleich gewaltig, weil für die Pandora-Plattform schon viele Teile fertig bereitlagen, durch die Existenz des Beagleboards. Der Dingoo musste erstmal dazu gebracht werden überhaupt einen Linux-Kernel zu booten, dann musste ein geeigneter Bootloader für den Dingoo realisiert werden und am Kernel waren trotz der Patches von Ingenic noch diverse Arbeiten nötig, die über die von dir genannten Sachen hinausgehen.

Wie gesagt, das taten die erstmal nicht. Vieles am Beagleboard wurde auch vom Pandora-Projekt übernommen. notaz hat eine Menge OMAP-Spezifischer Patches in den Mainline-Kernel übertragen.

Ich denke nicht, dass ich Booboos Arbeit unterschätze - aber ein System, welches nur ein paar Hardwarekomponenten hat, für die Treiber entwickelt werden müssen, ist definitiv simpler, als ein vollwertiges Desktop-System.

Neben dem Kernel hat notaz auch am X-Server schrauben dürfen:
Wußte jemand, dass ein X.Org-Server nicht mit zwei Tastaturen sauber arbeitet?
Kann jeder einfach nachvollziehen: Steckt an ein Notebook eine USB-Tastatur an und tippt auf beiden gleichzeitig rum. Lasst nebenher htop laufen: Die CPU-Last schnellt in die Höhe. Denn der X-Server ist tatsächlich noch auf eine Maus und eine Tastatur ausgelegt. Bei zwei Tastaturen kopiert er die Einstellungen jeweils neu hin- und her, wenn man jeweils die andere verwendet. Daher eine Riesenprozessorlast, die die Pandora zum Ruckeln veranlasst hat. Denn die Pandora hat quasi zwei Tastaturen: Eine normale und eine Zuschaltbare (DPAD + Buttons).

Komm da erstmal dahinter und bessere das dann mal im X.Org aus, das ist ein Riesenwust an Quellcode. Hat notaz gemacht.
Nächstes Problem: omapfb läuft nicht sauber zusammen mit dem XInput-Treiber des Touchscreens. Jede SDL-App in Fullscreen hat den X-Server gecrasht.
Auch hier heißt es: Erstmal rausfinden, warum die App den Server crasht und dann noch die Lösung dafür entwickeln.

Kommt am Beagleboard nicht vor, da wohl alle eine Maus verwenden...

Es gäbe noch zig andere Beispiele, die ich hier nennen könnte...

Ja, ich weiß mehr von der Pandora-Entwicklung als von der von Dingux. Trotzdem denke ich, dass ich auch dadurch, dass ich Open2x damals mitverfolgt habe, einigermassen einschätzen kann, was wo wieviel Arbeit macht.

Und da ist die Pandora eindeutig das deutlich komplexere System und ich bin froh, dass alle großen Probleme soweit beseitig sind. Bis eben auf SDIO.
 
Mal 'ne ganz doofe Frage... WLAN und Bluetooth stecken doch in einem Chip, oder? Hat Bluetooth dann mit dem selben SDIO-Problem zu kämpfen? Das mit dem WLAN lässt sich schon fast noch verschmerzen, aber ohne Bluetooth wäre schon ziemlich blöd... Eines der Hauptaufgabenfelder für meine Pandora wird sein unterwegs über das Handy eine Internetverbindung herstellen zu können.
 
eworm said:
Mal 'ne ganz doofe Frage... WLAN und Bluetooth stecken doch in einem Chip, oder? Hat Bluetooth dann mit dem selben SDIO-Problem zu kämpfen? Das mit dem WLAN lässt sich schon fast noch verschmerzen, aber ohne Bluetooth wäre schon ziemlich blöd... Eines der Hauptaufgabenfelder für meine Pandora wird sein unterwegs über das Handy eine Internetverbindung herstellen zu können.

Ja, das werd ich auch so machen und mache ich bereits so...
Da ich aber aufgrund der BT-Beschraenkung eh nie ueber 30kb/s komme, ist dies zu vernachlaessigen.
 
Also irgendwann will ich schon das versprochene W-LAN haben. Dabei wären bei mir sogar für 60% der Fälle die genannten 50 Kilobyte pro Sekunde ausreichend, also für den Anfang wär ich damit schon überglücklich.

Was mir gerade nur zutiefst Sorgen bereitet:

1) MWeston sprach von einem starken Paketverlust. Das ist AFAIK eher ein Hinweis auf eine schlechte Funkverbindung.

2) Irgendwie kann ich mich gerade nicht erinnern, das Wort "WLAN-Antenne" hier in letzter Zeit schon mal gelesen zu haben. Dabei bin ich mir aber unsicher und ich kann mich (hoffentlich) auch täuschen. Bei Laptops steckt die normalerweise im Displaydeckel.

Die Befürchtung die ich gerade habe, ist, dass MWeston einfach eine kleine SDIO-WLAN-Schaltung, wie man sie auf den entsprechenden SDIO-Kärtchen findet, genommen hat und sie irgendwo auf der Platine ("Idealerweise" noch in der Nähe des Displaykabels) ohne Antenne oder sonstiges verbaut hat. Dann wärs nämlich möglich, dass irgendwas von der Platine so stark auf die WLAN-Sektion einstrahlt, dass es zu Paketverlusten kommt.

Kann mir mal schnell jemand sagen, ob die Pandora eine W-LAN Antenne hat und wo die liegt?
 
Devaux said:
eworm said:
Mal 'ne ganz doofe Frage... WLAN und Bluetooth stecken doch in einem Chip, oder? Hat Bluetooth dann mit dem selben SDIO-Problem zu kämpfen? Das mit dem WLAN lässt sich schon fast noch verschmerzen, aber ohne Bluetooth wäre schon ziemlich blöd... Eines der Hauptaufgabenfelder für meine Pandora wird sein unterwegs über das Handy eine Internetverbindung herstellen zu können.
Ja, das werd ich auch so machen und mache ich bereits so...
Da ich aber aufgrund der BT-Beschraenkung eh nie ueber 30kb/s komme, ist dies zu vernachlaessigen.
Ich mache mir da weniger Sorgen um die Geschwindigkeit... Aber das Hauptproblem bei WLAN ist ja wohl, dass Pakete verloren gehen und dann die Verbindung einfriert. Wenn das bei Bluetooth auch so ist kann das nicht wirklich förderlich sein.
 
xyta said:
2) Irgendwie kann ich mich gerade nicht erinnern, das Wort "WLAN-Antenne" hier in letzter Zeit schon mal gelesen zu haben. Dabei bin ich mir aber unsicher und ich kann mich (hoffentlich) auch täuschen. Bei Laptops steckt die normalerweise im Displaydeckel.

Genau da steckt auch die WLAN-Antenne der Pandora :)
Die Befürchtung die ich gerade habe, ist, dass MWeston einfach eine kleine SDIO-WLAN-Schaltung, wie man sie auf den entsprechenden SDIO-Kärtchen findet, genommen hat und sie irgendwo auf der Platine ("Idealerweise" noch in der Nähe des Displaykabels) ohne Antenne oder sonstiges verbaut hat. Dann wärs nämlich möglich, dass irgendwas von der Platine so stark auf die WLAN-Sektion einstrahlt, dass es zu Paketverlusten kommt.
Kann mir mal schnell jemand sagen, ob die Pandora eine W-LAN Antenne hat und wo die liegt?

sie hat eine eigene Antenne, liegt rechts oben überhalb des Lautsprechers im Deckel :)
 
EvilDragon said:
notaz hat mit Michael rudimentäre Tests auf Minimal-Assembler-Basis gemacht, ein Hardware-Problem ist laut ihm, notaz und DJWillis so gut wie ausgeschlossen.
Wollen wir es hoffen. Es gab einfach schon zu viel Hardware (auch von großen Firmen), die Hardware-Bugs hatten. Ich bin da einfach skeptisch, gerade weil es noch keinen brauchbaren Treiber gibt. Die IDE-Controller auf den berüchtigten VIA-Chipsätzen liefen ja auch, nur leider eben nicht fehlerfrei.
Ich denke es ist genau andersrum. Du siehst es sehr sehr einfach.
Mal kurz als Info, was notaz alles erledigt hat, damit alles ging:

a) Akku: Ladekontrolle, Abfrage des Status, etc. Alles nicht auf dem Beagleboard.
b) LCD (Timings, allgemeine Ansteuerung): Nichts mit Beagleboard.
c) WiFi / Bluetooth-Modul: Nicht auf dem Beagleboard.
d) Eigenes Tastatur- und Joystick-System (ink. Möglichkeit, DPAD als Tastatur und Joystick zu nutzen): Ebenfalls nicht auf dem Beagleboard.
e) Verstärker-Chip, etc. Auch alles nicht drin.
Was ist das denn für ein Verstärker-Chip, dass der Software braucht?
Punkt c) ist ja grade der Knackpunkt.
Insgesamt halte ich das ganze dennoch für einfacher, als beim Dingoo, aufgrund der Dokumentation, die bei der Pandora-Hardware ja wohl vorhanden sein dürfte, im Gegensatz zum Dingoo, wo erstmal Reverse-Engeneering betrieben werden musste. Dieser Aspekt ist nicht zu unterschätzen. Ich möchte hier das überhaupt nicht haarklein aufrechnen, wer hier jetzt wo wie viel Arbeit in etwas gesteckt hat, aber zu behaupten, die Pandora wäre ja so viel komplexer, halte ich schlicht für Unfug. Ja, es sind ein paar mehr Komponenten enthalten, aber die Unterschiede (mal von der Leistungsfähigkeit der Hardware an sich abgesehen), halten sich doch stark in Grenzen. Das gilt insbesondere für die Komponenten, die bisher vernünftig laufen.
Eigentlich ist das einzige, was mit dem Beagleboard identisch ist, der SoC. Weder SDIO noch WiFi noch Bluetooth noch die LCD noch die Tastatur, etc. haben etwas mit dem Beagleboard zu tun.
Ich weiß ja nicht, wie ihr die Tastatur in der Pandora angebunden habt (per GPIO? Oder doch etwa über USB?), aber das dürfte wohl eine eher einfache Aufgabe gewesen sein. Tasten haben die anderen Handhelds auch alle. Zum LCD sollte es wohl ein Datenblatt geben.
Ich möchte die Arbeit der Pandora-Entwickler in keiner Weise abwerten, aber es ist wohl einfach nur fair, anzuerkennen, dass bei anderen Projekten ganz ähnliche Aufgaben anfallen und nur weil die Probleme beim "eigenen" Projekt sehr komplex wirken, sie nicht unbedingt komplexer sind, als bei anderen.
Zudem hat notaz auch eine Menge Fixes dem Beagleboard zugetragen.
Das möchte ich nicht abstreiten.
Das was Du dort als "Standard" abtust, ist mit nichten so einfach, wie es einem der nichts mit der Entwicklung zu tun hat, erscheinen mag.

Habe ich nicht behauptet. Aber fast alles, was Booboo beim Dingoo machen musste, hat notaz bei der Pandora ebenfalls gemacht. Nur noch mit wesentlich komplexeren Teilen und Funktionen (wie erwähnt: Hardwarebeschleunigung, etc.)

Ein simples System ohne X, ohne Tastatur, mit DPAD, etc. lief schon seit über einem Jahr.
Der Dingoo hat ebenfalls eine Tastatur, nur mit weniger Tasten. Spielt für die Ansteuerung aber keine Rolle. Übrigens gibt es auf dem Dingoo durchaus einen X-Server, wobei man über die Sinnhaftigkeit dabei wohl streiten kann. Übrigens funktioniert unter Dingux auch Hardware-Videobeschleunigung.
Auch notaz hat mir selber gesagt, dass der OMAP extrem unübersichtlich ist, weil er eben sehr komplex ist. Der GP2X und WIZ sind deutlich leichter und ein OS für diese kann man in kurzer Zeit anfertigen. Und ich denke, notaz weiß, wovon er spricht.
Das OS (im Sinne von Kernel) ist bei den einzelnen Geräten gar nicht groß verschieden. Dass auf Dingoo & Co. typischerweise kein X-Server läuft, liegt daran, dass der Speicher auf den Geräten doch eher knapp ist.
Dass der OMAP-Chip im speziellen ein durchaus komplexer Chip ist, streite ich überhaupt nicht ab.
Den Dingoo stufe ich von der Hardware nicht komplexer als den WIZ ein - lasse mich aber gern eines besseren belehren.
Ist er nicht. Er ist anders aber von den verfügbaren Funktionen durchaus ähnlich.
Mit notaz und DJWillis haben wir zwei Top-Leute am Grundsystem. Den Experten, den wir uns von TI gemietet haben (gegen Geld!) hätten wir uns sparen können. Nach zwei Monaten, in denen er an WiFi gearbeitet hat, ist nichts passiert. DJWillis hat den Treiber schließlich dann doch zum Laufen gebracht.

torpor hat sich selber auch schon gemeldet, mithelfen zu wollen. Von den 4000 Bestellungen sind viele Hacker und Devs dabei - wenn nur 10 am Kernel arbeiten, sind das fünfmal soviele wie vorher.
Dass sich da viel mehr viel schneller erledigen läßt, sollte klar sein :)
Das kann sein, das eigentliche Problem sehe ich, wie gesagt, an anderer Stelle. Sollte wider Erwarten doch ein Hardware-Problem vorliegen, nützen eventuell die besten Entwickler nichts.
Wie gesagt hinkt der Vergleich gewaltig, weil für die Pandora-Plattform schon viele Teile fertig bereitlagen, durch die Existenz des Beagleboards. Der Dingoo musste erstmal dazu gebracht werden überhaupt einen Linux-Kernel zu booten, dann musste ein geeigneter Bootloader für den Dingoo realisiert werden und am Kernel waren trotz der Patches von Ingenic noch diverse Arbeiten nötig, die über die von dir genannten Sachen hinausgehen.

Wie gesagt, das taten die erstmal nicht. Vieles am Beagleboard wurde auch vom Pandora-Projekt übernommen. notaz hat eine Menge OMAP-Spezifischer Patches in den Mainline-Kernel übertragen.

Ich denke nicht, dass ich Booboos Arbeit unterschätze - aber ein System, welches nur ein paar Hardwarekomponenten hat, für die Treiber entwickelt werden müssen, ist definitiv simpler, als ein vollwertiges Desktop-System.
Die Probleme, um die es hier geht, haben mit einem "vollwertigen Desktop-System" kaum etwas zu tun. Das was das Desktop-System letztlich ausmacht, ist "nur" Software. Mir ging es hier ausschließlich um die Hardware/Kernel/Treiber-Ebene, weil ich die als besonders kritisch erachte und an den Stellen, an denen die Pandora-Hardware komplexer ist, als Dingoo & Co., krankt es ja offenbar noch (WLAN, Grafik-Beschleunigung).

Neben dem Kernel hat notaz auch am X-Server schrauben dürfen:
Wußte jemand, dass ein X.Org-Server nicht mit zwei Tastaturen sauber arbeitet?
Kann jeder einfach nachvollziehen: Steckt an ein Notebook eine USB-Tastatur an und tippt auf beiden gleichzeitig rum. Lasst nebenher htop laufen: Die CPU-Last schnellt in die Höhe. Denn der X-Server ist tatsächlich noch auf eine Maus und eine Tastatur ausgelegt. Bei zwei Tastaturen kopiert er die Einstellungen jeweils neu hin- und her, wenn man jeweils die andere verwendet. Daher eine Riesenprozessorlast, die die Pandora zum Ruckeln veranlasst hat. Denn die Pandora hat quasi zwei Tastaturen: Eine normale und eine Zuschaltbare (DPAD + Buttons).
Also den Fehler habe ich bisher noch nie gehabt und ich habe relativ häufig mehrere Tastaturen an meinen Rechnern betrieben, möchte aber nicht ausschließen, dass irgendwo Fehler im X-Server schlummern. An sich ist der X-Server aber durchaus darauf ausgelegt, mehrere Eingabegeräte zu verwenden.
Komm da erstmal dahinter und bessere das dann mal im X.Org aus, das ist ein Riesenwust an Quellcode. Hat notaz gemacht.
Nächstes Problem: omapfb läuft nicht sauber zusammen mit dem XInput-Treiber des Touchscreens. Jede SDL-App in Fullscreen hat den X-Server gecrasht.
Auch hier heißt es: Erstmal rausfinden, warum die App den Server crasht und dann noch die Lösung dafür entwickeln.

Kommt am Beagleboard nicht vor, da wohl alle eine Maus verwenden...

Es gäbe noch zig andere Beispiele, die ich hier nennen könnte...
Ich wollte nicht behaupten, dass die Pandora-Entwickler nichts zu tun hätten, aber mit ganz ähnlichen Problemen hat man auf anderen Plattformen (Dingoo & Co.) genau so zu kämpfen gehabt.
 
EvilDragon said:
sie hat eine eigene Antenne, liegt rechts oben überhalb des Lautsprechers im Deckel :)

Beruhigend, dann kann es beim WLAN ja eigentlich nur ein seltsames Softwareproblem sein, dass sich wohl bald löst. :)

Wie verläuft denn das Kabel? Also wie ich das sehe verlaufen dann neben dem Flachbandkabel des Displays durch das Scharnier noch mindestens 2 Lautsprecherkabel und ein koaxiales Antennenkabel. Das Displaykabel wird gerollt, aber wie ist eigentlich der Knickschutz der Lautsprecher- und Antennenkabel realisiert?
 
wejp said:
Die Probleme, um die es hier geht, haben mit einem "vollwertigen Desktop-System" kaum etwas zu tun. Das was das Desktop-System letztlich ausmacht, ist "nur" Software. Mir ging es hier ausschließlich um die Hardware/Kernel/Treiber-Ebene, weil ich die als besonders kritisch erachte und an den Stellen, an denen die Pandora-Hardware komplexer ist, als Dingoo & Co., krankt es ja offenbar noch (WLAN, Grafik-Beschleunigung).

Halt, stopp! Nur WiFi. Grafik-Beschleunigung läuft (der X-Server läuft ja auch hardwarebeschleunigt).
Lediglich die Movieplayer nutzen die DSPs, etc. noch nicht.

Neben dem Kernel hat notaz auch am X-Server schrauben dürfen:
Wußte jemand, dass ein X.Org-Server nicht mit zwei Tastaturen sauber arbeitet?
Also den Fehler habe ich bisher noch nie gehabt und ich habe relativ häufig mehrere Tastaturen an meinen Rechnern betrieben, möchte aber nicht ausschließen, dass irgendwo Fehler im X-Server schlummern. An sich ist der X-Server aber durchaus darauf ausgelegt, mehrere Eingabegeräte zu verwenden.

Den Fehler habe ich auch noch nicht bemerkt - wann tippt man bitte mit zwei Tastaturen gleichzeitig? :)
Wenn man von einer auf die andere wechselt, geht nur für ein, zwei Sekunden die CPU-Last hoch. Am PC unmerklich (es sei denn, man schaut sich das mit top an).
Aber ständig von einer auf die andere wechseln mache ja normalerweise niemand ;)

-- 25 Feb 2010 19:50 --
eworm said:
Devaux said:
eworm said:
Mal 'ne ganz doofe Frage... WLAN und Bluetooth stecken doch in einem Chip, oder? Hat Bluetooth dann mit dem selben SDIO-Problem zu kämpfen? Das mit dem WLAN lässt sich schon fast noch verschmerzen, aber ohne Bluetooth wäre schon ziemlich blöd... Eines der Hauptaufgabenfelder für meine Pandora wird sein unterwegs über das Handy eine Internetverbindung herstellen zu können.
Ja, das werd ich auch so machen und mache ich bereits so...
Da ich aber aufgrund der BT-Beschraenkung eh nie ueber 30kb/s komme, ist dies zu vernachlaessigen.
Ich mache mir da weniger Sorgen um die Geschwindigkeit... Aber das Hauptproblem bei WLAN ist ja wohl, dass Pakete verloren gehen und dann die Verbindung einfriert. Wenn das bei Bluetooth auch so ist kann das nicht wirklich förderlich sein.

Bluetooth und WLAN sitzen zwar auf einem Modul, haben aber eigene Verbindungen.
Bluetooth läuft über UART und nicht über SDIO. :)

-- 25 Feb 2010 19:51 --
xyta said:
EvilDragon said:
sie hat eine eigene Antenne, liegt rechts oben überhalb des Lautsprechers im Deckel :)

Beruhigend, dann kann es beim WLAN ja eigentlich nur ein seltsames Softwareproblem sein, dass sich wohl bald löst. :)

Denke ich auch. Was Hardware betrifft, ist Michael extrem pingelig und legt Leitungen exakt nach Vorgaben. Bei einer Maximallänge sogar deutlich kürzer.
Hab selten so ein sauber designetes Board gesehen :)
Hinzu kommt: Ich habe mit der Pandora sogar schon meinen Access Point in einer Entfernung gefunden, bei der mein Handy keinen Erfolg mehr hatte.
Würde das Display reinstören, wäre das ja dauerhaft und man müsste sich wirklich sehr nahe ans Netz begeben.

Zudem tauchen die gleichen Probleme auch auf, wenn man das Display und die Antenne im aufgeschraubten Zustand weit voneinander entfernt und direkt neben dem Router sitzt. Und zwar unverändert, weder stärker noch schwächer werdend.
 
Back
Top