Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
dominbik napisał(-a):
openbox? ;DD masz jakiś link może ??
git openbox i zobacz co się dzieje.
Offline
435
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:44:39)
Offline
Z tymi Openboksem (i podobnymi) będzie ciekawie. Obawiam się, że będzie to o wiele bardziej skomplikowane lub pozostanie skazany na XWayland.
Wikipedia napisał(-a):
Openbox is a free, stacking window manager for the X Window System, licensed under the GNU General Public License.
Wayland itself integrates a compositor and window manager stuff. The structure is totally different from the existing display servers. A traditional window manager is not needed for Wayland.
https://lists.ubuntu.com/archives/lubuntu-users/201 … t/005457.html
Wiki LXDE-Qt napisał(-a):
We did not develop our own window manager. Instead, we use Openbox. To support Wayland, we need to find a new one if we want to migrate to Wayland later.
http://wiki.lxde.org/en/LXDE-Qt
Ale można jakoś połączyć z Westonem:
Compositing window managers like Compiz, KWin (KDE) and Mutter (GNOME) are already working on directly using the Wayland protocol to become Wayland display servers / compositors.
krh is the creator of wayland. 2011-01-31
<krh> I thin the sample compositor could live on as a simple core compositor with a pluging architecture
<krh> *think
<krh> and then that would be the answer when people want to run awesome or openbox or such with wayland: write a plugin to implement that behaviour in the sample compositor
<Darxus> krh: Awesome and openbox being examples of non-compositing window managers?
<bnf> Darxus: yes
<krh> Darxus: it was more an example of standalone window managers without and entire desktop environment
<krh> s/and/an
<krh> so in general, to answer the question of "how will my favourite, stand-alone window manager work with wayland"
<krh> to say that they have to bring up egl on kms and read input from evdev is a bit harsh
<krh> and one path forward there could be to define a pluing architecture for the sample compositor that will allow those cases to carry over their unique behaviour without all that low-level bring up
<krh> it's very hand-wavey at this point
2012-04-11:
<MeanEYE> Are there plans for plugin support? More specific question would be: is it possible to port tiling window to use Wayland?
<krh> or a plugin to weston
<krh> shell.c is the DE for weston
<soreau> krh: So its possible weston could be the server and let a plugin be the wm?
<krh> soreau: that how it works now, there's just only shell.c
http://www.chaosreigns.com/wayland/plugins/
Ostatnio edytowany przez yossarian (2014-02-08 13:49:54)
Offline
nie pamiętam czy ktoś wrzucał; http://www.phoronix.com/scan.php?page=news_item&px=MTU5NTU
Offline
436
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:44:41)
Offline
yossarian napisał(-a):
Z tymi Openboksem (i podobnymi) będzie ciekawie. Obawiam się, że będzie to o wiele bardziej skomplikowane lub pozostanie skazany na XWayland.
Wikipedia napisał(-a):
Openbox is a free, stacking window manager for the X Window System, licensed under the GNU General Public License.
Wayland itself integrates a compositor and window manager stuff. The structure is totally different from the existing display servers. A traditional window manager is not needed for Wayland.
https://lists.ubuntu.com/archives/lubuntu-users/201 … t/005457.html
Wiki LXDE-Qt napisał(-a):
We did not develop our own window manager. Instead, we use Openbox. To support Wayland, we need to find a new one if we want to migrate to Wayland later.
http://wiki.lxde.org/en/LXDE-Qt
Ale można jakoś połączyć z Westonem:
......
http://www.chaosreigns.com/wayland/plugins/
Weston jest referencyjnym klientem Waylanda, każdy może na jego bazie zrobić coś swojego.
To chyba w przyszłości będzie kompozytor obrazu dla LXQT:
http://qt-project.org/wiki/QtWayland
Online
439
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:44:45)
Offline
Ja nie wierzę, że deweloperzy Openboxa, Fluxboxa i innych napiszą je zupełnie na nowo od podstaw.
Albo skorzystają z części Westona do dalszych swoich prac, albo dadzą sobie spokój i zostaną przy XWaylandzie by potem umrzeć śmiercią naturalną.
Offline
Ależ oczywiście, że wykorzystają kod Westona albo Qtwaylanda.
Po to te projekty powstały.
Weston z resztą, to razem kilka tys linii kodu, podobnie jak Wayland,
dlatego jest dużo prostszy w obróbce od Xorga.
Choć równie dobrze mogą sobie wziąść conieco z Kwina albo Muttera.
Ostatnio edytowany przez Jacekalex (2014-02-08 19:40:26)
Online
Na przykładzie menadżera plików spacefm mogę powiedzieć, że zrobienie aplikacji działającej pod wayland to jest dopisanie ok. 200 linijek kodu. Tylko aplikacja musi działać pod kontrolą gtk3. Openbox zaczął ciągnąć elementy gtk3 i pochodnych jak tłusty Amerykanin colę przez słomkę.
Offline
Aplikacje akurat nie mają z tym zbyt wiele wspólnego. I tak muszą one działać z jakimś menedżerem kompozycji: Weston, Kwin, Mutter etc. które wspólnie z Waylandem przejmują funkcje dzisiejszych menedżerów okien typu Opnebox.
Ostatnio edytowany przez yossarian (2014-02-08 20:16:45)
Offline
440
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:44:46)
Offline
443
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:44:52)
Offline
yossarian napisał(-a):
Ja nie wierzę, że deweloperzy Openboxa, Fluxboxa i innych napiszą je zupełnie na nowo od podstaw.
Albo skorzystają z części Westona do dalszych swoich prac, albo dadzą sobie spokój i zostaną przy XWaylandzie by potem umrzeć śmiercią naturalną.
W "innych" już sobie radzą:
* x11-wm/kwin-standalone [2]
Available versions: [m]**9999 {gles opengl}
Homepage: https://groups.google.com/group/razor-qt/msg/b1d21a0cb8b665a2
Description: KWin version that only depends on kdelibs
Razor-gt i od razu LXQT możesz odfajkować z tych innych. ;)
Ostatnio edytowany przez Jacekalex (2014-02-10 15:37:51)
Online
To akurat żaden nowy projekt tylko przebudowane zalezności zwykły Kwin, który z Waylandem nie będzie miał problemów:
I understand that people care about the dependencies and think this is important. I just don’t think it’s of any importance in a world where a movie needs significantly more data storage. Still we care about the dependencies and we are working on breaking down the dependency chain as part of the frameworks modularization efforts. One of the results of this is that we have documented dependencies nowadays. And we are working on getting the dependency to the Plasma framework as a runtime-only dependency over QtQuick, so that people can put together themeing for KWin which does not pull in any bits of the Plasma dependency. Help on that is appreciated :-)
A more relevant issue is the question of memory usage due to running KWin. Unlike disk storage, memory storage is still rather constraint. Unfortunately it’s very difficult to provide correct measurements on the memory usage of a single KDE application. KDE applications have many shared libraries (e.g. Qt). So if KWin is the only Qt application, the relative memory usage is higher than when using several Qt applications as for example in LXDE on Qt.
http://blog.martin-graesslin.com/blog/2013/11/kwin- … environments/
Ostatnio edytowany przez yossarian (2014-02-10 15:54:35)
Offline
Zgadza się, wykastrowany Kwin, żeby pasował do standardu Razor-qt.
Wywalili z niego wszystkie niepotrzebne wodotryski.
Równie dobrze mogli to zarejestrować jak nowy projekt, w README napisać, że bazuje na Kwin, ale widocznie chodzi o kompozytor obrazu dla RazorQt,
a nie o PR i gratulacje. ;)
Online
Skończy się biadolenie tych co chcą compiza. Będzie Kwin.
Offline
Compiz nie zginie.
Może Norfield/Norwood na razie przycichł, ale raczej mamy czekanie, aż się Wayland dorobi pełnego, natywnego OpenGL, bo przepisywanie Compiza na egl/gles, to cholernie ciężka praca.
Prawdopodobnie sprawa Compiza na Waylandzie się wyjaśni w okolicach Waylanda 1.8 - 2.2, o ile standardowy OpenGL pojawi się w wersji 2.0.
Także jestem spokojny, Beryl nie zdechł, tylko zapoczątkował Compiza, teraz też będzie ciąg dalszy.
Mamy tylko coś w rodzaju "okresu przejściowego".
Oczywiście zależy to też od sterów Nvidii i Amd/Ati,
bo na sterach z KMS do tych kart Compiz to średni pomysł.
Ostatnio edytowany przez Jacekalex (2014-02-10 17:10:59)
Online
444
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:44:53)
Offline
uzytkownikubunt napisał(-a):
Jacekalex napisał(-a):
Compiz nie zginie.
Może Norfield/Norwood na razie przycichł, ale raczej mamy czekanie, aż się Wayland dorobi pełnego, natywnego OpenGL, bo przepisywanie Compiza na egl/gles, to cholernie ciężka praca..W otwartych sterownikach masz teraz pełny, natywny OpenGL i komunikację przez protokół EGL i tak już zostanie, co najwyżej będą małe poprawki ile razy można pisać....
Może do momentu, jak w paczce mesy pojawi się biblioteka libwaylandgl.so.
Natywny OpenGL obok EGL był zapowiadany w okolicach Waylanda-1.0, kiedy okazało się, ze nie udało się przepisać biblioteki libglx, dlatego trzeba tą bibliotekę dla Waylanda napisać od nowa.
I nie "przez protokół EGL", bo nikt nie będzie przepisywał wszystkiego,
co chodzi na OpeGL, żeby nagle poszło na EGL, te standardy się różnią.
Tak samo, jak powstał Xwayland, tak samo ma być natywna biblioteka OpenGL dla Waylanda.
W okolicach wersji Waylanda 2.0 ma być gotowa (wtedy Wayland ma być gotowy do całkowitego zastąpienia Xorga).
Ostatnio edytowany przez Jacekalex (2014-02-10 18:55:27)
Online
509
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:46:18)
Offline
To teraz czekamy, aż w Linuxie zrobią to samo.
I wina nie jest w sterownikach grafy, bo np w Nvidii uprawienia do wszystkich urządzeń w /dev ma grupa video, tylko w inputach, tty7 i vga_arbiter,
a to akurat nie sterownik, tylko kernel.
ls -ld /dev/dri/card* /dev/nvidia* /dev/input/* /dev/tty7 /dev/vga_* crw-rw----+ 1 root video 226, 0 02-24 05:15 /dev/dri/card0 drwxr-xr-x 2 root root 100 02-24 05:17 /dev/input/by-id drwxr-xr-x 2 root root 100 02-24 05:17 /dev/input/by-path crw-r----- 1 root root 13, 64 02-24 05:15 /dev/input/event0 crw-r----- 1 root root 13, 65 02-24 05:15 /dev/input/event1 crw-r----- 1 root root 13, 66 02-24 05:15 /dev/input/event2 crw-r----- 1 root root 13, 67 02-24 05:15 /dev/input/event3 crw-r----- 1 root root 13, 68 02-24 05:15 /dev/input/event4 crw-r----- 1 root root 13, 69 02-24 05:15 /dev/input/event5 crw-r----- 1 root root 13, 70 02-24 05:15 /dev/input/event6 crw-r----- 1 root root 13, 71 02-24 05:15 /dev/input/event7 crw-r----- 1 root root 13, 72 02-24 05:15 /dev/input/event8 crw-r----- 1 root root 13, 73 02-24 05:15 /dev/input/event9 crw-r----- 1 root root 13, 63 02-24 05:15 /dev/input/mice crw-r----- 1 root root 13, 32 02-24 05:15 /dev/input/mouse0 crw-rw---- 1 root video 195, 0 02-24 05:15 /dev/nvidia0 crw-rw---- 1 root video 195, 255 02-24 05:15 /dev/nvidiactl crw--w---- 1 root tty 4, 7 02-24 05:15 /dev/tty7 crw------- 1 root root 10, 63 02-24 05:15 /dev/vga_arbiter
W Linuxie też się da (i to w Ubuntu):
https://wiki.ubuntu.com/X/Rootless
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2014-02-24 10:15:28)
Online
511
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:46:21)
Offline
Nouveau nie przeportowali?
Straszna wiadomość. :D
Nvidia - ster binarny też nie działa z KMS, a wręcz przeciwnie, żeby ster chodził, trzeba wyłączyć KMS.
Zrzucenie Xorga z roota rozbija się o uprawnienia urządzeń w /dev, przy czym wsio, co tworzy sterownik Nvidii ma uprawnienia root:video.
Z resztą, jak w jaju poprawią, to Nvidia też pewnie poprawi sterownik, zmiana uprawień ustawianych przez sterownik, to zmiana w kilku linijkach kodu.
Ostatnio edytowany przez Jacekalex (2014-02-24 11:07:52)
Online
513
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:46:23)
Offline