14

When I boot up my desktop computer, which only has Linux on it, the video mode and/or console font gets switched four times:

  • When GRUB starts, it switches from 80x25 text to a graphical mode so it can draw a pretty background behind its menu;
  • GRUB then goes back to 80x25 text after I pick something from the menu;
  • When the KMS driver for my video card loads, it switches to a much higher-resolution text mode (I don't know if this is a hardware text mode or not);
  • Finally X starts and it goes graphics and stays that way. I think this last switch does not change the resolution of the video mode, only the graphicalness.

I'd like to get rid of as many of these mode switches as possible. Ideally, when GRUB takes over from the BIOS it would go directly to the same high-resolution text mode that the KMS driver selects, and the display would stay in that mode till X starts and brings up graphics. I am under the impression that this is possible by mucking with the kernel command line and/or the GRUB console module load parameters, but I don't know the details.

GRUB 1.98+20100706, kernel 2.6.32.15 using Nouveau video drivers. Distro is Debian unstable. Please no answers that involve recompiling anything or cobbling together bleeding-edge kernel/driver combinations, I don't care enough about this to go to that much trouble.

EDIT: Tobu suggests setting GRUB_GFXMODE to the full pixel resolution of the monitor, and GRUB_GFXPAYLOAD_LINUX=keep to avoid the mode switch after the menu goes away. This does part of what I want, but winds up being worse overall. There's no mode switch after the menu, but there's still a painfully-slow screen repaint (I should probably just give up on GRUB's gfxmode, it's waaaay too slow at 1920x1200). More seriously, there's now a double mode switch when nouveaufb loads, along with fun-looking error messages in dmesg

[    5.923798] [drm] nouveau 0000:02:00.0: allocated 1920x1200 fb: 0x40250000, bo ffff8801ba5f4600
[    5.923802] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver
[    5.923821] [drm] nouveau 0000:02:00.0: PFIFO_INTR 0x00000010 - Ch 1
("PFIFO_INTR" message repeats 400+ times)
[    5.925609] Console: switching to colour dummy device 80x25
[    5.925802] Console: switching to colour frame buffer device 240x75
2
  • I'm curious what "graphicalness" is. Jul 12, 2010 at 20:48
  • 1
    For any given pixel resolution, a video mode could be graphical (each individual pixel is addressable) or text (simulates a character-cell terminal from elder days). What I meant by "graphicalness" was, the fourth video mode switch I listed goes from text to graphical without changing pixel resolution, I think anyway.
    – zwol
    Jul 12, 2010 at 21:27

4 Answers 4

3

Plymouth is designed to help in this regards:

The idea is that early on in the boot process the native mode for the computer is set, plymouth uses that mode, and that mode stays throughout the entire boot process up to and after X starts. Ideally, the goal is to get rid of all flicker during startup.

As you only have a single OS installed, disabling the grub resolution changes (no background graphic), and even the menu itself, leaving it 80x25 would result in no change until Plymouth takes over.

1

Probe your resolution and your colour depth:

xrandr -q
xdpyinfo | grep 'depth of root window' | awk '{ print $5 }'

Set GRUB_GFXMODE=<width>x<height>x<depth> in /etc/default/grub so that the grub menu resolution matches the KMS resolution.

Maybe add GRUB_GFXPAYLOAD_LINUX=keep to the defaults as well, so that there is no intermediate step after the grub menu and before setting up KMS. X11 should keep what KMS uses, meaning there is no X11 switch to worry about.

Apply your edits with

sudo update-grub
1
  • Thanks! This did part of what I want, but had negative side effects that made it worse than the status quo. I added the details to the question.
    – zwol
    Jul 12, 2010 at 22:59
0

You can have KMS active from just after GRUB, and this usually will include a parameter to the kernel command line that turns it on. For intel, it's i910.modeset=1, but beyond you'd have to check your distribution's docs on this.

5
  • KMS is active from when the nouveau driver is loaded, I believe, but that happens only during udev's initial device scan, some time after userspace is running. I messed around with video= and vga= command line options a bit but didn't have any luck.
    – zwol
    Jul 12, 2010 at 21:35
  • You can tell it to load before then with this method
    – Daenyth
    Jul 13, 2010 at 3:34
  • Short of rebuilding the kernel with the nouveau module compiled in (which is too much trouble) the best I've been able to do is stick nouveau in /etc/initramfs-tools/modules ... but all that does is move the double mode switch earlier, from inside "Waiting for /dev to be populated" to right after "Loading, please wait..." The goal is to eliminate mode switches.
    – zwol
    Jul 13, 2010 at 17:48
  • In that case you need to use a boot loader which is capable of KMS. I think grub2 may do this, but if it does not, then you're completely out of luck.
    – Daenyth
    Jul 13, 2010 at 21:27
  • grub2 does set the mode and leave it set (that's what GRUB_GFXPAYLOAD_LINUX=keep accomplishes) but that is somehow not good enough for nouveau and/or the fb subsystem, hence the "Conflicting fb hw usage" error messages. Incidentally, exactly the same behavior with i915 on my laptop.
    – zwol
    Jul 13, 2010 at 22:02
0

You can add nomodeset to your kernel's command-line parameters.

nomodeset
Disable kernel modesetting. Most systems' firmware sets up a display mode and provides framebuffer memory for output. With nomodeset, DRM and fbdev drivers will not load if they could possibly displace the pre-initialized output. Only the system framebuffer will be available for use. The respective drivers will not perform display-mode changes or accelerated rendering.

The parameter does come with tradeoffs since many graphics features provided by (non-firmware) graphics drivers may be unavailable.

  • Hardware-accelerated video codecs.
  • Hardware-accelerated 3D-rendering.
  • Power saving features of connected monitor(s).

Exactly what is affected depends on both hardware/firmware capabilities and installed drivers/software.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .