We used "rhgb" because that's what Fedora users were used to
instinctively removing when graphical boot messes up. This
isn't a very intuitive (or very upstream-y) name though.
Now we check for "rhgb" or "splash"
If we don't then someone during boot up may change
out from raw when we aren't looking.
Maybe we should use TIOCSLCKTRMIOS to prevent that
from happening? Or maybe we should bypass the tty
for input entirely and use evdev?
Previously ply-entry was crashing with an assertion "entry->loop == NULL"
whenever the entry was updated. The change is basicly a copy of the working
version from spinfinity.
This will play a sequence of images from beginning to end at
a fixed frame rate. It differs from the throbber in that it starts
at the 0th image and does not repeat.
With integer options there's no obvious value to mean "unset" like there is for
string types (and to a lesser extent boolean types), so this commit
adds a mechanism.
Hashtable uses the bitarray to mark the used/dead places in the hash data array.
The hashtable functions follow the general gist of the glib ones. To create a
hashtable you supply the hashing and comparison functions. Examples of direct
and string based indexing are supplied. Hashtable is a single word because there
is no hash_somethingelse but the name may change soon. Notice the compare
function returns a signed int difference rather than an equal bool. This is
because it may be an idea to later migrate the collision system to a tree
sub-structure (currently it is a linear array search with an incrementing step
size).
The new limit is 2^32. This only affects the replies to the client. Data sent
along with requests (e.g. password prompt) remain limited to <256 characters.
Two new functions have been added to the ply-utils (ply_read_uint32 and
ply_write_uint32) which receive/transmit 32bit numbers on FD streams.
AFAICT in function ply_boot_client_process_incoming_replies the answer was not
NUL terminated, which may have caused some of the password error bugs.
The "Rework input methods" commit broke the pausing of the progress bar during
password entry. This commit reimplements that functionality but this time the
pausing is optional, applied with a --pause-progress parameter. The client
program sends the (un)pause commands before/after the password requests.
The default is currently to not pause but that may change quite soon.
This also fixes a couple minor bugs and formatting from "Rework input methods".
Also changed "progress-pause" to "pause-progress" to make it more human
intuitive.
When asking for a password or a question, if the user presses Ctrl+C or Ctrl+D
the backend will reply a NULL. This is interprited as a "Stop asking me". The
client will not repeat the request (even if number of retries hasn't been
reached) and quit with an error exit_status.
Progress bar expansion was previously halted on password entry. Now the
progress can be halted whenever the system wishes. This can be useful when the
system notices there is a big task which is normally not present during normal
boots e.g. fsck.
Previously the splash plugins would deal with password entry, which would mean
that code was repeated and upon splash unload the password entry would be lost.
Now the keyboard strokes are processed with outside the splash, and the plugins
only deal with showing an appropriate user interface. As well as password
entry, the system can ask questions with non hidden text entry and sensing of
keystrokes.
In some instances, ply-buffer did not terminate the data block with a '\0'.
Doing so allows the data to be used as a string. Additionally it now tries
harder to deal with very long additions to the buffer by repeatedly expanding
the capacity and dealing with appends larger than the maximum buffer size.
free() allows NULL so there is no reason ply_image_free
shouldn't. This also papers over a bug in the solar
plugin that we haven't been able to identify yet.
