Błąd X Window w 16-bitowym kolorze

[ra-v]

-------------------------
PC: Compaq Deskpro EN
Płyta głowna: Intel i815
RAM: 512MB 133MHz
CPU: PIII Coppermine 1GHz
Karta graficzna: Intel I810 4MB VRAM/64MB AGP (zintegrowana)
OS: Linux Fedora Core 1 (2.6.24.5)
-------------------------

Nie mogę ustawić 16-bitowej palety dla systemu X Window. W logu wyswietla się poważny błąd GDM i zawiesza się ekran, tzn. można się "po ciemku" zalogować w konsoli i wyłączyć zrestartować komputer. Przy tych samych ustawieniach na jądrze 2.6.21 i 2.4.22 16-bitowy kolor działa bez problemu.

W palecie 24b system działa bez problemu, ale to spowalnia m.in. emulatory.

Jedyny sposób to obejście tego to dodanie w pliku konfiguracyjnym X
palety 15b - działa, ale widać ubytek kolorów w porównaniu do 16b.

Może zna ktoś ten problem?
Jeśli nie, to pozostaje zawsze 15b:)

[arctgx]

Jeśli po logu (jakim logu?) widzisz, że to "poważny błąd GDM", to może spróbuj odpalić X z innego menedżera (choćby XDM) albo nawet na surowo, np. dając z konsoli tekstowej X :0 & xterm -display :0 & (możesz i bez xterma - da się go póżniej dodać . A z konsoli w X odpalisz sobie resztę.

Rezygnacja z GDM, który jest częścią Gnome, na rzecz lekkiego, choc może i surowego XDM, może przy okazji dobrze zrobić wydajności, tak samo jak zastąpienie Gnome czy KDE lżejszym menedżerem okien.

[ra-v]

Poniżej linia logu, w którym jest pokazany błąd GDM.

iso-8859-1Apr 29 21:58:01 rafalh gdm[2178]: gdm_slave_xioerror_handler:
  Powa??ny b?\\202Ä\\205d X - restartowanie :0

Po próbie logowanie XDM w logu nie widać żadnych błędów, mimo że dziaje się to samo.
Serwer X startuje (niebieski pulpit i kursor myszy), 5 razy miga i się zaiwesza.
Przewiduje, że w tle aktywna jest nadal konsola. Można się zalogować i uruchomić coś np. du -h - słychać że coś czyta na dysku.
CTRL+ALT+DEL "przepisowo" restartuje komputer.

To co, zostać przy 15b kolorze?

[arctgx]

A co widać w /var/log/Xorg.0.log? W razie problemów z dostępem do konsoli po awarii Xorg, dodaj po spacji 1 do parametrów jądra na starcie, by uruchomić system tylko w trybie single.

Nawiasem, tekst logu wygląda jakbyś miał system zlokalizowany na ISO-8859-1, a programy użytkownika na UTF-8. Może się mylę.

[ra-v]

Nawiasem, tekst logu wygląda jakbyś miał system zlokalizowany na ISO-8859-1, a programy użytkownika na UTF-8. Może się mylę.

I mnie też to dziwi czemu wyświetla ISO-8859-1...
System chodzi na UTF-8.

[arctgx]

Skoro dziwi, odpal i porównaj locale z roota i z rafalh.

Co z logami Xorg?

[ra-v]

Tymi sposobami kombinowałem już wcześniej - ale bez efektu. Zawsze kombinuję, jeśli coś nie działa, a potem dopiero szukam w necie:)

Mnie bardzo dziwi, czemu na jądrze 2.6.21 i 2.4.22 TAKA SAMA konfiguracja działa.

[arctgx]

Jeśli kombinowałeś, warto wspomnieć, co dokładnie. W tej chwili nie wiem czy mówiąc o "tych sposobach" masz na myśli to, że nie znalazłeś nic w Xorg.0.log czy że locale wychodzą tak samo lub różnią się. Jeśli nie napiszesz, jaką dokładnie robotę masz za sobą, ktoś z nas może niepotrzebnie produkować posty, zabierając czas i sobie, i Tobie.

[ra-v]

Locale są takie same. Można uruchomić system na starym i nowym jądrze i żadnych szczególnych zmian w logach się nie zauważy.

Przyszedł mi do głowy pomysł: a może jest to problem z buforem ramki? Może nowe jądro ma jakieś kłopoty z 16bitowym kolorem na tych kartach?

[ra-v]

...ano to był problem z buforem ramki.

Mianowicie wystarczyło skompilować obsługę framebuffer'a jako moduły. I sprawa załatwiona:)   ... po miesiącu:(