Summary: | vesafb broken with large memory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Christopher Rude <crude> |
Component: | [OLD] Core system | Assignee: | x86-kernel (DEPRECATED) <x86-kernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gurligebis, r.a.mercer |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://lkml.org/archive/2003/3/27/119/index.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Patch that shold work on 2.4 series kernel
Should correct issue with developmental sources updated 2.4 patch this patches the patch ;) |
Description
Christopher Rude
2003-04-09 19:24:28 UTC
Created attachment 10768 [details, diff]
Patch that shold work on 2.4 series kernel
bump ;~>....
I have been rather busy, but this is the patch for 2.4 kernel, it needs testing
tho
Thanks
Chris
Created attachment 10769 [details, diff]
Should correct issue with developmental sources
This patch I have tested on !!MY!! system, and have aplied it to vanilla and mm
series
once again thanks
Thank you, this solved my problems with my framebuffers :) Please somebody make sure this patch gets submitted to the people at www.kernel.org . I submitted the patch to the kernel mailing list and got the following response from Alan Cox Date: 30 Apr 2003 12:26:43 +0100 From: Alan Cox <alan@lxorguk.ukuu.org.uk> To: Adam Mercer <r.a.mercer@blueyonder.co.uk> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Marcelo Tosatti <marcelo@conectiva.com.br> Subject: Re: [PATCH 2.4.21-rc1] vesafb with large memory On Mer, 2003-04-30 at 09:09, Adam Mercer wrote: > - video_size = screen_info.lfb_size * 65536; The above is correct. It returns the size of the frame buffer > + video_size = screen_info.lfb_width * screen_info.lfb_height * video_bpp; > video_visual = (video_bpp == 8) ? > FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_TRUECOLOR; The change computes the mode size. Thats probably safe for the ioremap range My question is then..... is there a more appropriate way to correct this problem ;) seems to me that if the way it is done is correct, in short time we are going to see many more people running into the problem (memory is cheap, and graphics cards improve pushing up the base line), and it will need to be "fixed" in order to not push (read scare)people away from our wonderfull os... I guess what I am trying to say is how do we fix it (and get it accepted in to the kernel :) so that people with configurations like mine and others (systems that should be able to do framebuffer) don't have to do something that is not correct (even though it may be "safe") Thanks.... btw if my tone was off, I am sorry no sleep and long work days does that to me now and again, and thanks for taking the time to post to lkml (and reporting back ;) I'm using pfeifer-sources and this patch is working here too. I've just checked the changelog for 2.4.21-rc1-ac4 and Alans applied the patch I sent - so hopefully it should find its way to Marcelo before 2.4.21 i've got that patch here as well one from mandrake & a combo of the 2, i am going at least add the fix that computes the mode size. look for it in pfeifer-sources-2.4.20_pre11 Thanks, Jay Thank You... nuff said ;~> Created attachment 11697 [details, diff]
updated 2.4 patch
the patch has been applied to Marcelo's BitKeeper tree, but I've received the following in an email from Geert Uytterhoeven video_size must be in bytes, hence it must be video_size = screen_info.lfb_width*screen_info.lfb_height*video_bpp/8; which makes sense, find attached a new patch (against 2.4.21-rc1, but it cleanly applies to 2.4.20) Cheers Adam i already divided it by 8 as we are calculating bytes. the patch was already in pfeifer-sources-2.4.20_pre11 *and* pre11 has now become gentoo-sources-2.4.20-r4 - the tarball has been uploaded and it should be mirroring now. Get it while it's hot. Have a good one, Jay Thanks..... me thinks I will give my brand spanking new watercooled rig a compile job ;~> In course of this patch, the SuSE bootsplash patch won't run anymore in silent mode because it generates not enough "size" to run in that mode: vesafb: framebuffer at 0xd0000000, mapped to 0xd0800000, size 1536k vesafb: mode is 1024x768x16, linelength=2048, pages=0 vesafb: protected mode interface info at c000:0eb9 vesafb: pmi: set display start = c00c0ef2, set palette = c00c0f68 vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da vesafb: scrolling: redraw vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0 Looking for splash picture.... silenjpeg size 21768 bytes, does not fit into framebuffer. found (1024x768, 20089 bytes, v3). with the old option: vesafb: framebuffer at 0xd0000000, mapped to 0xd0800000, size 65526k vesafb: mode is 1024x768x16, linelength=2048, pages=0 vesafb: protected mode interface info at c000:0eb9 vesafb: pmi: set display start = c00c0ef2, set palette = c00c0f68 vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da vesafb: scrolling: ywrap using protected mode interface, yres_virtual=32763 vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0 Looking for splash picture.... silenjpeg size 21768 bytes, found (1024x768, 2008 9 bytes, v3). Got silent jpeg. Got silent jpeg. Console: switching to colour frame buffer device 122x40 this is an example from the wolk kernel version 4.2 the solution for this problem you can get here ( a diff which can be applied to the kernel (wolk)): http://article.gmane.org/gmane.linux.wolk.devel/26 or maybe easyer: video=vesa:vram:x in course of many people experience this problem when they try to use bootsplash, this maybe has to be offered somewhere to the community. Created attachment 13093 [details, diff]
this patches the patch ;)
This should take care of the problem. I have let a person on the forums test
it, results were good.
Apply this patch to the gentoo-sources-2.4.20-r5, and change:
Console drivers --> Frame-buffer support -->
<*> VESA VGA graphics console
(n) remap x times the graphics memory needed
n= intiger should be greater than 1
I hope this helps
--adapted a patch from the wolk kernel
I changed the status, as I am not sure if posting to it gets the info in the right place... Sory for my ignorance |