diff options
| author | Peter Hutterer <peter.hutterer@who-t.net> | 2010-11-09 16:31:30 +1000 |
|---|---|---|
| committer | Kristian Høgsberg <krh@bitplanet.net> | 2010-11-10 08:42:17 -0500 |
| commit | b97b28c339a94223119e122ab899f500d7a4bd9e (patch) | |
| tree | 7777d393bc2667cebaeca30558d6e22c705590c2 | |
| parent | 997ce64302482ba9958cbe784b44c548e42724ac (diff) | |
README: fix a few typos
And one in the main.tex spec document.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
| -rw-r--r-- | README | 6 | ||||
| -rw-r--r-- | spec/main.tex | 2 |
2 files changed, 4 insertions, 4 deletions
@@ -4,7 +4,7 @@ Wayland is a project to define a protocol for a compositor to talk to its clients as well as a library implementation of the protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X applications, or a wayland -client itself. The clients can be traditional appliactions, X servers +client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers. The wayland protocol is essentially only about input handling and @@ -64,7 +64,7 @@ libxkbcommon Wayland needs libxkbcommon for translating evdev keycodes to keysyms. There's a couple of repos around, and we're trying to consolidate the -development, but for wayland you'll need the repo from my get +development, but for wayland you'll need the repo from my git repository. For this you'll need development packages for xproto, kbproto and libX11. @@ -76,7 +76,7 @@ kbproto and libX11. cairo-gl -The Waland clients render using cairo-gl, which is an experimental +The Wayland clients render using cairo-gl, which is an experimental cairo backend. It has been available since cairo 1.10. Unless your distribution ships cairo with the gl backend enabled, you'll need to compile your own version of cairo: diff --git a/spec/main.tex b/spec/main.tex index 41e0367..8c512be 100644 --- a/spec/main.tex +++ b/spec/main.tex @@ -68,7 +68,7 @@ languages, but that hasn't been done at this point. The server sends back events to the client, each event is emitted from an object. Events can be error conditions. The event includes the object id and the event opcode, from which the client can determine -the type of event. Events are generated both in repsonse to a request +the type of event. Events are generated both in response to a request (in which case the request and the event constitutes a round trip) or spontanously when the server state changes. |