Frame buffer console resolution on Alpha [SOLVED]

Altivo · Last edited by Altivo on Wed Aug 12, 2015 2:40 am; edited 1 time in total

Can anyone tell me where the resolution of frame buffer console text is determined?

I see in the kernel there is a setting for a default of 1024x768 and 80x25 lines of text. When booting up Gentoo on my Alpha PWS 433au, I see two messages. First is

Console: setting screen to 80s25 [not the precise wording, it scrolls by very quickly]

Then after a screenful of text goes by

Console: setting screen to 80x30 [again, not precisely the wording, but that's what it says in meaning]

This machine has an Elsa Gloria Synergy video card (3DLabs, Permedia 2 chipset, 8192MB) and when the second message comes around, the VGA console display breaks up and is no longer readable. The actual hardware seems to be fine, since both Debian and OpenBSD are able to use the frame buffer console without difficulty. I suspect that the 80x30 display is at a resolution that the board doesn't support. I've hunted for this configuration setting and can't find it or anything about it. Unless I can fix it, the console display will remain unusable. (I have a VT220 on ttyS0, otherwise I would not even be able to see to operate and try to configure the machine.)

Any help would be greatly appreciated. Is it even possible to use Gentoo/X11 on the Alpha hardware? This problem suggests not.

Altivo · Posted: Sat Aug 08, 2015 2:55 pm Post subject:

Additional details. I used dmesg to dig out the exact wording. Ther first message:

Console: colour dummy device 80x25

Shortly after that, the second message:

Console: switching to colour frame buffer device 80x30
fb0: TVP4020 frame buffer device, memory = 8192K

The second line correctly identifies the video card, so it has been found and the pm2fb device driver should be active.

So I gather that these are two different device drivers. The dummy console is the one that is set up in the kernel gen itself. The question then becomes "How do I change the screen size for the colour frame buffer device?"

There doesn't appear to be a way to set this in the kernel gen itself. Is there a configuration file? Or a utility program that can pass commands to the device code? I suppose the source code itself could be changed but that is surely not the correct thing to do.

NeddySeagoon · Posted: Sat Aug 08, 2015 3:02 pm Post subject:

Altivo,

You pass parameters on the kernel command line. This is for an AMD box but I think its arch agnostic.

Altivo · Posted: Sat Aug 08, 2015 3:15 pm Post subject:

Thanks. I've looked through the kernel boot parameters but I missed that.

So I guess I need both vga= and video=

Off to find what the correct values would be...

NeddySeagoon · Posted: Sat Aug 08, 2015 4:47 pm Post subject:

Altivo,

vga= sets the text console - beyore framebuffer starts, or if you don't use framebuffer.
video= sets the framebuffer resolution.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Altivo · Posted: Sat Aug 08, 2015 4:52 pm Post subject:

Got it, thanks. I found it once you gave me enough so I knew where to look. I tend to forget that there are all those Documentation files in the kernel source. Reading them is confusing at times because they make so many assumptions based on Intel architecture, but I know what I have to try now.

You've helped a lot. Hopefully it will work.

Altivo · Posted: Sat Aug 08, 2015 9:30 pm Post subject:

Added this

NeddySeagoon · Posted: Sun Aug 09, 2015 8:50 am Post subject:

Altivo,

That does not sound like either a hardware nor a font problem as it works in half duplex - depending on the source of the characters.
glyph rendering uses the same hardware and software regardless.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Altivo · Posted: Sun Aug 09, 2015 11:42 am Post subject:

I pretty much have to agree with you. I've tried all the legal combinations of resolution and sync rate, though. The monitor doesn't have good documentation, but I have the recommended limits for horizontal and vertical frequency, and know the highest (1820x1024) resolution it supports. None that I tried were usable, and the symptoms were similiar each time. The same card was apparently sold under the Powerstorm brand name as a 4D10T, DEC/Compaq part number PBXGK-AB. As Elsa Gloria Synergy, the part number was PBXGK-BB. Compaq covered both in the same instruction manual and says they were supported by both OpenVMS and Tru64.

Debian and OpenVMS both work properly with the card in graphical mode. Debian provides the usual six character cell screens plus one graphic screen in X, but appears not to be using the frame buffer for the text consoles. OpenVMS, of course, knows nothing about frame buffer. OpenBSD provides six text consoles, but no graphical screen. (It has no Xserver at all, only the client side on Alpha.)

These video cards were perhaps the most frequently used in this Alpha model, as they were the least expensive offered by DEC and Compaq, and they worked with Windows NT as well as OpenVMS. Looking at the source of the pm2fb driver, I gather that the Permedia is a bit peculiar in the way it handles things, and it looks as if the author of the driver code was only able to test it on i386 architecture. So the driver may be the problem here. I have a Matrox Millennium (worked with Debian, but not OpenVMS when I last tried it) and an S3 Trio 64 (worked with OpenVMS but not Debian) here so I'll try one of them. If I can get Gentoo all the way to where it works with X, I don't need the old Debian any more. My uses for OpenVMS don't really require a graphical interface now. I'll report the results after I get a chance to swap cards.

NeddySeagoon · Posted: Sun Aug 09, 2015 12:09 pm Post subject:

Altivo,

Its something that affects console output but not console input being echoed.
The very thought of that makes my head hurt.

Maybe its not input output dependant, perhaps its framebuffer position dependant. Heres a test.

Log in and issue the reset command. You should get the prompt back in a clear console.
Press and hold the 'a' so you get a row or so of 'a's. Any key will do but you may want to try several.
Press return.
Whatever you typed should be echoed, along with an error message.
Can you post a photo somewhere?

Posting your dmesg output with the aid of wgetpaste might be useful too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Altivo · Posted: Sun Aug 09, 2015 2:18 pm Post subject:

Tried your suggested test, will get photos later this morning.

Yes, the keyboard input is echoed pretty much correctly, though some individual characters are shifted a tiny amount above or below the others, like an old mechanical typewriter might do. (Now THAT makes my head hurt as well. How could that happen?)

Output to the screen is mostly illegible, though you can see it if you know what to expect. "Wait, that is 'aaaaaaaaaaaaaaaaaaaaaaaa' all right, but it's displaying alternate scan lines at differing offsets from the left margin of the screen." (More head hurty.)

Looking at /usr/src/linux/drivers/video/fbdev/pm2fb.c I find that the code was last revised in 2003, it seems. And it was tested on a 32 bit Intel processor and on a Sun SPARC (for big-endian compatibility.)

I suspect this driver still works, but only on 32 bit machines. The code is probably loading data directly into video memory and has a bug in it when dealing with 64 bit processors. That may affect 64 bit Intel, as well as AMD and Alpha.

I believe the Debian drivers for the S3 Trio 64 card had similar issues and I could never make them work. I never looked at the source code in that instance.

Photos once I get some breakfast. I'll have to look into wgetpaste, as I'm not familiar with it.

NeddySeagoon · Posted: Sun Aug 09, 2015 3:44 pm Post subject:

Altivo,

Think about how the 80x25 text console works. There in a region of memory on the graphics card that holds the 80x25 ASCII codes to be displayed and the scan lines on the display are generated by a lookup table for each row of each symbol as the scan lines are generated. This only uses 2k of RAM for the text plus the look up table. You get differend fonts by changint the lookup table.

Framebuffer has a pixel in the video RAM for every on screen pixel and glyphs are rendered pixel by pixel into this space.
Typically, the framebuffer is one contiguous chunk of RAM. All that matters is that the reading and writing processes agree on the address for a given pixel. If that fails you can get some very interesting effects.
Its still the same for console input and output though.

Hmm that means some colour depths may work and others may fail. Try @32 for 32 bit colour, @16 for 16 bit. @8 and @15 might work too but not all framebuffers support all colour depths.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Altivo · Posted: Sun Aug 09, 2015 4:02 pm Post subject:

Here is the dmesg output from this morning's boot up.

http://pastebin.com/CjBVts3i

Taking photos now, will take a few minutes to get them out of the phone and uploaded somewhere.

Altivo · Posted: Sun Aug 09, 2015 5:37 pm Post subject:

Additional information: I booted Debian to see what settings it uses. Since it is not using framebuffer, but just X.org graphics, I logged in on the graphical screen and ran xvidtune to get the values. The optimal display for this card and monitor, as calculated by X.org, is 1024x768 with 16 bit color at 70 Hz. The display is slightly wobbly on the ancient monitor, so I've been aiming for the same resolution but at 60 Hz on Gentoo.

However, this morning I tried all possible bit depths (8, 16, 24, 32) at both 60 and 70 Hz, as well as at 800x600. The display results are pretty much the same on all of them. Going down to 640x480 produces some other undesirable artifacts and still has the same font distortions but at a larger size. I did not try 1820x1024 yet.

Photos.

Here's the actual login prompt text as it appears on the VT220 serial console

Login plus some tests to show typed input and screen output, on framebuffer

Sorry the photos aren't that great, but I think you can get the idea.

Specs from the Compaq manual for this video card:

NeddySeagoon · Posted: Sun Aug 09, 2015 6:38 pm Post subject:

Altivo,

NeddySeagoon · Posted: Sun Aug 09, 2015 6:57 pm Post subject:

Altivo,

Framebuffer consoles scroll by copying the video pixels further "up" the pixel buffer.
They do this either ove video line at a time - smooth scrolling ir one text line at a time.
leaving a blank space at the bottom.

If you allow you test lines of aaaa's and 2222's to scroll, do you have a case af now you see me now you don't.
That is, is it an odd/even (some other number) text line issue rather than an input/output issue.
Let the input text lines wrap too.

Try an 8 bit colour depth.

You may be able to use the uvesafb too. It was ported to non Intel Arches but I don't know if Alpha was one of them.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Altivo · Posted: Sun Aug 09, 2015 7:28 pm Post subject:

Yes, 1024x768 with 16 bit color at 60 Hz was the setting for that boot. I'm currently using the same but at 70 Hz. No apparent difference.

When you power up an Alpha, control first goes to a system monitor that lets you examine devices, perform debugging operations, some configuration steps, and even some scripting stuff in some models. This mode allows you to select a boot device, and boot from it, passing parameters from a predetermined list located on the device or by typing them in manually. These operations have to take place from somewhere, and you have a choice of using the system-attached keyboard and monitor (if present) or a serial device. I have a serial terminal attached to the ttyS0 port for this purpose because it lets me see the boot up messages as they appear. When the video console is not functioning properly (as in the current case) I would be unable to read those messages until the system was up, and I logged in from somewhere else via ssh or telnet, to use dmesg. If I'm testing a new kernel, and it fails to boot, even dmesg won't help because I can't log in to see it. Hence the preference for the serial terminal. It isn't essential in normal operation, no. Without that boot parameter, at a fairly early point in the boot sequence, all messages would be redirected to the (non-functioning right now) framebuffer or vga console and would be illegible.

The serial terminal becomes inactive at that stage and there is no control unless the system monitor and keyboard work, or ssh/telnet is possible from another machine. Once the system boots successfully, of course, an agetty can start to reactivate the serial terminal for login.

I have not yet been able to compile a working kernel on Gentoo. I've tried repeatedly, and though the kernel compile completes and I can install and boot, the boot cycle does not complete. It locks up right after "Freeing unneeded kernel memory" never to be heard from again. The system has to be recovered by powering it down. Since the kernel from the LiveCD is functional (but not perfect, as in the case of the framebuffer display) I've been using that while trying to figure out what I'm doing wrong with the kernel configuration. If I could create a custom kernel, I'd try dropping the framebuffer entirely to see if VGA alone functions. It would be sufficient for my present needs, though I hope to eventually get X up and running, which might once again come to this issue of video cards and drivers.

NeddySeagoon · Posted: Sun Aug 09, 2015 8:18 pm Post subject:

Altivo,

When you boot Gentoo from the liveCD, I recall it has a nofb option.
There are some help screens you should read.

The 60Hz/70Hz option only controls how fast the framebuffer is read to the screen. It sets the pixel clock and little else.
The colour depth changes the amount of RAM used for the framebuffer and maybe its location it the video card too.
Changing the resolution affects this too.

1024x768 with 16 bit colour needs 1024x768x2 bytes of RAM. That's two bytes to do 16 bit colour for each on screen pixel.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

chithanh · Posted: Sun Aug 09, 2015 8:24 pm Post subject:

Altivo · Posted: Sun Aug 09, 2015 8:38 pm Post subject:

Neddy-- Yes, I'm familiar with the concept. That comes to 1.5 MB or a bit more, which is hardly huge when the machine has 1024 MB of RAM and the video card has 8 MB. When up and running, this machine is usually only using half of the available memory.

BTW, I love the reference to The Goon Show. I've listened to those guys in reruns and from recordings many times, though I was just a little kid when they were actually on the air.

chithanh-- Yes, in fact, I have tried that. The kernel on the CD was apparently compiled under Gentoo 3.17.7, though. I've tried feeding it into genkernel with --kernel-config and --oldconfig and a kernel does come out, but it won't run. Boots up and stops at "Freeing unused kernel memory..." as I said above.

NeddySeagoon · Posted: Sun Aug 09, 2015 8:49 pm Post subject:

Altivo,

The framebuffer RAM is physically located on the graphics card. Its mapped into the memory map somewhere but I couldn't spot it in your dmesg.

My idea was to make the framebuffer RAM smaller in case it was a 64 bit/32 bit boudary issue and possibly sneak under boundary.
It looks like you have tested all te options anyway.

Heres a thought for the future. There is an xf86-video- driver for your card. It may not like the kernel framebuffer driver already taking over the card.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Altivo · Posted: Sun Aug 09, 2015 9:07 pm Post subject:

Altivo · Posted: Sun Aug 09, 2015 9:17 pm Post subject:

NeddySeagoon · Posted: Sun Aug 09, 2015 9:25 pm Post subject:

Altivo,

The liveCD kernel is normally made with genkernel all.
That produces a fully modular kernel that must have an initrd to get anywhere.

Post your kernel .config (use wgetpaste) and I'll look it over for boot options.
I will also need your lspci output and to know what filesystem you have on root and the disk label you use.
I suspect that Alpha has its own.

The get booted options are hardware specific but otherwise arch agnostic.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Altivo · Posted: Sun Aug 09, 2015 9:30 pm Post subject:

I'll note here that as I read and worked through the installation instructions in the Alpha Handbook, I did try 'genkernel all'. It failed in the compile, with error messages suggesting to me that the linkage editor had too many symbols to resolve or else had overflowed some table of a fixed size. That's why I went back to the configuration file for the LiveCD kernel and began working from that.

When the current attempt finishes (usually takes 3 hours or so) I'll test it and if it won't boot, then I'll pastebin the .config so you can look at it. No need to waste your time until we know I still can't make it work.

I really do appreciate the help, but I don't want to eat up your whole day (evening there now, I guess.)

With respect to the disk label, there's a whole thread here. The Alpha aboot bootstrap wants a BSD or OSF type label. The fdisk utility included on the LiveCD image I downloaded is unable to read or write one. I had to go to OpenBSD to generate the necessary label. Eventually discovered that the older version of fdisk in my Debian installation also works, and can even be run directly in Gentoo. Working version of fdisk is 2.12r from Debian. Non-working one from the LiveCD is 2.24.
_________________
Have patience with me, I'm only half-baked.
--Altivo