[PATCH] capitalize wayland
--- architecture.html | 10 +- building.html | 6 +++--- faq.html | 10 +- index.html| 4 ++-- toolkits.html | 2 +- xserver.html | 6 +++--- 6 files changed, 19 insertions(+), 19 deletions(-) diff --git a/architecture.html b/architecture.html index dd51b7f..e5b5d14 100644 --- a/architecture.html +++ b/architecture.html @@ -15,7 +15,7 @@ h2Wayland Architecture/h2 -pA good way to understand the wayland architecture and how it is +pA good way to understand the Wayland architecture and how it is different from X is to follow an event from the input device to the point where the change it affects appears on screen./p @@ -91,9 +91,9 @@ point where the change it affects appears on screen./p /p p - In wayland the compositor emis/em the display server. We + In Wayland the compositor emis/em the display server. We transfer the control of KMS and evdev to the compositor. The - wayland protocol lets the compositor send the input events directly + Wayland protocol lets the compositor send the input events directly to the clients and lets the client send the damage event directly to the compositor: /p @@ -122,7 +122,7 @@ point where the change it affects appears on screen./p li As in the X case, when the client receives the event, it updates -the UI in response. But in the wayland case, the rendering +the UI in response. But in the Wayland case, the rendering happens in the client, and the client just sends a request to the compositor to indicate the region that was updated. /li @@ -138,7 +138,7 @@ point where the change it affects appears on screen./p p One of the details I left out in the above overview is how clients - actually render under wayland. By removing the X server from the + actually render under Wayland. By removing the X server from the picture we also removed the mechanism by which X clients typically render. But there's another mechanism that we're already using with DRI2 under X: emdirect rendering/em. With direct rendering, the diff --git a/building.html b/building.html index 84629b7..aa30e36 100644 --- a/building.html +++ b/building.html @@ -117,7 +117,7 @@ this often./p h2libxkbcommon/h2 pWayland needs libxkbcommon for translating evdev keycodes to keysyms. -For wayland 0.85 use libxkbcommon branch for-weston-0.85. For this you'll +For Wayland 0.85 use libxkbcommon branch for-weston-0.85. For this you'll need a development packages for macros./p @@ -214,7 +214,7 @@ systemd session support for weston-launch (how?) or add yourself to the pTo run clients, switch to a different VT and run the client from there. Or run it under X and start up the clients from a terminal window. There are a few demo clients available, but they are all -pretty simple and mostly for testing specific features in the wayland +pretty simple and mostly for testing specific features in the Wayland protocol: /p ul @@ -222,7 +222,7 @@ protocol: /p but works well enough for bash/li li'flower' draws a flower on the screen, testing the frame protocol/li - li'gears' glxgears, but for wayland/li + li'gears' glxgears, but for Wayland/li li'smoke' tests SHM buffer sharing/li li'image' loads the image files passed on the command line and shows them/li diff --git a/faq.html b/faq.html index 5e3c9ef..5589f52 100644 --- a/faq.html +++ b/faq.html @@ -58,7 +58,7 @@ buffer, you're good to go. /p -h3Is wayland replacing the X server?/h3 +h3Is Wayland replacing the X server?/h3 p It could replace X as the native Linux graphics server, but I'm sure @@ -87,7 +87,7 @@ 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, such as running the GNOME screen saver as a native wayland + steps, such 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. @@ -135,7 +135,7 @@ for it. /p -h3What about the overhead of running X on wayland?/h3 +h3What about the overhead of running X on Wayland?/h3 p If you're running a fullscreen X server, which pushes its root @@ -175,13 +175,13 @@ /p p - It is also possible to put a remoting protocol into a wayland + It is also possible to put a remoting protocol into a Wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the forwarding into the desktop compositor could let you export or share - a window on the fly with a remote wayland compositor, for example, a + a window on
Re: [PATCH] capitalize wayland
Sorry, I forgot to mention this is for wayland-web. On Sun, Jan 13, 2013 at 3:51 AM, Diego Viola diego.vi...@gmail.com wrote: --- architecture.html | 10 +- building.html | 6 +++--- faq.html | 10 +- index.html| 4 ++-- toolkits.html | 2 +- xserver.html | 6 +++--- 6 files changed, 19 insertions(+), 19 deletions(-) diff --git a/architecture.html b/architecture.html index dd51b7f..e5b5d14 100644 --- a/architecture.html +++ b/architecture.html @@ -15,7 +15,7 @@ h2Wayland Architecture/h2 -pA good way to understand the wayland architecture and how it is +pA good way to understand the Wayland architecture and how it is different from X is to follow an event from the input device to the point where the change it affects appears on screen./p @@ -91,9 +91,9 @@ point where the change it affects appears on screen./p /p p - In wayland the compositor emis/em the display server. We + In Wayland the compositor emis/em the display server. We transfer the control of KMS and evdev to the compositor. The - wayland protocol lets the compositor send the input events directly + Wayland protocol lets the compositor send the input events directly to the clients and lets the client send the damage event directly to the compositor: /p @@ -122,7 +122,7 @@ point where the change it affects appears on screen./p li As in the X case, when the client receives the event, it updates -the UI in response. But in the wayland case, the rendering +the UI in response. But in the Wayland case, the rendering happens in the client, and the client just sends a request to the compositor to indicate the region that was updated. /li @@ -138,7 +138,7 @@ point where the change it affects appears on screen./p p One of the details I left out in the above overview is how clients - actually render under wayland. By removing the X server from the + actually render under Wayland. By removing the X server from the picture we also removed the mechanism by which X clients typically render. But there's another mechanism that we're already using with DRI2 under X: emdirect rendering/em. With direct rendering, the diff --git a/building.html b/building.html index 84629b7..aa30e36 100644 --- a/building.html +++ b/building.html @@ -117,7 +117,7 @@ this often./p h2libxkbcommon/h2 pWayland needs libxkbcommon for translating evdev keycodes to keysyms. -For wayland 0.85 use libxkbcommon branch for-weston-0.85. For this you'll +For Wayland 0.85 use libxkbcommon branch for-weston-0.85. For this you'll need a development packages for macros./p @@ -214,7 +214,7 @@ systemd session support for weston-launch (how?) or add yourself to the pTo run clients, switch to a different VT and run the client from there. Or run it under X and start up the clients from a terminal window. There are a few demo clients available, but they are all -pretty simple and mostly for testing specific features in the wayland +pretty simple and mostly for testing specific features in the Wayland protocol: /p ul @@ -222,7 +222,7 @@ protocol: /p but works well enough for bash/li li'flower' draws a flower on the screen, testing the frame protocol/li - li'gears' glxgears, but for wayland/li + li'gears' glxgears, but for Wayland/li li'smoke' tests SHM buffer sharing/li li'image' loads the image files passed on the command line and shows them/li diff --git a/faq.html b/faq.html index 5e3c9ef..5589f52 100644 --- a/faq.html +++ b/faq.html @@ -58,7 +58,7 @@ buffer, you're good to go. /p -h3Is wayland replacing the X server?/h3 +h3Is Wayland replacing the X server?/h3 p It could replace X as the native Linux graphics server, but I'm sure @@ -87,7 +87,7 @@ 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, such as running the GNOME screen saver as a native wayland + steps, such 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. @@ -135,7 +135,7 @@ for it. /p -h3What about the overhead of running X on wayland?/h3 +h3What about the overhead of running X on Wayland?/h3 p If you're running a fullscreen X server, which pushes its root @@ -175,13 +175,13 @@ /p p - It is also possible to put a remoting protocol into a wayland + It is also possible to put a remoting protocol into a Wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server
Re: [PATCH] faq.html: fix typos
Awesome. Thanks Darxus. On Tue, Sep 18, 2012 at 12:58 PM, dar...@chaosreigns.com wrote: Done. When using git format-patch or git send-email to send these, you can use --subject-prefix web to indicate which repo the patch is for, resulting in, for example: Subject: Re: [PATCH web] faq.html: fix typos On 09/17, Diego Viola wrote: Could you guys merge this please? On Sat, Sep 15, 2012 at 12:02 PM, Diego Viola diego.vi...@gmail.com wrote: Signed-off-by: Diego Viola diego.vi...@gmail.com --- faq.html | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/faq.html b/faq.html index bff7fb4..1dbd69a 100644 --- a/faq.html +++ b/faq.html @@ -20,7 +20,7 @@ p It's not an X server and not a fork. It's a protocol between a compositor and its clients. The compositor sends input events to - the clients. The clients renders locally and then communicate video + the clients. The clients render locally and then communicate video memory buffers and information about updates to those buffers back to the compositor. /p @@ -124,9 +124,9 @@ (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've - been able to keep the X.org server modern by adding extension such + been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less - useful extension. But we can't ever get rid of the core rendering + useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to a optional code path. Getting to a point where the X @@ -146,7 +146,7 @@ server buffer fills the entire screen, the Wayland compositor can change the video scanout to source from the X server buffer and retreat into the background. The X server uses the standard X.org - DDX drivers, renders to directly to its pixmaps and its root window, + DDX drivers, renders directly to its pixmaps and its root window, and the path from X to hardware is exactly as a native X.org server. /p -- 1.7.12 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- If you would be a real seeker after truth, it is necessary that at least once in your life you doubt, as far as possible, all things. - Rene Descartes http://www.ChaosReigns.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] faq.html: fix typos
Could you guys merge this please? On Sat, Sep 15, 2012 at 12:02 PM, Diego Viola diego.vi...@gmail.com wrote: Signed-off-by: Diego Viola diego.vi...@gmail.com --- faq.html | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/faq.html b/faq.html index bff7fb4..1dbd69a 100644 --- a/faq.html +++ b/faq.html @@ -20,7 +20,7 @@ p It's not an X server and not a fork. It's a protocol between a compositor and its clients. The compositor sends input events to - the clients. The clients renders locally and then communicate video + the clients. The clients render locally and then communicate video memory buffers and information about updates to those buffers back to the compositor. /p @@ -124,9 +124,9 @@ (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've - been able to keep the X.org server modern by adding extension such + been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less - useful extension. But we can't ever get rid of the core rendering + useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to a optional code path. Getting to a point where the X @@ -146,7 +146,7 @@ server buffer fills the entire screen, the Wayland compositor can change the video scanout to source from the X server buffer and retreat into the background. The X server uses the standard X.org - DDX drivers, renders to directly to its pixmaps and its root window, + DDX drivers, renders directly to its pixmaps and its root window, and the path from X to hardware is exactly as a native X.org server. /p -- 1.7.12 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland web typo fix
Here another fix for a typo: https://github.com/diegoviola/wayland/commit/e7b764d7bc0e6f58c05d339b4417cc6396dad745 Thanks soreau_ On Wed, Sep 12, 2012 at 11:37 PM, Diego Viola diego.vi...@gmail.com wrote: Krh, I've found more typos, fix here: https://github.com/diegoviola/wayland-web/commit/5a23ad65d9b4243197358f6e032234dc176c3b80 Thanks for your hard work. Diego Viola On Wed, Sep 12, 2012 at 12:51 PM, Kristian Høgsberg hoegsb...@gmail.com wrote: On Wed, Sep 12, 2012 at 05:43:58AM -0400, Diego Viola wrote: Hi, I've just made this small fix for some typos in wayland-web git repo: https://github.com/diegoviola/wayland-web/commit/b47acadd45bdf59a4b9f65b8294f7bed224b01b7 Please merge it. :) Thanks, done. Kristian Thanks, Diego ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland web typo fix
Sorry for sending the last email with the same subject. The last typo was for the wayland repository, not wayland-web. Diego On Thu, Sep 13, 2012 at 12:13 AM, Diego Viola diego.vi...@gmail.com wrote: Here another fix for a typo: https://github.com/diegoviola/wayland/commit/e7b764d7bc0e6f58c05d339b4417cc6396dad745 Thanks soreau_ On Wed, Sep 12, 2012 at 11:37 PM, Diego Viola diego.vi...@gmail.com wrote: Krh, I've found more typos, fix here: https://github.com/diegoviola/wayland-web/commit/5a23ad65d9b4243197358f6e032234dc176c3b80 Thanks for your hard work. Diego Viola On Wed, Sep 12, 2012 at 12:51 PM, Kristian Høgsberg hoegsb...@gmail.com wrote: On Wed, Sep 12, 2012 at 05:43:58AM -0400, Diego Viola wrote: Hi, I've just made this small fix for some typos in wayland-web git repo: https://github.com/diegoviola/wayland-web/commit/b47acadd45bdf59a4b9f65b8294f7bed224b01b7 Please merge it. :) Thanks, done. Kristian Thanks, Diego ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Wayland web typo fix
Krh, I've found more typos, fix here: https://github.com/diegoviola/wayland-web/commit/5a23ad65d9b4243197358f6e032234dc176c3b80 Thanks for your hard work. Diego Viola On Wed, Sep 12, 2012 at 12:51 PM, Kristian Høgsberg hoegsb...@gmail.com wrote: On Wed, Sep 12, 2012 at 05:43:58AM -0400, Diego Viola wrote: Hi, I've just made this small fix for some typos in wayland-web git repo: https://github.com/diegoviola/wayland-web/commit/b47acadd45bdf59a4b9f65b8294f7bed224b01b7 Please merge it. :) Thanks, done. Kristian Thanks, Diego ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] fix typo
--- README |2 +- TODO |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README b/README index b8ad9b4..64904ed 100644 --- a/README +++ b/README @@ -12,7 +12,7 @@ buffer management. The compositor receives input events and forwards them to the relevant client. The clients creates buffers and renders into them and notifies the compositor when it needs to redraw. The protocol also handles drag and drop, selections, window management and -other interactions that must go throught the compositor. However, the +other interactions that must go through the compositor. However, the protocol does not handle rendering, which is one of the features that makes wayland so simple. All clients are expected to handle rendering themselves, typically through cairo or OpenGL. diff --git a/TODO b/TODO index c8dcbac..abdab31 100644 --- a/TODO +++ b/TODO @@ -1,8 +1,8 @@ Core wayland protocol - We need rotation information in the output (multiples of 90 - degress) and we'll need a way for a client to communicate that it - has rendered it's buffer according to the output rotation. The + degrees) and we'll need a way for a client to communicate that it + has rendered its buffer according to the output rotation. The goal is to be able to pageflip directly to the client buffer, and for that we need the client to render accordingly and the compositor needs to know that it did. -- 1.7.10.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
