X-Git-Url: https://code.delx.au/refind/blobdiff_plain/1b45ba3611945b291e468f1b5d3b5452f99766ba..e99aa7a04054658c8d5d4595717b9b10e848564d:/docs/refind/todo.html

diff --git a/docs/refind/todo.html b/docs/refind/todo.html
index 5919dbc..459f766 100644
--- a/docs/refind/todo.html
+++ b/docs/refind/todo.html
@@ -15,7 +15,7 @@
 href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 
 <p>Originally written: 3/14/2012; last Web page update:
-11/6/2012, referencing rEFInd 0.4.7</p>
+12/16/2012, referencing rEFInd 0.6.0</p>
 
 
 <p>I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!</p>
@@ -195,6 +195,26 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 
     <ul>
 
+    <li>When in Secure Boot mode, rEFInd can launch just one driver that's
+	signed with a shim key or MOK. The second and later drivers
+	generate "access denied" errors. <!-- I think this is because of
+	the fast-and-loose sample code I borrowed from shim, which re-uses
+	rEFInd's own image handle (the <tt>image_handle</tt> variable in
+	<tt>start_image()</tt>) for launching shim/MOK-signed binaries. The
+	result is that when the second driver is loaded, it can't register
+	itself with the firmware because the firmware believes it's already
+	been registered. The solution is likely to involve creating a child
+	image handle rather than re-using rEFInd's own image handle, but
+	this is likely to be tedious to do&mdash;see
+	<tt>/usr/local/UDK2010/MyWorkSpace/MdeModulePkg/Core/Dxe/Image/Image.c</tt>
+	for the reference UEFI implementation. --> </li>
+
+    <li>When setting a resolution higher than about 800x600 (or maybe even
+	640x480) in text mode, the text displayed by rEFInd, and on some
+	systems shells and other programs launched from rEFInd, is
+	restricted to an 80x24-character area in the top-left corner of the
+	screen.</li>
+
     <li>The <a href="http://www.rodsbooks.com/gb-hybrid-efi/">Gigabyte
 	Hybrid EFI</a> has a bug that causes the allegedly case-insensitive
 	<tt>StriCmp()</tt> function to perform a case-sensitive comparison.
@@ -246,14 +266,6 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 
     <ul>
 
-    <li>With the arrival of PCs preloaded with Windows 8 and with Secure
-	Boot enabled, some way to cope is in order. I'm thinking of adding
-	code to limit or prohibit booting of unsigned boot loaders if
-	rEFInd detects that Secure Boot is active, and link with the <a
-	href="http://mjg59.dreamwidth.org/18945.html">Shim</a>
-	pre-bootloader to help handle signing and authentication. I need to
-	research the technical details more, though.</li>
-
     <li>EFI supports network boots. rEFInd doesn't, but it would be nice if
 	it would.</li>
 
@@ -289,9 +301,6 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 	boot. Perhaps this could be done via a separate tool that could be
 	launched much like the shell or <tt>gptsync</tt>.</li>
 
-    <li>I'd like to give the user the ability to set custom options on a
-	single-boot basis, similar to what's possible in GRUB.</li>
-
     <li>A way to set the color of the font would be useful for theming
         purposes.</li>
 
@@ -303,20 +312,15 @@ href="mailto:rodsmith@rodsbooks.com">rodsmith@rodsbooks.com</a></p>
 	written in a cross-platform GUI toolkit, so that a single code base
 	can be used on any of the major OSes.</li>
 
-    <li>A way to "source" one configuration file from another one would be
-	helpful for some types of configuration scripts. (This would enable
-	overriding options in a secondary file without modifying the
-	default original file, for instance.)</li>
-
     </ul></li> <!-- New features -->
 
     <li><b>Improvements to the EFI drivers:</b>
 
     <ul>
 
-    <li>Drivers for additional filesystems are required. Given the recent
-	shift to ext4fs, that should be the priority; however, other Linux
-	filesystems, UDF, and perhaps others would all be welcome
+    <li>Drivers for additional filesystems are desirable. Given the talk of
+	shifting to Btrfs, that should be the priority; however, other
+	Linux filesystems, UDF, and perhaps others would all be welcome
 	additions. Also along these lines, adding drivers for Linux LVM and
 	RAID setups would be useful, too.</li>