|
|
2008年老新闻 http://www.phoronix.com/scan.php ... g_wayland&num=1
2009年老新闻 http://www.phoronix.com/scan.php?page=news_item&px=NzUzMQ
Google Group https://groups.google.com/group/wayland-display-server
FAQ https://groups.google.com/group/ ... ly-askeds-questionsWhy fork the X server?
It's not an X server and not a fork. It's a minimal server that lets clients communicate GEM buffers and information about updates to those buffers to a compositor.
What is the license?
Wayland is licensed under the MIT license.
Why duplicate all this work?
Wayland is not really duplicating much work. Where possible Wayland reuses existing drivers and infrastructure. One of the reasons this project is feasible at all, is that I'm reusing the DRI drivers, the kernel side GEM scheduler and kernel mode setting. Wayland doesn't have to compete with other projects for drivers and driver writers, it lives within the X.org, mesa and drm community and benefits from all the hardware enablement and driver development happening there.
What is the drawing API?
What ever you want it to be, honey. Wayland doesn't get in the business of rendering, it expects the clients to use whatever means they prefer to render data into a GEM buffer and when it's done, inform the Wayland server of the new contents. The current test clients use either cairo software rendering or hardware accelerated OpenGL, but as long as you have a userspace driver library that will let you render into a GEM buffer, you're good to go.
Is wayland replacing the X server?
It could replace X as the native Linux graphics server, but I'm sure X will always be there on the side. I imagine that Wayland and X will coexist in two ways on a Linux desktop:
- Wayland is a graphics multiplexer for a number of X servers. Linux today typically only uses one X server for GDM and the user session, but we'll probably see that move to a dedicated GDM X server, an X server for user sessions (spawning more on the fly as more users log in) and maybe a dedicated screensaver/unlock X server. Right now we rely on VT switching to move between X servers, and it's horrible. We have no control over what the transitions look like and the VT ioctls are pretty bad. Wayland provides a solution here, in that it can host several X servers as they push their root window to Wayland as surfaces. The compositor in this case will be a dedicated session switcher that will cross-fade between X servers or spin them on a cube.
- Further down the road we run a user session natively under Wayland with clients written for Wayland. There will still (always) be X applications to run, but we now run these under a root-less X server that is itself a client of the Wayland server. This will inject the X windows into the Wayland session as native looking clients. The session Wayland server can run as a nested Wayland server under the system Wayland server described above, maybe even side by side with X sessions.
There's a number of intermediate steps, suchs as running the GNOME screen saver as a native wayland client, for example, or running a composited X desktop, where the compositor is a Wayland client, pushing the composited desktop to Wayland. Building and running Wayland
<img alt="" height="1" width="1">
These instructions assume some familiarity with git and building (autotools etc) and running experimental software. And be prepared that this project isn't at all useful right now, it's still very much a prototype. When the instructions suggest to clone a git repo, you can of course just add a remote and fetch instead, if you have a clone of that repo around already. I usually install all software I'm working on into $HOME/install, so that's what I'll use in the instructions below, but you can you your favorite directory of course.
Modesetting
At this point, the intel kernel modesetting isn't upstream, but it will be proposed for the 2.6.29 merge window. Getting modesetting support requires building a complete kernel, which is a bit of work and will take a while, but fortunately most distributions ship their kernel config file so it's easy to get started. The drm-intel-next branch in Eric Anholts kernel git repo has the latest modesetting bits which should work with Eagle and Wayland. Start out by cloning his tree and check out the modesetting branch:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git
$ git checkout -b drm-intel-next origin/drm-intel-next
For Fedora, the config file for the current kernel can be found over in /lib/modules/$(uname -r)/something so copy it over and start the build:
$ cd drm-2.6
$ cp /lib/modules/$(uname -r)/.../.config .
$ make oldconfig
$ make bzImage modules
If all that goes according to plan, you're ready to install the modules and the kernel. The kernel install process is designed to integrate with distro specific script that rebuild initrd, add grub entries and all that so it should be enough to just say:
$ sudo make modules_install install
Now is a good time to reboot and test that the modesetting works. The make install step above should have installed a new grub entry, so reboot and select that. Boot into runlevel 3 or if you boot into runlevel 5, change to a VT, log in as root and run
$ telinit 3
to switch to runlevel 3 and get rid of the X server. Then do
$ modprobe i915 modeset=1
to load the intel drm driver and watch it jump into graphics mode. If this does't work, you're in trouble as this is pretty hard to debug. You'll probably want to ssh in from a different machine, load the drm module manually with debug=1 and the watch the debug prints in dmesg.
Building mesa and libdrm
Check out libdrm from freedesktop first, build and install it:
$ git clone git://git.freedesktop.org/git/mesa/drm
$ cd drm
$ ./autogen.sh --help # Run only once to generate configure
$ ./configure --prefix=$HOME/install
$ make && make install
There's a small test application in libdrm/tests/modetest that will test the kernel/userspace API and print out a bit of info about the output and connectors currently configured on your graphics chip, and with the right option, it should show a blue test screen.
The Eagle EGL loader depends on a DRI driver extension that is not upstream yet. It is available on the eagle branch in my mesa repo on freedesktop.org:
$ git clone git://people.freedesktop.org/~krh/mesa
$ git checkout -b eagle origin/eagle
$ ./configure --prefix=$HOME/install
$ make && make install
Eagle and Wayland
We should be ready to build Eagle now. Check it out and build it:
$ git clone git://people.freedesktop.org/~krh/eagle
$ export PKG_CONFIG_PATH=$HOME/install/lib/pkg-config
$ ./configure --prefix=$HOME/install
$ make && make install
There's a test case in the wayland repo. If you've loaded the modesetting modules as above you should be able to run the 'test' application and see the well known gears spin. You will need to set two environment variables:
$ export LD_LIBRARY_PATH=$HOME/install/lib
$ export EAGLE_DRIVER_PATH=$HOME/install/lib/dri
If that works, pass go, collect $200 and proceed to building Wayland:
$ git clone git://people.freedesktop.org/~krh/wayland
$ make
Pick a background image that you like and copy it to the Wayland source directory as background.jpg or use the -b command line option:
$ ./wayland-system-compositor -b my-image.jpg
To get input devices working, you'll have to specify a file glob with the -i option that matches devices in /dev/input/by-path. Each glob will become an input group in Wayland, which corresponds to a pointer and a keyboard focus. So to setup multi-pointer Wayland run it like this:
$ ./wayland-system-compositor -i pci-usb-2*event* -i pci-usb-0.7*event*
or however your input devices are laid out. If you put all input devices (typically just a keyboard and a mouse) for one group on one hub it should be pretty easy to match with a glob. Look in /dev/input/by-path, but make sure you only add evdev type devices (those that are symlinks to a /dev/input/event* device).
If you want to run clients, your best bet is logging in remotely or blind typing as switching VT switches away from the Wayland frontbuffer and doesn't restore it when switching back. The three interesting clients at this point are 'window', 'flower' and 'screenshot'. And that's it. Wayland doesn't really do anything right now, there are no interesting clients to run, all you get after all this trouble is a mouse cursor, a half-assed terminal and glxgears in a pretty window.
X.org on Wayland
This assumes PKG_CONFIG_PATH is set as above.
$ git clone git://git.freedesktop.org/git/xorg/xserver
$ cd xserver
$ git checkout -b wayland origin/wayland
$ ./autogen.sh --prefix=$HOME/install
and build and install as usual. Then get the wayland branch of my xf86-driver-intel repo:
$ export ACLOCAL="aclocal -I~krh/install/share/aclocal"
$ git clone git://people.freedesktop.org/~krh/xf86-video-intel
$ git checkout -b wayland origin/wayland
$ ./autogen.sh --prefix=$HOME/install --enable-kms
Build and install the driver and then running X -wayland -noreset (with PATH and LD_LIBRARY_PATH set accordingly) should pop up an X server under wayland. If you want to run a second X server, add :1 to the X server command line arguments. You can then launch X clients under the display (possibly from the Wayland terminal) and watch them appear inside the X server. Alt-click to move the server when half-size, Alt-Enter to maximize the server. The server should support direct rendering GLX, including compiz and DRI2 and even xrandr does something reasonable (it resizes the server window).
此文档仅描述 intel 显卡情况。
已取得 KMS 支持的 ati nv 显卡能否使用，暂不清楚，至少偶没发现相应驱动，或许还没人开始写对应驱动。 |
|
IP卡
狗仔卡
发表于 2009-12-14 21:32:47
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主