[arch-releng] size of the "display" (framebuffer?) on our images

Dieter Plaetinck

19 Feb 2009 19 Feb '09

12:46 p.m.

Hi all, I find that the size of our "display" (this is the framebuffer resolution, right?) is quite small. Most distro's that I know of have a bigger size/resolution when booting their isos. Is there a reason we keep it so small? compatibility with older systems? If we could make it a bit bigger, that would be really useful, See for example http://users.edpnet.be/dieter/aif/aif-alpha_0.6-disks-overview-dia.png I just have sometimes many things to show which doesn't fit in the screen anymore :) Dieter

Show replies by date

Dan McGee

19 Feb 19 Feb

1:19 p.m.

On Thu, Feb 19, 2009 at 6:46 AM, Dieter Plaetinck wrote:

...

Hi all, I find that the size of our "display" (this is the framebuffer resolution, right?) is quite small. Most distro's that I know of have a bigger size/resolution when booting their isos. Is there a reason we keep it so small? compatibility with older systems?

Because we leave it up to the users to specify a vga= line in grub? For the installer, we could probably default to at least a 1024x768 FB resolution, but keep in mind this still breaks for some people- those installing on an Eee PC with a 800x480 resolution, etc.

...

If we could make it a bit bigger, that would be really useful, See for example http://users.edpnet.be/dieter/aif/aif-alpha_0.6-disks-overview-dia.png I just have sometimes many things to show which doesn't fit in the screen anymore :)

Aaron Griffin

3:56 p.m.

On Thu, Feb 19, 2009 at 7:19 AM, Dan McGee wrote:

...

On Thu, Feb 19, 2009 at 6:46 AM, Dieter Plaetinck wrote:

...
Hi all, I find that the size of our "display" (this is the framebuffer resolution, right?) is quite small. Most distro's that I know of have a bigger size/resolution when booting their isos. Is there a reason we keep it so small? compatibility with older systems?

Because we leave it up to the users to specify a vga= line in grub?

This is what I've always done. Just edit the grub line and add "vga=791" or something

Gerhard Brauer

1:52 p.m.

Am Thu, 19 Feb 2009 13:46:49 +0100 schrieb Dieter Plaetinck :

...

Hi all, I find that the size of our "display" (this is the framebuffer resolution, right?) is quite small.

No framebuffer. During install we use a normal 80x25 setup. Only the bootloader (splash)screens have an other resolution.

...

Most distro's that I know of have a bigger size/resolution when booting their isos. Is there a reason we keep it so small? compatibility with older systems?

Then we must use either a VGA or VESA framebuffer mode. VGA modes offers IMHO only modes with more lines (ex. 80x50) and look ugly without other console fonts. Framebuffer mode (640x480, 600x600, 1024x768 pixel size than char/line count) is mostly used by other installers, selectable by the user fitted their hardware. Same could be done by our users by adding a vga= parameter in the bootloader. For us maybe a grub entry with parameter vga=ask is the best, so users could select their resolution. But IMHO we should "design" our bash dialogs in a way that they also be usable on a normal 80x25 console..

...

Dieter

Gerhard

Loui Chang

2:13 p.m.

New subject: [arch-releng] size of the "display" (framebuffer?) on our images

On Thu, Feb 19, 2009 at 02:52:17PM +0100, Gerhard Brauer wrote:

...

For us maybe a grub entry with parameter vga=ask is the best, so users could select their resolution. But IMHO we should "design" our bash dialogs in a way that they also be usable on a normal 80x25 console..

Yeah I agree we should design things to fit within 80 columns. I find longer lines are generally harder to read and edit than shorter lines as well.

Michael Simpson

4:01 p.m.

New subject: [arch-releng] size of the "display" (framebuffer?) on our images

On Feb 19, 2009, at 9:13 AM, Loui Chang wrote:

...

On Thu, Feb 19, 2009 at 02:52:17PM +0100, Gerhard Brauer wrote:

...
For us maybe a grub entry with parameter vga=ask is the best, so users could select their resolution. But IMHO we should "design" our bash dialogs in a way that they also be usable on a normal 80x25 console..

Yeah I agree we should design things to fit within 80 columns. I find longer lines are generally harder to read and edit than shorter lines as well.

I think we may be overlooking the real issue. If anyone is familiar with genkernel (gentoo kernel building tool) I'm almost certain you are able to scroll left and right when selecting options. I will scour for the example I'm thinking of and see if I can turn anything up. Modifying the field to behave this way would effectively resolve Dieter's primary concern separating the text overflow from the issue of resolution. And indeed, I see these as being two explicitly different items. Dan McGee's point of netbooks is valid and IMHO should not be taken lightly- there are an increasing number of people interested in using linux on low resolution/obscure devices. Personally, I think it's great and should be encouraged instead of discouraged. I think any sort of character limitation should be very carefully considered. Things should be designed to scale gracefully by means of a solid interface not by designing things to fit in 80 columns or any other fixed number. Resolution selection would be a nice bonus feature, I have worries that allowing a slew of different resolutions will introduce issues we don't yet foresee but they are based on nothing but cynicism. The more I am thinking about it, I feel strongly that an installer "style- guide" based on a certain size is inherently flawed. Both of these mask the underlying design issue though which is that the fields are not flexible enough to handle more than X characters. These problems have been dealt with, there are valuable precedents which, as I said, I will certainly dig deeper if other's would like me to I'll find the gentoo menus I was talking about and sift their source a bit. I'll look into some screenshots/screencast this evening if someone asks for them. Kind regards, Michael .mgs`

Aaron Griffin

4:07 p.m.

On Thu, Feb 19, 2009 at 10:01 AM, Michael Simpson wrote:

...

I think any sort of character limitation should be very carefully considered. Things should be designed to scale gracefully by means of a solid interface not by designing things to fit in 80 columns or any other fixed number.

Just to be clear here - even the terminals from the 70s supported 80 characters. "wide terminals" supported 132. Designing/limiting for 80 characters is a practice that has been used for a long time

Michael Simpson

4:10 p.m.

On Feb 19, 2009, at 11:07 AM, Aaron Griffin wrote:

...

On Thu, Feb 19, 2009 at 10:01 AM, Michael Simpson wrote:

...
I think any sort of character limitation should be very carefully considered. Things should be designed to scale gracefully by means of a solid interface not by designing things to fit in 80 columns or any other fixed number.

Just to be clear here - even the terminals from the 70s supported 80 characters. "wide terminals" supported 132. Designing/limiting for 80 characters is a practice that has been used for a long time

I am a grammatical disgrace today. Excuse my mail, i'm apparently sleepier than I thought. I meant a limitation on *visible* characters. So as to avoid text overflowing into limbo where it cannot easily (or ever) be viewed.

Dan McGee

20 Feb 20 Feb

12:38 a.m.

On Thu, Feb 19, 2009 at 10:07 AM, Aaron Griffin wrote:

...

On Thu, Feb 19, 2009 at 10:01 AM, Michael Simpson wrote:

...
I think any sort of character limitation should be very carefully considered. Things should be designed to scale gracefully by means of a solid interface not by designing things to fit in 80 columns or any other fixed number.

Just to be clear here - even the terminals from the 70s supported 80 characters. "wide terminals" supported 132. Designing/limiting for 80 characters is a practice that has been used for a long time

/me points at his iPhone: Dan-s-Phone:~ mobile$ echo $COLUMNS 53

Aaron Griffin

12:54 a.m.

On Thu, Feb 19, 2009 at 6:38 PM, Dan McGee wrote:

...

On Thu, Feb 19, 2009 at 10:07 AM, Aaron Griffin wrote:

...
On Thu, Feb 19, 2009 at 10:01 AM, Michael Simpson wrote:

...
I think any sort of character limitation should be very carefully considered. Things should be designed to scale gracefully by means of a solid interface not by designing things to fit in 80 columns or any other fixed number.

Just to be clear here - even the terminals from the 70s supported 80 characters. "wide terminals" supported 132. Designing/limiting for 80 characters is a practice that has been used for a long time

/me points at his iPhone:

Dan-s-Phone:~ mobile$ echo $COLUMNS 53

Shitty modern technology. Hrrmph!

Loui Chang

19 Feb 19 Feb

4:23 p.m.

New subject: [arch-releng] size of the "display" (framebuffer?) on our images

On Thu, Feb 19, 2009 at 11:01:18AM -0500, Michael Simpson wrote:

...

Resolution selection would be a nice bonus feature, I have worries that allowing a slew of different resolutions will introduce issues we don't yet foresee but they are based on nothing but cynicism. The more I am thinking about it, I feel strongly that an installer "style-guide" based on a certain size is inherently flawed. Both of these mask the underlying design issue though which is that the fields are not flexible enough to handle more than X characters.

Think about why newspapers and magazines write articles in columns. Because it's easier to process the information in that format. It's inconvenient, both technically and mentally to be scrolling sideways too much. So I would say such a style guide is imperative.

Smartboy

9:11 p.m.

What about those with Intel cards and widescreen resolutions? Currently, they look horrible because the BIOS don't give the right resolution. Could we also add 915resolution as an option for the CD, so that they can get their widescreen resolution in the framebuffer? Smartboy

5537

Age (days ago)

5538

Last active (days ago)

List overview

Download

11 comments

7 participants

participants (7)

Aaron Griffin
Dan McGee
Dieter Plaetinck
Gerhard Brauer
Loui Chang
Michael Simpson
Smartboy