Frame-buffer 'resolution'?

[no.to...@gmail.com]

I've got a program which needs to run in FrameBuffer rather than
in X. mode.

After much effort, I eventually got it to run by setting grub to
"...vga=865 ro"

I've used it for a few months, but I'd like to have a 'bigger font'.
Not actually the 'font' but the 'magnification of the screen'.

If I set grub to:
"...vga=ask ro"
I'm able to select any one of <scan> plus 0,1..6.

What confuses me, is that, depending on my selection,
the boot-trace-font differs, but towards the end of the
boot process, just after <setting the rtc> and before 'login',
the font changes to the same, independant of my selection.

It's as if the font, and therefore perhaps the frame-buffer
selection is set to a default value. So I lose my original selection.

I've just realised, while writing this, that since the setting
"...vga=865 ro"
does NOT get lost/reset, if I could know a sequence of values to
test, besides "865", perhaps I could find a good setting.

It's an HP-netbook running Debian-Etch from a CompactFlash,
so there's no question about video-cards matching the screen.

How does this work?
What should I try?

==TIA.

[root]

Here are some modes to try:
Mode 0x0300: 640x400 (+640), 8 bits
Mode 0x0301: 640x480 (+640), 8 bits
Mode 0x0303: 800x600 (+800), 8 bits
Mode 773=0x0305: 1024x768 (+1024), 8 bits
Mode 775=0x0307: 1280x1024 (+1280), 8 bits
Mode 0x030e: 320x200 (+640), 16 bits
Mode 0x030f: 320x200 (+1280), 24 bits
Mode 0x0311: 640x480 (+1280), 16 bits
Mode 0x0312: 640x480 (+2560), 24 bits
Mode 0x0314: 800x600 (+1600), 16 bits
Mode 0x0315: 800x600 (+3200), 24 bits
Mode 791=0x0317: 1024x768 (+2048), 16 bits
Mode 792= 0x0318: 1024x768 (+4096), 24 bits is 32bits
Mode 794=0x031a: 1280x1024 (+2560), 16 bits
Mode 795=0x031b: 1280x1024 (+5120), 24 bits is 32bits
Mode 0x0330: 320x200 (+320), 8 bits
Mode 0x0331: 320x400 (+320), 8 bits
Mode 0x0332: 320x400 (+640), 16 bits
Mode 0x0333: 320x400 (+1280), 24 bits
Mode 0x0334: 320x240 (+320), 8 bits
Mode 0x0335: 320x240 (+640), 16 bits
Mode 0x0336: 320x240 (+1280), 24 bits
Mode 0x033d: 640x400 (+1280), 16 bits
Mode 0x033e: 640x400 (+2560), 24 bits
Mode 837=0x0345: 1600x1200 (+1600), 8 bits
Mode 838=0x0346: 1600x1200 (+3200), 16 bits
Mode 842=0x034a: 1600x1200 (+6400), 24 bits

[Thomas Richter]

Am 28.03.2012 11:52, schrieb no.to...@gmail.com:
> I've got a program which needs to run in FrameBuffer rather than
> in X. mode.

> What confuses me, is that, depending on my selection,
> the boot-trace-font differs, but towards the end of the
> boot process, just after<setting the rtc> and before 'login',
> the font changes to the same, independant of my selection.
>

> It's an HP-netbook running Debian-Etch from a CompactFlash,
> so there's no question about video-cards matching the screen.
>
> How does this work?
> What should I try?

Changing the console or rather setting it up is done by
/etc/init.d/console-setup, the configuration of which you find in
/etc/default/console-setup. Editing the latter file will provide you
with many options, including one that does not change the font.

HTHH,
Thomas

[no.to...@gmail.com]

- [snip]-

> Mode 837=0x0345: 1600x1200 (+1600), 8 bits

...

OK, thanks. I'll try one each time I reboot.

[no.to...@gmail.com]

OK, my Etch has got: /etc/init.d/console-screen.sh == ...
# Description: Set console screen modes and fonts
...
reset_vga_palette ()
{
if [ -f /proc/fb ]; then
# They have a framebuffer device.
# That means we have work to do...
echo -n ".]R"
fi
}
--------------------
The program I want to <change the look of>
runs in a framebuffer, and has its own fonts.
I want to magnify the whole screen/framebuffer.
I.e. change the resolution.

This video stuff seems quiet complex:
on my Slal13 installation, I've AGAIN lost the
CTRL ALT +/- ability to change resolution.

There seems to be a lot of files, which hold
configuration setting for the display.
And they are not yet coordinated/centralised ?

Thanks,
==Chris Glur.

[Thomas Richter]

Am 29.03.2012 11:39, schrieb no.to...@gmail.com:

> OK, my Etch has got: /etc/init.d/console-screen.sh == ...
> # Description: Set console screen modes and fonts

Probably you should use a non-deprecated distribution.

Anyhow, you'll see that "/etc/init.d/console-screen.sh" calls
/usr/bin/consolechars, and the options for calling are set in the init
file itself. Thus, "man consolechars" should you give the options you
have, and you could edit this file such that the console settings
match your requirements.

> There seems to be a lot of files, which hold
> configuration setting for the display.
> And they are not yet coordinated/centralised ?

Not beyond what was already said. But anyhow, the init files pretty much
tell you what is called when and where the configuration is taken from.

Greetings,
Thomas

[no.to...@gmail.com]

In article <jl1ntn$k5c$1...@news.belwue.de>, Thomas Richter <th...@math.tu-berlin.de> wrote:

> Am 29.03.2012 11:39, schrieb no.to...@gmail.com:
>
> > OK, my Etch has got: /etc/init.d/console-screen.sh == ...
> > # Description: Set console screen modes and fonts
>
> Probably you should use a non-deprecated distribution.
>

Ten [or 100] years ago, you also thought that "if I get the latest, I'll be OK".

> Anyhow, you'll see that "/etc/init.d/console-screen.sh" calls
> /usr/bin/consolechars, and the options for calling are set in the init
> file itself. Thus, "man consolechars" should you give the options you
> have, and you could edit this file such that the console settings
> match your requirements.
>

OK, I'll read "man consolechars", but it was solved for me thus:
using a table of: V*H*bits-per-pixel, select a smaller resolution
and convert the hex-to-decimal; and live-edit grub to
<kernel-line> vga=<decimal> ro

Interestingly, 8-bits-per-pixel, gives 'bad' colours.
My app has it's own fonts.
It's the resolution that I needed to change.
Apparently, for frame-buffer that can only be done before full boot.
But related to that: NOW my Slak:PC has lost 'Ctrl/Alt/+- zoom'
capability [under X].
So if X can do 'live-zoom', why can't frame-buffer?

> > There seems to be a lot of files, which hold
> > configuration setting for the display.
> > And they are not yet coordinated/centralised ?
>
> Not beyond what was already said. But anyhow, the init files pretty much
> tell you what is called when and where the configuration is taken from.
>

-> locate init | wc -l == 581 on Slak13-derivative, partial Etch will be less.

> Greetings,
> Thomas

[Johann Klammer]

no.to...@gmail.com wrote:
> So if X can do 'live-zoom', why can't frame-buffer?

Tried fbset yet (and their own version of modelines)?

I think VGA framebuffer uses the realmode software interrupts
to set modes (like archaic DOS games did...). These only work with real
mode as they basically execute code in the video BIOS. I think there's a
way to emulate those SW interrupts from protected mode (where LINUX
runs). But I do not know if fbset uses that feature, so it may not
actually work...

The X drivers are more hardware specific and usually know where the
cards registers are and what they do...

Greets,
JK

[Aragorn]

On Saturday 31 March 2012 13:38, Johann Klammer conveyed the following
to alt.os.linux.debian...

> I think VGA framebuffer uses the realmode software interrupts
> to set modes (like archaic DOS games did...).

That is correct.

> These only work with real mode as they basically execute code in the
> video BIOS. I think there's a way to emulate those SW interrupts from
> protected mode (where LINUX runs). But I do not know if fbset uses
> that feature, so it may not actually work...

32-bit Linux uses V86 ("virtual 86") mode to emulate real mode for those
instructions, but I don't know how it is done in (x86-)64-bit Linux,
given that 64-bit long mode does not support V86 anymore.

I can't seem to find any documentation on the exact mechanism x86-64
uses for initializing the video adapter, and I don't /speak/ C so
examining the source code of the kernel is no option. :-/

--
= Aragorn =
(registered GNU/Linux user #223157)