From: Ray Olszewski <ray@comarre.com>
To: linux-newbie@vger.kernel.org
Subject: Re: framebuffer console problems: not enough video RAM?
Date: Sat, 23 Oct 2004 15:17:51 -0700 [thread overview]
Message-ID: <5.1.0.14.1.20041023151156.01f32200@celine> (raw)
In-Reply-To: <Pine.LNX.4.58.0410231453210.1287@debian-emach>
At 03:06 PM 10/23/2004 -0500, James Miller wrote:
>Latest on this problem is that I'm using only the video=atyfb:102x768-8@75
>argument (no vga=xxx argument) in menu.lst. During the boot process the
>screen goes black for a time--with just a cursor at the very bottom, which
>starts scooting back and forth horizontally--then comes back just as it
>was at a 640x480 resolution. Boot process continues and gdm fires up. In
>all this fiddling around, I've somehow gotten fbset to work--maybe by
>adding atyfb to /etc/modules. When I run fbset (no options) it tells me
>the console is set to 640x480-60. Trying to reset it to 1024x768-75--or
>any other of the 1024x768 or 1280x1024 settings I've tried--makes the
>console go black and the "vga mode not support(ed)" message appear on it.
>Reading some further info on the web, I decided to try issuing some
>resolution setting options separately with fbset--i.e., specifying just
>the V or H resolutions. yres at 768 "works" although the screen goes
>blank. When I try to set xres at 1024, I get an IOCTL error though. When
>I check dmesg output afterwards, I see "kernel: not enough video memory."
>Is my problem therefore--with atyfb just as with vesafb--not enough video
>memory to do 1024x768? I would have guessed 8MB would suffice, but that's
>just a layman's conjecture. I actually have 12MB--added an 8MB SGRAM
>module where a 4MB one was supposed to go--but BIOS seems only to see 8
>and that's what dmesg reports too. So, is this the inglorious end of all
>this researching and tweaking? Feedback appreciated.
One more thought: although the spec for setting video mode looks like you
can put in any old values, in fact you have to use a mode that the kernel
source understands. I don't have a 2.6.x source tree handy, but 2.4.21
doesn't include any 1024x758-b@75 choices. The only entries I can find for
1024x768 in that source are:
/* 1024x768 @ 87 Hz interlaced, 35.5 kHz hsync *
/* 1024x768 @ 60 Hz, 48.4 kHz hsync */
/* 1024x768 @ 70 Hz, 56.5 kHz hsync */
/* 1024x768 @ 76 Hz, 62.5 kHz hsync */
/* 1024x768 @ 85 Hz, 70.24 kHz hsync */
/* 1024x768 @ 100Hz, 80.21 kHz hsync */
So if your LCD panel will support multiple refresh rates, try picking from
the choices listed above. Or get the kernel source and look in
./drivers/video/modedb.c to see what is available in your 2.6.x kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
next prev parent reply other threads:[~2004-10-23 22:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-22 16:42 framebuffer console problems James Miller
2004-10-22 19:00 ` James Miller
2004-10-22 20:08 ` Ray Olszewski
2004-10-22 21:02 ` James Miller
2004-10-22 21:49 ` James Miller
2004-10-22 20:09 ` Jim Nelson
2004-10-22 21:14 ` James Miller
2004-10-22 22:42 ` Jim Nelson
2004-10-23 4:40 ` James Miller
2004-10-23 20:06 ` framebuffer console problems: not enough video RAM? James Miller
2004-10-23 22:00 ` Ray Olszewski
2004-10-24 3:16 ` James Miller
2004-10-24 5:02 ` Ray Olszewski
2004-10-24 5:45 ` James Miller
2004-10-24 16:07 ` Ray Olszewski
2004-10-24 20:00 ` James Miller
2004-10-25 17:43 ` What distributions support dual processors 'out of the box' ? chuck gelm
2004-10-25 20:26 ` Owen Ford
2004-10-27 12:59 ` framebuffer console problems: not enough video RAM? Stephen Samuel
2004-10-23 22:17 ` Ray Olszewski [this message]
2004-10-24 3:25 ` James Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5.1.0.14.1.20041023151156.01f32200@celine \
--to=ray@comarre.com \
--cc=linux-newbie@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox