diff mbox

ui/ncurses: Periodically refresh display

Message ID 20170711051908.19301-1-sam@mendozajonas.com
State Rejected
Headers show

Commit Message

Sam Mendoza-Jonas July 11, 2017, 5:19 a.m. UTC
When connecting to IPMI or serial consoles quite often the user must hit
a key or exit and restart petitboot-nc to cause it to appear. This
occurs when the user connects after petitboot-nc has drawn the current
screen. This can be a little confusing to users, especially in text
screens where keys such as 'Enter' won't have an affect.
To add some user friendliness create a timer callback that every five
seconds re-draws the current screen automatically.

Signed-off-by: Samuel Mendoza-Jonas <sam@mendozajonas.com>
---
 ui/ncurses/nc-cui.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

Comments

Stewart Smith July 11, 2017, 11:29 p.m. UTC | #1
Samuel Mendoza-Jonas <sam@mendozajonas.com> writes:
> When connecting to IPMI or serial consoles quite often the user must hit
> a key or exit and restart petitboot-nc to cause it to appear. This
> occurs when the user connects after petitboot-nc has drawn the current
> screen. This can be a little confusing to users, especially in text
> screens where keys such as 'Enter' won't have an affect.
> To add some user friendliness create a timer callback that every five
> seconds re-draws the current screen automatically.

After having done the math on how slow I've seen some IPMI SoL
implementations, I think this should end up being fine, and even still
usable on effectively 9600bps with the worst case scenario of drawing.

Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Cyril Bur July 12, 2017, 1:05 a.m. UTC | #2
On Wed, 2017-07-12 at 09:29 +1000, Stewart Smith wrote:
> Samuel Mendoza-Jonas <sam@mendozajonas.com> writes:
> > When connecting to IPMI or serial consoles quite often the user must hit
> > a key or exit and restart petitboot-nc to cause it to appear. This
> > occurs when the user connects after petitboot-nc has drawn the current
> > screen. This can be a little confusing to users, especially in text
> > screens where keys such as 'Enter' won't have an affect.
> > To add some user friendliness create a timer callback that every five
> > seconds re-draws the current screen automatically.
> 
> After having done the math on how slow I've seen some IPMI SoL
> implementations, I think this should end up being fine, and even still
> usable on effectively 9600bps with the worst case scenario of drawing.
> 

I was wondering the same thing, I figured Sam knew what he was doing,
now that both Sam AND Stewart have come to a consensus, I'm not even
needed here.

Good day!

> Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com>
>
Sam Mendoza-Jonas July 12, 2017, 4:53 a.m. UTC | #3
On Wed, 2017-07-12 at 11:05 +1000, Cyril Bur wrote:
> On Wed, 2017-07-12 at 09:29 +1000, Stewart Smith wrote:
> > Samuel Mendoza-Jonas <sam@mendozajonas.com> writes:
> > > When connecting to IPMI or serial consoles quite often the user must hit
> > > a key or exit and restart petitboot-nc to cause it to appear. This
> > > occurs when the user connects after petitboot-nc has drawn the current
> > > screen. This can be a little confusing to users, especially in text
> > > screens where keys such as 'Enter' won't have an affect.
> > > To add some user friendliness create a timer callback that every five
> > > seconds re-draws the current screen automatically.
> > 
> > After having done the math on how slow I've seen some IPMI SoL
> > implementations, I think this should end up being fine, and even still
> > usable on effectively 9600bps with the worst case scenario of drawing.
> > 
> 
> I was wondering the same thing, I figured Sam knew what he was doing,
> now that both Sam AND Stewart have come to a consensus, I'm not even
> needed here.
> 
> Good day!

So I found out in testing this breaks the user experience in a hilarious
way - I may do a v2 on some UI refactoring I have going on in the
background, which will be neater and should avoid this issue.

> 
> > Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com>
> > 
> 
> _______________________________________________
> Petitboot mailing list
> Petitboot@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/petitboot
Stewart Smith July 12, 2017, 5:32 a.m. UTC | #4
Samuel Mendoza-Jonas <sam@mendozajonas.com> writes:
> On Wed, 2017-07-12 at 11:05 +1000, Cyril Bur wrote:
>> On Wed, 2017-07-12 at 09:29 +1000, Stewart Smith wrote:
>> > Samuel Mendoza-Jonas <sam@mendozajonas.com> writes:
>> > > When connecting to IPMI or serial consoles quite often the user must hit
>> > > a key or exit and restart petitboot-nc to cause it to appear. This
>> > > occurs when the user connects after petitboot-nc has drawn the current
>> > > screen. This can be a little confusing to users, especially in text
>> > > screens where keys such as 'Enter' won't have an affect.
>> > > To add some user friendliness create a timer callback that every five
>> > > seconds re-draws the current screen automatically.
>> > 
>> > After having done the math on how slow I've seen some IPMI SoL
>> > implementations, I think this should end up being fine, and even still
>> > usable on effectively 9600bps with the worst case scenario of drawing.
>> > 
>> 
>> I was wondering the same thing, I figured Sam knew what he was doing,
>> now that both Sam AND Stewart have come to a consensus, I'm not even
>> needed here.
>> 
>> Good day!
>
> So I found out in testing this breaks the user experience in a hilarious
> way - I may do a v2 on some UI refactoring I have going on in the
> background, which will be neater and should avoid this issue.

What are you doing *testing* things? There's your problem :)
Jeremy Kerr July 19, 2017, 1:49 a.m. UTC | #5
Hi Sam,

> So I found out in testing this breaks the user experience in a hilarious
> way - I may do a v2 on some UI refactoring I have going on in the
> background, which will be neater and should avoid this issue.

One other option would be to:

 - only start the interactive UI when input is received
 - before that, we just print the petitboot logs (possibly without
   ncurses), and possibly a 'hit any key' message

The advantage of this is that the ncurses startup doesn't happen until
there is an actual terminal connected, which can be queried for its
capabilities & size.

Cheers,


Jeremy
Sam Mendoza-Jonas July 19, 2017, 3:31 a.m. UTC | #6
On Wed, 2017-07-19 at 09:49 +0800, Jeremy Kerr wrote:
> Hi Sam,
> 
> > So I found out in testing this breaks the user experience in a hilarious
> > way - I may do a v2 on some UI refactoring I have going on in the
> > background, which will be neater and should avoid this issue.
> 
> One other option would be to:
> 
>  - only start the interactive UI when input is received
>  - before that, we just print the petitboot logs (possibly without
>    ncurses), and possibly a 'hit any key' message
> 
> The advantage of this is that the ncurses startup doesn't happen until
> there is an actual terminal connected, which can be queried for its
> capabilities & size.

That's a good idea (especially for something like a 'datacenter' mode
discussed elsewhere). On the other hand we still have a problem of users
disconnecting and reconnecting, eg. someone leaves a machine in
Petitboot, someone else connects and the screen is blank.
I suspect V2 will be a combination of both ideas :)

Cheers,
Sam
Stewart Smith July 19, 2017, 5:01 a.m. UTC | #7
Samuel Mendoza-Jonas <sam@mendozajonas.com> writes:
> On Wed, 2017-07-19 at 09:49 +0800, Jeremy Kerr wrote:
>> Hi Sam,
>> 
>> > So I found out in testing this breaks the user experience in a hilarious
>> > way - I may do a v2 on some UI refactoring I have going on in the
>> > background, which will be neater and should avoid this issue.
>> 
>> One other option would be to:
>> 
>>  - only start the interactive UI when input is received
>>  - before that, we just print the petitboot logs (possibly without
>>    ncurses), and possibly a 'hit any key' message
>> 
>> The advantage of this is that the ncurses startup doesn't happen until
>> there is an actual terminal connected, which can be queried for its
>> capabilities & size.
>
> That's a good idea (especially for something like a 'datacenter' mode
> discussed elsewhere). On the other hand we still have a problem of users
> disconnecting and reconnecting, eg. someone leaves a machine in
> Petitboot, someone else connects and the screen is blank.
> I suspect V2 will be a combination of both ideas :)

Just don't break my test scripts :)
diff mbox

Patch

diff --git a/ui/ncurses/nc-cui.c b/ui/ncurses/nc-cui.c
index fbc02b9..6332585 100644
--- a/ui/ncurses/nc-cui.c
+++ b/ui/ncurses/nc-cui.c
@@ -499,6 +499,25 @@  static int cui_process_js(void *arg)
 	return 0;
 }
 
+/*
+ * Refresh the current screen. This helps in cases where the user connects to a
+ * serial interface after the screen has already been drawn.
+ * Five seconds is a nice compromise between not having the user wait too long
+ * and over-stressing certain OEM's terrible IPMI implementations.
+ */
+static int cui_refresh_timeout(void *arg)
+{
+	struct cui *cui = cui_from_arg(arg);
+
+	nc_scr_unpost(cui->current);
+	nc_scr_post(cui->current);
+	redrawwin(cui->current->main_ncw);
+
+	waiter_register_timeout(cui->waitset, 5000, cui_refresh_timeout, cui);
+
+	return 0;
+}
+
 /**
  * cui_handle_resize - Handle the term resize.
  */
@@ -1104,6 +1123,8 @@  retry_start:
 	waiter_register_io(cui->waitset, STDIN_FILENO, WAIT_IN,
 			cui_process_key, cui);
 
+	waiter_register_timeout(cui->waitset, 5000, cui_refresh_timeout, cui);
+
 	if (js_map) {
 
 		cui->pjs = pjs_init(cui, js_map);