Changing the terminal resolution after boot.

haroldjclements · 2010-08-25 11:50:33

Hello forum,

I have a terminal only install of Arch. I have set the vga flag in grub to 792 (1024x768x16M). I have written application that I want to run at 640x480.

Is there any way of changing the resolution for my application; either by a system call or programming API?

Thanks for your time,
Harold Clements

Inxsible · 2010-08-25 12:02:32

usually KMS will autodetect the resolution that you need in tty. Is there any specific reason that you are not using KMS

karol · 2010-08-25 12:21:51

Inxsible wrote:

usually KMS will autodetect the resolution that you need in tty. Is there any specific reason that you are not using KMS

Setting the resolution may be such a reason.

If you add 'nomodeset' to the kernel line in grub, you should be able to pick the desired resolution with 'vga=###'.

haroldjclements · 2010-08-25 12:28:06

Thank you for your reply Inxsible / Karol,

I apologise for my ignorance.

By KMS, I take it you mean Kernel Mode-Setting?

I have written an application in ncurses that I want to run at 640x480. The target machine needs to be 1024x768 for other applications. I have no X-Window / GUI installed (and have no plans to install).
When I run the 640x480 application it runs at 1024x768.

Could you explain how KMS will help me? I am fairly new to Linux so all help is gratefully received...

Kind Regards,
Harold Clements

Last edited by haroldjclements (2010-08-25 12:50:39)

karol · 2010-08-25 12:30:22

Can you post your /boot/grub/menu.lst?

http://wiki.archlinux.org/index.php/KMS

Last edited by karol (2010-08-25 12:30:55)

haroldjclements · 2010-08-25 12:34:40

# (0) Arch Linux
title  Arch Linux
root   (hd0,0)
kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/408765cb-7d0c-455f-ff5b-74cc520b8c74 ro vga=792 nomodeset
initrd /boot/kernel26.img

karol · 2010-08-25 12:36:52

Google says vga=792 means 1024×768 in 24-bit.

sand_man · 2010-08-25 12:42:54

I think the OP want's to boot as 1024x768 (which he is) but wants to be able to change it to 640x480 afterwards to run a particular application.
I don't know anything about KMS because I've never used it but I would say that's the only way to go. I don't think it's possible to change the resolution of the terminal after booting without KMS. Although I could be wrong.

karol · 2010-08-25 12:45:31

vga=785 - 640x480x64k
vga=784 - 640x480x32k
vga=769 - 640x480x256

haroldjclements · 2010-08-25 12:47:31

You are correct sand_man that is what I am trying to do. I am currently trying the KMS approach as per the link from karol.

haroldjclements · 2010-08-25 12:49:59

karol wrote:

vga=785 - 640x480x64k
vga=784 - 640x480x32k
vga=769 - 640x480x256

Thanks Karol, but if I set the mode in the grub menu to 640x480 none of the applications that need to run at 1024x768 will display correctly.

karol · 2010-08-25 12:51:49

haroldjclements wrote:

karol wrote:
vga=785 - 640x480x64k
vga=784 - 640x480x32k
vga=769 - 640x480x256
Thanks Karol, but if I set the mode in the grub menu to 640x480 none of the applications that need to run at 1024x768 will display correctly.

Yeah, I know, I posted just in case you need the codes to run in 640x480 only.

I don't know if any framebuffers can change the resolution on the fly.

Proofrific · 2010-08-26 01:24:20

haroldjclements wrote:

I am currently trying the KMS approach as per the link from karol.

Actually, having "nomodeset" in your menu.lst means you're *not* using KMS.

As others have suggested, you may not be able to change resolution on the fly without KMS. But, at least you can boot into a specified resolution now. You could have two separate entries in your menu.lst, one for 1024x768 and one for 640x480. That way, you can select the correct one at boot instead of editing in grub each time.

kokoko3k · 2010-08-26 02:17:52

"fbset" command can actually change the resolution on the fly after boot if you don't use kms (set nomodeset in menu.lst)
You can also program your preferred modelines in /etc/fb.modes.
See man fbset for details.

Proofrific · 2010-08-26 02:21:19

kokoko3k wrote:

"fbset" command can actually change the resolution on the fly after boot if you don't use kms (set nomodeset in menu.lst)
You can also program your preferred modelines in /etc/fb.modes.
See man fbset for details.

I didn't know that existed. Thanks! It's available in the extra repository. You can install it using:

sudo pacman -S fbset

haroldjclements · 2010-08-26 10:14:00

Thank you for your post kokoko3k.

"fbset" was one of the first things that I tried. However, when I try the following command nothing happens.

fbset -g 640 680 640 480 32

As your post specified that "nomodeset" should be in grub, I tried removing just to see what would happen! When I type the above command the resolution of my screen resolution did not change, just the amount of space available to use within the consoles. In other words I still had a 1024x768 screen with console that could only used 640x480 pixels, leaving just black in bottom and right hand size (filling the remaining 384x288 pixels).

Is this what is expected if you remove the "nomodeset" in grub? If so, why does nothing change when I execute the same command with the "nomodeset" grub prameter present?

Thank you very much for your time,
Harold Clements

PS

I have also tried the following just in case the virtual dimensions had to match the monitors native resolution.

fbset -g 640 680 1024 768 32

karol · 2010-08-26 12:23:53

NAME
       fbset - show and modify frame buffer device settings

SYNOPSIS
       fbset [options] [mode]

DESCRIPTION
       This documentation is out of date!!

If it's out of date, it may not work.

What framebuffer are you running?

haroldjclements · 2010-08-26 12:53:43

I assume that I am using the default (/dev/fb0).

Is there a way of checking? (Sorry if this is a dumb question...)

Kind Regards...

marfig · 2010-08-26 14:18:50

haroldjclements,

This is slightly off-topic and I don't know the answer to your problem. However, I can't help but try and give you some piece of humble advise.

Are you really sure you want to eventually turn KMS into a dependency of your application? Do you even think that makes sense in the context of a ncurses based application?
You 640x480 application will run just fine in any higher resolution and in a way that is expected (and desired!) by users. That is, users expect applications on the console to occupy only the space required. Forcing a change of the the framebuffer resolution to match your console application (even if this is a full interactive application) carries with it a series of consequences. Some of which may be damaging to your app:

According to the path this thread is taking, you'll have a dependency on KMS. Which isn't apparently supported by all chipsets, and consequently may turn your application unusable on those systems, unless you introduce fallback code. More code that you need to test, debug and maintain. For no real benefit to the user (see below).
From my understanding, KMS requires X, or has the potential to affect X. I'm not clear on this. It also requires specific video drivers that may not work properly on certain systems. You should want your console app to install with minimum impact to the system. A dependency on KMS may really not be desirable. Your console app expects specific system configurations. This decision should never be taken lightly.
Monitor resolution changes on the fly have a strong impact on the usability of the entire system. You can try this by running your system for a couple of hours in 640x480 fullscreen and then swapping to 1024x768 or higher. Then do the same the other way around. In both instances, you will experience an immense visual impact when switching. You don't want to impose these things on your users.
LCD monitors (which are the norm these days) have trouble dealing with resolutions outside their native resolution mode. This is true of even resolutions with the same aspect ratio of the monitor native resolution. But is particularly damaging when the monitor tries to run resolutions on different aspect ratios in fullscreen. Since the 4:3 ratio of the 640x480 resolution you wish to impose is all but entirely gone from LCD monitors, users running your app will experience one of two things
1. They run your app in fullscreen mode (LCD zoom), in which case the fonts are distorted according to the different zoom ratio applied in each axis by the monitor and also introducing a quite pronounced and unaesthetic blur.
2. They run your app in true resolution mode, in which case only 640x480 pixels are available for rendering in the center of the screen area of monitor. For large monitors particularly this may mean a very small 4:3 square with potential eye strain to the users. And no real benefit.

Carefully weight the pros and cons of what you are trying to do and consider your application; what it does, the environment where it is expected to run, the systems targeted, and the users you expect to use your application. For a console application, I have to be frank here, and suggest I can't see a reason for doing what you are trying to do. Unless this is just for fun, in which case this lengthy post becomes useless. But I'm willing to take that chance.

Last edited by marfig (2010-08-26 14:20:02)

karol · 2010-08-26 15:18:07

marfig wrote:

haroldjclements,
This is slightly off-topic and I don't know the answer to your problem. However, I can't help but try and give you some piece of humble advise.
Are you really sure you want to eventually turn KMS into a dependency of your application? Do you even think that makes sense in the context of a ncurses based application?
You 640x480 application will run just fine in any higher resolution and in a way that is expected (and desired!) by users. That is, users expect applications on the console to occupy only the space required. Forcing a change of the the framebuffer resolution to match your console application (even if this is a full interactive application) carries with it a series of consequences. Some of which may be damaging to your app:
According to the path this thread is taking, you'll have a dependency on KMS. Which isn't apparently supported by all chipsets, and consequently may turn your application unusable on those systems, unless you introduce fallback code. More code that you need to test, debug and maintain. For no real benefit to the user (see below).
From my understanding, KMS requires X, or has the potential to affect X. I'm not clear on this. It also requires specific video drivers that may not work properly on certain systems. You should want your console app to install with minimum impact to the system. A dependency on KMS may really not be desirable. Your console app expects specific system configurations. This decision should never be taken lightly.
Monitor resolution changes on the fly have a strong impact on the usability of the entire system. You can try this by running your system for a couple of hours in 640x480 fullscreen and then swapping to 1024x768 or higher. Then do the same the other way around. In both instances, you will experience an immense visual impact when switching. You don't want to impose these things on your users.
LCD monitors (which are the norm these days) have trouble dealing with resolutions outside their native resolution mode. This is true of even resolutions with the same aspect ratio of the monitor native resolution. But is particularly damaging when the monitor tries to run resolutions on different aspect ratios in fullscreen. Since the 4:3 ratio of the 640x480 resolution you wish to impose is all but entirely gone from LCD monitors, users running your app will experience one of two things
They run your app in fullscreen mode (LCD zoom), in which case the fonts are distorted according to the different zoom ratio applied in each axis by the monitor and also introducing a quite pronounced and unaesthetic blur.
They run your app in true resolution mode, in which case only 640x480 pixels are available for rendering in the center of the screen area of monitor. For large monitors particularly this may mean a very small 4:3 square with potential eye strain to the users. And no real benefit.
Carefully weight the pros and cons of what you are trying to do and consider your application; what it does, the environment where it is expected to run, the systems targeted, and the users you expect to use your application. For a console application, I have to be frank here, and suggest I can't see a reason for doing what you are trying to do. Unless this is just for fun, in which case this lengthy post becomes useless. But I'm willing to take that chance.

Maybe the screens the app will run on are native 640x480. In higher resolutions it would e.g. occupy only top left part of the screen - not the prettiest solution but I have no problem with that.
'dependency on KMS' is not yet sure. adding 'nomodeset' to the kernelline says: 'no KMS, thank you'.

karol · 2010-08-26 15:42:04

haroldjclements wrote:

I assume that I am using the default (/dev/fb0).
Is there a way of checking? (Sorry if this is a dumb question...)
Kind Regards...

'fbset -i' will show you what you're using.

Edit: I've just switched to 640x480 using nouvaufb (I have an nvidia card) so fbset is working. The terminal doesn't scale to the whole screen, it's just the 640x480 part in the top left corner, if, however I play a movie with mplayer it can be shown on the whole screen.

Last edited by karol (2010-08-26 15:58:21)

haroldjclements · 2010-08-30 14:20:31

marfig wrote:

haroldjclements,
This is slightly off-topic and I don't know the answer to your problem. However, I can't help but try and give you some piece of humble advise.

All advice is appreciated...

marfig wrote:

Are you really sure you want to eventually turn KMS into a dependency of your application? Do you even think that makes sense in the context of a ncurses based application?

Yes, I had a look at KMS, and as you say it have a lots of X11 dependencies. However, this did mention an console only alternate, Uvesafb, which I did try but did not have much luck with.

marfig wrote:

Your 640x480 application will run just fine in any higher resolution and in a way that is expected (and desired!) by users.

However, not the desire of my customer, who wants their application running at 640x480.

marfig wrote:

That is, users expect applications on the console to occupy only the space required. Forcing a change of the the framebuffer resolution to match your console application (even if this is a full interactive application) carries with it a series of consequences. Some of which may be damaging to your app:

Noted...

marfig wrote:

According to the path this thread is taking, you'll have a dependency on KMS. Which isn't apparently supported by all chipsets, and consequently may turn your application unusable on those systems, unless you introduce fallback code. More code that you need to test, debug and maintain. For no real benefit to the user (see below).

The customer has standardised hardware to which I am developing to.

marfig wrote:

From my understanding, KMS requires X, or has the potential to affect X. I'm not clear on this. It also requires specific video drivers that may not work properly on certain systems. You should want your console app to install with minimum impact to the system. A dependency on KMS may really not be desirable. Your console app expects specific system configurations. This decision should never be taken lightly.

As mentioned above, I have ruled out KMS.

marfig wrote:

Monitor resolution changes on the fly have a strong impact on the usability of the entire system. You can try this by running your system for a couple of hours in 640x480 fullscreen and then swapping to 1024x768 or higher. Then do the same the other way around. In both instances, you will experience an immense visual impact when switching. You don't want to impose these things on your users.

The way in which this application is intended to be used, this will not be a problem.

marfig wrote:

LCD monitors (which are the norm these days) have trouble dealing with resolutions outside their native resolution mode. This is true of even resolutions with the same aspect ratio of the monitor native resolution. But is particularly damaging when the monitor tries to run resolutions on different aspect ratios in fullscreen. Since the 4:3 ratio of the 640x480 resolution you wish to impose is all but entirely gone from LCD monitors, users running your app will experience one of two things
They run your app in fullscreen mode (LCD zoom), in which case the fonts are distorted according to the different zoom ratio applied in each axis by the monitor and also introducing a quite pronounced and unaesthetic blur.
They run your app in true resolution mode, in which case only 640x480 pixels are available for rendering in the center of the screen area of monitor. For large monitors particularly this may mean a very small 4:3 square with potential eye strain to the users. And no real benefit.

Standardised hardware...

marfig wrote:

Carefully weight the pros and cons of what you are trying to do and consider your application; what it does, the environment where it is expected to run, the systems targeted, and the users you expect to use your application. For a console application, I have to be frank here, and suggest I can't see a reason for doing what you are trying to do. Unless this is just for fun, in which case this lengthy post becomes useless. But I'm willing to take that chance.

I appreciate your post. It is always good to get another prospective. If it was not for strict customer requests and hardware restrictions, I would not be investigating this avenue.

Kind Regards,
Harold Clements

fsckd · 2010-08-30 17:02:59

Out of curiosity, is your application required to change the reolution to 640x480 or is it to expect the resolution to always be 640x480? If it's any consolation, 640x480 is an excellent resolution and I would heartily recommend it to anyone.

Arch Linux

#1 2010-08-25 11:50:33

Changing the terminal resolution after boot.

#2 2010-08-25 12:02:32

Re: Changing the terminal resolution after boot.

#3 2010-08-25 12:21:51

Re: Changing the terminal resolution after boot.

#4 2010-08-25 12:28:06

Re: Changing the terminal resolution after boot.

#5 2010-08-25 12:30:22

Re: Changing the terminal resolution after boot.

#6 2010-08-25 12:34:40

Re: Changing the terminal resolution after boot.

#7 2010-08-25 12:36:52

Re: Changing the terminal resolution after boot.

#8 2010-08-25 12:42:54

Re: Changing the terminal resolution after boot.

#9 2010-08-25 12:45:31

Re: Changing the terminal resolution after boot.

#10 2010-08-25 12:47:31

Re: Changing the terminal resolution after boot.

#11 2010-08-25 12:49:59

Re: Changing the terminal resolution after boot.

#12 2010-08-25 12:51:49

Re: Changing the terminal resolution after boot.

#13 2010-08-26 01:24:20

Re: Changing the terminal resolution after boot.

#14 2010-08-26 02:17:52

Re: Changing the terminal resolution after boot.

#15 2010-08-26 02:21:19

Re: Changing the terminal resolution after boot.

#16 2010-08-26 10:14:00

Re: Changing the terminal resolution after boot.

#17 2010-08-26 12:23:53

Re: Changing the terminal resolution after boot.

#18 2010-08-26 12:53:43

Re: Changing the terminal resolution after boot.

#19 2010-08-26 14:18:50

Re: Changing the terminal resolution after boot.

#20 2010-08-26 15:18:07

Re: Changing the terminal resolution after boot.

#21 2010-08-26 15:42:04

Re: Changing the terminal resolution after boot.

#22 2010-08-30 14:20:31

Re: Changing the terminal resolution after boot.

#23 2010-08-30 17:02:59

Re: Changing the terminal resolution after boot.

Board footer