A Fedora 21-ben alapértelmezett lesz a Wayland

A Fedora technikai vezetőtestületének (FESCo) tegnapelőtti ülésén egyebek mellett az a döntés született, hogy a Wayland alapértelmezettként fog bemutatkozni a Fedora 21-ben:

F21 System Wide Change: Wayland - AGREED: Wayland change approved

A Fedora Wayland-del kapcsolatos információi itt érhetők el.

Hozzászólások

Izgalmasan hangzik. Beta tesztet azt hiszem mindenképpen csinálok ebben a periódusban.

Akinek gondja támad vele, legfeljebb használja a X.org-ot.

Elég nagy lépés ez a Fedorától. Utoljára még csak azt olvastam, hogy az X szerver nem root joggal fog futni, ami értelemszerűen biztonságosabb. Aztán most meg már Wayland.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem írtam, de én is nagyon izgatottam várom. Kíváncsi vagyok a fenti támogatásokra, az indulási időre, a root nélküliségre amit írsz meg egyéb. Illetve habár már valszeg sokmindenkit nem érint, kíváncsi lennék hogy CRT monitorokat mennyire lenne könnyű vele konfigurálni, vagy ha LCD is de pl. felbontást váltani vagy eleve választható felbontást és frekvenciát beállítani. Remélem ezen a téren is lesz nagy előrelépés.

Egy otthoni felhasználó sem vesz manapság CRT monitort: sok helyet foglal, nehéz, sugárzik/villog, felejtős... nyilván aki valami nagyon
színhűfontos dolgot csinál, az használja, bár arra a célra is biztos vannak TFT monitorok.. de azért a pár száz emberrel nem igazán foglalkoznék
egy dist helyében... nem célközönség...

Lényegében igen, de mégsem. LCD-nél gyakorlatilag mindegy, hogy egy adott pixel 13.3 vagy 16.7 ms gyakorisággal veszi fel az új értékét. Mivel a pixel a frissítések közti időben a legutóbbi frissítéskor meghatározott színű, intenzitású, így nem villódzik. CRT-nél elszalad az elektronsugár, hirtelen nagy intenzitású a pixel, majd exponenciálisan csökken az intenzitása az idő függvényében. Gyakoribb frissítés esetén kisebbek lesznek az intenzitás változások, valamint a szem sem képes annyira követni a villogást.

Tehát LCD-nél jó a 60 Hz, nem kell agyalni rajta, hogy mennyi legyen.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Elvileg a digitális kimenet pontosan ugyanúgy működik, mint az analóg. Eleinte az időzítések teljesen megegyeztek azonos felbontásban analóg és digitális kimeneten, beleértve a szinkronjeleknek és kioltási időknek kihagyott időablakokat is. General Timing Formula alapján számolták őket, így ugyanis CRT-kompatibilis maradt a digitális jel is, egyszerű DAC-kal lehetett átalakítani analógra, framestore nélkül.

Aztán később bejöttek a "reduced blanking" üzemmódok, amik már nem hagynak ki felesleges időket szinkronjelre. Ezzel elég nagyot lehet spórolni sávszélességben, ami főleg nagy felbontásnál kritikus, a single link DVI sávszélesség határához közel.

Viszont a lényeg, hogy egy LCD monitor tipikusan tartalmaz saját belső framestore-t is. Ez ma már általában 1-nél több képet is tárol (response boost üzemmódoktól függően). Az LCD panel frissítése általában független időzítést követ a bemenő jeltől, leginkább fixen 60Hz-et. Vagyis ha eltérsz a 60Hz-es bementi üzemmódtól, akkor a kép laggolni, szaggatni fog, de a képfrissítés biztosan nem lesz jobb. Amelyik monitor mégis tudja az LCD frissítését a bemenethez igazítani, arra általában akkora betűkkel írnak rá valami vevővakítő feliratot (120Hz, 24Hz-compatible), hogy lelóg a csomagolásról.
---
Régóta vágyok én, az androidok mezonkincsére már!

Az LCD működési elvéből adódóan a vezérlőelektronikának folyamatosan frissíteni kell a képet és eközben ráadásul váltogatnia kell a feszültségeket pozitív és negatív között. Itt van részletesen leírva, hogy miért: http://techmind.org/lcd/, az inversion scheme részt kell elolvasni.

60Hz alá lényegesen nem tud lemenni a frissítéssel anélkül, hogy észrevehetően villogni kezdene a kép. A 24Hz-et natívan támogató monitoroknál is biztosan annak valami egésszámú többszörösével fog megjeleníteni. Ha a display processzor ügyes, akkor van egy tartomány, amin belül illeszteni tudja a bemenethez képfrissítést, ha nem, akkor mindig 60Hz-re fogja force-olni.

Másrészt a ma elterjedt response time compensation technikákat nehéz megcsinálni változó frissítési időre. Meg lehet oldani, de ez valami, amiért a gyártó plusz pénzt fog elkérni.

4-5 évvel ezelőttig (a 3d őrület, és emiatt a 120Hz-es monitorok megjelenése előtt) gyakorlatilag nem lehetett olyat találni, ami 60Hz-től eltérő képfrissítést értelmesen kezelte volna. Esetleg 30Hz-et tudtak kényszerből, ha olyan nagy volt a felbontás, ami nagyobb képfrissítéssel már nem fért át DVI-on.
---
Régóta vágyok én, az androidok mezonkincsére már!

Nekem viszonylag régebbi monitoraim vannak/voltak a kezeim között.
A legtöbb 75Hz-re input out of range-et ad. Némelyik Samsung tudja a 75Hz-es üzemmódot, hirdeti is magáról a grafkártya fele. Viszont határozottan rosszabb a kép vele, az egér cursor, ablakok mozgása jól láthatóan "darabosabb". Akkor vicces, amikor az X alapból a nagyobb képfrissítést akarja beállítani.

Új monitoroknál lehet, hogy jobb lesz a helyzet, de igazán garantáltan csak a 120Hz-et tudó típusoknál bízhatsz benne.
---
Régóta vágyok én, az androidok mezonkincsére már!

Én is anno nagyon nehezen szakadtam el a CRT-től. Kontrasztja, dinamikája miatt nagyon sokáig vártam az LCD-re váltással, és akkor is rögtön PVA panelessel kezdtem, ami legalább valamelyest értelmes kontrasztot tud produkálni. De képélességben az LCD verhetetlen, nem kell szarakodni konvergenciával, fókusz, moire állítással, majd bemelegedés közben elmászó paraméterek miatti újrabeállítással. Márpedig 21"-on, 1600x1200 és afelett ezeket már állítgatni kellett, mert eléggé zavaróak tudtak lenni az apróbb képhibák is.
Na szóval ez a része nem hiányzik a CRT-nek.
---
Régóta vágyok én, az androidok mezonkincsére már!

Én sem, csak puszta kíváncsiság részemről. Ugye az Xorg állítása mindig szívás volt, ha az automatikusan felismerttől eltérőt szerettünk volna beállítani (felbontás vagy frekvencia). Volt rá suse-n sax vagy milyen nevű tool (de lehet rosszul emlékszem). Szóval csak kíváncsiság, hogy waylanddel is ennyi szívás lenne-e? Illetve a beállításoknál hozni fog-e értelmes értékeket? Pl. egy nagy HD TV-nél azért ajánljon fel a max-on kívül is megfelelő arányú felbontást, hogy ha kevesebb pixelen akarnak játszani stb.

Jól emlékszel (SaX2-ig jutottak), sőt, a múltkor volt a kezemben egy Novell-es SuSE (11-es, de nem a legutolsó SP-vel, bár azt hiszem abban is ott van) és abban még megtaláltam a Yast modulok közt, alapbeállításon telepítve :) [https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&ver…]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ebben mi a pláne? A Jollám tavaly ősz óta tudja. ;)

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

Kíváncsi vagyok ubuntuék mikor lépnek meg egy hasonlót a mirrel végre...

Persze, de mégiscsak mutatja hogy közép- ill. hosszútávon a fejlesztők melyik úton akarnak tovább haladni.

Ráadásul merem feltételezni, hogy csak egy hozzáértő, tudatos kisebbség foglalkozik a telepítés testreszabásával, míg az átlag Linux-használó hagyja úgy, ahogy alapból feltelepül. Nyilván ez minden másra is igaz "egyszerű fogyasztók" esetében.

Most mutatkozott volna be a 14.04-ben, de voltak vele még problémák (pl. multimonitor támogatás), ami miatt elhalasztották, valószínűleg a következőben már benne lesz, de ez leghamarabb nyáron derül ki.
Egyébként úgy tudom, hogy a Mir előrébb jár, mint a Wayland.

Én is ezen a véleményen voltam. Nem értettem miért nem egyesítik inkább az erőforrásokat. Aztán olvastam egy interjút Mark Shuttleworthről, amiben kifejtette, hogy miért távolodtak el a Waylandtől. A lényeg az volt, hogy technikai csapat döntése volt ez, mert szerintük a Wayland kódja nem volt megfelelő minőségű. A TDD hiányát emlegette.
Össze lehet hasonlítani:
http://cgit.freedesktop.org/wayland/wayland/tree/tests
http://bazaar.launchpad.net/~mir-team/mir/utopic/files/head:/tests/

Én úgy vagyok vele, hogy győzzön a jobbik megvalósítás.

A zárójelek elhagyása önmagában nem okoz debuggolást. De ha debuggolni kell, akkor esélyes, hogy megnehezíti a dolgod. Elég triviálisnak hangzik, de ezerszer belefut az ember olyanba, hogy eredetileg csak egy utasítást akart végrehajtani az ifben, aztán hozzáírt mégegyet, de nem tette ki a zárójelpárt, stb. Erre a fordító nem figyelmeztet, egy hosszabb kódban viszont sokáig tarthat megtalálni.

Mondom, így elég banálisnak tűnik, de IRL nem biztos, hogy észreveszed.

"eredetileg csak egy utasítást akart végrehajtani az ifben, aztán hozzáírt mégegyet, de nem tette ki a zárójelpárt"

így van, ez a probléma gyökere... még ha van is automatikus kódformázás (mi eclipse-et használunk, bár nincs beállítva a fájl mentésekor az automatikus formázás, meg ha meg is formázza, nem biztos, hogy át fogja valaki nézni a commitot), simán benézheti az ember. Amióta mindig kirakom a kapcsos zárójeleket, azóta nem volt gondom...

http://stackoverflow.com/questions/359732/why-is-it-considered-a-bad-pr…


std::shared_ptr<mf::Connector> make_connector(
    std::string const& socket_name,
    std::shared_ptr<mf::ProtobufIpcFactory> const& factory,
    std::shared_ptr<mf::ConnectorReport> const& report)
{
    return std::make_shared<mf::PublishedSocketConnector>(
        socket_name,
        std::make_shared<mf::ProtobufSessionCreator>(
            factory,
            std::make_shared<mtd::StubSessionAuthorizer>(),
            mr::null_message_processor_report()),
        10,
        report);
}

WTF is this shit?

Az X.org-hoz nem értek, szóval ha Wayland tudja majd a monitor duplication/extended akkor nekem jó.
Inkább arra várok mikor lesz majd a Cinnamon az alapértelmezett ellenben a 'csodálatos' Gnome 3... :(
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

ebben teljesen igazad van, de miért nem adnak ki egy spin-t ahol a cinnamon a default?
van Gnome3, KDE4 vagy már 5 nem tudom, meg XFCE4 stb a többit meg rá kell húzni valamire.

--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/