Re: Inconsistent behaviour of "keystatus" in a waiting loop

[Arbiel (gmx)]

Le 19/05/2015 05:39, Andrei Borzenkov a écrit :

Let me explain what I want to do.
Running a GNU/Linux system, I want  the user to set a grub environment
variable into
the grubenv environment block to instruct grub to perform a specific
task at next boot,
but only once, at that specific next boot.
When grub performs that specific task, it resets the environment
variable with a "save_env" statement.
Unfortunetaly, grub cannot write into a LVM partition neither in some
specific file systems
(btrfs, cpiofs, newc, odc, romfs, …).
So, if the save_env statement returns an error condition, I want grub to
1)instruct the user either to press "Ctrl" key to perform the task or
"Alt" to forget about it and boot normally and
2) wait until the user has got time to read and understand the
instructions and pressed the desired key.

> Ð’ Mon, 18 May 2015 22:24:00 +0200
> "Arbiel (gmx)" <address@hidden> пишет:
>
>> Hi
>>
>> I wish to have grub wait until the user has taken a specific action and
>> presses down a key, such as control, shift or alt keys to inform the
>> action has been taken. It's possible to test this with the keystatus
>> --<key> function.
>>
>> With the following lines
>>
>>     echo "Press Ctrl key down to go on." ;
>>     until keystatus --ctrl ; do true ; done ;
>>     echo "Ctrl key pressed down." ;
>>
>> grub seems to enter and endless loop. However, if the Ctrl key is
>> pressed before the "Press Ctrl key down to go on." message is displayed,
>> grub immediately exits the loop.
>>
> keystatus checks whether key state is "pressed". It has no way to know
> since when key is pressed. It does not check for transition, it checks
> for state. What behavior you expect when key is pressed before loop
> starts?
I do not expect anything else than what you explain : keystatus checking
the state
of the key in real time and returning it into a boolean value, true if
the key is down at the time of
the statement being executed, false if it is up.
It turns out that, if I press the key after the first message and so
after the first keystatus statement,
grub seems to loop endlessly, as if never finding the key to be down,
even if it really is down.
Whereas if I press the key before the first message, and keep it down
until the message has been
displayed, at the first occurence of the keystatus statement, the key is
checked down
and grub do not enter the loop and goes on with the "Ctrl key pressed
down." message.

>> With
>>
>>     until keystatus --alt ; do
>>         echo "Press Alt key down to go on" ;
>>         sleep -v 3 ;
>>         done ;
>>     echo "Alt key pressed down." ;
>>
>> grubs exits the loop, however after a delay which seems to increase with
>> the number of "Press Alt down to go on" displayed before the alt key is
>> pressed down.
>>
> Not sure I understand what do you mean or how is it different from the
> first example.
This second exemple differs from the first one in the fact that the loop
runs much
slower because of the echo statement. After a while whose duration seems
to depend on
the user reaction time, grub exits the loop.
So, I wondering whether there is a underlying timing problem, or some
additionnal statements to
perform to achieve that goal.
>
>> How can this behaviour be explained and what should I do to have grub
>> react at the pressing of the key ?
>>
> Loop while key is pressed; echo message; loop until key is pressed. But
> please note that in general it is not even guaranteed that terminal is
> capable of returning modifier status at all; so you should first check
> whether keystatus is supported on current input source(s), otherwise you
> will enter endless loop.
If the plateform is not able to check the status of the keys, what do
you suggest me
to do ?

signature.asc
Description: OpenPGP digital signature