moin,
ich hab nen alten Fujitsu Futro S500 gefunden und mit siduction wiederbelebt. Dazu nen alten SATA PCI Controler aus meiner Grabbelkiste gefischt und nen PCI Riser. Das Slotblech auf halbe Höhe umgedengelt und die 5 Volt für die Festplattenspannung aus einer ungenutzten USB Schnittstelle geholt.
die interne 128MB CF Card brauche ich noch fürs /boot und Grub, weil das bios es nicht schafft vom Sata Controler zu booten.
didi@siductionbox:~$inxi -v5
System: Host: siductionbox Kernel: 3.11-0.towo-siduction-amd64 x86_64 (64 bit, gcc: 4.8.1)
Desktop: Xfce 4.10.0 (Gtk 2.24.10) Distro: siduction 12.2.0 Riders on the Storm - xfce - (201212092126)
Machine: System: FUJITSU SIEMENS product: FUTRO S500
Mobo: FUJITSU SIEMENS model: D2703-A1 version: S26361-D2703-A1
Bios: FUJITSU SIEMENS // Phoenix version: 6.00 R1.07.2703.A1 date: 10/21/2008
CPU: Single core Mobile AMD Sempron 2100+ (-UP-) cache: 256 KB flags: (lm nx sse sse2 sse3) bmips: 1999.69 clocked at 999.847 MHz
Graphics: Card: Advanced Micro Devices [AMD] nee ATI RS690M [Radeon X1200 Series] bus-ID: 01:05.0
X.Org: 1.12.4 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1680x1050@59.9hz
GLX Renderer: Gallium 0.4 on ATI RS690 GLX Version: 2.1 Mesa 8.0.5 Direct Rendering: Yes
Audio: Card: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) driver: snd_hda_intel bus-ID: 00:14.2
Sound: Advanced Linux Sound Architecture ver: k3.11-0.towo-siduction-amd64
Network: Card: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller
driver: r8169 ver: 2.3LK-NAPI port: a000 bus-ID: 08:00.0
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 00:19:99:59:69:ef
Drives: HDD Total Size: 500.2GB (18.4% used) 1: id: /dev/sda model: FCR128 size: 0.1GB
2: id: /dev/sdb model: SAMSUNG_HM500JI size: 500.1GB
Optical: No optical drives detected.
Partition: ID: / size: 226G used: 86G (41%) fs: ext4 dev: /dev/sdb3
label: N/A uuid: 61c398aa-7e46-4fce-9936-544c2d27f5e1
ID: /boot size: 121M used: 45M (40%) fs: ext2 dev: /dev/sda1
label: N/A uuid: 984c7b4b-864d-4495-971a-e0e2455d1f1a
ID: swap-1 size: 1.07GB used: 0.11GB (10%) fs: swap dev: /dev/sdb2
label: N/A uuid: e2d7b9f8-a79f-495a-bf47-ee43f7ab5257
RAID: No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors: System Temperatures: cpu: 58.1C mobo: 50.0C
Fan Speeds (in rpm): cpu: 0 fan-2: 0 fan-3: 0 fan-4: 0
Info: Processes: 137 Uptime: 33 min Memory: 293.4/431.4MB Runlevel: 5 Gcc sys: 4.7.2 Client: Shell inxi: 1.8.20
Altteil recycle macht Spaß!
ein Problem bleibt mir erhalten:
auf der console in init 3 benutze ich nur das obere linke Viertel meines 1680x1050 Bildschirms und lightdm kommt mit 640x480 Auflösung daher.
Das liegt, vermute ich, daran das außer DVI-0 auch noch LVDS von xrandr gefunden wird. Ne vernünftige X-Auflösung habe ich auch erst durch ausschlten von LVDS in X bekommen.
Kann mir jemand weiterhelfen wie ich in der Console den ganzen Bildschirm nutzen kann und beim lightdm von 640x480 erlöst werde, mein Schirm macht 1680x1050.
schau dir mal diese datei an: /etc/default/grub
wichtig!!! vbeinfo in grub ausführen, um zu sehen, was die grafikkarte wirklich unterstützt.
mit meiner radeon habe bei mir die tty auflösung auf 1280x1024 hingebogen:
GRUB_GFXMODE=1280x1024
GRUB_GFXPAYLOAD_LINUX=1280x1024
der Xserver lief auch erst nur mit 640x480. Änderungen wurden ignoriert, bis ich auf die Idee kam LVDS zu deaktivieren. Jetzt funktioniert der Xserver so wie er soll.
gibt es zu xrandr eine Entsprechung für die Console?
Das system krankt daran, das es glaubt 2 Schirme zu haben, obwohl es definitiv nur einen hat. Und die automatische Einstellung scheint sich immer ausgerechnet den nicht existierenden rauszusuchen. Auf dem Mainboard gibt es ein leeres Areal mit LVDS bezeichnet, aber nicht bestückt.
wie gesagt, mit den optionen von oben konnte ich bei mir das tty auf eine angenehme auflösung nageln.
update-grub sollte man nicht vergessen. das hab ich vorhin nicht erwähnt
vbeinfo in grub sagt zu preferred mode 1680x1050.
wenn ich das in /etc/default/grub eintrage und update-grub ausführe, habe ich nen schönen grub Bootscreen, der nach den ersten großen Zeilen beim laden des kernels wieder auf den viertel screen umspringt.
kommentiere ich die beiden einträge und setzte ich
GRUB_TERMINAL=console
ändert sich wieder nur der grub bootscreen, danach wieder das gleiche Problem.
ich bin schätze wenn es mir gelänge den Mist LVDS screen zu disablen wäre ich das problem los. Aber wie? im Bios gibt es dazu nix. xrandr funktioniert nur in X. gibt es nicht die Möglichkeit über die vbetools etwas einzustellen? Die manpage bringt mich da leider nicht weiter.
interessant... ich kenne den thinclient nicht. was kann man denn alles im Bios einstellen?
bei einigen TFT-Displays kann man die Darstellung des Signals anpassen: bekommt das Display ein Signal mit niedrigerer Auflösung, als es nativ darstellen kann (z.b. 800x600 statt 1680x1050), so kann es die Darstellung a) skalieren oder b) in der Mitte/Ecke nicht skaliert.
kann es sein, dass da etwas in die Richtung passiert?
Mal austesten: GRUB_GFXPAYLOAD_LINUX=keep (statt expliziter Zahl)
oder Farbtiefe angeben und mehrere probieren (GRUB_GFXPAYLOAD_LINUX=1680x1050x8 ,x16 ...)
Hab ich auch nochmnal ausprobiert, aber es bringt alles keine Änderung. nur der erste blaue Grub Bootscreen verändert sich.
während des Bootens, dann wenn kms greift (so glaube ich) wird der Schirm kurz schwarz und schaltet in den "viertel Screen Modus oben links". der Anmeldebildschirm kommt dann 640x480 und erst wenn in X die Einstellungen greifen, wo ich den physisch nicht vorhandenen LVDS screen disablen kann, hab ich wieder den vollen 1680x1050 Bildschirm.
Ich erklär mir das so:
mit /etc/default/grub stelle ich mir die Fontgröße richtig ein, bin im Bios mode und hab den ganzen bildschirm ausgefüllt. Dann während des Bootens wird irgendwann kms aktiv und plötzlich glaubt Linux 2 Schirme zu haben LVDS und DVI-0, wobei dann die Fontgröße von /etc/default/grub erhalten bleibt, aber der LVDS als 1. Bildschirm die Bildschirmgröße (640x480) bestimmt. Das führ dan dazu das ich ungefähr das obere linke Viertel des Screens benutze.
eben 640x480 von 1680x1050.
Ich versuch jetzt mal was bei radeon.modeset=0 rauskommt.
Edit:
Ich glaube ich liege mit meiner Einschätzung nahe an der Wahrheit.
mit radeon.modeset=0 hab ich nen gleichgroßen lightdm und xfce Screen, es gibt auch nur noch einen Bildschirm namens default, aber leider auch nur noch 1280x1024 als größte Auflösung. und as sieht richtig Sch.... aus.
Also werde ich wohl mit dem viertel Bildschirm leben müssen, bis mir jemand verrät, wie ich bei radeon.modeset=1 per Bootparameter den blöden LVDS Screen disablen kann.
video=LVDS:off geht jedenfalls nicht mehr. gibt es dafür ne andere Syntax bei neuen Kerneln?
Edit_2:
Ich hab jetzt das Paket fbset installiert. Jetzt kann ich mit
fbset -g 1680 1050 1680 1050 32
die console wieder so einstellen wie es soll.
Nur wenn ich das in /etc/rc.local eintrage funktioniert das nicht.
Dann bleibt der bootvorgang sogar hängen beim starten von lightdm.
es endet mit einem grafischen cursor auf schwarzen Grund, der sich aber auch nur im ominösen linken oberen viertel bewegen lässt.
ctlr-alt-f1 und direkt danach alt-f7 zeigt dann lightdm.
die console ist aber trotz der veränderten rc.local noch bei 640x480.
jemand ne Idee wie ich diesen fbset Befehl beim booten automatisch ausgeführt bekomme, so das alles funktioniert?
Edit_3:
wenn ich im Grub mit e die kernelzeile bearbeite und in runlevel 3 starte ist zeig die rc.local das gewünschte Verhalten und ich hab meine 1680x1050 console. Warum geht das dann nicht wenn ich direkt in den runlevel 5 boote?
https://bbs.archlinux.org/viewtopic.php?id=94990
scheinbar lautet die syntax: video=LVDS:d
klappt's damit?
leider auch nicht. Ich muss mal den ganzen Artikel lesen, möglicherweise heißt der Schirm ja unter X anders als in der console, aber wenn dann wie daran kommen?
Bis jetzt ist mein "Würg herum" ein display setup script für lightdm mit folgendem inhalt:
#!/bin/bash
xrandr --output LVDS --off
xrandr --otput DVI-0 --mode 1680x1050
und in der .bashrc von root hab ich mir nen alias gebastelt:
alias fb='fbset -g 1680 1050 1680 1050 32'
damit brauche ich dann im runlevel 3 nur noch 3 Tastendrücke um die console da zu haben wo ich sie haben will.
ls /sys/class/drm :
card0 card0-DVI-I-1 card0-LVDS-1 controlD64 ttm version
aber auch video=LVDS-1:d macht keinen Unterschied.
Der verlinkte Artikel beschreibt genau mein Problem.
Aber ist mit kernel 3.11 denn der video= Befehl in grub überhaupt noch existent?
Mit welchen Suchbegriffen hast Du den Artikel gefunden ?
Ich hab den nähmlich nicht gerfunden. Und gesucht hab ich weiß Gott genug.
meine google suche keywords waren: "kernel boot grub video lvds off"
es gibt schon einige treffer zu dem thema...
was ist, wenn du statt LVDS abzuschalten versuchst auch das LVDS auf die gewünschte auflösung zu nageln?
--> video=LVDS-1:1680x1050 video=DVI-I-1:1680x1050
oder doch LVDS aus, aber dann DVI explizit an:
--> video=LVDS-1:d video=DVI-I-1:e
ggf. müsste man die anderen anpassungen (framebuffer, GFX_MODE, ...) abschalten, damit die sich nicht gegenseitig behindern.
die Kernel Parameter Liste:
https://www.kernel.org/doc/Documentation/kernel-parameters.txt
ich habs!
meine /etc/default/grub musste so aussehen:
GRUB_CMDLINE_LINUX_DEFAULT="video=LVDS-1:d video=DVI-I-1:e\ drm_kms_helper.edid_firmware=edid/1680x1050.bin quiet"
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=1680x1050
GRUB_GFXPAYLOAD=keep
Die Werte für die Schirme hab ich aus dem Verzeichnis /sys/class/drm und dann das card0- weggelassen.
besten Dank für Deine Hilfe absolut
ha! das ist ja super!
ein bisschen unsicher bin ich bei GRUB_GFXPAYLOAD... müsste es nicht korrekt GRUB_GFXPAYLOAD_LINUX heißen? ich glaube, GRUB_GFXPAYLOAD ist deprecated.
gute Frage, eins davon ist alt eins neu aber was ist was?
da die anderen Optionen auch ohne _LINUX in der Datei standen hab ich es weggelassen. Das System läuft immerhin. Werde mal googlen was die Syntax angeht.
ich denke Du wirst recht haben mit GRUB_GFXPAYLOAD_LINUX.