Update README to match changes to display.

README

@@ -428,7 +428,7 @@ Q quits the application.
 
 G gives you something like:
 
-GPU 0: [124.2 / 191.3 Mh/s] [Q:212  A:77  R:33  HW:0  E:36%  U:1.73/m]
+GPU 0: [124.2 / 191.3 Mh/s] [A:77  R:33  HW:0  U:1.73/m  WU 1.73/m]
 Temp: 67.0 C
 Fan Speed: 35% (2500 RPM)
 Engine Clock: 960 MHz
@@ -461,17 +461,17 @@ dedicated to this program,
 	http://forum.bitcoin.org/index.php?topic=28402.0
 
 The output line shows the following:
-(5s):1713.6 (avg):1707.8 Mh/s | Q:301  A:729  R:8  HW:0  E:242%  U:22.53/m
+(5s):1713.6 (avg):1707.8 Mh/s | A:729  R:8  HW:0  U:22.53/m  WU:22.53/m
 
 Each column is as follows:
 5s:  A 5 second exponentially decaying average hash rate
 avg: An all time average hash rate
-Q:   The number of requested (Queued) work items from the pools
 A:   The number of Accepted shares
 R:   The number of Rejected shares
 HW:  The number of HardWare errors
-E:   The Efficiency defined as number of shares returned / work item
 U:   The Utility defined as the number of shares / minute
+WU:  The Work Utility defined as the number of diff1 shares work / minute
+     (accepted or rejected).
 
  GPU 1: 73.5C 2551RPM | 427.3/443.0Mh/s | A:8 R:0 HW:0 U:4.39/m
 
@@ -486,11 +486,10 @@ The number of hardware erorrs
 The utility defines as the number of shares / minute
 
 The cgminer status line shows:
- ST: 1  SS: 0  DW: 0  NB: 1  LW: 8  GF: 1  RF: 1  WU:4.4/m
+ ST: 1  SS: 0  NB: 1  LW: 8  GF: 1  RF: 1  WU:4.4/m
 
 ST is STaged work items (ready to use).
 SS is Stale Shares discarded (detected and not submitted so don't count as rejects)
-DW is Discarded Work items (work from block no longer valid to work on)
 NB is New Blocks detected on the network
 LW is Locally generated Work items
 GF is Getwork Fail Occasions (server slow to provide work)
@@ -897,12 +896,6 @@ A: The defaults are sane and safe. I'm not interested in changing them
 further. The starting fan speed is set to 50% in auto-fan mode as a safety
 precaution.
 
-Q: Why is my efficiency above/below 100%?
-A: Efficiency simply means how many shares you return for the amount of work
-you request. It does not correlate with efficient use of your hardware, and is
-a measure of a combination of hardware speed, block luck, pool design and other
-factors
-
 Q: What are the best parameters to pass for X pool/hardware/device.
 A: Virtually always, the DEFAULT parameters give the best results. Most user
 defined settings lead to worse performance. The ONLY thing most users should
@@ -929,9 +922,10 @@ penalty on generating new binaries. It is recommended to not use this SDK at
 this time unless you are using an ATI 7xxx card that needs it.
 
 Q: Which ATI SDK is the best for cgminer?
-A: At the moment, versions 2.4 and 2.5 work the best. If you are forced to use
-the 2.6 SDK, the phatk kernel will perform poorly, while the diablo or my
-custom modified poclbm kernel are optimised for it.
+A: At the moment, versions 2.4 and 2.5 work the best for R5xxx and R6xxx GPUS.
+If you are need to use the 2.6+ SDK ofr R7xxx or later, the phatk kernel will
+perform poorly, while the diablo or my custom modified poclbm kernel are
+optimised for it.
 
 Q: I have multiple SDKs installed, can I choose which one it uses?
 A: Run cgminer with the -n option and it will list all the platforms currently
@@ -960,7 +954,7 @@ with -g 1. It is also recommended to use --failover-only since the work is
 effectively like a different block chain. If mining with a minirig, it is worth
 adding the --bfl-range option.
 
-Q: Are kernels from other mining software useable in cgminer?
+Q: Are OpenCL kernels from other mining software useable in cgminer?
 A: No, the APIs are slightly different between the different software and they
 will not work.