X on tty1 in Rawhide/F10

[Gerd Hoffmann]

Jesse Keating wrote:
> On Tue, 2008-10-28 at 18:38 +0100, Ralf Corsepius wrote:
>> Once more, your "F1 fetish" to me is a silly, avoidable change, whose
>> only feature it is to break documentations, habits and to add further
>> hassle.  A completely superfluous change.
> 
> As noted multiple times on this thread, the change prevents the
> multi-second monitor refresh issues when mode is changed by vt switches.

The flicker / resync delay comes from the *mode switch*, not the *vt
switch*.  And, no, a vt switch does *not* imply a mode switch.

The reason you'll have flicker today when switching from/to X11 is that
X11 does a mode switch when you switch from/to the terminal X11 is
running on.

I havn't played with kernel mode setting yet, but I'd expect kernel mode
setting killing that mode switch because ...

  (a) you'll drive all your text consoles and the X11 screen in the
      very same video mode and
  (b) X11 doesn't play with video modes any more because that is the
     kernels job now and
  (c) the kernel knows it doesn't need to switch the video mode.

If that isn't the case you are doing something very wrong.

Make an experiment, using "poor mans kernel mode setting" aka linux
framebuffer:

 (1) Grab any box next to you.  F8, F9, RHEL-5, whatever,
     doesn't matter, should work with any.
 (2) Setup the machine to boot using vesafb: add
     vga=0x314 (800x600) or vga=0x317 (1024x768) to the kernel
     command line.
 (3) Setup X11 to use the fbdev driver.

Reboot the machine.  When it is done, switch between X11 and text
consoles.  Notice the mode switch and thus the flicker is gone.

Probably you have to make plymouth draw its nice graphics on tty7
instead of tty1 to maintain the fancy cross fading effect when starting
X11 in tty7.  Shouldn't be a big deal though, if plymouth does that vt
switch right after KMS entered graphics mode and before printing
anything on the screen it should went unnoticed.

cheers,
  Gerd