linux-kernel - Re: [PATCH 24/41] Documentation: fb: fix spelling mistakes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5731A48C.4070004@ti.com>
Date:	Tue, 10 May 2016 12:06:20 +0300
From:	Tomi Valkeinen <tomi.valkeinen@...com>
To:	Eric Engestrom <eric@...estrom.ch>, <linux-kernel@...r.kernel.org>
CC:	Bernie Thompson <bernie@...gable.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Jonathan Corbet <corbet@....net>,
	<linux-fbdev@...r.kernel.org>, <linux-doc@...r.kernel.org>
Subject: Re: [PATCH 24/41] Documentation: fb: fix spelling mistakes

On 25/04/16 03:24, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom <eric@...estrom.ch>
> ---
>  Documentation/fb/udlfb.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt
> index 57d2f29..c985cb6 100644
> --- a/Documentation/fb/udlfb.txt
> +++ b/Documentation/fb/udlfb.txt
> @@ -9,7 +9,7 @@ pairing that with a hardware framebuffer (16MB) on the other end of the
>  USB wire.  That hardware framebuffer is able to drive the VGA, DVI, or HDMI
>  monitor with no CPU involvement until a pixel has to change.
>  
> -The CPU or other local resource does all the rendering; optinally compares the
> +The CPU or other local resource does all the rendering; optionally compares the
>  result with a local shadow of the remote hardware framebuffer to identify
>  the minimal set of pixels that have changed; and compresses and sends those
>  pixels line-by-line via USB bulk transfers.
> @@ -66,10 +66,10 @@ means that from a hardware and fbdev software perspective, everything is good.
>  At that point, a /dev/fb? interface will be present for user-mode applications
>  to open and begin writing to the framebuffer of the DisplayLink device using
>  standard fbdev calls.  Note that if mmap() is used, by default the user mode
> -application must send down damage notifcations to trigger repaints of the
> +application must send down damage notifications to trigger repaints of the
>  changed regions.  Alternatively, udlfb can be recompiled with experimental
>  defio support enabled, to support a page-fault based detection mechanism
> -that can work without explicit notifcation.
> +that can work without explicit notification.
>  
>  The most common client of udlfb is xf86-video-displaylink or a modified
>  xf86-video-fbdev X server. These servers have no real DisplayLink specific
> 

Thanks, queued for 4.7.

 Tomi



Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)