From: S Ait-Kassi <sait-kassi@zonnet.nl>
To: linux-kernel@vger.kernel.org
Subject: VESA fb weirdness in 2.6.0 kernel
Date: Wed, 31 Dec 2003 16:07:38 +0100 [thread overview]
Message-ID: <200312311607.38342.sait-kassi@zonnet.nl> (raw)
Hi,
I'm having the same problem that has come to mention before in the mailing
list but hasn't been fixed since.
I have been having the problem since a late 2.5 kernel (2.5.70 I believe)
before that I was using a 2.4 kernel with vesafb and didn't have any
complaints. The most apparent occurrence of the problem for me is when
running mc (Midnight Commander). The blue blackground isn't drawn in the
parts where there is no text. When using mcedit this comes all the more clear
and particularly when scrolling is done. The space which hasn't got any text
is replaced with RGB pixels (looks grey from a distance). If you jump back
from one console and back again the screen is redrawn correctly.
I checked if using ypan, ywrap or redraw would make a difference and also
passed the other options through (mtrr,nomtrr ect.). Checked if the options
where taken by checking dmesg which was indeed the case. But I found that the
problem still continued to occur. It am using a resolution of 1024x768x24
(0x318).
I thought that maybe the redraw wasn't working since the redraw was faster
than under 2.4 allbut the problem mentioned in 2.6 and I thought it might be
using ypan by mistake. But since my card seems to handly ypan and ywrap under
2.4 I do think that the cause lies in the vesafb implementation in the 2.6
kernel.
The only other overlap I found was with the author of the following message to
the mailing list concerning the same problem I believe is the use of an ATI
card. His was a Radeon 7000 mine is a Radeon 9500.
Here is and excerpt of the message:
>"VESA fb weirdness in 2.6.0-test4-mm4"
From: Petr Baudis
>Date: Sun Aug 31 2003 - 08:36:36 EST
>
>when using VESA fb on 2.6.0-test4-mm4, some areas of the screen, in
>particular those which have background set but space on that spot (or other
>blank character), the area is drawn with thin vertical lines of other color
>over them (bluespace is shown as magenta with thin cyan lines over it,
>redspace
>is shown as darkgreen with darkred lines over it). Ie. in menuconfig, the
>blue
>background shows such an effect, as well as the active item highlight in mutt
>mails list.
I'm already compiling different kernels to see where the problem started and
have been looking in to the source to see if I can make sense of the changes.
Too bad that the console and vesa parts have been seperated making it a lot
harder for a novice like myself to find the cause. I'll be back on this if I
find out more.
Regards,
S Ait-Kassi
reply other threads:[~2003-12-31 15:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=200312311607.38342.sait-kassi@zonnet.nl \
--to=sait-kassi@zonnet.nl \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®