könnte kernel mode-setting alternativen zu X11 hervorbringen?
-
rüdiger schrieb:
Beim kms wird iirc nicht der gesamte Treiber in den Kernel gepackt. Daher müsste man bei einem alternativen System immer noch den größten Teil des Treibers selbst schreiben.
mmhhh, zugegebenermaßen habe ich mich noch nie mit den internas der xorg usermode treiber beschäftigt, aber sollte nicht schon ein vom kernel unterstütztes modesetting neben dem vorhandenen drm reichen um ein generisches system zu implementieren? :xmas1:
-
Hallo,
nein, DRM erlaubt lediglich, aus dem Usermode heraus auf die Grafikhardware (Register, Rings etc.) zuzugreifen.
Die ganzen "interressanten" Sachen, also die richtigen Register mit den passenden Kommandos zu füllen, um z.B. einen BitBLT durchzuführen, die stecken alle im speziellen X11-Grafikkartentreiber.
Man darf auch nicht von der Annahme ausgehen, dass alle Grafikkarten in der gewünschten Auflösung einen linearen Framebuffer haben. Daher reicht es nicht, einfach nur mal eben den Modus zu setzen und dann direkt in den Speicher zu schreiben.
Diese Treiber sind leider auch sehr auf die Xlib mit ihren Befehlssatz zugeschnitten. Z.B. gibt es bis heute keine definierte Funktion, den Framebuffer auch auszulesen, was vom DirectFB Projekt verlangt würde,
(Das brächte wahrscheinlich auch Sicherheitsprobleme mit sich.)DRI und GLX/Mesa ist dann noch einmal ein anderes Thema
Es gibt ja das Linux Framebuffer Device, was auch beschränkte HW-Beschleunigung kennt. Das käme deiner Vorstellung wohl am nächsten. Ist in der Praxis aber leider zu langsam.
-
-
In der Tat.
Aber davon geht die Welt auch nicht unter.
-
kleiner nachtrag. kms ist cool. endlich 1600x1200x16 console mit der man vernünftig arbeiten kann, schnell wie 80x24 textmode und das auch ohne proprietäre kernel module. fetzt wie sau \o/ :xmas1:
-
ist es denn jetzt moeglich, ein programm mit openGL ohne Xserver laufen zu lassen?
-
linuubs schrieb:
ist es denn jetzt moeglich, ein programm mit openGL ohne Xserver laufen zu lassen?
Nein, siehe GNU-Fans Beitrag.
-
Warum sollte es nicht gehen? Also Hardwareunterstützung ist damit natürlich nicht drin, aber es gibt ja auch Grafiktreiber für "ohne X".
-
dann werden wir also bald einen bootprozess haben bei dem nicht 5x die bildschirmauflösung geändert wird
. ich muss sagen das wurde aber auch mal zeit :xmas1:
-
EFI sollte das Problem eigentlich lösen, immerhin will man dort gleich neue feste Video Standards mitdefinieren, so daß ein PC nicht mehr im Textmodus booten muß, sondern auch gleich Auflösungen und Farbtiefen jenseits von VGA zur Verfügung stehen.
-
borg schrieb:
dann werden wir also bald einen bootprozess haben bei dem nicht 5x die bildschirmauflösung geändert wird
wenn man grub mit splash-screen benutzt und die Auflösung des splash-Screens anpaßt an diejenige, die man auf dem Desktop fährt, gibt es auch schon heute keine 5 Änderungen der Auflösung mehr. Bei mir zumindest nicht.
:xmas1:
-
Um das (nervige) Wechseln, wenn X gestartet wird kommt man allerdings nicht rum. Ebenso das Wechseln des Splash-Screens von Bootstrap zum Init-Prozess (wenn man fbsplash benutzt).
Große Distributionen haben da wohl stark am Kernel rumgefummelt, dass dieser Wechsel nicht da ist.Wenn man als Login-Manager Qingy benutzt fällt der Wechsel zu X zumindest nicht so auf, da Qingy mit DirectFB läuft und X erst nach dem Login gestartet wird.
Allerdings wird auch hier immernoch das Display einmal kurz ausgeschaltet, bevor dann X übernimmt.Das sind natürlich nur Kleinigkeiten, aber sie verhindern doch den Eindruck, dass alles aus einem Guss wäre.
-
ja, hast recht - beim Starten von X wird immer noch geschaltet, 1-mal. Das muß man als *n*x'er halt aushalten können :xmas2: