Input rework

[Ray Strode]

Hi,

>
> As a replacement for "clearword", I went for "question"
> i.e."on_ask_question",
> "ask_question_handler", "question_answer_state"... To clarify things a
> little I differentiated "answer_state" to "password_answer_state" (to match
> question_answer_state).
Sounds good.

> I have already pushed the buffer fixups into git as they were unrelated.
Great.
> And the rest of the patch is here:
> http://www.cs.man.ac.uk/~brejc8/temp/input_method.patch
> Are you OK with it being pushed into the master?
Yup, looks good.
>
> I made a couple of scripts to try out logging in early using plymouth (log
> into the machine while it is still booting and then bypass the gdm login
> screen). Your idea of, once logged in it goes straight to a locked
> screensaver, is probably necessary too. It works very well. One feature I
> stumbled across was that if you have already typed in your password to
> decrypt a partition, if it is the same as your username password, you don't
> have to type it in. I would like to propose it as a feature for F11. Most of
> the required plymouth functionality is already there but it would require
> initscripts and gdm to be poked around a bit and also it requires quite a
> bit of testing. What do you think?
Well question is how to enable it...  It only makes sense to do some cases.
How are you gettng the password to pam?

We should probably use the automatic login path of gdm to use a pam
conversation that doesn't ask for password,
and to by pass the greeter entirely.

The idea of booting up and getting coffee and coming back to a loaded
session sounds nice though.

> I was also going to work on the following next (Do they sound ok?):
>
> - Add pause/unpause-progress commands to allow the initscripts to pause the
> progress if they know something slow is about to be performed. And remove
> the automatic pause on the password entry.
I think pause and unpause makes sense, but i'd still do it implicitly
for passwords,
since there's never a point where it makes sense to ask for a password and not
stop the clock.

> - Add show/hide-message to show any important messages that the user should
> see in any splash (Press 'I' for interactive startup, Press 'L' to login
> early...).
Oh, I see you want to make "L" do early login.  I don't know, I almost
fill like this is
the kind of setting most users would set once and want to keep on, so
it shouldn't
be a transient thing.

Not sure i'm warm to showing the "I" interactive startup message
either.  It's definitely a debug feature and I don't think we should
announce it.

I'd really like the startup splash to be

1) really short (boot up shouldn't ever be more than 10 seconds).
That's improving each release.
2) very simple.  More like a Cell phone splash than a traditional linux boot.

There are cases where we have to fall short of that (encrypted
filesystems, serial consoles, etc), and that's ok.  For the most
common cases, though, I'd like it to be something the user sees but
doesn't really think about.  Boot up should just be an uninteresting
implementation detail of getting to state where work can get done.
That's why it's got to be fast (which others like Arjan and Harald are
working on) and not have instructions.

That doesn't mean I'm against a --show-message command.  I just think
we shouldn't use it under default circumstances.

> - Fix the background to the text entry which calls erase from the draw label
> function. I was going to do this by drawing the text to a pixmap first and
> then later drawing to the framebuffer.
Sounds good. At some point in the near future I want to port plymouth
to use libdrm (with the current setup as a fallback) so we can get
multihead right.  When I do that the abstractions might change around
a little bit. Haven't figured out exactly what I'm going to do yet,
but I think it may make sense to make have general pixel buffers where
the framebuffer is just one (or more pixel buffers) that have been
told to scan out.  If we did have a ply_pixel_buffer_t object of some
sort then that might help for this case (it would also be good to use
in ply_image_t i guess).

--Ray