![]() ![]() The file is searched for in /usr/lib64/weston, or you can pass an absolute path. Load backend.so instead of the default backend. Options Weston core options -B backend.so, -backend= backend.so It has also its own X window manager where cursor themes and sizes can be chosen using XCURSOR_PATH and XCURSOR_SIZE environment variables. When the first X client connects, Weston launches a special X server as a Wayland client to handle the X client and all future X clients. Weston starts listening on a new X display socket, and exports it in the environment variable DISPLAY. XWayland is activated by instructing weston to load the XWayland module, see Examples. ![]() XWayland provides backwards compatibility to X applications in a Wayland stack. This X server will connect to a Wayland server as a Wayland client, and X clients will connect to the X server. XWayland requires a special X.org server to be installed. IVI-shell starts with loading ivi-shell.so, and then a controller module which may launch helper clients. In-vehicle infotainment shell is a special purpose shell that exposes a GENIVI Layer Manager compatible API to controller modules, and a very simple shell protocol towards clients. The shell consists only of the shell plugin fullscreen-shell.so. The other compositor does not need to handle any platform-specifics like DRM/KMS or evdev/libinput. This is primarily intended for running another compositor on Weston. Fullscreen shellįullscreen shell is intended for a client that needs to take over whole outputs, often all outputs. Desktop shell consists of the shell plugin desktop-shell.so and the special client weston-desktop-shell which provides the wallpaper, panel, and screen locking dialog. Desktop shellĭesktop shell is like a modern X desktop environment, concentrating on traditional keyboard and mouse user interfaces and the familiar desktop-like window management. This means that a client must be specifically written for a shell protocol, otherwise it will not work. ShellsĮach of these shells have its own public protocol interface for clients. Each connecting client has its own seat making it a cheap way to test multi-seat support. Access to the desktop is done by using the RDP protocol. The RDP backend runs in memory without the need of graphical hardware. This is a cheap way to test multi-monitor support of a Wayland shell, desktop, or applications. Weston shows up as a single desktop window on the parent server. The Wayland backend runs on another Wayland server, a different Weston instance, for example. It supports multiple monitors in a unified desktop with DPMS. The DRM backend uses Linux KMS for output and evdev devices for input. Weston also supports X clients via XWayland, see below. If your system supports the logind D-Bus API and the support has been built into weston as well, it is possible to start weston with just weston. not under X nor under another Wayland server), it should be done with the command weston-launch to set up proper privileged access to devices. When weston is started as the first windowing system (i.e. Two plugins are provided: the desktop shell, and the tablet shell. Weston supports fundamentally different graphical user interface paradigms via shell plugins. Weston has several backends as loadable modules: it can run on Linux KMS (kernel modesetting via DRM), as an X client, or inside another Wayland server instance. A Wayland server is a display server, a window manager, and a compositor all in one. Weston is the reference implementation of a Wayland server.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |