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

Groups > linux.debian.user > #184081 > unrolled thread

video driver - new thread

Back to article view | Back to linux.debian.user

Contents

  video driver - new thread "D. R. Evans" <doc.evans@gmail.com> - 2017-07-22 19:50 +0200
    Re: video driver - new thread Hans <hans.ullrich@loop.de> - 2017-07-22 20:00 +0200
      Re: video driver - new thread "D. R. Evans" <doc.evans@gmail.com> - 2017-07-22 21:20 +0200
    Re: video driver - new thread Reco <recoverym4n@gmail.com> - 2017-07-22 20:40 +0200
      Re: video driver - new thread "D. R. Evans" <doc.evans@gmail.com> - 2017-07-22 21:10 +0200
        Re: video driver - new thread Felix Miata <mrmazda@earthlink.net> - 2017-07-22 21:30 +0200
          Re: video driver - new thread Curt <curty@free.fr> - 2017-07-22 22:00 +0200
            Re: video driver - new thread Felix Miata <mrmazda@earthlink.net> - 2017-07-22 22:30 +0200
              Re: video driver - new thread Greg Wooledge <wooledg@eeg.ccf.org> - 2017-07-24 15:10 +0200
                Re: video driver - new thread Darac Marjal <mailinglist@darac.org.uk> - 2017-07-24 15:30 +0200
                  Re: video driver - new thread Greg Wooledge <wooledg@eeg.ccf.org> - 2017-07-24 15:50 +0200
                    Re: video driver - new thread Henrique de Moraes Holschuh <hmh@debian.org> - 2017-07-24 17:20 +0200
    Re: video driver - new thread "D. R. Evans" <doc.evans@gmail.com> - 2017-07-24 02:00 +0200
      Re: video driver - new thread David Wright <deblis@lionunicorn.co.uk> - 2017-07-24 02:40 +0200
      Re: video driver - new thread Felix Miata <mrmazda@earthlink.net> - 2017-07-24 04:30 +0200
        [SOLVED] - Re: video driver - new thread "D. R. Evans" <doc.evans@gmail.com> - 2017-07-25 21:20 +0200
          Re: [SOLVED] - Re: video driver - new thread <tomas@tuxteam.de> - 2017-07-25 21:50 +0200
            Re: [SOLVED] video driver - new thread Felix Miata <mrmazda@earthlink.net> - 2017-07-26 03:50 +0200

#184081 — video driver - new thread

[Multipart message — attachments visible in raw view] — view raw

As my old thread has been hijacked, I thought that I'd better start a new one.

Teemu Likonen wrote on 07/17/2017 03:09 PM:
> D. R. Evans [2017-07-17 14:19:32-06] wrote:
>
>> Beginning a couple of weeks ago, I started to experience occasional freezes or
>> sudden blank screens on my 64-bit jessie system.
>
>> Jul 17 13:58:23 homebrew kernel: [24262.075187] nouveau E[     DRM] GPU lockup
>> - switching to software fbcon
>>
>> I don't know how a particular driver gets chosen by the system, but is there a
>> different driver I could try?
>
> I have an Nvidia card and experienced complete lockups with nouveau
> driver. Solution: Install nvidia-driver packages and all is working
> well. Just one additional problem: non-free software.
>

I have installed the nvidia-driver package.

At that point X did not start on boot, so I installed nvidia-xconfig and ran
it. It gave half a dozen errors, but on reboot X started and looks good.

How do I confirm that I am actually using the proprietary driver rather than
nouveau?

I am 99+% sure that the proprietary driver is being used, because the screen
looks quite different during the boot sequence, and slightly different once I
have a desktop. But I'd like to know how to confirm the fact.

Thanks to people for their helpful suggestions about installing the
proprietary driver (sorry it took so long to actually get it done: I had some
work in progress for a client, and didn't want to run a risk of ending up
without a working graphical desktop. That work ended yesterday, so this is the
first time it's felt safe to try the switch to the new driver.)

  Doc

-- 
Web:  http://enginehousebooks.com/drevans

[toc] | [next] | [standalone]

#184082

Maybe try to add a file /etc/X11/xorg.conf (ask google, how it has to look), 
and in it set the driver "nvidia".

Make sure, the nouveau kernel driver is blacklisted.

BTW: Is the proprietrary driver compatible with latest xserver-xorg again?

Best regards

Hans 
> Thanks to people for their helpful suggestions about installing the
> proprietary driver (sorry it took so long to actually get it done: I had
> some work in progress for a client, and didn't want to run a risk of ending
> up without a working graphical desktop. That work ended yesterday, so this
> is the first time it's felt safe to try the switch to the new driver.)
> 
>   Doc

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

#184085

[Multipart message — attachments visible in raw view] — view raw

Hans wrote on 07/22/2017 11:55 AM:
> Maybe try to add a file /etc/X11/xorg.conf (ask google, how it has to look), 
> and in it set the driver "nvidia".
> 

nvidia-xconfig created such a file, and the driver in it is set to "nvidia",
so I think that is indeed the confirmation I was looking for.

Thank you.

> Make sure, the nouveau kernel driver is blacklisted.
> 

How do I do that? (Although it doesn't seem to be necessary.)

> BTW: Is the proprietrary driver compatible with latest xserver-xorg again?
> 

I have no idea how to answer that, I'm afraid. If you can tell me what
commands I should try in order to get that information, I'll happily try them.

The system here (jessie, 64-bit) is completely up to date, so it should be
using the latest version of everything that is supported in jessie.

(It's on my to-do list to move to stretch, but given that the first system on
which I tried that produced a not-particularly-pleasant experience, with one
issue still unresolved, I'm waiting for a bit before upgrading my main desktop
system.)

  Doc

-- 
Web:  http://enginehousebooks.com/drevans

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

#184083

	Hi.

On Sat, 22 Jul 2017 11:48:42 -0600
"D. R. Evans" <doc.evans@gmail.com> wrote:

> As my old thread has been hijacked, I thought that I'd better start a new one.
> 
> Teemu Likonen wrote on 07/17/2017 03:09 PM:
> > D. R. Evans [2017-07-17 14:19:32-06] wrote:
> >
> >> Beginning a couple of weeks ago, I started to experience occasional freezes or
> >> sudden blank screens on my 64-bit jessie system.
> >
> >> Jul 17 13:58:23 homebrew kernel: [24262.075187] nouveau E[     DRM] GPU lockup
> >> - switching to software fbcon
> >>
> >> I don't know how a particular driver gets chosen by the system, but is there a
> >> different driver I could try?
> >
> > I have an Nvidia card and experienced complete lockups with nouveau
> > driver. Solution: Install nvidia-driver packages and all is working
> > well. Just one additional problem: non-free software.
> >
> 
> I have installed the nvidia-driver package.
> 
> At that point X did not start on boot, so I installed nvidia-xconfig and ran
> it. It gave half a dozen errors, but on reboot X started and looks good.
> 
> How do I confirm that I am actually using the proprietary driver rather than
> nouveau?

grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log

If you see nvidia in the result - you're using proprietary driver.

Reco

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

#184084

[Multipart message — attachments visible in raw view] — view raw

Reco wrote on 07/22/2017 12:37 PM:
> grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log

[HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log
grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or directory
[HN:~]

  Doc

-- 
Web:  http://enginehousebooks.com/drevans

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

#184086

D. R. Evans composed on 2017-07-22 13:06 (UTC-0600):

> Reco wrote:

>> grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log

> [HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log
> grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or directory
> [HN:~]
> 

I don't know why he suggested that:

$ inxi -c0 -G
Graphics:  Card: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated
Graphics Controller
           Display Server: X.Org 1.17.2 drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1200@60.0hz
           GLX Renderer: Mesa DRI Intel Haswell Desktop GLX Version: 3.0 Mesa 11.0.8

# grep glx /var/log/Xorg.[0-9]*.log
/var/log/Xorg.0.log:[    22.700] (II) LoadModule: "glx"
/var/log/Xorg.0.log:[    22.701] (II) Loading
/usr/lib64/xorg/modules/extensions/libglx.so
/var/log/Xorg.0.log:[    22.727] (II) Module glx: vendor="X.Org Foundation"
/var/log/Xorg.1.log:[2946089.809] (II) LoadModule: "glx"
/var/log/Xorg.1.log:[2946089.809] (II) Loading
/usr/lib64/xorg/modules/extensions/libglx.so
/var/log/Xorg.1.log:[2946089.810] (II) Module glx: vendor="X.Org Foundation"

If the NVidia driver is in use, Xorg.[0-9].log will have /many/ lines in
sequence that include:

	NVIDIA(0)

If Nouveau:

	NOUVEAU(0)

If modesetting:

	MODESET(0)

If Intel:

	INTEL(0)

# grep -i MODESET /var/log/Xorg.0.log | wc -l
233

If Radeon:

	RADEON(0)

If Amdgpu

	AMDGPU(0)
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#184087

On 2017-07-22, Felix Miata <mrmazda@earthlink.net> wrote:
> D. R. Evans composed on 2017-07-22 13:06 (UTC-0600):
>
>> Reco wrote:
>
>>> grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log
>
>> [HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log
>> grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or directory
>> [HN:~]
>> 
>
> I don't know why he suggested that:
>

KMS rootless X indeed puts the log in ~/.local/share/xorg. As it's
enabled by default for the nouveau driver since Squeeze, the "No such
file or directory" message indicates the OP is using the proprietary
driver, for which KMS must be enabled manually.

Kind of a roundabout, teach a fish to fly kind of thing, but Reco is
twisted.

Actually just kidding.

How 'bout

 grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log

But then if the OP had been using the nouveau driver, he'd get a "No such
file or directory" message.

Now a word from our sponsor.

-- 
“We’ll sit around talking about the good old days, when we wished that we were dead.”
--Samuel Beckett, speculating on the nature of the afterlife.

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

#184089

Curt composed on 2017-07-22 15:58 (UTC-0400):

> Felix Miata wrote:

>> D. R. Evans composed on 2017-07-22 13:06 (UTC-0600):

>>> Reco wrote:

>>>> grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log

>>> [HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log
>>> grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or directory
>>> [HN:~]

>> I don't know why he suggested that:

> KMS rootless X indeed puts the log in ~/.local/share/xorg. As it's
> enabled by default for the nouveau driver since Squeeze, the "No such
> file or directory" message indicates the OP is using the proprietary
> driver, for which KMS must be enabled manually.

Rather than "suggested that" I should have written "suggested glx as search string".

I don't often here fail to find a current /var/log/Xorg.0.log. I think what's
happening is the one in .local/share/ is getting copied to /var/log/ so that it
remains available in the location people historically expect, where Googling
will suggest to look, plus the typing is easier with no shifts required and
fewer characters to type.

> Kind of a roundabout, teach a fish to fly kind of thing, but Reco is
> twisted.

> Actually just kidding.

> How 'bout

>  grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log

Is a mere mortal going to know, seeing the following, which driver is actually
in use?

# grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log
[    22.731] (II) Module modesetting: vendor="X.Org Foundation"
..
[    22.731] (II) Module fbdev: vendor="X.Org Foundation"
..
[    22.731] (II) Module vesa: vendor="X.Org Foundation"

Someone using a file viewer (e.g. MC -> F3) rather than grep is going to spot a
large mass of similar *(0) lines faster than one short string in a file with 300
or more lines.

Another grepping option:

# grep Output /var/log/Xorg.0.log
[    22.851] (II) modeset(0): Output VGA-0 has no monitor section
[    22.864] (II) modeset(0): Output HDMI-0 has no monitor section
[    22.864] (II) modeset(0): Output HDMI-1 has no monitor section
[    22.879] (II) modeset(0): Output VGA-0 disconnected
[    22.879] (II) modeset(0): Output HDMI-0 connected
[    22.879] (II) modeset(0): Output HDMI-1 disconnected
[    22.879] (II) modeset(0): Output HDMI-0 using initial mode 1920x1200

> But then if the OP had been using the nouveau driver, he'd get a "No such
> file or directory" message.

> Now a word from our sponsor.-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#184166

On Sat, Jul 22, 2017 at 04:27:42PM -0400, Felix Miata wrote:
> I don't often here fail to find a current /var/log/Xorg.0.log. I think what's
> happening is the one in .local/share/ is getting copied to /var/log/ so that it
> remains available in the location people historically expect, where Googling
> will suggest to look, plus the typing is easier with no shifts required and
> fewer characters to type.

Absolutely not true in my case.

wooledg:~$ ls -l /var/log/Xorg.0.log 
-rw-r--r-- 1 root root 46028 Apr 10 10:13 /var/log/Xorg.0.log
wooledg:~$ ls -l ~/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 wooledg voice 24472 Jul 24 08:10 /home/wooledg/.local/share/xorg/Xorg.0.log

How would your idea even *work*?  The X server can't write to /var/log
because it doesn't have EUID 0 privileges any more.  It writes to this
file in the home directory because that's the only place it's sure to
be able to open.

There's simply no short-cutting it: the X server's log can be in either
of these two places, and you need to check both.

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

#184169

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jul 24, 2017 at 08:59:56AM -0400, Greg Wooledge wrote:
>On Sat, Jul 22, 2017 at 04:27:42PM -0400, Felix Miata wrote:
>> I don't often here fail to find a current /var/log/Xorg.0.log. I think what's
>> happening is the one in .local/share/ is getting copied to /var/log/ so that it
>> remains available in the location people historically expect, where Googling
>> will suggest to look, plus the typing is easier with no shifts required and
>> fewer characters to type.
>
>Absolutely not true in my case.
>
>wooledg:~$ ls -l /var/log/Xorg.0.log
>-rw-r--r-- 1 root root 46028 Apr 10 10:13 /var/log/Xorg.0.log
>wooledg:~$ ls -l ~/.local/share/xorg/Xorg.0.log
>-rw-r--r-- 1 wooledg voice 24472 Jul 24 08:10 /home/wooledg/.local/share/xorg/Xorg.0.log
>
>How would your idea even *work*?

You'd need some sort of system logging daemon. Something which runs with
the privileges necessary to write to the log file, and which can accept
log messages from unprivileged processes, perhaps by listening on a UNIX
socket.

Just making a suggestion.

>The X server can't write to /var/log because it doesn't have EUID 0
>privileges any more.  It writes to this file in the home directory
>because that's the only place it's sure to be able to open.
>
>There's simply no short-cutting it: the X server's log can be in either
>of these two places, and you need to check both.
>

-- 
For more information, please reread.

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

#184171

On Mon, Jul 24, 2017 at 02:20:08PM +0100, Darac Marjal wrote:
> You'd need some sort of system logging daemon. Something which runs with
> the privileges necessary to write to the log file, and which can accept
> log messages from unprivileged processes, perhaps by listening on a UNIX
> socket.

Like syslogd, you mean.  Which X doesn't use.

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

#184175

On Mon, 24 Jul 2017, Greg Wooledge wrote:
> On Mon, Jul 24, 2017 at 02:20:08PM +0100, Darac Marjal wrote:
> > You'd need some sort of system logging daemon. Something which runs with
> > the privileges necessary to write to the log file, and which can accept
> > log messages from unprivileged processes, perhaps by listening on a UNIX
> > socket.
> 
> Like syslogd, you mean.  Which X doesn't use.

You can redirect the stdout/stderr from the xserver to a pipe, and
rsyslogd can be happily configured to read from that pipe and write to
the system logger.

Or you can just use xconsole and the like.

-- 
  Henrique Holschuh

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

#184154

[Multipart message — attachments visible in raw view] — view raw

D. R. Evans wrote on 07/22/2017 11:48 AM:

> I am 99+% sure that the proprietary driver is being used, because the screen
> looks quite different during the boot sequence, and slightly different once I

I have discovered that if I open a console after switching to the NVIDIA
driver, the text is huge.

I tried this solution (for Arch; I saw some posts about Debian, but nothing
that seemed to be a definitive solution):

https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution

and added the following two lines to the grub configuration file:

GRUB_GFXMODE=1280x1024x16,1024x768,auto
GRUB_GFXPAYLOAD_LINUX=keep

that had the effect of making the font considerably better during booting, but
I no longer saw a graphical login screen, and switching manually to the :
0
display with ctrl-alt-F7 just gave me a blank screen. (I chose the
1280x1024x16 number more or less at random, just to try it and see what it
looked like.)

So I have removed those two lines, and returned to having a massive console
font (but a working desktop), but am wondering what the right way is in debian
jessie to get a more reasonable size of font on the console while still having
a desktop.

FWIW, my (KDE) desktop resolution is 1920x1200.

And if I execute
  hwinfo --framebuffer
I get:

----

root@homebrew:/home/n7dr# hwinfo --framebuffer
02: None 00.0: 11001 VESA Framebuffer
  [Created at bios.459]
  Unique ID: rdCR.jdAEt395qn6
  Hardware Class: framebuffer
  Model: "NVIDIA GK208 Board - 21310000"
  Vendor: "NVIDIA Corporation"
  Device: "GK208 Board - 21310000"
  SubVendor: "NVIDIA"
  SubDevice:
  Revision: "Chip Rev"
  Memory Size: 14 MB
  Memory Range: 0xe9000000-0xe9dfffff (rw)
  Mode 0x0300: 640x400 (+640), 8 bits
  Mode 0x0301: 640x480 (+640), 8 bits
  Mode 0x0303: 800x600 (+800), 8 bits
  Mode 0x0305: 1024x768 (+1024), 8 bits
  Mode 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 0x0317: 1024x768 (+2048), 16 bits
  Mode 0x0318: 1024x768 (+4096), 24 bits
  Mode 0x031a: 1280x1024 (+2560), 16 bits
  Mode 0x031b: 1280x1024 (+5120), 24 bits
  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 0x0345: 1600x1200 (+1600), 8 bits
  Mode 0x0346: 1600x1200 (+3200), 16 bits
  Mode 0x034a: 1600x1200 (+6400), 24 bits
  Config Status: cfg=new, avail=yes, need=no, active=unknown
root@homebrew:/home/n7dr#

----

  Doc

-- 
Web:  http://enginehousebooks.com/drevans

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

#184156

On Sun 23 Jul 2017 at 17:52:19 (-0600), D. R. Evans wrote:
> D. R. Evans wrote on 07/22/2017 11:48 AM:
> 
> > I am 99+% sure that the proprietary driver is being used, because the screen
> > looks quite different during the boot sequence, and slightly different once I
> 
> I have discovered that if I open a console after switching to the NVIDIA
> driver, the text is huge.
> 
> I tried this solution (for Arch; I saw some posts about Debian, but nothing
> that seemed to be a definitive solution):
> 
> https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution
> 
> and added the following two lines to the grub configuration file:
> 
> GRUB_GFXMODE=1280x1024x16,1024x768,auto
> GRUB_GFXPAYLOAD_LINUX=keep
> 
> that had the effect of making the font considerably better during booting, but
> I no longer saw a graphical login screen, and switching manually to the :0
> display with ctrl-alt-F7 just gave me a blank screen. (I chose the
> 1280x1024x16 number more or less at random, just to try it and see what it
> looked like.)
> 
> So I have removed those two lines, and returned to having a massive console
> font (but a working desktop), but am wondering what the right way is in debian
> jessie to get a more reasonable size of font on the console while still having
> a desktop.

I use setfont. One advantage is that you can set different fonts
on different consoles. Having xfonts-terminus installed, I use

alias my-font-vast='setfont Lat15-Terminus32x16'
alias my-font-huge='setfont Lat15-Terminus28x14'
alias my-font-large='setfont Lat15-Terminus24x12'
alias my-font-medium='setfont Lat15-Terminus20x10'
alias my-font-small='setfont Lat15-Terminus14'
alias my-font-tiny='setfont Lat15-Terminus12x6'

and I have the bash function

my-font-usr-share-consolefonts

set up so that I can use command completion to remind me where
the fonts are. This function loads an arbitrary font (by file
completion) from that directory. The meat of the function is
local FILENAME="$(basename "$1")"; setfont "${FILENAME%%.*}"

Cheers,
David.

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

#184157

D. R. Evans composed on 2017-07-23 17:52 (UTC-0600):

> D. R. Evans wrote:

>> I am 99+% sure that the proprietary driver is being used, because the screen
>> looks quite different during the boot sequence, and slightly different once I

> I have discovered that if I open a console after switching to the NVIDIA
> driver, the text is huge.

The NVidia driver /directly/ affects only Xorg, not the vttys.

That said, a very likely explanation for the huge text is that the proprietary
nvidia driver installation resulted in placement of the string nomodeset on the
kernel cmdline via a reconfiguration of /boot/grub/grub.cfg at the least and
probably also /etc/default/grub. Checking kernel cmdline content can be done
with 'cat /proc/cmdline' or inspecting the top few lines of the Xorg.0.log file.

A brief test here, without any installed proprietary anything, and with nothing
on the kernel cmdline to affect video modes anywhere, except for nomodeset,
shows the result of

	ll /dev/fb*

to be

	ls: cannot access /dev/fb*: No such file or directory.

and the vttys to be running in 80x25 ("giant") text mode. Translated, lack of
/dev/fb* means there is no framebuffer for the kernel to use to produce the
nominal default size 16 vtty text in a likable physical size using a mode
appropriate for a 1920x1200 display. As long as a proprietary driver needs
kernel modesetting disabled, then to have something other than 80x25 on the
vttys requires /something/ to select what configuration will be used via the
kernel cmdline.

To find the mode currently in use on a vtty, normally a simple

	fbset

works.

> I tried this solution (for Arch; I saw some posts about Debian, but nothing
> that seemed to be a definitive solution):

> https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution

> and added the following two lines to the grub configuration file:

> GRUB_GFXMODE=1280x1024x16,1024x768,auto
> GRUB_GFXPAYLOAD_LINUX=keep

> that had the effect of making the font considerably better during booting, but
> I no longer saw a graphical login screen, and switching manually to the :0
> display with ctrl-alt-F7 just gave me a blank screen. (I chose the
> 1280x1024x16 number more or less at random, just to try it and see what it
> looked like.)

I wouldn't expect those lines to override X in Jessie. Which DM is installed,
GDM? SDDM? LightDM? KDM?

> So I have removed those two lines, and returned to having a massive console
> font (but a working desktop), but am wondering what the right way is in debian
> jessie to get a more reasonable size of font on the console while still having
> a desktop.
The cited URL has more to offer than what you reported. It shows a fallback to
deprecated vtty mode control via the vga= option, thus:

	"GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"

Testing Jessie here, vga=792 produces "undefined mode number". 791 produces 16
bit 1024x768, a much more agreeable text size than 80x25. 794 produces 16 bit
1280x1024, so smaller yet text. 1920x1200 is not possible via vga=, as it's
limited to VESA standard modes, none of which are widescreen.

> FWIW, my (KDE) desktop resolution is 1920x1200.

While David Wright's method of controlling text on the vttys is valid, it's a
lot simpler for people who don't use the vttys much to control their vtty modes
via kernel cmdline, thus Grub.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#184236 — [SOLVED] - Re: video driver - new thread

[Multipart message — attachments visible in raw view] — view raw

Felix Miata wrote on 07/23/2017 08:26 PM:

> 
>> I tried this solution (for Arch; I saw some posts about Debian, but nothing
>> that seemed to be a definitive solution):
> 
>> https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution
> 

[material elided]

> The cited URL has more to offer than what you reported. It shows a fallback to
> deprecated vtty mode control via the vga= option, thus:
> 
> 	"GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"
> 

Right. I didn't mention that earlier for two reasons:
  1. the allowed numbers (e.g., 792) seemed like pure magic, with no
explanation of how the numbers are calculated or their precise meaning;
  2. as you say, it is deprecated, so I didn't want to rely on something that
might go away.

However, since it seemed to work for you, I tried it (with "794") and it works
fine. In particular, opening :0 and :1 works properly, unlike the case when I
used the GRUB_GFXMODE option. The console text is still quite a bit larger
than it was when using nouveau, but it's acceptable. So I now consider the
problem solved. Thank you very much for your patience.

  Doc

-- 
Web:  http://enginehousebooks.com/drevans

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

#184237 — Re: [SOLVED] - Re: video driver - new thread

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jul 25, 2017 at 01:15:48PM -0600, D. R. Evans wrote:
> Felix Miata wrote on 07/23/2017 08:26 PM:
> 
> > 
> >> I tried this solution (for Arch; I saw some posts about Debian, but nothing
> >> that seemed to be a definitive solution):
> > 
> >> https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution
> > 
> 
> [material elided]
> 
> > The cited URL has more to offer than what you reported. It shows a fallback to
> > deprecated vtty mode control via the vga= option, thus:
> > 
> > 	"GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"
> > 
> 
> Right. I didn't mention that earlier for two reasons:
>   1. the allowed numbers (e.g., 792) seemed like pure magic, with no
> explanation of how the numbers are calculated or their precise meaning;

Maybe you're looking for this:

  https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAll3oFQACgkQBcgs9XrR2kaxCwCeI3GzvUD6/J5an9j1RNXrQBuP
UFYAnRJ6YraMYZAza/jSO9ycMslV9Z2H
=xu4N
-----END PGP SIGNATURE-----

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

#184257 — Re: [SOLVED] video driver - new thread

tomas@tuxteam.de composed on 2017-07-25 21:47 (UTC+0200):

> On Tue, Jul 25, 2017 at 13:15:48 -0600, D. R. Evans wrote:

>> Felix Miata wrote:
...
>>>> https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution
...
>>> The cited URL has more to offer than what you reported. It shows a fallback to
>>> deprecated vtty mode control via the vga= option, thus:

>>> 	"GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"
>>> 

>> Right. I didn't mention that earlier for two reasons:
>>   1. the allowed numbers (e.g., 792) seemed like pure magic, with no

The magic is in legacy support. :-D

Those numbers were the standard valid method of specifying framebuffer modes
with Lilo, when Grub was born >2 decades ago.

>> explanation of how the numbers are calculated or their precise meaning;

> Maybe you're looking for this:

>   https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers

That includes a superset of hex values at
http://tldp.org/HOWTO/Framebuffer-HOWTO/x168.html
converted to decimal. Set

	vga=ask

to get your kernel to list the modes your video bios supports. 796 (0x31C)
likely can provide yet smaller text in 8 bit color, 798 (0x31E) in 16, 799
(0x31F) in 24. I've yet to observe a use for more than 8 bit color in a vtty.

Note that vga= only works in the framebuffers because KMS has been disabled via
nomodeset (or gfxchip-specific equivalent) in order to enable a proprietary Xorg
video driver. It's rarely needed with FOSS drivers except temporarily for
occasional troubleshooting. It does also work briefly as init starts even with
KMS enabled, but may not be noticed if plymouth is enabled. Once KMS actually
starts, the vga= configuration disappears.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web