[syslinux] setting sound indicators for Isolinux menu selections

[Ady]

> Hi Ady,
> I appreciate your reply although I don't fully understand your thought on
> the use of the DISPLAY directive. The "^G" is as you assumed the ascii 7
> which sounds the system bell and I've found adding it to the first label
> statemt will beep the pc speaker when the menu loads. That will work as a
> bare minimum to let a blind user know the menu has loaded. I read something
> on the Grml blog greacently announcing their latest release had sound
> indicators for each menu item and I had hoped to implement something
> similar. I've also found that Grub can be configured to produce tones of
> different lengths for each menu item, but their approach won't work with
> syslinux/isolinux. Adding the ^G to each label statement doesn't help since
> syslinux only looks at the first instance. My thought is a global setting
> much like the menu color hotsel statement that highlights the active menu
> item. My understanding of "say" is that it will print text to the display
> although I'm unsure if "say ^G" would beep the pc speaker each time it is
> invoked. Further experimenting with "say" and maybe a look at how Grml has
> implemented thair sound indicators.
> 
> Best Regards,
> Jeff
> 
> -----Original Message-----
> From: syslinux-bounces at zytor.com [mailto:syslinux-bounces at zytor.com] On
> Behalf Of Ady
> Sent: Monday, February 25, 2013 2:16 PM
> To: syslinux at zytor.com
> Subject: Re: [syslinux] setting sound indicators for Isolinux menu
> selections
> 
> 
> > Hello,
> > I am an active member of the Vinux community and have taken on a 
> > project of remastering a Ubuntu installation Cd in order to make it 
> > accessable to a blind user. I am able to sound the system bell when 
> > the boot menu loads by adding a ^G to the label statement which works 
> > well to tell a blind user they are at the boot menu. My intent is to 
> > sound the bell at each menu item, but I'm unable to do so since I'm 
> > only able to use the hotkey once. My questions is, is it possible to 
> > set an "onselect" function that would sound the bell each time the 
> > selection changed? I'm looking at the "say" command but I'm unsure if 
> > that will accomplish my goal. Any suggestions would be greatly
> appreciated.
> > 
> > Thanks,
> > Jeff Malewski
> > 
> 
> I am just a simple user of Syslinux, so I cannot actually contribute to the
> question about new directives.
> 
> With your "^G" comment I guess you mean the ASCII 7 character in so-called
> DISPLAY files (those that are activated by F1-F12 keys or by the DISPLAY
> directive). For every ASCII 7 character in each display file, the speaker
> beeps. It seems this would not be an adequate solution to "beep on menu
> selection".
> 
> I have seen distros using Syslinux with GFXBoot where F1-F12 keys can
> perform (or trigger) an "action" (as oppose to just displaying a DISPLAY
> text file with no additional consequence), so maybe with such method there
> is a possibility to also add a beep (just as with ASCII
> 7) when a specific F1-F12 key is pressed. If more than one beep could be
> added, then the length of the beeps could potentially indicate which key was
> pressed.
> 
> Yet, that possibility would mean that a certain action was already
> triggered. Still under the "Syslinux with GFXboot" assumption, a two-step
> selection procedure might help. F1 key would make one beep and would load
> one specific config file. Pressing F1 key again would make an additional
> beep and would actually start the specific boot entry. But if the second
> time a different key would be pressed (say, F2), a different config file
> (corresponding to F2) would be selected and two beeps would sound (or a
> two-seconds beep). Now if F2 is pressed again, then the same sound is heard
> and the selected boot entry (which corresponds to F2) would load.
> 
> As we all could assume, all the above, even _IF_ possible - of which, I am
> not so sure - would not be as simple as what Syslinux usually offers, so
> probably a new set of directives that would trigger
> (different) sound(s) or different duration of beeps for each menu selection
> (in menu.c32 after each label directive, if an additional global directive
> is set) would probably be better.
> 
> Of course, "menu selected" is not the same as "some key was pressed", and
> "menu selected" doesn't mean the boot entry was actually triggered (yet).
> 
> I hope it makes some sense.
> 
> Best Regards,
> Ady.
 
 
Hi Jeff,

The DISPLAY and SAY directives are less useful when using menu.c32. 
The DISPLAY files can be presented with F1-F12 keys while using 
either CLI or [vesa]menu.c32, and each DISPLAY (F1-F12) file that 
contains the ASCII 7 character will beep once (when the respective Fx 
key is pressed), but they are probably not going to help in this 
case. As it is now, the only immediate utility for your case, as you 
already discovered, is that when the hardware first boots up and 
Syslinux is initially ready for the first user intervention, a beep 
will sound.

Regarding F1-F12 potentially generating sounds as part of other 
actions (like selecting a certain boot entry), it is not currently 
part of Syslinux. In the official Syslinux, F1-F12 can't perform 
'actions' (like selecting a boot option and making a sound), except 
for sending text (DISPLAY-format) files to the output. For F1-F12 to 
trigger other 'actions', GFXboot is needed AFAIK (and I don't really 
know much about it).

Now, I am not a developer, so the following are just potential ideas 
for some Syslinux developer / contributor to think about (and 
hopefully also to implement them in Syslinux).

A global directive, "SOUND 1" would allow all the other sound-related 
directives. By changing it to "SOUND 0", the other sound-related 
directives would have no effect (silence). This is most probably the 
_first_ directive to introduce regarding sounds in Syslinux. As an 
_initial_ approach only, it would trigger a sound (simple beep) for 
"every and any key" pressed in the boot menu.

Regarding global directives for sounds, indeed, similarly to the 
global MENU COLOR 'element' directives, a set of "MENU SOUND 
'element' directives would be useful. For example:
 MENU SOUND sel [some kind of code]
 MENU SOUND tab [some kind of code]

where 'sel' is "make a sound when a menu is 'selected' ", and where 
'tab' is "make a sound when the 'tab' key is pressed". Keys like 
[HOME], [END], [PGDN], [PGUP] and [ENTER] are also potential very 
useful 'elements' for such MENU SOUND global directives. There might 
be a need for an 'element' for "each and any key or any action", 
which would be overridden by other "MENU SOUND 'element'" directives 
for the keys and/or actions specified in the config file. The "[some 
kind of code]" part of the directive might indicate the type of 
beep(s), as used in BIOS POST for example (I have no idea if this is 
even possible), or it might only be zero/one (off/on) option, or a 
combination of codes for "on/off" and for a combination of different 
types (or duration) of beeps and silence in between.

But label-specific directives could also be useful.

Instead of using the same sound for every menu selection ("MENU SOUND 
SEL" directive), it could be useful to make one particular label make 
a (specific) sound when it is selected in the menu, while the other 
boot entries (labels) have a different sound (duration, type, cycles, 
tone,...).

An additional label-specific option could be _similar_ to the global 
"SOUND 1 | 0" I mentioned above, but in particular to a specific 
label. This is probably less useful, but maybe someone else can think 
of a practical case.

One additional _GLOBAL_ directive could be to automatically make one 
beep for the first row selection; then "one 
beep-silence-beep-silence" when the second row is selected; then "one 
beep-silence-beep-silence-beep-silence" for the third row... This 
series of beeps is just one possible example, and the type of beeps 
could be selected by this global directive too, while each row 
selection would mean additional cycles of the same type of beep(s).

As with the MENU COLOR directives, submenus would take the parent 
values for global sound-related directives with the possibility to 
change (override) them for each submenu.

The appropriate combination of all these potential (global and 
label-specific) directives could provide an adequate boot menu 
solution for those users that require sounds for adequate boot 
selection.

These are just some ideas from a user's perspective. A developer 
would need to take all this forward, starting from the global "SOUND 
1 | 0" proposed directive. I can only hope.

Best Regards,
Ady.