Virtueller Bildschirm mit xrand

OsunSeyi

Well-Known Member
Hi,
Ich möchte einen virtuellen Bildschirm einrichten, der eine geringere Auflösung verwendet, bei gleichen Maßen.
Also sozusagen einfach nur vergrößern. Das sollte mW normalerweise mit xrandr --output --scale --panning gehen.
Allerdings will xrandr eine Angabe für --output. Dieser wird normalerweise ausgegeben:
Code:
$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1400 x 1050, maximum 1400 x 1050
default connected 1400x1050+0+0 0mm x 0mm
   1400x1050      0.00*
   1280x1024      0.00
   1024x768       0.00
   800x600        0.00
   640x480        0.00
Dort, wo jetzt 'default' steht, könnte zB LVDS, VGA1 oder dergleichen stehen. Möglicherweise will xrandr ja eine xorg.conf sehen.

xrandr --output default --mode 1024x768

...klappt! Ist aber nicht nicht wirklich scharf...

Code:
$ xrandr --output default  --panning 1500x1000
xrandr: Failed to get size of gamma for output default
xrandr: screen cannot be larger than 1400x1050 (desired size 1500x1050)

$ xrandr --output default  --scale 2x2
xrandr: Failed to get size of gamma for output default
xrandr: screen cannot be larger than 1400x1050 (desired size 1500x1050)

...klappt leider nicht.

Im Grunde würde ich gerne folgendes können:

xrandr --output default --mode 1024x768 --panning 1400x1050

Also eine Vergößerung des Bildschirms, größer als der tatsächliche Bildschirm, der Ausschnitt mit der Maus zu verschieben und scharf.

Leider steige ich durch X nicht mehr durch, war schon mit xorg.conf schwierig, aber so etwas 'banales' gibt's ja nicht mehr...

BTW:
beim Starten von X zeigt sich immer zuerst ein schickes Streifenmuster, ist das Deko oder kann ich das auch rausschmeißen?
 
Interessanterweise funktioniert ein virtueller Bildschirm (--panning) unter salix problemlos, ebenfalls auf einem Thinkpad T60. Dort verwendet X per default allerdings die Auflösung 1024x768, auf freeBSD wird per default 1400x1050 verwendet.

Auf Salix sind daher zB alle Icons von Rox deutlich größer. Leider habe ich mich daran gewöhnt, weil meine Augen nicht mehr so gut sind wie früher. Auch habe ich viele text-Dokumente zur internen Dokumentation mit proportionaler Schrift (Segoe 12), die Linien enthalten. Alles ist auf eine genaue Breite zugeschnitten. Ich kann bei diesen Dokumente nicht einfach eine größere Schriftart verwenden, weil dann der Schnitt nicht mehr stimmt. Also sind all diese auf freeBSD jetzt sehr klein geraten, fast winzig.

Darum finde ich es cool, per Tastenkombi eine Art "Bildschirmlupe" zu verwenden, die tatsächlich exact den gleichen Bildschirmausschnitt verwendet, aber auf einen virtuellen Screen vergrößert.

Aber ich vermute, es wird über definieren einer neuen Modline klappen...

wie so oft Ubuntu
mikrocontroller.net
kilobyte.bplaced.net
und nicht zuletzt das hervorragende Handbuch

Betreffs der Streifen-Deko beim Start von X, könnte ich mir vorstellen, daß X mit einer falschen Auflösung startet und sich dann selber korrigiert, also mit einer anderen Einstellung nochmal neu startet. Das kann man doch möglicherweise durch Anlegen einer xorg.conf mit der korrekten Einstellung verhindern !?

Ach a propos gibt's auch noch das mit Vorsicht zu benutzende 'xvidtune', das mit der Option -show die aktuell verwendete Modline ausgibt.
 
Also, ich hatte gehofft, folgendes machen zu können:

Vom Salix T60 die verwendete Modline bekommen:

Code:
~ xvidtune -show
"1024x768"     65.00   1024 1048 1184 1344    768  771  777  806 -hsync -vsync

Diese auf dem freeBSD T60 mit xrandr definieren:
Code:
$ xrandr --newmode       "1024x768"     65.00   1024 1048 1184 1344    768  771  777  806 -hsync -vsync
xrandr: Failed to get size of gamma for output default
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  16 (RRCreateMode)
  Serial number of failed request:  19
  Current serial number in output stream:  19
...klappt also schon mal nicht. Normalerweise käme danach
xrandr --addmode default "1024x768"
und
xrandr --output default --mode 1024x768

...um zunächst exakt die gleiche Auflösung zu erhalten, und es danach mit dem Panning zu probieren.

Nun ja, bisher hat ja niemand dazu etwas schreiben können. Scheint kein einfaches Thema zu sein! Liest man im Inet, hört sich das alles so selbstverständlich an, was dann in der Praxis wohl doch nicht so leicht ist...
 
Es ist ein bisschen schade, daß die Editiermöglichkeit der Beiträge relativ schnell "verjähren", sonst würde ich die Überschrift korrigieren und nicht in einer Art Selbstdialog ständig neue Beiträge hinzufügen.

Habe jetzt verschiedene Life-CD's probiert, mit denen wird die Auflösung bei "1024x768" zT subjektiv schärfer, aber man kann damit so wie es ist schon leben. Die normale Auflösung hier ist wie gesagt "1400x1050", und die ist scharf aber zT winzig. Panning (also ein virtuell größerer Bildschirm) ist hier nicht möglich.

Umschalten zwischen den beiden Modi geht hier ketzt mit Win+plus bzw Win+minus.
In der Hinsicht ist OB ja wirklich super!

Ich kann mir nicht vorstellen, daß es an freeBSD liegt, bei Linux sind zwischen den Distributionen wohl auch verschiedene Konfigurationen von X. Wenn man per Modeline einfach verschiedene Konfigurationen von A nach B kopieren könnte, wäre das toll, aber so einfach scheint es nicht zu sein.

Man müsste halt mehr herumprobieren. Weil ich aber relativ im Dunklen tappe und eher weniger als mehr klappt, würde ich mit dem Thema gerne erst einmal abschließen wollen!
 
Die Sache ist über die Jahre nicht einfacher geworden... Modelines waren früher der Weg um dem X-Server Monitorparameter mitzuteilen. Dann kam EDID, wodurch der X-Server sich die Parameter selbst ableiten konnte. Dann Flatpanels, die eigentlich ganz anders funktionieren. Dann die RANDR-Erweiterung. Und so weiter. Ich meine, dass Modelines zwar intern noch benutzt werden, aber in wie weit sie tatsächlich Wirkung haben vom DDX-Treiber (also dem xf86-video-xyz Dings) abhängt.

Wenn du eine größere Darstellung willst, ist es der schlechteste Weg das Panel in eine nicht-native Auflösung zu zwingen. Je nachdem wie gut der Scaling-Algorithmus der Displayfirmware ist, führt das zu mehr oder weniger bösen, nervenden Artefakten. Das ganze Bild mit RANDR zu skalieren, bringt meist bessere Ergebnisse, aber hat letztendlich das gleiche Problem. Die Darstellung von Desktopanwendungen, vor allem die Schriften, ist nicht dazu gemacht nachträglich skaliert zu werden. Das Ergebnis wird immer matschig und unbefriedigend sein.

Ich würde in deiner Stelle mal versuchen den High-DPI-Support, den inzwischen fast alle Toolkits und Anwendungen haben, zu msisbrauchen. Dann skaliert die Anwendung selbst und du bekommst eine scharfe, in sich konsistente Darstellung. Als Beispiel mal für mein T480s. Das ist mit 2560x1440 auf 14" schon tief im High-DPI-Bereich, aber das funktioniert exakt so auf allen Displays:
  • Das Display hat rechnerisch horizontal 2560 / 14 = 182 DPI. Durch Subpixelverteilung, den Displayrahmen und so weiter mögen es in der Realität ein paar mehr oder ein paar weniger sein. Das ist nicht so wichtig. Wenn wir den Toolkits nun sagen, dass sie von diesen 182 DPI ausgehen sollten, skalieren sie so, dass die Darstellungsgröße einem klassischen 96 DPI Monitor entspricht. Nun ist das Skalieren auf krumme Faktoren aber immer so eine Sache. Die meisten Toolkits können daher nur "gerade" Werte, also Faktor 1, 1.5 oder 2. Hier würden sie wohl auf 2 gehen.
  • 2 wäre sicher ein schöner SKalierungsfaktor, wenn man recht schlechte Augen hätte. Ich sehe zwar nicht mehr so gut wie früher, aber es sind nur -1 Dioptin. Ich wollte daher eine etwas kleinere Darstellung, also Faktor 1.5. Das entspricht 96 * 1.5 = 144 DPI. Daher wird in der ~/.xinitrc vor allem anderen eine DPI von 144 erzwungen: xrandr --dpi 144. Damit erzwingt man nicht eine andere DPI im eigentlichen Sinn, man sagt dem X-Server und allem, was daran hängt nur, dass es ein breites logisches (nicht physisches!) Display annehmen soll, als tatsächlich vorhanden ist. In der Aufgabe von xrandr wird damit die Bildschirmgröße größer: DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm (Das ist nicht vom T480s-Display, sondern von einem 27" Desktop-Monitor)
  • Für Qt-Anwendungen setzt man wieder in der ~/.xinitrc einfach export QT_AUTO_SCREEN_SCALE_FACTOR=1. Damit skaliert das Toolkit alle Anwendungen anhand der gesetzten logischen DPI. Der Skalierungsschieber in KDE macht übrigens nichts anderes. Er verändert die logischen DPI und schaltet die Skalierung von Qt ein.
  • Für GTK3-Anwendungen muss man nichts machen, das Toolkit sollte sie einfach so anhand der logischen DPI skalieren.
  • Bei GTK2-Anwendungen ist es von der Anwendung selbst abhängig, das Toolkit hat keine globale EInstellung.
  • Das Gleiche gilt für Anwendungen ohne Toolkit. rxvt-unicode skaliert z.B. direkt, wenn man eine Xft-Schrift nutzt. Bei Bitmap-Schriften muss man drauf achten, dass sie im gewünschten Skalierungsfaktor vorliegt. Ich habe Terminus mit 10 Punkt gesetzt, also muss es Terminus mit 10 * 1.5 Punkt = 15 Punkt oder nahe daran geben. tint2 hat eine eigene Skalierungsoption, scale_relative_to_dpi = 144. Openbox skaliert alles korrekt, außer die Fenstericons. Da habe ich mit Gimp nachgeholfen, sie einfach um Faktor 1.5 vergrößert.
Nachtrag: Denkfehler im Skalierungsfaktor korrigiert.
 
Es ist ziemlich off-topic, ich wollte trotzdem kurz schreiben das es mich sehr freut das hier noch jemand das gute alte T60 verwendet, das Notebook hat mich recht lange begleitet und irgendwie mag ich das Design noch immer sehr gerne.

(Leider ist meins irgendwann kaputtgegangen, theoretisch hab ich hier wieder eins liegen das ich mal geschenkt bekommen hab, nur leider hab ich momentan da keinen so wirklichen Einsatzzweck.)
 
Auch, wenn niemand was zu sagen hat...
:):):) Da hast Du ja den Nagel auf den Kopf getroffen, ich war tatsächlich etwas pikiert... Dabei kann man alles behaupten, aber sicher nicht, daß ihr schreibfaul wäret! wir lesen (durchaus interessiert) Das ist mal wirklich sehr symphatisch, vielen Dank!

ich wollte trotzdem kurz schreiben das es mich sehr freut das hier noch jemand das gute alte T60 verwendet
Hab mal irgendwo die Geschichte gehört, jemand hatte so einen Bauklotz auf dem Tisch stehen, und ist dann quer durch den Raum gegangen, so über das Netzkabel gestolpert, daß das Laptop vom Tisch geflogen, gegen die Wand geknallt und auf den Boden gefallen ist. Und das gut überstanden hat... sie kosten in etwa 150 € in gutem Zustand, und alle guten Betriebssysteme laufen zügig darauf ;)

Das Display hat rechnerisch horizontal 2560 / 14 = 182 DPI.
"Possessed With Psi Powers" Praktische Sache, wenn man's einmal kann :huth:

Auch das T60-Display hat 14,1". Laut xrandr ist die höchste Auflösung 1400x1050 und wohl die native Aulösung, weil scharf.

1400 / 14 = 100 DPI

Also werden, wenn ich Dich recht verstehe, die Toolkits auf 96 DPI 1:1 (garnicht) skalieren.
Zum Testen nehme ich mal doppelt so groß:

96 / 2 = 48 DPI

Code:
$ xrandr --dpi 48
xrandr: Failed to get size of gamma for output default

Die Fehlermeldung besagt glaube ich nicht allzu viel (?), weil sie immer auftaucht.
Allein, es tut sich da nichts, auch wenn ich es in die ~/xinitrc eintrage und X neu starte.
Auch die Ausgabe von xrandr ändert sich nicht!

Übrigens ändert auch --panning nichts, obwohl da ja garnicht skaliert wird, sondern nur ein virtueller Desktop erzeugt.

Das ist praktisch, wenn man zB eine sehr breite Tabelle hat und nicht innerhalb der Anwendung nach rechts skrollen will. Man kann ja alle diese Features mit Tastenkombis belegen (wenn sie denn funktionieren).

Auf Salix geht es, (das entspricht Slackware 13.37) in der installierten Version, und ich verstehe nicht, warum X und die Tookits sich nicht auf nachvollziebare Weise verhalten wollen...
Code:
$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1400 x 1050, maximum 1400 x 1050
default connected 1400x1050+0+0 0mm x 0mm
   1400x1050      0.00*
   1280x1024      0.00
   1024x768       0.00
   800x600        0.00
   640x480        0.00
$ xrandr --output default --panning 1400x2000
xrandr: Failed to get size of gamma for output default
xrandr: screen cannot be larger than 1400x1050 (desired size 1400x2000)

screen cannot be larger than 1400x1050
Warum das denn?

Aber zunächst mal vielen Dank für Deine großartige Unterstützung!
Und einen schönen Sonntag...
 
Zuletzt bearbeitet:
Was das »panning« betrifft - Du mußt das Seitenverhältnis beibehalten, also beide Werte z.B. mit 1,5 multiplizieren.

Hab das gerade probiert, »output default« gibt eine Fehlermeldung, da muß der konkrete Anschluß hin.

Real habe ich 2560x1440.

Code:
xrandr --output DP-1 --panning 3840x2160

Ergibt:

Code:
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192

VGA-1 disconnected primary (normal left inverted right x axis y axis)

HDMI-1 disconnected (normal left inverted right x axis y axis)

DP-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 597mm x 336mm panning 3840x2160+0+0

Toll, wie in alten 17"-Zoll-Zeiten mit der xorg.conf.


Wünsche gutes Gelingen!


Gruß
 
Du mußt das Seitenverhältnis beibehalten
Nein, das habe ich auf dem anderen Rechner anders, da wird nur die Breite vergrößert.
Aber auch wenn so, geht es leider nicht:

Bash:
$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1400 x 1050, maximum 1400 x 1050
default connected 1400x1050+0+0 0mm x 0mm
   1400x1050      0.00*
   1280x1024      0.00 
   1024x768       0.00 
   800x600        0.00 
   640x480        0.00 
$ xrandr --output default --panning 2800x2100
xrandr: Failed to get size of gamma for output default
xrandr: screen cannot be larger than 1400x1050 (desired size 2800x2100)
 
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192
Screen 0: minimum 640 x 480, current 1400 x 1050, maximum 1400 x 1050
Ich habe nur selten xrandr benutzt, aber ich würde nicht erwarten, dass es anders reagiert, als beschrieben.
Im positiven Beispiel von @Arjan bewegt sich die neue Größe innerhalb des zulässigen Bereiches, der maximal mit 8192 x 8192 angegeben wird.
Im negativen Beispiel von @OsunSeyi ist maximal 1400 x 1050 erlaubt und deshalb muss das scheitern.
 
Allein, es tut sich da nichts, auch wenn ich es in die ~/xinitrc eintrage und X neu starte.
Auch die Ausgabe von xrandr ändert sich nicht!
Hmm... Ich könnte mir vorstellen, dass man nicht deutlich unter 96 DPI gehen kann. Das hatte ich nicht bedacht... :( Die 96 DPI kommen aus der Windows-Welt, Windows zwischen NT4 und ich meine Vista sprach Monitore immer stumpf mit 96 DPI an. Daher bewegen sich die meisten älteren Displays auch in dem Bereich.
 
Leider steige ich durch X nicht mehr durch, war schon mit xorg.conf schwierig, aber so etwas 'banales' gibt's ja nicht mehr...

Warum sollte es das nicht mehr geben?
Ich verwende die jedenfalls, und krieg meinen Schrott überhaupt nur damit zum laufen (das Brett kann eigentlich kein 2560x1440).

Code:
$ xrandr
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
VGA1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   2560x1440     38.48*+
   1920x1440     57.58  
   1920x1200     55.90  
   1920x1080     60.00  
   1600x1200     60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   848x480       60.00  
   640x480       59.94  
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

xrandr --output default --mode 1024x768 --panning 1400x1050

Also eine Vergößerung des Bildschirms, größer als der tatsächliche Bildschirm, der Ausschnitt mit der Maus zu verschieben und scharf.

Das geht hier:

$ xrandr --output VGA1 --mode 1920x1080 --panning 2560x1440

"Scharf" ist aber so ne sache - das kommt auf den Monitor an, denn der muss das Zeug umrechnen. Wenn es keine ganzzahligen Teiler sind, sieht das hier übel aus.
Das ist halt das Problem mit den Flatscreens, die Pixel sind Hardware.

screen cannot be larger than 1400x1050
Warum das denn?

Das dürfte ein Hardware-Limit sein. Früher (sehr viel früher ;) ) hing das von der menge an Memory in der Grafikkarte ab. Keine Ahnung ob man das irgendwo dengeln kann.
 
Mhm, schade, weiß ich momentan auch nicht weiter.

Gruß

PS: Grafikspeicher als Limit kann ich mir nicht vorstellen - vor zwanzig Jahren ging solch ein VirtulDesktop auch mit ner alten S3-Karte, und die hatte nur 4 MByte Speicher oder so...
 
Sorry, hatte länger keine Zeit.
Endlich geht's weiter...

aber ich würde nicht erwarten, dass es anders reagiert, als beschrieben.

Da wollte ich doch mal die Probe auf's Exempel machen, das sollte die Frage nach ausreichend RAM auch beantworten:

Rich (BBCode):
$ xrandr
Screen 0: minimum 640 x 480, current 1400 x 1050, maximum 1400 x 1050
default connected 1400x1050+0+0 0mm x 0mm
   1400x1050      0.00*
   1280x1024      0.00 
   1024x768       0.00 
   800x600        0.00 
   640x480        0.00 

$ xrandr --output default  --mode 1024x768
xrandr: Failed to get size of gamma for output default
dürfte
$ xrandr --output default  --panning 1280x1024
X Error of failed request:  BadRRCrtc (invalid Crtc parameter)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  29 (RRSetPanning)
  Crtc id in failed request: 0x35b
  Serial number of failed request:  22
  Current serial number in output stream:  22

Error of failed request: BadRRCrtc (invalid Crtc parameter)
hab ich ohne (für mich) brauchbares Ergebnis gegoogelt.

Warum sollte es das nicht mehr geben?
Ich verwende die jedenfalls, und krieg meinen Schrott überhaupt nur damit zum laufen (das Brett kann eigentlich kein 2560x1440).

Ja, das will ich mal probieren!
.....
 
Ich hab mal nur diesen Auschnitt genommen (hab' ja keine Ahnung, ist also geraten).
Stammt aus diesem Link:

FreeBSD X11 configuration file for ThinkPad T60 · GitHub

Code:
Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
    Identifier  "Card0"
    Driver      "intel"
    VendorName  "Intel Corporation"
    BoardName   "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
    BusID       "PCI:0:2:0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    DefaultDepth 24
    SubSection "Display"
        Viewport   0 0
        Depth     24
        Modes      "1024x768"
    EndSubSection
EndSection

War nicht so toll... muste im Single-user-mode starten, um das wieder herauszunehmen...
Kenne mich mit Treibern usw nicht so aus.

Vielleicht ist es am Besten, die Sache erst mal zu vergessen...
Vielleicht eine stärkere Brille ;)


Auf Salix geht es ja auch, die selbe Hardware (BIOS-Einstellungen nicht geprüft). Vielleicht kann man -abgesehen von der Modline- genauer herausfinden, was der Unterschied ist? Was könnte ich denn noch prüfen?
 
Auf Salix geht es ja auch, die selbe Hardware (BIOS-Einstellungen nicht geprüft).

Langsam. "Hier" bei mir ist ein Desktop mit Ivybridge-Prozessor und dem normalen Grafikchip im Prozessor, HD2500 glaub ich. Das ist dafür gebaut, dass man möglichst jeden Monitor anschließen und dafür geeignet konfigurieren kann. Was Du da hast, ist ein Laptop mit schon eingebautem Bildschirm, wo man nicht so genau weiss was das BIOS da alles eigenintelligent anstellt ohne dass der Benutzer es konfigurieren müsste (oder könnte).
Nun hat aber auch ein Laptop normalerweise einen Stöpsel für externen Monitor, d.h. es sollte auch da eigentlich möglich sein, die Grafik so halbwegs zu konfigurieren - es kann aber auch sein, dass der das merkt, welcher Monitor in Benutzung ist, oder dass er für den externen Stöpsel einen extra Grafikchip hat. Das würde dann dieses feste "maximum 1400x1050" erklären: der Windows Normaluser braucht ja auf dem internen Monitor nicht mehr.

Was wir nun wissen ist dass das xrandr im FreeBSD (hier: 11.3) prinzipiell tun kann was es soll (weils bei mir geht).
Wenn Du nun sagst, das Salix (das ist glaub ich ein Linux) geht - das X im Linux ist keine grundsätzlich andere Software als das X im FreeBSD; da sollte herauszufinden sein, wie sie das da konfigurieren, und die Konfiguriation sollte weitgehend übertragbar sein.

Das setzt natürlich voraus, dass man sich mit diesen Config-files, und vor allem mit den produzierten Logfiles, einigermaßen wohlfühlt, und da forschen und experimentieren mag.
Es läuft im grunde darauf hinaus: Manual-Page lesen, Parameter ausprobieren, schauen was im Logfile gemeldet wird, und dementsprechend nachbessern.
Man sollte auch mal rausfinden, was dieser Laptop eigentlich für einen Grafikchip hat - das muss nicht bei allen derselbe sein. Und wenn das nicht derselbe ist, dann ist es eher unwahrscheinlich, dass eine aus dem Web gefischte xorg.conf funktioniert.
Zu dem "BadRRCrtc" finde ich auf die schnelle auch nichts erleuchtendes, ausser einem offenbar irgendwann gefixten NVidia Bug. An so einer Stelle wäre weiterprobieren angesagt: mit welchen Optionen und Parametern scheitert es, mit welchen funktioniert es...
(und ja, da können nächte draufgehen ;) )
 
Ich hab mal nur diesen Auschnitt genommen (hab' ja keine Ahnung, ist also geraten).
Das geht aber meistens schief.
Du hast ja ein laufendes X und deshalb wäre für mich die Quelle der weiteren Erleuchtung die /var/log/Xorg.0.log. Die wird beim Start von X angelegt und sagt dir ziemlich alles, was du wissen möchtest an einem einzigen Platz. Das ist daher natürlich nicht besonders übersichtlich und braucht Geduld, um aufmerksam gelesen zu werden.
Aber du findest dort, welcher Grafik Chip erkannt ist und an welchem PCI-Platz der liegt. Du siehst, welche Module (Treiber) erfolgreich geladen wurden oder welche vielleicht vermisst werden (oder man kann sich das zusammenreimen: hat man eine nvidia-Karte und es wird keinerlei nvidia*.so geladen, dann fehlt hier garantiert was).

Desweiteren funktioniert noch immer der im Handbuch ganz unten aufgelistete Befehl (bin gerade in Eile und sehe nicht nach), in etwa so X --configure, womit ein Test Xorg.conf erstellt werden kann. In der Regel werden auch hier bereits die HW-Relevanten Einstellungen gefunden und passend ausgegeben. Ist allerdings zB der passende Treiber für die eigene GraKa gar nicht installiert oder grundsätzliche Module nicht geladen, dann funktioniert dies auch nicht richtig.

Mein Verdacht liegt in dieser Richtung, weil das ein beliebtes Problem ist. Es wird einfach X installiert und oft die Treiber vergessen. Solltest du tatsächlich die oben in der xorg.conf gelistete Karte haben, dann bräuchtest du zB xf86-video-intel, damit der Aufruf des Treibers überhaupt funktionieren kann und ob deine Karte tatsächlich auf PCI:0:2:0 sitzt, kannst du nicht raten. Das musst du auslesen. Meine aktuelle sitzt etwa auf PCI:101:0:0.
 
dann bräuchtest du zB xf86-video-intel

Habe diesen installiert, aber ohne Erfolg. Die Ausgabe von xrandr hat sich nicht geändert.

Eine Konfigurationsdatei kann, basierend auf der von Xorg erfassten Hardware erzeugt werden. Diese Konfigurationsdatei ist ein guter Ausgangspunkt für angepasste Konfigurationen.
Erzeugung einer xorg.conf:

# Xorg -configure

Die Konfigurationsdatei wird in /root/xorg.conf.new gespeichert.

Hier nun also diese (in Auszügen):

Code:
...

Section "Monitor"
    Identifier   "Monitor0"
    VendorName   "Monitor Vendor"
    ModelName    "Monitor Model"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        #Option     "ShadowFB"               # [<bool>]
        #Option     "DefaultRefresh"         # [<bool>]
        #Option     "ModeSetClearScreen"     # [<bool>]
    Identifier  "Card0"
    Driver      "vesa"
    BusID       "PCI:1:0:0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    SubSection "Display"
        Viewport   0 0
        Depth     1
    EndSubSection
.....
    SubSection "Display"
        Viewport   0 0
        Depth     24
    EndSubSection
EndSection

Kann ich denn nun einfach statt "vesa" besagten "xf86-video-intel" eintragen?
Hab' auch in der "Xorg.0.log" nach Hinweisen für die Karte geschaut.

Code:
...
[  1509.430] (--) PCI:*(0:1:0:0) 1002:7149:17aa:2005 rev 0, Mem @ 0xd8000000/134217728, 0xee100000/65536, I/O @ 0x00002000/256, BIOS @ 0x????????/65536
[  1509.431] List of video drivers:
[  1509.431]     scfb
[  1509.431]     vesa
[  1509.431]     modesetting
[  1509.431]     intel
[  1509.431] (II) LoadModule: "scfb"
[  1509.431] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[  1509.432] (II) Module scfb: vendor="X.Org Foundation"
[  1509.432]     compiled for 1.18.4, module version = 0.0.4
[  1509.432]     ABI class: X.Org Video Driver, version 20.0
[  1509.432] (II) LoadModule: "vesa"
[  1509.432] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so
[  1509.432] (II) Module vesa: vendor="X.Org Foundation"
[  1509.432]     compiled for 1.18.4, module version = 2.4.0
[  1509.432]     Module class: X.Org Video Driver
[  1509.432]     ABI class: X.Org Video Driver, version 20.0
[  1509.432] (II) LoadModule: "modesetting"
[  1509.433] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[  1509.433] (II) Module modesetting: vendor="X.Org Foundation"
[  1509.433]     compiled for 1.18.4, module version = 1.18.4
[  1509.433]     Module class: X.Org Video Driver
[  1509.433]     ABI class: X.Org Video Driver, version 20.0
[  1509.433] (II) LoadModule: "intel"
[  1509.433] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so
[  1509.523] (II) Module intel: vendor="X.Org Foundation"
[  1509.523]     compiled for 1.18.4, module version = 2.99.917
[  1509.523]     Module class: X.Org Video Driver
[  1509.523]     ABI class: X.Org Video Driver, version 20.0
[  1509.523] (WW) Falling back to old probe method for scfb
[  1509.523] scfb trace: probe start
[  1509.523] (II) VESA: driver for VESA chipsets: vesa
...

Das sagt mir alles nichts...
 
Zuletzt bearbeitet:
Identifier "Card0" Driver "vesa" BusID "PCI:1:0:0"
Das würde ich so deuten, dass entweder nicht der passende Intel-Treiber geladen ist oder eines der Module fehlt, die zuvor geladen sein müssen. So etwas sieht man in der Installations-Nachricht, nachdem ein Paket installiert wurde. Nachträglich kann man das mit pkg info -D nochmal lesen. In deinem Fall vielleicht soetwas, wie pkg info -D xf86-intel

Du kannst die Ausgabe von pciconf ansehen und auch daraus Informationen zu deinem Chip/deiner GraKa erhalten.
Etwa pciconf -lv und vielleicht mal grob nach grep -C6 VGA pipen. Das sollte den entsprechenden Hinweis enthalten. Danach muss man dann entscheiden, ob der Chipsatz überhaupt unterstützt wird und mit welchem Treiber.

Ich will das nun nicht alles hier ausführlich für meine Karte zeigen, das würde sicher mehr verwirren, als gut ist.
Jedenfalls kannst du auch schon mal sehen, das deine Karte offenbar nicht auf PCI:0:2:0 sitzt und deshalb kann das Beispiel von jemand Fremden für dich vollkommen in die Hose gehen.
Lieber herausfinden, man selbst hat und braucht.
Derzeit hast du offenbar nur den VESA-Treiber aktiv.
Das würde etwas weiter unten in der Xorg.0.log stehen müssen, aber die ist nicht so einfach zu lesen und verwirrt auf Anhieb immer. Es lohnt sich aber, genauer hinzusehen.
 
ah, nebenbei sollte mit X in GNU/Linux ziemlich gleich sein. Also, da kann man sich dann ja gut orientieren, wenn es dort funktioniert. Die gleichen Dateien, meist an den gleichen Orten, gleiche Funktionen und so.
 
Das würde ich so deuten, dass entweder nicht der passende Intel-Treiber geladen ist oder eines der Module fehlt, die zuvor geladen sein müssen.

Soweit ich sehe, ist dieser Laptop mit verschiedenen Grafikchips ausgeliefert worden. Da muss gar nicht unbedingt ein intel chip drin sein -> wäre evtl. über die Seriennummer rauszufinden, steht aber vielleicht auch in dmesg.boot (egrep "vga|drm" /var/run/dmesg.boot). Oder eben pciconf.

Derzeit hast du offenbar nur den VESA-Treiber aktiv.

Wenn dem so ist, dann ist es kein Wunder, wenn viele der "xrandr" Features nicht funktionieren. Vieles mit den modelines ist da nicht unterstützt.

Das würde etwas weiter unten in der Xorg.0.log stehen müssen, aber die ist nicht so einfach zu lesen und verwirrt auf Anhieb immer. Es lohnt sich aber, genauer hinzusehen.

Auch wenn man das meiste in diesem Log nicht versteht, kann man doch anfangen zu vergleichen: was ändert sich im Log, wenn man in der Config etwas ändert?
 
Also der Reihe nach..

Die verwendete Hardware gibts im Thinkpad-Wiki nachzulesen.
T60 14,1"/15,0" ATI X1300, X1400, V5200 2007, 2008, 2009, 2613, 2623, 2637

Laut Typenschild handelt es sich um das Model "2007".

Code:
pciconf -lv

vgapci0@pci0:1:0:0:     class=0x030000 card=0x200517aa chip=0x71491002 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'RV515/M52 [Mobility Radeon X1300]'
    class      = display
    subclass   = VGA

Also "ATI X1300".

FreeBSD Manual Pages "radeon" sagt dazu:

he radeon driver supports PCI, AGP, andPCIe video cards based on the
following ATI/AMD chips (note: list is non-exhaustive):

...
RV505/RV515/RV516/RV550
Radeon X1300/X1400/X1500/X1550/X2300
Code:
$ sudo pkg install radeon
...
pkg: No packages available to install matching 'radeon' have been found in the repositories

$ sudo pkg search radeon

radeontool-1.5                 ATI Radeon video card controlling tool useful for laptops
radeontop-1.2                  Program that shows AMD Radeon GPU resource utilization

Ich vermute also, daß ich den Treiber von den Ports installieren muss, habe mich damit aber noch nicht auseinander gesetzt (neues Thema). Aber doch schon mal einen Schritt weiter!

Oder Kann es sein, daß "radeontool-1.5" bereits den Treiber beinhaltet?
 
Zurück
Oben