Re: [gentoo-user] Re: SVGA mode the console

2011-01-04 Thread Paul Hartman
On Mon, Jan 3, 2011 at 5:22 PM, Nikos Chantziaras rea...@arcor.de wrote:
 On 01/03/2011 10:23 PM, Paul Hartman wrote:

 On Mon, Jan 3, 2011 at 2:07 PM, Nikos Chantziarasrea...@arcor.de  wrote:

 uvesafb will not give you extra resolutions.  It will however allow you
 to
 use non-default refresh-rates which is sometimes useful with CRT
 monitors.

 But it has a drawback too: it needs a userspace tool and resolution is
 switched too late during the boot process, meaning until it loads you'll
 be
 seeing the kernel boot in 80x25 mode (which in turn means no boot
 graphics/logo right from the start.)

 I use uvesafb and I can see Tux (eight of him) during my boot process
 before uvesafb kicks in.

 I mean more something like this when I say boot logo:

 http://mjanusz.files.wordpress.com/2008/02/shot.png

 It's at least 10 years since I saw that default Tux boot thingy :-P  But
 anyway, if uvesafb hasn't kicked in yet, what on earth is drawing that Tux?

Ah-ha, I think that's bootsplash (which I'm not using).  I've only
seen it on a Live CD. :)

In my kernel config I have enabled VESA framebuffer as well as
userspace framebuffer (uvesafb), and I enabled Bootup Logo. So maybe
what happens is that VESA framebuffer starts immediately into some
default resolution, I see eight Tuxs (Tuxes?), then shortly thereafter
the uvesafb kicks in and video mode changes to the one I specified. At
least that's how it seems to happen. I reboot so rarely that I never
gave it much thought.



Re: [gentoo-user] Re: SVGA mode the console

2011-01-04 Thread Alan McKinnon
Apparently, though unproven, at 18:03 on Tuesday 04 January 2011, Paul Hartman 
did opine thusly:

 On Mon, Jan 3, 2011 at 5:22 PM, Nikos Chantziaras rea...@arcor.de wrote:
  On 01/03/2011 10:23 PM, Paul Hartman wrote:
  On Mon, Jan 3, 2011 at 2:07 PM, Nikos Chantziarasrea...@arcor.de 
 wrote:
  uvesafb will not give you extra resolutions.  It will however allow you
  to
  use non-default refresh-rates which is sometimes useful with CRT
  monitors.
  
  But it has a drawback too: it needs a userspace tool and resolution is
  switched too late during the boot process, meaning until it loads
  you'll be
  seeing the kernel boot in 80x25 mode (which in turn means no boot
  graphics/logo right from the start.)
  
  I use uvesafb and I can see Tux (eight of him) during my boot process
  before uvesafb kicks in.
  
  I mean more something like this when I say boot logo:
  
  http://mjanusz.files.wordpress.com/2008/02/shot.png
  
  It's at least 10 years since I saw that default Tux boot thingy :-P  But
  anyway, if uvesafb hasn't kicked in yet, what on earth is drawing that
  Tux?
 
 Ah-ha, I think that's bootsplash (which I'm not using).  I've only
 seen it on a Live CD. :)
 
 In my kernel config I have enabled VESA framebuffer as well as
 userspace framebuffer (uvesafb), and I enabled Bootup Logo. So maybe
 what happens is that VESA framebuffer starts immediately into some
 default resolution, I see eight Tuxs (Tuxes?), then shortly thereafter
 the uvesafb kicks in and video mode changes to the one I specified. At
 least that's how it seems to happen. I reboot so rarely that I never
 gave it much thought.


It's the VESA framebuffer that does it, nothing to do with bootsplash.

Look at the help text for CONFIG_FB_VESA in menuconfig.


-- 
alan dot mckinnon at gmail dot com



Re: [gentoo-user] Re: SVGA mode the console

2011-01-03 Thread Paul Hartman
On Mon, Jan 3, 2011 at 2:07 PM, Nikos Chantziaras rea...@arcor.de wrote:
 uvesafb will not give you extra resolutions.  It will however allow you to
 use non-default refresh-rates which is sometimes useful with CRT monitors.

 But it has a drawback too: it needs a userspace tool and resolution is
 switched too late during the boot process, meaning until it loads you'll be
 seeing the kernel boot in 80x25 mode (which in turn means no boot
 graphics/logo right from the start.)

I use uvesafb and I can see Tux (eight of him) during my boot process
before uvesafb kicks in.



Re: [gentoo-user] Re: SVGA mode the console

2011-01-02 Thread meino . cramer
Nikos Chantziaras rea...@arcor.de [11-01-02 14:12]:
 On 01/02/2011 01:28 PM, meino.cra...@gmx.de wrote:
 Hi,
 
 there is a small linux distribution (GRML), which I use for rescue
 and other purposes. I installed it on a USB-stick.
 
 Furthermore installed in my PC there is a MSI GT430 (nvidia) graphics
 card and I use the nvidia-driver in conjunction with xorg 1.9.2.
 
 So far so nice...
 
 The GRML uses the noveau driver as far as I know.
 
 When I boot from my USB-stick I get a very nice high resolution
 linux console. It uses vga=791 on the kernel commandline.
 
 Nouveau uses KMS, which means it automatically uses the monitor's 
 native resolution and supports all resolutions the graphics card is 
 capable of.
 
 On your PC, you're using the VESA fb driver, not Nouveau KMS.  That 
 means you're limited to VESA resolutions for your consoles.  You can 
 use the vbetest utility to detect which modes your card's VESA BIOS 
 supports.  To use this tool, emerge the sys-libs/lrmi package.  
 Simply run the tool and it will print a list of modes you can use, and 
 the resolutions those modes correspond to.
 
 If your desired resolution is not in the list, then there's no way to 
 use that resolution in a VESA fb; you will need to switch to Nouveau's 
 KMS fb.
 
 

Hi Nikos,

unfortunately lrmi fails to compile.

Best regards,
mcc




Re: [gentoo-user] Re: SVGA mode the console

2011-01-02 Thread meino . cramer
Nikos Chantziaras rea...@arcor.de [11-01-02 16:12]:
 On 01/02/2011 03:57 PM, meino.cra...@gmx.de wrote:
 unfortunately lrmi fails to compile.
 
 In addition to what I wrote in my other reply, make sure you use a 
 32bit Live CD.  vbetest does not work with 64-bit kernels.
 
 Btw, if you're on a 32-bit Gentoo, you can compile lrmi on it.  Steps:
 
 Download 
 http://sourceforge.net/projects/lrmi/files/lrmi/0.10/lrmi-0.10.tar.gz/download
 
 Unpack it and apply the patch from Gentoo with:
 
   cd lrmi-0.10
   patch -p1  
 /usr/portage/sys-libs/lrmi/files/lrmi-0.10-kernel-2.6.26.patch
 
 Simply run make.  Now you can run it with: ./vbetest
 
 You don't need to install anything.  When you're done, simply delete 
 the lrmi-0.10 directory.
 
 

Hi Nikos,

unfortunately I am on a AMD64 Gentoo.

I will whether GRML has this tool...