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

Groups > linux.debian.user > #184157

Re: video driver - new thread

Show all headers | View raw

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/

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web