Bug#686528: linux-image-3.2.0-3-486: doesn't understand modes passed via GRUB_GFXPAYLOAD_LINUX in /etc/default/grub
Package: src:linux
Version: 3.2.23-1
Severity: normal
For some reason, lxfb doesn't understand the recommended method for setting the screen mode on non-KMS framebuffers via GRUB_GFXPAYLOAD_LINUX in /etc/default/grub. This, combined with the fact that lxfb recently started to ship as a compiled-in feature, rather than as a module, systematically results in this host booting to a rather small 80x30 console, rather than a graphic framebuffer at a larger resolution.
... which works fine whenever vesafb use is enforced over lxfb via cmdline option video=vesafb, but fails whenever I let the kernel choose lxfb as its preferred driver.
-- Package-specific info:
** Version:
Linux version 3.2.0-3-486 (Debian 3.2.23-1) (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 Mon Jul 23 02:47:49 UTC 2012
** USB devices:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 03f9:0100 KeyTronic Corp. KT-2001 Keyboard
Kernel: Linux 3.2.0-3-486
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-image-3.2.0-3-486 depends on:
ii debconf [debconf-2.0] 1.5.46
ii initramfs-tools [linux-initramfs-tool] 0.107
ii kmod 9-1
ii linux-base 3.5
ii module-init-tools 9-1
Versions of packages linux-image-3.2.0-3-486 recommends:
ii firmware-linux-free 3.1
Versions of packages linux-image-3.2.0-3-486 suggests:
pn debian-kernel-handbook <none>
ii grub-pc 1.99-22.1
pn linux-doc-3.2 <none>
Versions of packages linux-image-3.2.0-3-486 is related to:
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
pn firmware-brcm80211 <none>
pn firmware-intelwimax <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
ii firmware-iwlwifi 0.36
pn firmware-libertas <none>
ii firmware-linux 0.36
ii firmware-linux-nonfree 0.36
pn firmware-myricom <none>
pn firmware-netxen <none>
pn firmware-qlogic <none>
pn firmware-ralink <none>
pn firmware-realtek <none>
pn xen-hypervisor <none>
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120902193847.3050.75316.reportbug@geode.lan">htt p://lists.debian.org/20120902193847.3050.75316.reportbug@geode.lan
09-02-2012, 08:26 PM
Ben Hutchings
Bug#686528: linux-image-3.2.0-3-486: doesn't understand modes passed via GRUB_GFXPAYLOAD_LINUX in /etc/default/grub
I'm cc'ing Andres because he's previously requested various Geode config
changes to support OLPC.
On Sun, 2012-09-02 at 22:38 +0300, Martin-Éric Racine wrote:
> Package: src:linux
> Version: 3.2.23-1
> Severity: normal
>
> For some reason, lxfb doesn't understand the recommended method for
> setting the screen mode on non-KMS framebuffers via
> GRUB_GFXPAYLOAD_LINUX in /etc/default/grub.
I think this hand-over only works with basic VGA and VESA drivers, not
with any 'native' video driver.
> This, combined with the fact that lxfb recently started to ship as a
> compiled-in feature, rather than as a module,
It looks like lxfb was always built-in on the 486 flavour and modular on
the 686 flavour, so this change results from the removal of the 686
flavour. I don't see any good reason for the difference and I think it
should be modular on 486 too. (Also, I notice that the Geode
framebuffer drivers are enabled on the 686-pae flavour, which doesn't
run on any of the Geode SoCs!)
> systematically results in this host booting to a rather small 80x30
> console, rather than a graphic framebuffer at a larger resolution.
>
> What I have configuered:
>
> GRUB_GFXMODE=800x600x32,800x600x24,800x600x16,800x 600x8,800x600
> GRUB_GFXPAYLOAD_LINUX=1280x1024x32,1280x1024x24,12 80x1024x16,1280x1024x8,1280x1024
>
> ... which works fine whenever vesafb use is enforced over lxfb via
> cmdline option video=vesafb, but fails whenever I let the kernel
> choose lxfb as its preferred driver.
Apparently the lxfb driver requires you to specify the mode through the
'lxfb' kernel parameter or the 'mode_option' module parameter.
Ben.
--
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of comp.compilers
09-03-2012, 12:45 AM
Andres Salomon
Bug#686528: linux-image-3.2.0-3-486: doesn't understand modes passed via GRUB_GFXPAYLOAD_LINUX in /etc/default/grub
On Sun, 02 Sep 2012 21:26:21 +0100
Ben Hutchings <ben@decadent.org.uk> wrote:
> I'm cc'ing Andres because he's previously requested various Geode
> config changes to support OLPC.
Thanks!
>
> On Sun, 2012-09-02 at 22:38 +0300, Martin-Éric Racine wrote:
> > Package: src:linux
> > Version: 3.2.23-1
> > Severity: normal
> >
> > For some reason, lxfb doesn't understand the recommended method for
> > setting the screen mode on non-KMS framebuffers via
> > GRUB_GFXPAYLOAD_LINUX in /etc/default/grub.
>
> I think this hand-over only works with basic VGA and VESA drivers, not
> with any 'native' video driver.
>
> > This, combined with the fact that lxfb recently started to ship as a
> > compiled-in feature, rather than as a module,
>
> It looks like lxfb was always built-in on the 486 flavour and modular
> on the 686 flavour, so this change results from the removal of the 686
> flavour. I don't see any good reason for the difference and I think
> it should be modular on 486 too. (Also, I notice that the Geode
> framebuffer drivers are enabled on the 686-pae flavour, which doesn't
> run on any of the Geode SoCs!)
I'd certainly prefer it to be modular. Module autoloading happens
properly thanks to the video chip being a (virtual) PCI device.
>
> > systematically results in this host booting to a rather small 80x30
> > console, rather than a graphic framebuffer at a larger resolution.
> >
> > What I have configuered:
> >
> > GRUB_GFXMODE=800x600x32,800x600x24,800x600x16,800x 600x8,800x600
> > GRUB_GFXPAYLOAD_LINUX=1280x1024x32,1280x1024x24,12 80x1024x16,1280x1024x8,1280x1024
> >
> > ... which works fine whenever vesafb use is enforced over lxfb via
> > cmdline option video=vesafb, but fails whenever I let the kernel
> > choose lxfb as its preferred driver.
>
> Apparently the lxfb driver requires you to specify the mode through
> the 'lxfb' kernel parameter or the 'mode_option' module parameter.
That's correct. On olpc, we need to boot with video=lxfb in order to
have the framebuffer come up properly. Maybe someday someone will port
lxfb to kms, but I'm not holding my breath.
09-03-2012, 01:19 AM
Ben Hutchings
Bug#686528: linux-image-3.2.0-3-486: doesn't understand modes passed via GRUB_GFXPAYLOAD_LINUX in /etc/default/grub
On Sun, 2012-09-02 at 17:45 -0700, Andres Salomon wrote:
[...]
> > > This, combined with the fact that lxfb recently started to ship as a
> > > compiled-in feature, rather than as a module,
> >
> > It looks like lxfb was always built-in on the 486 flavour and modular
> > on the 686 flavour, so this change results from the removal of the 686
> > flavour. I don't see any good reason for the difference and I think
> > it should be modular on 486 too. (Also, I notice that the Geode
> > framebuffer drivers are enabled on the 686-pae flavour, which doesn't
> > run on any of the Geode SoCs!)
>
> I'd certainly prefer it to be modular. Module autoloading happens
> properly thanks to the video chip being a (virtual) PCI device.
[...]
So long as it's not blacklisted, which it is by default
(/etc/modprobe.d/fbdev-blacklist.conf). Anyway, I think this means that
you'll both be happy if I make it modular.
Ben.
--
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.