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 430
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

  • 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