Tryby graficzne w jądrze – pierwsze testy
- Dodano: 21 April 2008
- Wprowadził: kocio
- Komentarze: 68
Wychodząca niedługo Fedora 9 będzie pierwszą dużą dystrybucją Linuksa, która pozwoli na obsługę trybów graficznych bezpośrednio w jądrze. Serwis Phoronix pokazał pierwsze testy przedstawiające tę funkcję w akcji.
Ponieważ jej API nie zostało jeszcze ustabilizowane, można ją zaobserwować tylko przy podaniu specjalnego parametru rozruchu jądra “i915.modeset=1″. Ta nazwa oznacza, że na razie test mogą powtórzyć tylko posiadacze kart Intela. Kolejny będzie zapewne sterownik do Radeonów.
Nowa funkcja nie chciała działać z każdym monitorem, ale gdy już działała, to przełączanie między trybem graficznym a tekstowym było rzeczywiście szybkie i bardzo gładkie.
Zmiana trybów graficznych na poziomie jądra to tylko jedna z nowości, które mają zostać wprowadzone do Xorg.
Więcej informacji: http://www.phoronix.com/scan.php?page=ar...ting&num=1
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
68 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Bardzo fajna funkcja – dobrze wygląda. Może też okazać się bardzo użyteczna, bo prawdopodobnie pozwoli na rezygnację X'a z praw administratora
(z tego co wiem, to właśnie do wykrywania ustawień karty graficznej X potrzebuje uprawnień root'a)
Niestety na razie tylko dla kart Intela – czekam na wsparcie ze strony sterowników nv czy nouveau.
nv to juz historia, ztcw nouveau jest nie tylko aktywniej wspierany, ale i bardziej funkcjonalny.
fakt – ide o zaklad ze to nouveau bedzie kolejnym po intelu sterownikiem toto obslugujacym
Swoja droga, OpenBSD od dosyc dawna ma mechanizm umozliwiajacy xserwerowi dzialanie bez praw roota – root jest "zrzucany" po zainicjalizowaniu sprzetu.
Dziwne troche, ze nikt tego pod Linuksa nie przeportowal.
Hej, ale na serio, czy blefujesz?? Trochę mnie to śmieszy(nie ty, ale sam fakt).
A co będzie, jeżeli będziemy przełączali się między kilkoma X serwerami lub X serwerem i konsolą? Wtedy X serwer ponownie musi ustawić odpowiadający mu tryb graficzny. I jeszcze jedno: co z emulacja?
Nie jestem żadnym guru informatyki. Zaciekawiłem się tym. Mógłbyś wskazać na jakieś tksty na ten temat
.
No, troche (nieswiadomie) uproscilem.
.
"Privilege separation has been implemented in the X server. The privileged child process is responsible for the operations that cannot be done after the main process has switched to a non-privileged user. This greatly reduces the potential damage that could be caused by malicious X clients, in case of bugs in the X server."
.
http://www.billswrite.com/bsd/openbsdnews.html
Takie cos to nawet na windowsie jest ;p
Ot kazdy proces (nawet zforkowany) moze byc przypisany innemu userowi – zatem zadna nowosc.
Co tam Windows, to nawet w Linuksie jest. Tyle, ze tutaj chodzi o wykorzystanie tego po to, aby xserwer nie dzialal na prawach roota. W OpenBSD jest, w Linuksie nie.
W OpenBSD jest systrace.
Nie widze zwiazku.
A jak sobie to zrobić na innym distro?
Tzn wystarczy mieć odpowiednią wersję Xorga i wkompilować co trzeba w jajko?
Proponuję zajrzeć na ftp z pakietami dla F9, ściągnąć źródła jądra i X'a i zobaczyć jakie łatki są wymagane.
pewnie wystarczy z gita pobrac xorg-server-video-intel no i oczywiscie odpowiednie latki na jajo…
osobiscie wyczekuje na ta wlasnie funkcje, jak i na poprawienie drivera do i965 (poki co nie obsluguje np. xvmc na ktorym mi dosc zalezy, a i po powrocie z uspienia, konsola zle sie inicjuje sie…)
pytanie kiedy to w innych driverach rowniez zostanie zaimplementowane… 95% ze nastepne bedzie nouveau…
stawiam na radeona
tj. na "wolne" sterowniki do radeona?
ostatnio chyba ich rozwoj "nieco" zwolnil, mimo udostepnianych dokumentacji…
Nie zwolnil, zarówno oryginalny radeon, jak i radeonhd aktywnie się rozwijają, aż miło przeglądać repozytorium gita
.
Największy brak to póki co to dokumentacja akceleracji 3D dla chipów R600, reszta w zasadzie już jest.
XvMC już jest, teraz pozostaje czekać na poprawki w EXA i TTM w jajku.
Nie wiem, czy wszyscy zauważyli, ale fedora9 butuje się naprawdę błyskawicznie, nawet z CD! W zasadzie prawie jak Viśta
.
Zauważyłem – adres: stardust dot webpages dot pl slash files slash fedora-upstart pliki bootchart-parallel.png i bootchart-serial.png.
Niestety upstart 0.3 jeszcze nie jest tym czego byśmy wszyscy chcieli – nie obsługuje bardziej skomplikowanych zależności między zdarzeniami np. "start on started foo and bar" oraz nie posiada możliwości eksportowania zmiennych ze skryptów. Na szczęście upstart 0.5 będzie miał już wszystko co potrzeba i będę mógł przepisać bootscript F9.
To co jest w bootchart-parallel to tylko mała zapowiedź tego (zrobione na prostych wrapperach na skrypty sysvinit) co chcę osiągnąć przepisując bootscript – rc.sysinit też będzie równoległe
Ale ja na Ubuntu z upstartem (skrypty wykonujące polecenia z /etc/init.d) osiągam czasy nieco ponad 20s. Wystarczyło trochę podłubać i ściągnąć gotową paczkę ze skryptami.
Gdybyś nie zauważył, to w moich testach używałem prawie wszystkich usług jakie są w domyślnej instalacji F9 – duża część z nich jest domyślnie wyłączona.
Napisałem też, że użyłem wrapperów które wyglądają mniej więcej tak
start on started rsyslog
start on runlevel 2
start on runlevel 3
start on runlevel 4
start on runlevel 5
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
console output
script
/etc/init.d/acpid start
end script
pre-stop script
/etc/init.d/acpid stop
end script
Czyli są używane standardowe skrypty sysvinit, tylko są uruchamiane prawie równolegle – z powodu nieobsługiwania przez upstart 0.3 bardziej skomplikowanych zależności.
Jeśli używasz skryptów korzystających z dobrodziejstw upstart, to są one oczywiście wykonywane trochę szybciej niż skrypty sysvinit.
W F10 prawdopodobnie znajdzie się już nowy bootscript – przepisany pod upstart 0.5 – celem jest wystartowanie dystrybucji z domyślnymi usługami w czasie poniżej 30 sekund
Ciekaw jestem kiedy taką funkcjonalność wprowadzą w debianie.
jak juz tk offtopujemym, to najszybciej bootujacym sie livecd jest chyba archie (taki archlinux livecd). sam livecd tez szybko smiga.
Uhh, prawie się piwem udławiłem:P "Szybko jak Vista"? To ironia, sarkazm, etc.?
Nie wiem, w zasadzie nie używałem, ale swego czasu jak się mu przyglądałm to dość szybko wstawał – a, że później już ta różwo nie jest, no… to już inna bajka
.
2 minuty to nie jest szybko:P Może masz na myśli wybudzanie z hibernacji? Tego nie próbowałem.
Nie wiem co to było, na pewno było to dawno – w każdym razie "skojarzenia to przekleństwo" jak widać
.
Czy jesteś studentem? Pijesz piwo przed komputerem, oglądając filmiki pornograficzne, z przerwami na lekturę LinuxNews?
Pije Kuba do YouTuba…
Tak, dokładnie. A co gorsza, głosowałem na PO :0
:P:P
Już po Tobie.
A czym to się różni z punktu widzenia użytkownika któremu coś się "sypło w iksach" od funkcjonalności zwanej jako BulletProofX ?
Celem? BulletproofX pozwala na wystartowanie X.orga przy złym xorg.conf, na minimalnej rozdzielczości, albo skonfigurowanie go z okienka jeszcze przed logowaniem, a to to ma umożliwić płynniejsze przejścia pomiędzy trybami (terminalami), w dodatku ulepszyć obsługę sprzętu i zredukować objętość Xserwera.
Może to dać chyba niezłe efekty w połączeniu z bootsplashem
No i pojawiła się kolejny powód dla którego warto czymać kartę ATI
s/czymać/trzymać/
piszmy poprawnie…
Ups… Sory to nieświadomie było…
W praktyce będzie jak zawsze – nVidia dopisze po 2 miesiącach, Intel będzie kulał przez pół roku, na ATI/AMD nie będzie przed 2010. W desktopie mam GF, w notebooku i965GM i na poprawną obsługę EXA przyjdzie mi czekać do jesieni b.r. (na TTM). Na chwilę obecną wolałbym mieć jednak GF.
A jaki to ma wpływ na bezpieczeństwo jajka?
Duży – mniej grzebania po rejestrach sprzętowych z przestrzeni użytkownika, więcej pod kontroją samego jajka.
Kiedy to bedzie w FreeBSD
12 maja o 17:03.
O 17:11.
Masz nieaktualne informacje
A po co komu taki "feature" na serwerze?
A kto powiedział że FreeBSD jest na serwer?
Używam na laptopie bez żadnych problemów.
Wiadomo, że można na laptopie używać choćby i Solarisa – jeśli tylko sprzęt się nada – "bez żadnych problemów".
Z obsluga sprzetu to dziala w obie strony. Jakis czas temu, na przyklad (jakis czas, bo od pewnego czasu na zabawy ze sprawdzaniem wsparcia dla roznego sprzetu nie mam czasu ani ochoty) z obsluga IDE (w sensie, ATA) pod FreeBSD bylo mniej problemow niz w Linuksie. Teraz tak samo (afaik) wyglada sytuacja z WiFi.
Zgoda, że nie wszystkie sterowniki robi się dla Linuksa – a potem dopiero "portuje" do xBSD. Ale, tak prawdę mówiąc, to jednak Linuksowi deweloperzy znacznie bardziej wyczuleni są na zgłaszane błędy – w xBSD trzeba być przygotowanym na podejście typu: "to stary sprzęt, to już nam się do tego wracać nie chce", albo: "to ochotniczy projekt – i tak nie płacisz, to nie zawracaj głowy" (dosłownie). Oczywiście, że "nie płacę" – pełna zgoda – ale przecież za Linuksa też nie płacę, prawda? A może być i humorystyczniej; można czasem dostać w odpowiedzi: "masz dostępne `źródła', to sam se napraw. Jak skończysz – patcha `zapodaj' ". Taki drobny detal, że jakbym mógł zrobić to sam, tobym nie zawracał nikomu d… – jakoś umyka uwagi takiego dowcipnisia.
Tak więc, skoro w świecie Linuksowym podejście do usuwania niedostatków jest wyraźnie solidniejsze, to wspomniana "sytuacja z WiFi" z całą pewnością jest czysto przejściowa.
@Z: Szczerze powiem, ze mam doswiadczenia dokladnie odwrotne – w dodatku taki RedHat potrafi olewac zgloszony problem mimo wykupienia supportu. Z FreeBSD mialem troche problemow (ostatnio z if_bridge, na przyklad), ale po zgloszeniu byly dosyc szybko rozwiazywane. Kwestia tego, na kogo konkretnie trafisz. Podobnie zreszta jak z Linuksem.
Nie mam w ogóle żadnych doświadczeń z RedHat-em (nie używam) – ale co do sterowników, to raczej należało na kernel-list.
No, jeśli chodzi o "fejczery" takie "bardziej na czasie", to zawsze łatwiej jest kogoś zainteresować. Ale spróbuj zgłosić potrzebę poprawki czegoś, czym tam akurat deweloperzy już dłuższy czas temu przestali się bawić, uznając za ostatecznie ukończone.
Podejście, jakie zauważyłem, jest z grubsza takie, jakby to mieli za darmo robić wyłącznie dla Ciebie – a nie również dla 10 tysięcy innych właścicieli tego samego sprzętu, z których – powiedzmy – dwustu, być może, zainteresowałoby się xBSD, gdyby im toto chciało działać. A przecież w masie użytkowników Ci, którzy zgłaszają błędy, to też nieliczna grupka. I raczej na pewno nie dotyczy to tych, którzy dopiero "przymierzają się": ot, wrzucą instalkę, stwierdzą "co za badziew" – i przez najbliższe parę lat do tematu nie wrócą.
To na pewno; problem w tym, że nie zawsze jest wybór, jeśli – na przykład – w jakiejś sprawie decyzje podejmuje akurat jedna-jedyna osoba, wtedy i tak wszystko do niej wraca.
Czy to oznacza, że będą też poprawione sterowniki konsol framebuffer?
No właśnie. Powie ktoś, jaki to ma związek z warstwą framebuffera albo zarzuci ktoś linkiem?
Z tego co widzę w łatce linux-2.6-drm-i915-modeset jest nowa implementacja bufora ramki dla kart Intela.
wget http://koji.fedoraproject.org/packages/kernel/2.6…
http://www.osnews.com/story/19667
=}
Konkurencja – Windows albo komercyjne uniksy – miala to w latach dziewiecdziesiatych, wiec to nie tak calkiem dwudziesty pierwszy wiek.
Spójrz w kalendarz – to jednak już…
Spojrz w funkcjonalnosc Linuksa w porownaniu do, dajmy na to, OSX. Nie, jeszcze nie. ;->
OSX kuleje i jakoś zainteresowanie nim zaczęło coraz bardziej spadać
. Jeśli porównujesz prekonfigurowany system (macosx) pod konkretny sprzęt do Linuksa, którego sam musisz skonfigurować to tak. Ale trzeba przyznać, że to trochę głupie. Jaką funkcjonalność masz na myśli? Chyba nie możliwości jądra, środowisk, aplikacji? 
Hmm… A jeszcze mi gdzieś tam po głowie się kołacze kilka artykułów w których hackerzy jajka lamentowali nad obsługą grafiki w jądrze Windows. Że może to i szybsze, ale jakże destabilizuje jądro i w ogóle… Widać, punkt siedzenia się nieco zmienił
Ale tu zupełnie nie o to chodzi. W tej chwili obsługą sprzętu zajmuje się X, a tymczasem jest to działka kernela. Tak więc chce się przenieść nie całą grafikę do jądra, tylko tą część iksów odpowiedzialną za sprzęt. Nie destabilizuje to jądra bardziej niż obsługa, dajmy na to, dźwięku czy sieci w jądrze.
W Windows jest zupełnie inna bajka. Cały kod obsługujący GUI jest w jądrze – jeśli silić się na porównania, to tak jakby chcieć przenieść GTK+ i Qt do jądra.
I tez to niczego (w Windows) nie destabilizuje. Kiedy ostatni raz miales bluescreen spowodowany przez win32k.sys, ktory nie wynikal z uszkodzonego (albo przetaktowanego, na jedno wychodzi) sprzetu?
.
Owszem, byl taki okres, zaraz po tym, jak to wrzucili do kernela. Gdzies w okolicach wczesnego NT4.
z ta grafika w jadrze, jest jak w GOTO – moze to i dziala, ale jakie to brzydkie
z tym goto sie nieco rozpedziles – prawdziwi programisci nie boja sie uzywac goto
Goto ma swoje zastosowania i w okreslonych sytuacjach zwieksza czytelnosc kodu. Oczywiscie w _niektorych_ sytuacjach. Dobrze opisal to Linus gdzies kiedys, piszac o zwalnianiu zasobow w razie bledu.
.
Poza tym nie powiedzialbym, aby grafika w jadrze byla jakos specjalnie brzydka. Ladniejsze to, niz na przyklad poryty sposob bootowania Linuksa – szopki z initrd itd, spowodowane tym, ze badziewny bootloader nie umie kernelowi modulow podladowac.
Za to sytuacje, w których całe windowsowe GUI stoi przez kilkadziesiąt sekund (sic!) bo akurat się zblokowało na jakiejś operacji I/O są naprawdę denerwujące. Jak ktoś używa aplikacji przenośnych na flashu, wie o czym mówię.
Ale ja nie mówię, że to destabilizuje. Nie destabilizuje dlatego, że kiedy GUI zostało wprowadzone do jądra NT, to GUI miało już kilka(naście? nie wiem dokładnie) lat, i było na tyle dobrze przetestowane, że nie destabilizuje niczego.
Co nie zmienia faktu, że w ogólnym przypadku nie uważam tego za dobry pomysł;)
nadal grafika nie bedzie obslugiwana na poziomie jadra – chodzi tylko o ustawianie odpowiednich trybow graficznych, a w przyszlosci – tzw. "prymitywow" – czyli podstawowych operacji typu blit, alokacja pamieci dla tekstury i takie tam…
Eeee tam, ja od dawna pamiętam Torvaldsa, który lamentował, że obecne DRI zbyt dużo robi poza wiedzą jądra i trzeba z tym skończyć.
Well this kind of details is in fact worth looking for, good information for readers and obviously shows high quality writing. Its cool to have these kinds of posts about to help keep the details flow. Helping those who truly get pleasure from this, wonderful perform! Thanks once again for taking the time to place this online. I unquestionably liked every portion of it.