Wayland 1.3 i Weston 1.3 z udoskonaloną dokumentacją, obsługą libhybris i sprzętową...

Wayland 1.3 i Weston 1.3 z udoskonaloną dokumentacją, obsługą libhybris i sprzętową akceleracją przechwytywania obrazu

    przez -
    27 329
    Pulpit
    Kristian Høgsberg ogłosił wydanie Wayland 1.3 i Weston 1.3, protokołu systemu okien, który łączy w sobie menadżera kompozycji oraz system okien. Jest on swojego rodzaju protokołem dla kompozytora, który łączy się z klientami i posiada towarzyszącą mu bibliotekę implementującą, napisaną w języku C. Częścią projektu Wayland jest Weston, który jest implementacją kompozytora Waylanda. Weston może działać, jako klient X lub Linux KMS, i zapewnia kilka przykładowych klientów.

    Wayland 1.3:

    • Udoskonalono dokumentację
    • Dodano wsparcie dla pixel format z wl_shm
    • Dodano obsługę wielu źródeł
    • Dodano wsparcie dla dowiązywania języków
    • Dodano wsparcie w instalacji dla definicji XML głównego protokołu Waylanda
    • Pojawiła się wstępna wersja dodania łatek do obsługi dotyku, wskaźnika i klawiatury
    • Naprawiono sporo błędów

    Weston 1.3:

    • Dodano sprzętową obsługę akceleracji graficznej do przechwytywania obrazu, z użyciem biblioteki VA-API i kodowania H.264
    • Dodano wsparcie biblioteki libhybris z backendem fbdev, co pozwala używać Westona na Androidzie z użyciem sterowników EGL/GLES2
    • Pojawiła się obsługa wielu zdarzeń wejścia
    • Poprawiono obsługę dotyku
    • Dodano lepszą obsługę pełnego ekranu
    • Pojawiły się nowe możliwości weston-launch
    • Dodano wsparcie dla buforów klienta RGB565
    • Dodano nowy atrybut udev WL_OUTPUT dla porównywania wejścia i wyjścia urządzeń z ekranami dotykowymi
    • Dodano nowe opcje konfiguracji pliku Weston.ini
    • Dodano nowe opcje linii komend
    • Udoskonalono terminal

    Podobne artykuły

    KDE

    przez -
    0 572

    przez -
    0 466
    Pulpit

    przez -
    0 417
    • buba

      pliki .ini kojarzą mi się z windowsem

      • W KDE też takie masz, jak i w całym free desktop.

      • Razi

        Czy to ważne jakie rozszerzenie? Wymyślanie koła na nowo nie ma sensu.

      • riss

        Pliki INI są zazwyczaj bardzo dobre do przechowywania konfiguracji – przynajmniej nie jest to przerost formy na treścią.

      • O wiele lepsze by były binarne ze względu na wydajność wczytywania (szybsze uruchamianie). Ale z dwojga złego lepsze to niż XML.

      • Masz ciekawszą propozycję?

      • pijaczek

        Wspomniane przez Ciebie binarne pliki. Szybsze wczytywanie, mniejszy rozmiar plików… jednak pisanie dodatkowego edytora plików, wymyślanie struktury, walczenie z różnicami w wielkości zmiennych czy kolejnością bitów na różnych architekturach sprzętowych… to mimo, że gorsze technicznie pliki tekstowe są zdecydowanie wygodniejsze… i chociażby dlatego warto się kierować regułą KISS.

      • I tu dochodzimy do sensowności projektu o nazwie Rejestr Windows ;-)
        Kiedyś próbowano lansować do tego sqlite, ale każdy wie jak to jest z jego wydajnością.
        Można też ujednolicać binaria i stworzyć jeden edytor. Tylko, że jak znam świat Opin Surz, to wrzucą do formatu tyle możliwości kosztem wydajności i przejrzystości, że to się przestanie opłacać.

      • quest

        >Opin Surz

        Jak już to "Ołpen Sors".

        W ogóle skąd się wzięło to propagowanie własnej głupoty w ramach komentarzy? Już widziałem "wypok" (wykop.pl) i "krul" (Korwin-Mikke). Ludziom się wydaje, że rzucają ripostą, gdy piszą jak analfabeci?

      • Starość nie radość.
        Przekręcanie nazw to nie analfabetyzm tylko żarty. Często określające przynależność subkultury.

      • Razi

        Rejestr Windows jest po prostu bazą danych. Wadą tego rozwiązania była jednak jego „uniwersalność”. Jeden rejestr na cały OS i rosnąca niepotrzebnie baza, do tego ta specjalna właściwość, że się fragmentuje i nie podlega defragmentacji (bez użycia dodatkowych narzędzi). Wpisy są luźne i tak zostają, bo nie ma odgórnego zarządcy.

        Ujednolicić binaria i stworzyć jeden edytor? Pisałeś kiedyś aby hello worlda? Binariów nie ujednolicisz, nie na tyle żeby były uniwersalne i wydajne. Jak idziesz w stronę ujednolicenia, potrzebujesz tylu metadanych, że tracisz na wydajności. Nie, to nie ta strona. Tekstowy format pozwala na łatwą i szybką naprawę z zewnątrz. Jak się w Linuksie środowisko graficzne zepsuje to włączasz konsolę i naprawiasz konfigi (albo usuwasz, niech wczyta defaulta). Na Windowsie jak ci się tryb awaryjny nie włącza (a miałem wiele takich sytuacji) to robisz formata, bo nawet z LiveCD niewiele zrobisz, bo te konfigi siedzą w plikach binarnych których formatów nie znasz albo w rejestrze cholera-wie-pod-jakim-kodem.

        Poza tym przy takich plikach operacja parsowania go to zaledwie niewielki procent jego wczytania – najdłużej trwa oczekiwanie na HDD. To naprawdę nie ma znaczenia czy to plik binarny czy tekstowy, procesory są na tyle szybkie że różnice widać tylko na benchmarkach z dokładnością do nanosekund.

      • pijaczek

        Ujednolicić binarki do konfiguracji się ofc da… czyli bardzo uniwersalne SQLite lub My/PostgreSQL… można też wykorzystać mniej uniwersalne bazy NoSQL, a dokładniej bazy klucz-wartość (tak jak rejestr windowsa). Są to ogólnie stosowane rozwiązania (wszystkie) i sprawdzają się świetnie… ofc o ile każdy program ma własną bazę (własny mały plik z bazą – sporo desktopowych programów i praktycznie wszystkie pod Androidem (każdy program może na konfigurację wykorzystać własną lokalną dla siebie bazę key-value i SQLite)), a nie system i każdy istniejący program w systemie jest w jednej bazie (rejestr Windowsa).

        Ogólnie takie sposoby zapisu są… średnie. Tzn wymaga dodatkowego oprogramowania do edycji ich (nawet standardowych baz pod konsolą w edytorze tekstu nie zedytujesz, a może być taka potrzeba… szczególnie przy konfiguracji serwera wyświetlania, jeśli nie działa). Wydajność jest wyższa ofc niż w wypadku plików tekstorych (SQLite wcale taki wolny nie jest i zdecydowanie wydajniej działa niż przetwarzanie plików tekstowych), ale do binarnego pliku dostosowanego do programu gdzie wystarczy jedno memcpy aby wszystko odczytać z pliku i mieć już w strukturach programu daleko. Ze względu jednak na to, że wydajność w odczycie przy starcie pliku tekstowego nie ma wielkiego znaczenia (przynajmniej w tego typie oprogramowania), a łatwość edycji konfiguracji, przy praktycznym braku narzędzi jest bardzo ważny to pliki tekstowe są najlepszym wyjściem. Ja w wielu moich programach gdzie konfiguracja wygląda jak relacyjna baza danych, a przy okazji zapisuję tam dane doczytywane na żądanie w czasie działania programu to wykorzystuję SQLite, do konfiguracji scen/materiałów/shaderów… stosuje dostosowane do struktur pliki binarne szyte na miarę, ale w wypadku serwera wyświetlania po prostu najlepszą opcją jest plik tekstowy i zalety innych rozwiązań można olać przy zalecie plików tekstowych czyli łatwego dostępu do zawartości.

      • Najlepszym rozwiązaniem według mnie jest JSON.

      • pijaczek

        IMO JSON jest najgorszą opcją… już lepszy XML, mimo że to druga opcja nie warta rozważania opcja.

      • MikolajS

        "IMO JSON jest najgorszą opcją… już lepszy XML"
        Chyba tylko z powodu braku w innych językach niż JS dobrych bibliotek do jego obsługi. JSON jest o wiele czytelniejszy.

      • pijaczek

        Czytelniejszy może (niewiele i to też zależy), ale przetwarzanie go to katorga i nie można wybrać sobie tylko wybranej rzeczy do odczytania przy przetwarzaniu, a trzeba przetworzyć zawsze cały… tu już XML jest lepszy, który ma identyfikatory wszystkiego i można przeskoczyć do przetwarzania tylko małej części pliku.

      • Trzeba wymyślić JSONpath ;-)

      • pijaczek

        I mieć niższą czytelność niż w XML przy braku nad nim zalet… super, ale ani JSON, ani XML nie są dobrym rozwiązaniem.

      • MikołajS

        "ale przetwarzanie go to katorga"
        Nie w JavaScript ;)

      • Nie wiem czemu się uparliście, że to musi być graficzny edytor. Oczywiście może.
        Edytor można napisać w ncurses z wygodną wyszukiwarką kluczy. Można go napisać nawet tak, by pracował w terminalu. Też będzie to wygodne. Równie dobrze można się czepiać, że DBus nie wysyła danych tekstowych.

        Razi: Z tym brakiem ujednolicania pokazałeś, to co chciałem napiętnować. Pijaczek wspomniał niedawno o KISS.

      • Procesory mają taką wydajność, że najbardziej to się opłaca trzymać na dysku skompresowane grupy plików, bo mniejsza ilość danych z dysku w jednym sekwencyjnym odczycie jest więcej warta niż czas dekompresji.

      • pijaczek

        Czas odczytu plików konfiguracyjnych jest zupełnie bez znaczenia, przy przykładowo fragmentacji bazy (przez co rejestr windowsa jest tak do dupy). Ofc na dyskach talerzowych przestawienie głowicy na plik w innym miejscu dysku to kilka ns stracone, jednak program odczytuje taki plik przy starcie i te kilka ns nie jest warte tego, aby wszystkie pliki konfiguracyjne wszystkich programów trzymać w jednym miejscu. OFC lepiej dla programu kiedy wszystkie swoje assety razem z plikami konfiguracyjnymi ma spakowane do VFS i siedzi na dysku w jednym miejscu (jak to przykładowo robią praktycznie wszystkie gry), jednak w wypadku wolnego oprogramowania, zazwyczaj nie wydajność jest priorytetem, a to, żeby do wszystkich plików i zasobów był łatwy dostęp (nie przez montowanie VFS pod katalog przez FUSE, a po prostu bezpośredni dostęp do plików).

      • Wiem, napisałem tylko co jest bardziej optymalne.
        Dyski mechaniczne mają czas dostępu w milisekundach. Obecnie około 4ms. Domyślam się, że w cache dysku ląduje od razu cały cylinder.
        Kompresję kilku plików z załącznikami stosuje też format ODF.

      • Z resztą dziś nawet RAM się kompresuje.

      • Wintel Outside