Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #14671 > unrolled thread

What determines the width of the virtual consoles?

Back to article view | Back to comp.os.linux.misc

Contents

  What determines the width of the virtual consoles? gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-28 23:56 +0000
    Re: What determines the width of the virtual consoles? The Natural Philosopher <tnp@invalid.invalid> - 2015-04-29 05:13 +0100
      Re: What determines the width of the virtual consoles? Aragorn <thorongil@telenet.be.invalid> - 2015-04-29 06:43 +0200
        Re: What determines the width of the virtual consoles? The Natural Philosopher <tnp@invalid.invalid> - 2015-04-29 06:30 +0100
          Re: What determines the width of the virtual consoles? J G Miller <miller@yoyo.ORG> - 2015-04-29 15:14 +0000
            Re: What determines the width of the virtual consoles? gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-29 15:53 +0000
        Re: What determines the width of the virtual consoles? gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-29 11:33 +0000
          Re: What determines the width of the virtual consoles? Robert Heller <heller@deepsoft.com> - 2015-04-29 06:51 -0500
            Re: What determines the width of the virtual consoles? gazelle@shell.xmission.com (Kenny McCormack) - 2015-04-29 13:07 +0000
              Re: What determines the width of the virtual consoles? Robert Heller <heller@deepsoft.com> - 2015-04-29 09:15 -0500
            Re: What determines the width of the virtual consoles? no.top.post@gmail.com - 2015-05-22 08:05 +0000
              Re: What determines the width of the virtual consoles? Lucas Levrel <lucas.levrel@u-pec.fr> - 2015-05-22 15:38 +0200
          Re: What determines the width of the virtual consoles? ruben safir <ruben@mrbrklyn.com> - 2015-05-09 19:41 -0400
        Re: What determines the width of the virtual consoles? Andreas Kohlbach <apr15.7.ankman@spamgourmet.net> - 2015-04-29 18:09 -0400
          Re: What determines the width of the virtual consoles? Aragorn <thorongil@telenet.be.invalid> - 2015-04-30 01:02 +0200
            Re: What determines the width of the virtual consoles? Andreas Kohlbach <may15.7.ankman@spamgourmet.net> - 2015-05-02 16:28 -0400
              Re: What determines the width of the virtual consoles? Chris <cmilnec@spam.net> - 2015-05-04 03:40 +0000
                Re: What determines the width of the virtual consoles? gazelle@shell.xmission.com (Kenny McCormack) - 2015-05-04 11:23 +0000
                Re: What determines the width of the virtual consoles? Andreas Kohlbach <may15.7.ankman@spamgourmet.net> - 2015-05-05 16:45 -0400
                  Re: What determines the width of the virtual consoles? Aragorn <thorongil@telenet.be.invalid> - 2015-05-06 00:21 +0200
                    Re: What determines the width of the virtual consoles? Andreas Kohlbach <may15.7.ankman@spamgourmet.net> - 2015-05-06 17:07 -0400
              Re: What determines the width of the virtual consoles? Bill Marcum <bill.marcum57@gmail.com> - 2015-05-06 03:22 -0400
                Re: What determines the width of the virtual consoles? Chick Tower <c.tower@deadspam.com> - 2015-05-08 21:30 +0000
                  Re: What determines the width of the virtual consoles? Andreas Kohlbach <may15.7.ankman@spamgourmet.net> - 2015-05-09 16:28 -0400
    Re: What determines the width of the virtual consoles? philo <philo@privacy.net> - 2015-04-29 06:56 -0500
      Re: What determines the width of the virtual consoles? "Rinaldi J. Montessi" <rinaldi@notaserver.com> - 2015-04-29 13:00 -0500

Page 1 of 2  [1] 2  Next page →

#14671 — What determines the width of the virtual consoles?

What I mean is: The number displayed as the number of columns when I do
"stty -a", like this: stty -a -F /dev/tty1

I have two systems, running the same OS on the same hardware.  One one
machine, when I do: sudo stty -a -F /dev/tty1, it says "164 columns".
On the other one, when I do the same command, it says "222 columns".

Note that on both machines (and, as far as I know, on any Linux system),
you get the same result for any of the virtual consoles (/dev/tty1,
/dev/tty2, etc).  But you seem to get different results on different
systems.

What determines this?

-- 

First of all, I do not appreciate your playing stupid here at all.

	- Thomas 'PointedEars' Lahn -

[toc] | [next] | [standalone]

#14673

On 29/04/15 00:56, Kenny McCormack wrote:
> What I mean is: The number displayed as the number of columns when I do
> "stty -a", like this: stty -a -F /dev/tty1
>
> I have two systems, running the same OS on the same hardware.  One one
> machine, when I do: sudo stty -a -F /dev/tty1, it says "164 columns".
> On the other one, when I do the same command, it says "222 columns".
>
> Note that on both machines (and, as far as I know, on any Linux system),
> you get the same result for any of the virtual consoles (/dev/tty1,
> /dev/tty2, etc).  But you seem to get different results on different
> systems.
>
> What determines this?
>
first of all, what do you consider a 'virtual console ' is???

Is it the user interface without X windows, or the textual user 
interface provided as part of the X window GUI ?

Because the width is set differently in either case.




-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#14674

On Wednesday 29 April 2015 06:13, The Natural Philosopher conveyed the 
following to comp.os.linux.misc...

> On 29/04/15 00:56, Kenny McCormack wrote:
>> What I mean is: The number displayed as the number of columns when I
>> do "stty -a", like this: stty -a -F /dev/tty1
>>
>> I have two systems, running the same OS on the same hardware.  One
>> one machine, when I do: sudo stty -a -F /dev/tty1, it says "164
>> columns". On the other one, when I do the same command, it says "222
>> columns".
>>
>> Note that on both machines (and, as far as I know, on any Linux
>> system), you get the same result for any of the virtual consoles
>> (/dev/tty1, /dev/tty2, etc).  But you seem to get different results
>> on different systems.
>>
>> What determines this?
>>
> first of all, what do you consider a 'virtual console ' is???
> 
> Is it the user interface without X windows, or the textual user
> interface provided as part of the X window GUI ?
> 
> Because the width is set differently in either case.

A console window running on top of the X Window System is not a virtual 
console but a terminal emulator, and it is never indicated as /dev/tty1, 
/dev/tty2 et al.  Much rather, it will be indicated as /dev/pts/0, 
/dev/pts/1, et al.

The width of the virtual console depends upon the chosen VGA or 
framebuffer screen resolution.  This screen resolution can be set in 
many different ways, and also depends on the graphics driver.  

On systems with a kernel mode-setting driver ─ i.e. "intel", "radeon" or 
"nouveau" ─ the virtual console's resolution will by default be the same 
as that of the X server.  On systems with a proprietary graphics driver 
─ e.g. fglrx or nvidia ─ the virtual console will either be in a 
resolution set via GRUB or LILO directly, or perhaps as a parameter to a 
console framebuffer driver such as vesafb, and on the command line for 
the pertinent kernel ─ in LILO, this would be in the kernel's "append" 
line.

There are of course also other ways of setting the framebuffer 
resolution, post-boot, which is then usually something taken care of by 
the init scripts or systemd configuration files ─ whichever is 
applicable.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

#14675

On 29/04/15 05:43, Aragorn wrote:
> On Wednesday 29 April 2015 06:13, The Natural Philosopher conveyed the
> following to comp.os.linux.misc...
>
>> On 29/04/15 00:56, Kenny McCormack wrote:
>>> What I mean is: The number displayed as the number of columns when I
>>> do "stty -a", like this: stty -a -F /dev/tty1
>>>
>>> I have two systems, running the same OS on the same hardware.  One
>>> one machine, when I do: sudo stty -a -F /dev/tty1, it says "164
>>> columns". On the other one, when I do the same command, it says "222
>>> columns".
>>>
>>> Note that on both machines (and, as far as I know, on any Linux
>>> system), you get the same result for any of the virtual consoles
>>> (/dev/tty1, /dev/tty2, etc).  But you seem to get different results
>>> on different systems.
>>>
>>> What determines this?
>>>
>> first of all, what do you consider a 'virtual console ' is???
>>
>> Is it the user interface without X windows, or the textual user
>> interface provided as part of the X window GUI ?
>>
>> Because the width is set differently in either case.
>
> A console window running on top of the X Window System is not a virtual
> console but a terminal emulator, and it is never indicated as /dev/tty1,
> /dev/tty2 et al.  Much rather, it will be indicated as /dev/pts/0,
> /dev/pts/1, et al.

This, Aragorn, is pure semantics.

Virtual consoles as you describe them are also terminal emulators.

In fact since I unplugged my last Wyse 50, I haven't seen a REAL 
terminal in years!



>
> The width of the virtual console depends upon the chosen VGA or
> framebuffer screen resolution.  This screen resolution can be set in
> many different ways, and also depends on the graphics driver.
>
> On systems with a kernel mode-setting driver ─ i.e. "intel", "radeon" or
> "nouveau" ─ the virtual console's resolution will by default be the same
> as that of the X server.

Not necessarily so.

The 'virtual consoles' of which you speak have nothing to do with X at 
all, and may not even use the same drivers.


   On systems with a proprietary graphics driver
> ─ e.g. fglrx or nvidia ─ the virtual console will either be in a
> resolution set via GRUB or LILO directly, or perhaps as a parameter to a
> console framebuffer driver such as vesafb, and on the command line for
> the pertinent kernel ─ in LILO, this would be in the kernel's "append"
> line.
>

That is IIRC te case fir all graphics.

see 
http://unix.stackexchange.com/questions/107479/how-do-you-pass-vga-vesa-modes-with-grub2

> There are of course also other ways of setting the framebuffer
> resolution, post-boot, which is then usually something taken care of by
> the init scripts or systemd configuration files ─ whichever is
> applicable.
>


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. – Erwin Knoll

[toc] | [prev] | [next] | [standalone]

#14682

On Wednesday, April 29th, 2015, at 06:30:12h +0100, The Natural Philosopher wrote:
>
> On 29/04/15 05:43, Aragorn wrote:
>>
>> A console window running on top of the X Window System is not a virtual
>> console but a terminal emulator, and it is never indicated as /dev/tty1,
>> /dev/tty2 et al.  Much rather, it will be indicated as /dev/pts/0,
>> /dev/pts/1, et al.
> 
> This, Aragorn, is pure semantics.
> 
> Virtual consoles as you describe them are also terminal emulators.

But what Aragorn wrote was correct and made the helpful distinction
that an X terminal emulator window is not a virtual console.

Not all terminal emulators (other examples being minicom, putty)
are virtual consoles.

As Wonkeypedia correctly reports

   "Usually in Linux (see Linux console), the first six virtual consoles
    provide a text terminal with a login prompt to a Unix shell."

All {cars|trucks|vans} are vehicles, but not all vehicles are {car|trucks|vans}.

This is not pure semantics.

[toc] | [prev] | [next] | [standalone]

#14683

In article <mhqsgv$rrb$3@dont-email.me>, J G Miller  <miller@yoyo.ORG> wrote:
>On Wednesday, April 29th, 2015, at 06:30:12h +0100, The Natural Philosopher wrote:
>>
>> On 29/04/15 05:43, Aragorn wrote:
>>>
>>> A console window running on top of the X Window System is not a virtual
>>> console but a terminal emulator, and it is never indicated as /dev/tty1,
>>> /dev/tty2 et al.  Much rather, it will be indicated as /dev/pts/0,
>>> /dev/pts/1, et al.
>> 
>> This, Aragorn, is pure semantics.
>> 
>> Virtual consoles as you describe them are also terminal emulators.
>
>But what Aragorn wrote was correct and made the helpful distinction
>that an X terminal emulator window is not a virtual console.

It is hard to imagine anyone actually thinking it was.

>Not all terminal emulators (other examples being minicom, putty)
>are virtual consoles.
>
>As Wonkeypedia correctly reports
>
>   "Usually in Linux (see Linux console), the first six virtual consoles
>    provide a text terminal with a login prompt to a Unix shell."
>
>All {cars|trucks|vans} are vehicles, but not all vehicles are {car|trucks|vans}.
>
>This is not pure semantics.

Actually it *is* semantics.  But the problem is that people tend to throw the
word "semantics" around as if it was an insult.  It is not.  Semantics is
what words mean.  And words have meanings.   If they didn't, we'd be apes.

-- 
There are two kinds of Republicans: Billionaires and suckers.
Republicans: Please check your bank account and decide which one is you.

[toc] | [prev] | [next] | [standalone]

#14676

In article <mhpnfe$vpq$1@dont-email.me>,
Aragorn  <thorongil@telenet.be.invalid> wrote:
>On Wednesday 29 April 2015 06:13, The Natural Philosopher conveyed the 
>following to comp.os.linux.misc...
>
>> On 29/04/15 00:56, Kenny McCormack wrote:
>>> What I mean is: The number displayed as the number of columns when I
>>> do "stty -a", like this: stty -a -F /dev/tty1
...
>A console window running on top of the X Window System is not a virtual 
>console but a terminal emulator, and it is never indicated as /dev/tty1, 
>/dev/tty2 et al.  Much rather, it will be indicated as /dev/pts/0, 
>/dev/pts/1, et al.

Correct.  The term "virtual console" is well-defined in Linux.
It's not just some random pair of words, free to be interpreted at will by
Usenet posters.  In any event, my specific reference to /dev/tty1 and
/dev/tty2 should have made that crystal clear.

>The width of the virtual console depends upon the chosen VGA or 
>framebuffer screen resolution.  This screen resolution can be set in 
>many different ways, and also depends on the graphics driver.  

Understood, but I'd like to know in greater detail, since, as I mentioned,
I have two identical systems [*] that display different widths.

[*] Identical hardware-wise for sure - should be (at least almost)
identical OS-wise.  I need to do further checking to find out if there are
any observable OS differences (such that might account for the difference
in the VC widths).

>the pertinent kernel ─ in LILO, this would be in the kernel's "append" 
>line.

These systems don't have any LILO or "append" lines.

>There are of course also other ways of setting the framebuffer 
>resolution, post-boot, which is then usually something taken care of by 
>the init scripts or systemd configuration files ─ whichever is 
>applicable.

That might actually be useful.  The underlying problem here is that I'd
like them to be the same (across systems).  Is there a simple way to change
it?  (Is it as simple as just doing "stty columns <N>" ?)

-- 

Prayer has no place in the public schools, just like facts
have no place in organized religion.
 -- Superintendent Chalmers

[toc] | [prev] | [next] | [standalone]

#14677

At Wed, 29 Apr 2015 11:33:24 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:

> 
> In article <mhpnfe$vpq$1@dont-email.me>,
> Aragorn  <thorongil@telenet.be.invalid> wrote:
> >On Wednesday 29 April 2015 06:13, The Natural Philosopher conveyed the 
> >following to comp.os.linux.misc...
> >
> >> On 29/04/15 00:56, Kenny McCormack wrote:
> >>> What I mean is: The number displayed as the number of columns when I
> >>> do "stty -a", like this: stty -a -F /dev/tty1
> ...
> >A console window running on top of the X Window System is not a virtual 
> >console but a terminal emulator, and it is never indicated as /dev/tty1, 
> >/dev/tty2 et al.  Much rather, it will be indicated as /dev/pts/0, 
> >/dev/pts/1, et al.
> 
> Correct.  The term "virtual console" is well-defined in Linux.
> It's not just some random pair of words, free to be interpreted at will by
> Usenet posters.  In any event, my specific reference to /dev/tty1 and
> /dev/tty2 should have made that crystal clear.
> 
> >The width of the virtual console depends upon the chosen VGA or 
> >framebuffer screen resolution.  This screen resolution can be set in 
> >many different ways, and also depends on the graphics driver.  
> 
> Understood, but I'd like to know in greater detail, since, as I mentioned,
> I have two identical systems [*] that display different widths.
> 
> [*] Identical hardware-wise for sure - should be (at least almost)
> identical OS-wise.  I need to do further checking to find out if there are
> any observable OS differences (such that might account for the difference
> in the VC widths).

*Identical* *monitors* as well as video cards? (Eg same make, model, etc.)

Also: were the *monitors* turned on & connected at boot time?

Both the kernel and X11 will choose the VGA/framebuffer resolution based on
the *connected* monitor (if any). If there is no monitor connected or it is not
powered on, a default value will be chosen (usually something low res like
640x480).

Also, there might be *non-identical* BIOS settings that could affect things.
Check those as well.

> 
> >the pertinent kernel ─ in LILO, this would be in the kernel's "append" 
> >line.
> 
> These systems don't have any LILO or "append" lines.

Presumably they are using grub -- grup has much the same sort of config 
options.

> 
> >There are of course also other ways of setting the framebuffer 
> >resolution, post-boot, which is then usually something taken care of by 
> >the init scripts or systemd configuration files ─ whichever is 
> >applicable.
> 
> That might actually be useful.  The underlying problem here is that I'd
> like them to be the same (across systems).  Is there a simple way to change
> it?  (Is it as simple as just doing "stty columns <N>" ?)
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                   

[toc] | [prev] | [next] | [standalone]

#14679

In article <hfmdncc4jvctWN3InZ2dnUU7-KudnZ2d@giganews.com>,
Robert Heller  <heller@deepsoft.com> wrote:
...
>> These systems don't have any LILO or "append" lines.

(or grub)

>Presumably they are using grub -- grup has much the same sort of config 
>options.

Nope.

They are not x86.

-- 
"Although written many years ago, Lady Chatterley's Lover has just
been reissued by the Grove Press, and this fictional account of the
day-to-day life of an English gamekeeper is still of considerable
interest to outdoor minded readers, as it contains many passages on
pheasant raising, the apprehending of poachers, ways to control vermin,
and other chores and duties of the professional gamekeeper.

"Unfortunately, one is obliged to wade through many pages of extraneous
material in order to discover and savor these sidelights on the
management of a Midlands shooting estate, and in this reviewer's opinion
this book cannot take the place of J.R. Miller's Practical Gamekeeping"
(Ed Zern, Field and Stream, November 1959, p. 142).

[toc] | [prev] | [next] | [standalone]

#14680

At Wed, 29 Apr 2015 13:07:46 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:

> 
> In article <hfmdncc4jvctWN3InZ2dnUU7-KudnZ2d@giganews.com>,
> Robert Heller  <heller@deepsoft.com> wrote:
> ...
> >> These systems don't have any LILO or "append" lines.
> 
> (or grub)
> 
> >Presumably they are using grub -- grup has much the same sort of config 
> >options.
> 
> Nope.
> 
> They are not x86.

They are probably using some sort of bootloader.  What is that bootloader 
passing to the kernel?

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                                       

[toc] | [prev] | [next] | [standalone]

#14834

At Wed, 29 Apr 2015 11:33:24 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:
> Aragorn  <thorongil@telenet.be.invalid> wrote:
> >On Wednesday 29 April 2015 06:13, The Natural Philosopher conveyed the 
> >following to comp.os.linux.misc...
> >
This could be related to the problem that I've failed to solve for 10 years:
 HOW2 know in which of 26 WorkSpaces, Xterm [known pid & cwd] is located.
 Eg. with 99 Xterms spread over 26 WS;
     where's the one with mc open-on <Path/File>.
     
> >> On 29/04/15 00:56, Kenny McCormack wrote:
> >>> What I mean is: The number displayed as the number of columns when I
> >>> do "stty -a", like this: stty -a -F /dev/tty1
> ...
> >A console window running on top of the X Window System is not a virtual 
> >console but a terminal emulator, and it is never indicated as /dev/tty1, 
> >/dev/tty2 et al.  Much rather, it will be indicated as /dev/pts/0, 
> >/dev/pts/1, et al.
> 
> Correct.  The term "virtual console" is well-defined in Linux.
> It's not just some random pair of words, free to be interpreted at will by
> Usenet posters.  In any event, my specific reference to /dev/tty1 and
> /dev/tty2 should have made that crystal clear.
> 
OK then, `stty -a -F /dev/pts/0` looks interesting too.
===
re. my problem:
in the days of KDE3 `pstree` corresponded to the tree of
 WorkSpaces / Xterminals.
Now I prefer blackbox to KDE or any other.
Here's part of `pstree`
|-2*[xterm---mcedit]
|-2*[xterm---bash---mc---bash]
|-linux.oberon.no---pstree
|-xterm---bash---xpdf
|-xterm---mc---bash---Wf---wily

All the Xterms all hang-off of
|-bash---startx---xinit-+-X
|                       `-blackbox-
   instead of being grouped per WorkSpace.
   
Since blackbox's menu shows the Xterms per WS,
the required info is available; but with old kde, I could
ask in which WS/s <Name> was located, instead of
manually searching.

Since Xterms can be moved between WSs, apparently
they don't 'belong' to any WS, unlike PIDs who can't 
change parent?

But Xterms do have common-parents, in the sense that
blackbox's menu shows them grouped under a common WS.

WDYS?
   

[toc] | [prev] | [next] | [standalone]

#14839

Le 22 mai 2015, no.top.post@gmail.com a écrit :

> This could be related to the problem that I've failed to solve for 10 years:
> HOW2 know in which of 26 WorkSpaces, Xterm [known pid & cwd] is located.

wmctrl -lp | grep $PID

The second number is the workspace number.

-- 
LL
  Ἕν οἶδα ὅτι οὐδὲν οἶδα (Σωκράτης)

[toc] | [prev] | [next] | [standalone]

#14748

On 04/29/2015 07:33 AM, Kenny McCormack wrote:
> Understood, but I'd like to know in greater detail, since, as I mentioned,
> I have two identical systems [*] that display different widths.
> 
> [*] Identical hardware-wise for sure - should be (at least almost)
> identical OS-wise.  I need to do further checking to find out if there are
> any observable OS differences (such that might account for the difference
> in the VC widths).


i have a problem with this on my fit/pc.  The virtual terminals only
cover about 2/3rd of my screen space.  I use it as a webserver, so i
never cared enough to actually fix it but I think the problem is with
the intel video driver.

[toc] | [prev] | [next] | [standalone]

#14685

Aragorn wrote on 29. April 2015:
>
> On systems with a kernel mode-setting driver ─ i.e. "intel", "radeon" or 
> "nouveau" ─ the virtual console's resolution will by default be the same 
> as that of the X server.  On systems with a proprietary graphics driver 
> ─ e.g. fglrx or nvidia ─ the virtual console will either be in a 
> resolution set via GRUB or LILO directly, or perhaps as a parameter to a 
> console framebuffer driver such as vesafb, and on the command line for 
> the pertinent kernel ─ in LILO, this would be in the kernel's "append" 
> line.

I run a budget radeon GPU (APU actually; hybrid with an AMD CPU). a
"nomodeset" passed to the kernel on boot has no effect.

Is there a way to get the "old classic" (like it was on most Linuxes
prior 2000) 80x25 character tty with the low (might have been 640x400?)
resolution back?

And right, when I tried the fglrx driver instead, the console was indeed as I
want it to be with the radeon now.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often as I
have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#14686

On Thursday 30 April 2015 00:09, Andreas Kohlbach conveyed the following 
to comp.os.linux.misc...

> Aragorn wrote on 29. April 2015:
>>
>> On systems with a kernel mode-setting driver ─ i.e. "intel", "radeon"
>> or "nouveau" ─ the virtual console's resolution will by default be
>> the same as that of the X server.  On systems with a proprietary
>> graphics driver ─ e.g. fglrx or nvidia ─ the virtual console will
>> either be in a resolution set via GRUB or LILO directly, or perhaps
>> as a parameter to a console framebuffer driver such as vesafb, and on
>> the command line for the pertinent kernel ─ in LILO, this would be in
>> the kernel's "append" line.
> 
> I run a budget radeon GPU (APU actually; hybrid with an AMD CPU). a
> "nomodeset" passed to the kernel on boot has no effect.

Depending on the distribution, you may need to use "nokmsboot" instead.

> Is there a way to get the "old classic" (like it was on most Linuxes
> prior 2000) 80x25 character tty with the low (might have been
> 640x400?) resolution back?

Have you tried setting "vga=0" in your grub.cfg?

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

#14690

Aragorn wrote on 29. April 2015:
>
> On Thursday 30 April 2015 00:09, Andreas Kohlbach conveyed the following 
> to comp.os.linux.misc...
>
>> Aragorn wrote on 29. April 2015:
>>>
>>> On systems with a kernel mode-setting driver ─ i.e. "intel", "radeon"
>>> or "nouveau" ─ the virtual console's resolution will by default be
>>> the same as that of the X server.  On systems with a proprietary
>>> graphics driver ─ e.g. fglrx or nvidia ─ the virtual console will
>>> either be in a resolution set via GRUB or LILO directly, or perhaps
>>> as a parameter to a console framebuffer driver such as vesafb, and on
>>> the command line for the pertinent kernel ─ in LILO, this would be in
>>> the kernel's "append" line.
>> 
>> I run a budget radeon GPU (APU actually; hybrid with an AMD CPU). a
>> "nomodeset" passed to the kernel on boot has no effect.
>
> Depending on the distribution, you may need to use "nokmsboot" instead.
>
>> Is there a way to get the "old classic" (like it was on most Linuxes
>> prior 2000) 80x25 character tty with the low (might have been
>> 640x400?) resolution back?
>
> Have you tried setting "vga=0" in your grub.cfg?

Thanks.

I tried both, "nokmsboot" and "vga=0" at the boot prompt. None produces
the result I hoped for. Not even when I pass both to the kernel at the
same boot.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often as I
have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#14696

> I tried both, "nokmsboot" and "vga=0" at the boot prompt. None produces
> the result I hoped for. Not even when I pass both to the kernel at the
> same boot.

My computer has a budget 5450 radeon graphics card and uses the open
source xorg driver. Wheezy.
In file
/etc/modprobe.d/radeon-kms.conf
the line
options radeon modeset=1
results in teeny tiny text in virtual consoles and
allows sound through the HDMI connection

the line
options radeon modeset=0
gives the old vga low-resolution 80x25 character text in consoles and
disables HDMI sound.

[toc] | [prev] | [next] | [standalone]

#14699

In article <slrnmkdqb1.fnu.cmilnec@heron.lake>,
Chris  <cmilnec@spam.net> wrote:
>> I tried both, "nokmsboot" and "vga=0" at the boot prompt. None produces
>> the result I hoped for. Not even when I pass both to the kernel at the
>> same boot.
>
>My computer has a budget 5450 radeon graphics card and uses the open
>source xorg driver. Wheezy.

How nice.  Now, to get this back on-topic...

I've also noticed that it varies from boot to boot.  That is, exact same
hardware, exact same conditions (monitor on, etc), exact same everything,
but the width of the virtual console(s) (the number of columns, as
displayed by "stty -a") varies from boot to boot.

It doesn't, as far as I can tell, vary once the the machine is booted - it
doesn't change after that - but it does look like it needs to be checked at
the start of each boot session (i.e., right after the machine has been
booted).

-- 
    Nov 4, 2008 - the day when everything went
    from being Clinton's fault to being Obama's fault.

[toc] | [prev] | [next] | [standalone]

#14712

Chris wrote on 03. May 2015:
>
>> I tried both, "nokmsboot" and "vga=0" at the boot prompt. None produces
>> the result I hoped for. Not even when I pass both to the kernel at the
>> same boot.
>
> My computer has a budget 5450 radeon graphics card and uses the open
> source xorg driver. Wheezy.
> In file
> /etc/modprobe.d/radeon-kms.conf
> the line
> options radeon modeset=1
> results in teeny tiny text in virtual consoles and
> allows sound through the HDMI connection
>
> the line
> options radeon modeset=0
> gives the old vga low-resolution 80x25 character text in consoles and
> disables HDMI sound.

I tried that and I also get the low-resolution text. But then X won't
come up. Getting

| [KMS] drm report modesetting isn't supported.

in the Xorg log.

I set "modeset=1" again. And will investigate this weekend if there isn't
a way to have both.
-- 
Andreas

I use a Unix based operating system, which means I get laid almost as often as I
have to reboot my computer.

[toc] | [prev] | [next] | [standalone]

#14713

On Tuesday 05 May 2015 22:45, Andreas Kohlbach conveyed the following to 
comp.os.linux.misc...

> Chris wrote on 03. May 2015:
>>
>>> I tried both, "nokmsboot" and "vga=0" at the boot prompt. None
>>> produces the result I hoped for. Not even when I pass both to the
>>> kernel at the same boot.
>>
>> My computer has a budget 5450 radeon graphics card and uses the open
>> source xorg driver. Wheezy.
>> In file
>> /etc/modprobe.d/radeon-kms.conf
>> the line
>> options radeon modeset=1
>> results in teeny tiny text in virtual consoles and
>> allows sound through the HDMI connection
>>
>> the line
>> options radeon modeset=0
>> gives the old vga low-resolution 80x25 character text in consoles and
>> disables HDMI sound.
> 
> I tried that and I also get the low-resolution text. But then X won't
> come up. Getting
> 
> | [KMS] drm report modesetting isn't supported.
> 
> in the Xorg log.
> 
> I set "modeset=1" again. And will investigate this weekend if there
> isn't a way to have both.

If you want high resolution graphics in X without using a modesetting 
driver, then you must blacklist the modesetting driver ─ in your case, 
that's "radeon" ─ and use the proprietary driver for X ─ in your case, 
fglrx.

-- 
= Aragorn =

         http://www.linuxcounter.net - registrant #223157

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.os.linux.misc

csiph-web