[syslinux] maximum resolution

[Nazo]

On 1/12/06, Murali Krishnan Ganapathy <gmurali at cs.uchicago.edu> wrote:
> Nazo wrote:
> > On 1/12/06, Murali Krishnan Ganapathy <gmurali at cs.uchicago.edu> wrote:
> >
> >> Nazo wrote:
> >>
> >>> On 1/11/06, Geert Stappers <stappers at stappers.nl> wrote:
> >>>
> >>>
> >>>> On Wed, Jan 11, 2006 at 06:20:02PM -0500, Andrey Vul wrote:
> >>>>
> >>>>
> >>>>> in isolinux, what's the maximimum text resolution (how many characters
> >>>>> per screen)?
> >>>>> i need to expand the f2 file and i don't know if the limit's been reached
> >>>>>
> >>>>>
> >>>> I never knew ISOLinux does switch text resolution. Neither didn't known
> >>>> that it can have different resolutions on different screens.
> >>>>
> >>>>
> >>>> Geert Stappers
> >>>> (missing the context of the original question)
> >>>>
> >>>> _______________________________________________
> >>>> SYSLINUX mailing list
> >>>> Submissions to SYSLINUX at zytor.com
> >>>> Unsubscribe or set options at:
> >>>> http://www.zytor.com/mailman/listinfo/syslinux
> >>>> Please do not send private replies to mailing list traffic.
> >>>>
> >>>>
> >>>>
> >>>>
> >>> Andrey is asking due to the fact that it can use images.
> >>> Unfortunately, Syslinux is unable to change resolutions as you
> >>> suspected.  In fact, what it actually does is use the default
> >>> 640x480x4 that is set by the VGA bios (so don't go setting it to EGA
> >>> or you may get troubles.)  The easiest solution for when you run out
> >>> of room on the F2 page is to make an F3 page.  Of course, you can
> >>> always create a module (I'm thinking complex menu would be a start)
> >>> and you could maybe do a bit using that, and, you can also boot
> >>> another bootloader like lilo (which seems to be able to support VESA,
> >>> though I don't really know how it does it since the only times I use
> >>> lilo are when an installer sets it up for me.)
> >>>
> >>>
> >> I wonder if something like this can be done?
> >>
> >> Extend the syntax of "F1 filename" to "F1 prog arg1 arg2 ....". If the
> >> user hits F1, then prog is launched with specified arguments. Ofcourse
> >> when only one word appears after F1 we default to current
> >> interpretation. We assume that "prog" is a well behaved program, i.e.
> >> either it does not switch text modes (preferred) or if it does switches
> >> back when control goes back to syslinux. If this is done, then one can
> >> write a small comboot code which displays the contents of a text file
> >> and allows the user to scroll through the text file.
> >>
> >> Extending this analogy even further, it might be cool to be able to
> >> assign shortcut keys to certain commands. But given the size constraints
> >> I dont know if it is a good idea. This might be possible if we had a
> >> comboot version of the current CLI. This way those who want to add
> >> features can just add it to the comboot and use their CLI.
> >>
> >> - Murali
> >>
> >> _______________________________________________
> >> SYSLINUX mailing list
> >> Submissions to SYSLINUX at zytor.com
> >> Unsubscribe or set options at:
> >> http://www.zytor.com/mailman/listinfo/syslinux
> >> Please do not send private replies to mailing list traffic.
> >>
> >>
> >>
> > Well, the usual argument is that these things can be done easily
> > enough with the menu systems.  As for more extended help, the argument
> > is that the only sure-fire proper way to do that would be to write a
> > COM32 module.
> >
> > You know, it strikes me that this sort of problem crops up rather
> > often.  I can't help but wonder if there isn't some way that someone
> > with more programming knowledge could come up with a sort of generic
> > COM32 help module that can parse some external file (I'm thinking it'd
> > be nicest if it didn't have to be xxxlinux.cfg since that means the
> > module will only work in the latest versions.)  Such a system would be
> > easy enough that those of us with less programming abilities can even
> > do it.  I'm kind of thinking something along the lines of a program
> > like less, or maybe even just more (funny how less is more, but, more
> > is less.)  d-:
> >
> >
> Yes. It is better for the menu system to support these features and let
> syslinux stick to what it does best.
>
> The complex menu supports context sensitive help (as long as each help
> screen is limited to a page). Currently the major shortcoming of the
> complex menu is that one needs to know some C programming to use these
> features. Eliminating that requirement is a long term goal, but for the
> short term I am working on a python script which reads a ".menu" file
> and generates the C program for you. It currently supports intricate
> menu systems, user authentication (and permissions on menu entries),
> checkboxes and context sensitive help. Eventually most things which can
> be done using a C program which is not dynamic in nature (eg. selecting
> a checkbox makes an invisible menu visible) should be do-able using just
> the .menu file. Hopefully this should satisfy the needs of most
> potential users of a menu system.
>
> - Murali
>
Wow, that does sound handy.  Now you've got my hopes up.  d-:  I hope
that you'll give us an announcement in the mailing list whenever you
come up with that.

BTW, I forgot to say, but, back on answering the poster's questions, I
should point out that the simple menu (menu.c32) does do shortcut keys
(at least, for selecting the item.)  I personally recommend to
everyone that I can that they at least try the simple menu because
it's so easy to integrate and will work on some quite old versions of
syslinux (actually, even the ones that don't support the menu commands
in the configuration will just spit out warnings of unknown lines but
they still go on despite that if I recall correctly.  At least, I
think that's what happened once when I tried menu.c32 on a really old
version.)