Hallo, ich habe eine Bastelplatine gebaut mit USB3 Interface über FT600, zwei HyperRAM Bausteinen und einem Videoausgang (HDMI über USB-C). Jetzt bin ich am Überlegen was ich mit der Hardware so machen könnte und kam auf die Idee da eine USB-Grafikkarte zu bauen. Die zwei RAM Bausteine könnten als Framebuffer dienen, immer abwechselnd wird ein RAM über USB mit einem neuen Bild beschrieben und der andere RAM wird als aktuelles Bild über HDMI ausgegeben. Der RAM ist dafür schnell genug und USB3 müsste über den FT600 mit 200 MByte/s ebenfalls ausreichen, denn für 1280x800@55 Hz und 1 Byte je Farbe brauche ich "nur" grob 169 MByte/s. Die Hardwarebeschreibung im FPGA sollte ich hinbekommen, aber was ich nicht abschätzen kann ist, wie kompliziert es ist einen Treiber für Windows/Linux zu schreiben. Der soll sich dann als Grafikkarte melden und somit quasi einen zusätzlichen Monitor anbieten. Hat das schonmal Jemand hier gemacht? Was muss ich alles lernen/können um das zu verwirklichen? Gibt es irgendwelche harten Hürden die das verhindern wie Treibersignatur oder Ähnliches? Ich will da kein OpenGL/Direct3D machen, das soll "nur" ein Framebuffergerät werden. So wie die Defaultgrafik unter Linux wenn kein GPU-Treiber verwendet wird. Ich stelle mir das sehr einfach so vor: Der Treiber meldet sich im Betriebsystem. Dann bekommt der eben das Rohbild unkomprimiert. Und das schiebe ich dann über USB raus. Vielen Dank!
:
Bearbeitet durch User
Gustl B. schrieb: > Ich stelle mir das sehr einfach so vor: > Der Treiber meldet sich im Betriebssystem. Dann bekommt der eben das > Rohbild unkomprimiert. Und das schiebe ich dann über USB raus. Und von welcher Grafikkarte soll das Rohbild berechnet werden das du bekommen willst? https://de.wikipedia.org/wiki/Grafikprozessor#/media/Datei:Generic_block_diagram_of_a_GPU.svg Bis jetzt hast du gerade mal einen Framebuffer und sonst noch garnichts. In der Regel gibt es da kein fertiges Bitmap das irgendwo rumliegt sondern nur Anweisungen wie "Male mir mal eine Linie von nach" usw. von OS. Das willst du also alles in Software auf der CPU nachbilden?
Gustl B. schrieb: > Der Treiber meldet sich im Betriebsystem. Dann bekommt der eben das > Rohbild unkomprimiert. Und das schiebe ich dann über USB raus. Dann brauchst du aber erstmal eine Grafikkarte für deine Grafikkarte, denn das Rohbild muss ja von irgendwem gezeichnet werden.
Irgend W. schrieb: > Das willst du also alles in Software auf der CPU nachbilden? Ja genau. Also das soll/muss nicht performant werden. Unter Linux gibt es dieses Framebuffer Device fbdev und sowas würde ich auch verwenden wollen. Ich dachte jetzt naiver Weise, dass man dem OS sagen kann "hier das ist ein Speicherbereich, nutze den als Framebuffer und rechne das Bild auf der CPU".
Gustl B. schrieb: > Der Treiber meldet sich im Betriebsystem. Dann bekommt der eben das > Rohbild unkomprimiert. Und das schiebe ich dann über USB raus. Keine Ahnung von Windows, aber in Linux könntest du das vollständig im Userspace machen, was die Bastelei ganz extrem vereinfacht. Mit Xvfb gibts einen X11-Server mit reiner "RAM-Ausgabe". Dieses RAM liegt memory-mapped in einem (bekannten) File, d.h. mit mmap darauf hast du gleich den Inhalt als Pointer und kannst ihn dann per libusb rausnudeln... Einen "unabhängigen" Blick bzw. die Steuerung des ganzen kann man mit vnc machen.
Sehr fein! Genau so will ich das :-) Aber ... Xvfb kenne ich nicht, VNC natürlich schon. Linux-only würde mir auch erstmal reichen. Aber ich möchte das schon unter einem normalen Desktop Linux wie Ubuntu als Videoausgabe verwenden können. Also als zusätzlichen Monitor. Geht das mit Xvfb? Ich würde den Speicherbereich dann über die FTDI Lib rausschieben.
Gustl B. schrieb: > Sehr fein! Genau so will ich das :-) Aber ... Xvfb kenne ich nicht, VNC > natürlich schon. Linux-only würde mir auch erstmal reichen. Aber ich > möchte das schon unter einem normalen Desktop Linux wie Ubuntu als > Videoausgabe verwenden können. Also als zusätzlichen Monitor. Geht das > mit Xvfb? Natürlich, Xvfb ist ein normaler X11-Server, da kannst du Gnome, KDE oder sowas darüber laufen lassen (wenn auch ohne GPU/Bitblitting-Support etwas zäh). Schau mal so als Start zB. hier nach: https://stackoverflow.com/questions/36221215/using-vncserver-gui-application-virtual-display-in-docker-container Xvfb selbst hat eine Option (fbdir), mit der man den Ort der Video-RAM-Datei angeben kann. Alternativ gäbs auch IPC/Shared-Memory, aber effektiv läufts auf dasselbe raus (pointer=mmap() oder pointer=shmat() ist ja recht egal...) Edit: Ah, du meinst als Zusatz-Screen zu einem normalen GPU-Screen? Das wird schwer, AFAIK kann Gnome/KDE nicht mehreren X11-Devices verteilt laufen (das normale Multiscreen ist ja immer dieselbe Graka).
:
Bearbeitet durch User
Die mehreren Xserver könnte man via xdmx wieder zu einem Screen zusammen fassen und darauf dann einen Windowmanager/Desktop laufen lassen. Ginge sogar über mehrere Rechner übers Netz. Schön isses eher nicht, gehen tuts - BTDT
Hier gibts einen Linux treiber für einen USB zu HDMI wandler: https://github.com/klogg/fl2000_drm#Sources Evtl. kannst du dich ja daran orientieren.
Vielen Dank! Zu dem FL2000 gab es mal einen Vortrag bei einem der CCC Events, da ging es drum den als SDR Output zu verwenden. Ja, sieht interessant aus. Georg A. schrieb: > Ah, du meinst als Zusatz-Screen zu einem normalen GPU-Screen? Das > wird schwer, AFAIK kann Gnome/KDE nicht mehreren X11-Devices verteilt > laufen (das normale Multiscreen ist ja immer dieselbe Graka). Je genau. Als weiteres Display im X. Ginge das eigentlich, dass das Bild weiterhin von meiner PC-GPU gerendert wird, aber dann eben nicht über die Grafikkarte ausgegeben wird, sondern nur in einem Speicherbereich liegt und ich das über USB ausgebe? Ich stele mir das so vor, dass ich dem X sage er soll einen Bildschirm mehr haben, und den dann entweder auf der GPU oder CPU rendern, mir egal, aber eben das Bild in einem Speicherbereich ablegen.
seere schrieb: > Die mehreren Xserver könnte man via xdmx wieder zu einem Screen zusammen > fassen und darauf dann einen Windowmanager/Desktop laufen lassen. Ginge > sogar über mehrere Rechner übers Netz. Schön isses eher nicht, gehen > tuts - BTDT Ui, mach ja schon fast 30 Jahre mit X rum, aber den kannte ich noch nicht :)
Gustl B. schrieb: > Ginge das eigentlich, dass das Bild > weiterhin von meiner PC-GPU gerendert wird, aber dann eben nicht über > die Grafikkarte ausgegeben wird, sondern nur in einem Speicherbereich > liegt und ich das über USB ausgebe? Ich stele mir das so vor, dass ich > dem X sage er soll einen Bildschirm mehr haben, und den dann entweder > auf der GPU oder CPU rendern, mir egal, aber eben das Bild in einem > Speicherbereich ablegen. Hm, man müsste mit xrandr den Bildschirm schon virtuell erweitern können. Den Screen-Inhalt kann man dann auch sehr schnell mit XShmGetImage() als Pointer bekommen. Braucht aber vorher noch etwas Init-Kram, da das auch über SHM-IPC läuft, ist aber überschaubar (10-20 Zeilen).
Fuer USB Treiben allenfalls bei Thesycon reisnschauen . Ein Kollene, welche Fit war mit PC software hat mal 2 Monate Vollzeit verbraten fuer einen USB Treiber. Das Aufwendige war das Zusammentragen der Informationen
Georg A. schrieb: > xrandr Damit habe ich früher meine Displayauflösung gesetzt wenn der Beamer mal nicht ordentlich am Laptop funktionierte ... Georg A. schrieb: > Braucht aber vorher noch etwas > Init-Kram, da das auch über SHM-IPC läuft, ist aber überschaubar (10-20 > Zeilen). OK, davon habe ich keine Ahnung, aber man kann ja lernen. Joggel E. schrieb: > Fuer USB Treiben allenfalls bei Thesycon reisnschauen . OK, Danke! Ich werde wenn überhaupt erstmal eine Demo bauen, also unter Linux/Windows mit einem C Programm Bilder in einen Speicherbereich schreiben und den dann über USB -> HDMI ausgeben. Wenn das funktioniert könnte ich anfangen das mit dem Framebufferdevice zu bauen oder sonst wie. Jedenfalls ist der Aufwand jetzt besser abzuschätzen. Für Linux sieht das machbar aus, bei Windows könnte es knifflig werden.
Joggel E. schrieb: > Fuer USB Treiben allenfalls bei Thesycon reisnschauen . Ein Kollene, > welche Fit war mit PC software hat mal 2 Monate Vollzeit verbraten fuer > einen USB Treiber. Das Aufwendige war das Zusammentragen der > Informationen Windows und USB ist tatsächlich nicht ganz einfach. Nicht umsonst hat Jungo da schon früh viel Kohle mit ihrem generischen Treiber verdient, da gabs noch kein libusb für Windows... Muss man sich halt überlegen, ob es wirklich ein eigener Treiber im Kernel werden muss oder man das nicht alles im Userspace abhandeln kann. Oft reicht der Userspace aus ;)
Gustl B. schrieb: > Georg A. schrieb: >> Braucht aber vorher noch etwas >> Init-Kram, da das auch über SHM-IPC läuft, ist aber überschaubar (10-20 >> Zeilen). > > OK, davon habe ich keine Ahnung, aber man kann ja lernen. Hier mal so grob zusammengefummelt (d.h. vmtl. mit Syntaxfehlern...)
1 | #include <X11/Xlib.h> |
2 | #include <X11/Xatom.h> |
3 | #include <X11/Xutil.h> |
4 | #include <X11/extensions/XShm.h> |
5 | #include <sys/ipc.h> |
6 | #include <sys/shm.h> |
7 | |
8 | Display x_display = XOpenDisplay (NULL); |
9 | Window root = DefaultRootWindow(x_display); |
10 | XWindowAttributes window_attributes; |
11 | |
12 | XGetWindowAttributes(x_display, root, &window_attributes); |
13 | Screen* screen = window_attributes.screen; |
14 | XShmSegmentInfo shminfo; |
15 | XImage* ximg = XShmCreateImage(x_display, DefaultVisualOfScreen(screen), |
16 | DefaultDepthOfScreen(screen), |
17 | ZPixmap, NULL, &shminfo, window_attributes.w, window_attributes.h); |
18 | |
19 | shminfo.shmid = shmget(IPC_PRIVATE, ximg->bytes_per_line * ximg->height, IPC_CREAT|0777); |
20 | shminfo.shmaddr = ximg->data = (char*)shmat(shminfo.shmid, 0, 0); |
21 | shminfo.readOnly = False; |
22 | if(shminfo.shmid < 0) {
|
23 | //Fatal |
24 | } |
25 | Status s1 = XShmAttach(x_display, &shminfo); |
26 | |
27 | // Grab |
28 | XShmGetImage(x_display, root, ximg, 0, 0, 0xffffffff); |
29 | |
30 | // DISPLAY @ (uint8_t*)ximg->data; |
Georg A. schrieb: > da gabs noch kein libusb für Windows Naja, also für das rausschieben der Daten gibt es einen Treiber von FTDI. Aber irgendwo müsste ich eben unter Windows die Bitmap herbekommen. Georg A. schrieb: > Hier mal so grob zusammengefummelt (d.h. vmtl. mit Syntaxfehlern...) Danke, aber investiere da nicht zu viel Zeit, ich weiß noch nicht ob ich das tatsächlich baue. Du kannst das aber selber als Projekt bauen wenn du magst, Schaltung und Layout werde ich im Forum irgendwann (wenn ich mir sicher bin, dass alles funktioniert) hochladen.
Georg A. schrieb: > Joggel E. schrieb: >> Fuer USB Treiben allenfalls bei Thesycon reisnschauen . Ein Kollene, >> welche Fit war mit PC software hat mal 2 Monate Vollzeit verbraten fuer >> einen USB Treiber. Das Aufwendige war das Zusammentragen der >> Informationen > > Windows und USB ist tatsächlich nicht ganz einfach. Nicht umsonst hat > Jungo da schon früh viel Kohle mit ihrem generischen Treiber verdient, > da gabs noch kein libusb für Windows... Muss man sich halt überlegen, ob > es wirklich ein eigener Treiber im Kernel werden muss oder man das nicht > alles im Userspace abhandeln kann. Oft reicht der Userspace aus ;) Naja ... seit es Ende XP Anfang Vista winusb, die WDF(Windows Driver Foundation)und die Unterstützung im Visual Studio gibt, ist es auch kein Hexenwerk mehr. @gustl Emuliere doch einfach mir deinem Device einen USB Stick dann brauchst du keinen Treiben und kannnst einfach in ein File schreiben.
Irgend W. schrieb: > In der Regel gibt es da kein fertiges Bitmap das irgendwo rumliegt > sondern nur Anweisungen wie "Male mir mal eine Linie von nach" usw. von > OS. Was heisst fertig - unter Windows gibt es unzählige Funktionen, um graphische Elemente in eine Bitmap im Speicher zu rendern. Damit hat die Grafikkarte nichts zu tun, die muss diese Bitmap bloss rausschieben in den physikalischen Device, z.B. Bildschirm oder Drucker. Sonst könnte man ja garkeine Grafik drucken, weil der Drucker ja nicht an der Grafikkarte hängt. Ein kleines bisschen sollte man sich schon auskennen wenn man sich so entschieden äussert. Georg
georg schrieb: > Was heisst fertig - unter Windows gibt es unzählige Funktionen, um > graphische Elemente in eine Bitmap im Speicher zu rendern. Damit hat die > Grafikkarte nichts zu tun, die muss diese Bitmap bloss rausschieben in > den physikalischen Device, z.B. Bildschirm oder Drucker. Sonst könnte > man ja garkeine Grafik drucken, weil der Drucker ja nicht an der > Grafikkarte hängt. Da sprichst du aber eher von GUI-Toolkits, die man in einem eigenen Programm nutzen kann, um Grafiken explizit irgendwohin zu rendern. Der TE möchte aber einfach, dass der komplette Desktop auf seinem Gerät wie auf einer normalen Grafikkarte läuft.
Hans-Georg L. schrieb: > Emuliere doch einfach mir deinem Device einen USB Stick dann brauchst du > keinen Treiben und kannnst einfach in ein File schreiben. Und das macht dann der Windows Displaymanager? Der schreibt dann jedes neue gerenderte Vollbild als Bitmep in eine Datei? Rolf M. schrieb: > dass der komplette Desktop auf seinem Gerät wie > auf einer normalen Grafikkarte läuft. Ja genau. Und dachte ich mir, dass man dem OS/Windows/Linux sagen kann hier das ist ein neuer Desktop, rendere den mal komplett auf der CPU ohne irgendeine Beschleunigung und schreibe die Vollbilder in einen Speicherbereich. Eigentlich sollte das ja sogar mit GPU gehen, dann rendert eben die GPU den zusätzlichen Bildschirm, aber schiebt das nicht selber über HDMI/DP raus, sondern schreibt die Pixel in einen Speicherbereich.
Gustl B. schrieb: > rendere den mal komplett auf der CPU > ohne irgendeine Beschleunigung und schreibe die Vollbilder in einen > Speicherbereich. Habe ich doch geschrieben, dass Windows selbst das macht (lesen macht schlau). Und dazu brauchst du auch keinen Desktop, sondern nur einen Speicherbereich, unter Windows einen DC - Device Context. Siehe z.B. https://docs.microsoft.com/en-us/windows/win32/gdiplus/-gdiplus-drawing-a-line-use Georg
georg schrieb: > Und dazu brauchst du auch keinen Desktop Irgendwie scheinst du es nicht zu verstehen. Er will einen Desktop! Da bringt im ein Programm, das ein Fenster aufmacht und eine Linie da rein malt, nichts. Da soll nicht nur ein Fenster, sondern alle dargestellt werden können, von allen Programmen, die grad so laufen - auch welchen, die man nicht selbst geschrieben hat. Und da soll auch der Desktophintergrund, der Mauszeiger und das Startmenü drauf zu sehen sein.
Windows kann seit geraumer Zeit alles was gerade dargestellt wird als Bild an gewünschter Stelle in den Speicher schieben. Wann haben die Spezialexperten hier eigentlich das letzte mal irgend ne Windows-Doku gelesen? -_-
Gustl B. schrieb: > Hans-Georg L. schrieb: >> Emuliere doch einfach mir deinem Device einen USB Stick dann brauchst du >> keinen Treiben und kannnst einfach in ein File schreiben. > > Und das macht dann der Windows Displaymanager? Der schreibt dann jedes > neue gerenderte Vollbild als Bitmep in eine Datei? > Natürlich wird da kein Bild ausgegeben es ist nur eine einfache Methode Daten über usb ohne Treiber zu streamen. War gestern schon spät und ich habs nicht richtig gelesen. Was du willst nennt sich bei Windows "indirect display". https://docs.microsoft.com/en-us/windows-hardware/drivers/display/indirect-display-driver-model-overview. Und ein Code Beispiel dafür gibts hier: https://github.com/microsoft/Windows-driver-samples/tree/master/video/IndirectDisplay. USB 3.1 soll HDMI kompatibel sein, vielleicht is da schon alles drin und man muss den (passenden) Monitor nur einstecken.
Vielen Dank! Das sieht schon sehr brauchbar aus. Windows schrieb: > Wann haben die > Spezialexperten hier eigentlich das letzte mal irgend ne Windows-Doku > gelesen? -_- Sorry, ich bin kein Software Spezialexperte. Ich baue Hardware und schreibe zur Bedienung dann Programme in C oder Python. Hans-Georg L. schrieb: > USB 3.1 soll HDMI kompatibel sein, vielleicht is da schon alles drin und > man muss den (passenden) Monitor nur einstecken. DisplayPort. Ist auch halbwegs logisch, denn für HDMI muss der Takt dauerhaft anliegen und das Bildschirmtiming einigermaßen eingehalten werden. Also es dürfen keine Pausen entstehen. Bei Displayport werden Pakete übertragen. Also eher wie bei PCIe und wie ich das verstanden habe recht unabhängig vom Displaytiming.
Es gibt USB 3.1 Type C Adapter auf HDMI, die unter Windows10 ohne Treiber Installation funktionieren. Für Mac und Linux gilt wahrscheinlich das gleiche. Kosten knapp über 40€. @Gustl Die Windows Treiber sind wahrscheinlich nur die halbe Miete du musst bestimmt auch ein USB "Video" konformes Device haben. Kann das dein Chip oder musst du da auch noch die Firmware dafür schreiben ? Dann nimm dir für alles mal gut Zeit ;-) Und unter Windows 64bit müssen die Treiber signiert sein. Windows 7 kann man im Test-Modus laufen lassen und dafür das Treiberpackage selbst zertifizieren aber die inf datei dafür ist sehr "tricky".
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Es gibt USB 3.1 Type C Adapter auf HDMI, die unter Windows10 ohne > Treiber Installation funktionieren. Für Mac und Linux gilt > wahrscheinlich das gleiche. Kosten knapp über 40€. Ja, so einan habe ich heute Zerlegt. Und drinnen war ein Wandler von Displayport nach HDMI. (Ich suche so einen Adapter, aber von HDMI/USB-C nach HDMI/Normaler Stecker, siehe Beitrag "[S] USB-C (kein DP, sondern HDMI) nach HDMI Kabel/Adapter" ) Hans-Georg L. schrieb: > Die Windows Treiber sind wahrscheinlich nur die halbe Miete du musst > bestimmt auch ein USB "Video" konformes Device haben. Kann das dein Chip > oder musst du da auch noch die Firmware dafür schreiben ? Dann nimm dir > für alles mal gut Zeit ;-) OK, ja mein Stein ist erstmal nur ein FPGA, was ich da reinbaue steht noch nicht allzu fest. Hans-Georg L. schrieb: > Und unter Windows 64bit müssen die Treiber signiert sein. Das ist nicht so gut. Ja, vielleicht sollte ich das auch lassen und mir eine andere Demoanwendung überlegen die USB3 nutzt. Mal sehen.
Gustl B. schrieb: > > Ja, vielleicht sollte ich das auch lassen und mir eine andere > Demoanwendung überlegen die USB3 nutzt. Mal sehen. Baue einen Logic Analyzer z.B. auf Basis von SUMP wirf die Uart Übertragung zum PC raus und ersetze sie durch USB3. Die Leute von Sigrok werden dir bestimmt bei der PC Seite behilflich sein. Das dürfte ein überschaubarer Zeitrahmen sein.
Das ist eine sehr gute Idee und das habe ich sogar geplant. Das war auch einer der Gründe für USB-C. USB-C liefert eine Versorgungsspannung und weitere Pins. Damit kann ich also extern eine kleine Platine bauen, ebenfalls mit USB-C-Buchse, auf der z. B. ein SPI DAC sitzt und auf dem schnelle Komparatoren sitzen mit differentiellem Ausgang. Damit könnte man einen LA bauen, der sehr schnell abtastet, eben so schnell wie der SerDes im FPGA hergibt. Gut, ich habe nur eine USB-C Buchse am FPGA, der LA hätte also nur 4 schnelle Eingänge, aber für ein Testprojekt trotzdem nett. Wenn das gut funktioniert kann ich der nächsten Platine 4 USB-C Buchsen für 16 LA Eingänge spendieren. Hier in diesem Thread https://www.eevblog.com/forum/testgear/rpl1116-active-logic-probe-pod-for-1000z-series-teardown/175/ wird übrigens sowas gemacht, aber mit ein paar Unterschieden: - Die Signale werden nicht an einem FPGA mit USB Abschluss erfasst, sondern mit einem DSO. - Die Spannung für den Komparator kommt aus dem DSO und wird nicht lokal mit einem DAC erzeugt. - Die USB-C Belegung ist nicht für viele andere Dinge (wie bei mir HDMI) nutzbar. Aber ich weiß noch nicht was ich baue. Noch nehme ich meine Bastelplatine in Betrieb. Hier wollte ich mal abschätzen was ein nächstes lohnendes Ziel sein könnte.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.