Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#5103 - Console framebuffers

Attached to Project: Arch Linux
Opened by Aaron Griffin (phrakture) - Monday, 24 July 2006, 14:59 GMT
Task Type Feature Request
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I'm not sure when it happened, as I've been using vesafb for some time, but the additional framebuffers (radeonfb, nvidiafb, etc etc) are no longer part of the stock kernel. These are actually very important for those of us with non-standard resolutions and want them in framebuffer mode.

Please, when you release the next version, can you add these back into the kernel config?
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Tuesday, 06 February 2007, 13:48 GMT
Reason for closing:  Fixed
Comment by James Rayner (iphitus) - Tuesday, 25 July 2006, 00:22 GMT
some of them are known to cause conflicts with 3D drivers, radeonfb+fglrx in particular.

this should probably be checked into with some more depth however.

In kernel26, im pretty sure the kernel chooses the relevant fb driver automatically, which is where the problems are most likely to occur -- it choosing radeonfb which would then conflict with fglrx.

It may be possible to explicitly choose using video= as implied by the docs, however I don't know whether this overrides the auto picking.

In kernel26beyond, the driver is specified in the video= option passed at boot, again, im pretty sure this overrides the auto picking.

I'll look into this a bit more -- i've got some changes I want to make in the fb layer anyway.

Comment by Tobias Powalowski (tpowa) - Wednesday, 26 July 2006, 06:15 GMT
ok tried enabling the drivers as modules, udev loads them automatically and this will cuase a high risk of trouble.
Comment by Tobias Powalowski (tpowa) - Thursday, 24 August 2006, 08:37 GMT
only solution i would think would work is build the modules and move them out of the kernel module tree, that HOOKS can add them if needed.
Comment by héctor (hacosta) - Sunday, 26 November 2006, 18:17 GMT
maybe intelfb and intel810fn (which do not conflict with xorg's i810 drivers) can be added as a module in the meantime.
Comment by héctor (hacosta) - Sunday, 26 November 2006, 18:17 GMT
err meant intel810fb
Comment by Roman Kyrylych (Romashka) - Sunday, 03 December 2006, 16:26 GMT
intelfb and intel810fb was enabled before, I wonder why this was reverted in later versions.
Comment by Tobias Powalowski (tpowa) - Tuesday, 06 February 2007, 13:48 GMT
kernel 2.6.20 supports any fb you like to use