Summary: | Framebuffer not working in gentoo-dev-sources-2.6.10-r4 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marcos González <mgtroyas> |
Component: | [OLD] Core system | Assignee: | Michal Januszewski (RETIRED) <spock> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | lpetersen |
Priority: | High | ||
Version: | 2004.3 | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://forums.gentoo.org/viewtopic.php?p=1964712#1964712 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Marcos González
2005-01-11 03:10:10 UTC
I had the same problem, and tracked it down to being caused by a wrong kernel command line option for the vesa-tng driver: From 2.6.9 to 2.6.10, the option 'vram' seems to have been replaced by a new 'vtotal' option (complemented by another, 'vremap'; have a look at /usr/src/linux/Documentation/fb/vesafb.txt). I had a kernel command line parameter video=vesafb:1280x1024-16,mtrr,ywrap,vram:64 which had to be changed to video=vesafb:1280x1024-16,mtrr,ywrap,vtotal:64 That fixed the problem for me. As it seems, any module parameter for the vesafb-tng module which is not syntactically correct ends up being interpreted as a video mode. Since 'vram:64' is no longer a legal module parameter, but isn't a legal videomode either, the driver complains about no width being given (the screen width being the first parameter in a legal mode string). (So maybe, there is a clever way of improving command line parsing and, in particular, reporting errors in the vesafb-tng module without bloating it too much!?) Lars got he fix for my problem. From my part, this bug can be marked as fixed ;) Not sure if you want to do anything with this feedback... if you don't, just close it :) Didn't know a no developer could close a bug request. It's closed now. Thanx. |