Menu
▾
▴
linux-fbdev-devel
|
From: Miles L. <mil...@at...> - 2002-12-11 00:39:49
|
Hi, I have tried getting rivafb to work in 2.5.51. It is much better than before (thanks!). It compiles and sorta works. Here are the problems: When I run "fbset -a 640x480", I get display that fills the screen and looks okay, but most of the characters are flipped along the vertical axis, so they are backwards, so that: +---- ----+ | | +--- becomes ---+ | | | | Also, when I boot, the penguin logo looks like it is being rendered in about five colors. In addition, the text is black, except for the white underscore cursor, so all I can see is the cursor. When the gpm gets loaded, the mouse pointer, instead of showing a white rectangle that, when it passes over a character, shows that character in reverse-video, shows a colored cursor that always contains some character. The character shown in the mouse cursor changes when it passes over text in the window, but it never shows the character it is passing over. Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows a usable console window, but it is embedded in the larger high resolution display, like this: +---------+----------------+ | | | | | | | | | +---------+ | | | | | | | | | | | +--------------------------+ The area outside of the 640x480 boundary is filled with colored junk (no characters). Any ideas? Miles |
|
From: James S. <jsi...@in...> - 2002-12-11 04:56:04
|
> I have tried getting rivafb to work in 2.5.51. It is much better > than before (thanks!). It compiles and sorta works. Ug. Now that several drivers compile now I get bug reports :-( I'm getting alot of positive feedback as well as one negative source. > Here are the problems: > > When I run "fbset -a 640x480", I get display that fills > the screen and looks okay, but most of the characters are > flipped along the vertical axis, so they are backwards, so that: > > +---- ----+ > | | > +--- becomes ---+ > | | > | | Okay. That is weird. I have this card so I will give it a try. > Also, when I boot, the penguin logo looks like it is being rendered > in about five colors. Yipes. Imageblit sounds broken. > In addition, the text is black, except for > the white underscore cursor, so all I can see is the cursor. I noticed this. The color palette is for some reason messed up. > When the gpm gets loaded, the mouse pointer, instead of showing > a white rectangle that, when it passes over a character, shows that > character in reverse-video, shows a colored cursor that always > contains some character. The character shown in the mouse cursor > changes when it passes over text in the window, but it never shows > the character it is passing over. Same things. Color palette is messed up. > Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows > a usable console window, but it is embedded in the larger high > resolution display, like this: > > +---------+----------------+ > | | | > | | | > | | | > +---------+ | > | | > | | > | | > | | > | | > +--------------------------+ > > The area outside of the 640x480 boundary is filled with colored > junk (no characters). > > Any ideas? Yeap. I migrated changing the console from /dev/fb to actually using the tty layer. I haven't merged those changes yet but you will be able to do a stty -f /dev/ttyX 80 col 50 row and change the video mode. So I didn't plan to push so soon but I kept getting emails about various drivers being broken. So I did this push to make more drivers work. Unfortuenly I sent a watered down fbcon system. |
|
From: Miles L. <mil...@at...> - 2002-12-11 06:10:44
|
James, I appreciate all your hard work. I hope my bug report isn't too upsetting for you. I think you are making great progress. It is also a shame that so much of the driver porting has fallen on your shoulders. If I were a programmer. I'd help, but my skills are in software testing, for the most part. All the best, Miles James Simmons wrote: >>I have tried getting rivafb to work in 2.5.51. It is much better >>than before (thanks!). It compiles and sorta works. > > > Ug. Now that several drivers compile now I get bug reports :-( I'm getting > alot of positive feedback as well as one negative source. > > >>Here are the problems: >> >>When I run "fbset -a 640x480", I get display that fills >>the screen and looks okay, but most of the characters are >>flipped along the vertical axis, so they are backwards, so that: >> >>+---- ----+ >>| | >>+--- becomes ---+ >>| | >>| | > > > Okay. That is weird. I have this card so I will give it a try. > > >>Also, when I boot, the penguin logo looks like it is being rendered >>in about five colors. > > > Yipes. Imageblit sounds broken. > > >>In addition, the text is black, except for >>the white underscore cursor, so all I can see is the cursor. > > > I noticed this. The color palette is for some reason messed up. > > >>When the gpm gets loaded, the mouse pointer, instead of showing >>a white rectangle that, when it passes over a character, shows that >>character in reverse-video, shows a colored cursor that always >>contains some character. The character shown in the mouse cursor >>changes when it passes over text in the window, but it never shows >>the character it is passing over. > > > Same things. Color palette is messed up. > > >>Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows >>a usable console window, but it is embedded in the larger high >>resolution display, like this: >> >> +---------+----------------+ >> | | | >> | | | >> | | | >> +---------+ | >> | | >> | | >> | | >> | | >> | | >> +--------------------------+ >> >>The area outside of the 640x480 boundary is filled with colored >>junk (no characters). >> >>Any ideas? > > > Yeap. I migrated changing the console from /dev/fb to actually using the > tty layer. I haven't merged those changes yet but you will be able to do a > > stty -f /dev/ttyX 80 col 50 row > > and change the video mode. > > So I didn't plan to push so soon but I kept getting emails about various > drivers being broken. So I did this push to make more drivers work. > Unfortuenly I sent a watered down fbcon system. > > > > > > |
|
From: James S. <jsi...@in...> - 2002-12-11 14:15:12
|
> James, I appreciate all your hard work. I hope my bug report > isn't too upsetting for you. I think you are making great progress. > It is also a shame that so much of the driver porting has fallen > on your shoulders. If I were a programmer. I'd help, but my skills > are in software testing, for the most part. Thank you :-) Its getting there. |
|
From: Antonino D. <ad...@po...> - 2002-12-11 09:55:09
|
On Wed, 2002-12-11 at 05:39, Miles Lane wrote: > Hi, > > I have tried getting rivafb to work in 2.5.51. It is much better > than before (thanks!). It compiles and sorta works. > > Here are the problems: > > When I run "fbset -a 640x480", I get display that fills > the screen and looks okay, but most of the characters are > flipped along the vertical axis, so they are backwards, so that: > > +---- ----+ > | | > +--- becomes ---+ > | | > | | > What's the hardware, is it on a big endian machine? I think there's a typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN). This should produce the "mirroring" effect. Secondly, a lot of the changes there are for riva128, which may not apply for all cards. Try doing fbset -accel false/true and see if there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277 and comment out the line with the FB_ACCELF_TEXT. This should force the hardware to do everything in software. > Also, when I boot, the penguin logo looks like it is being rendered > in about five colors. In addition, the text is black, except for That's definitely a color map problem. > the white underscore cursor, so all I can see is the cursor. > When the gpm gets loaded, the mouse pointer, instead of showing > a white rectangle that, when it passes over a character, shows that > character in reverse-video, shows a colored cursor that always > contains some character. The character shown in the mouse cursor > changes when it passes over text in the window, but it never shows > the character it is passing over. > I get this with every framebuffer driver, so this is generic. > Lastly, when I run "fbset -a 1600x1200", a 640x480 area shows > a usable console window, but it is embedded in the larger high > resolution display, like this: > > +---------+----------------+ > | | | > | | | > | | | > +---------+ | > | | > | | > | | > | | > | | > +--------------------------+ > > The area outside of the 640x480 boundary is filled with colored > junk (no characters). Because changes done via fbset are not passed to fbcon anymore. So you'll see the display change, but fbcon still thinks it's still on 640x480. I guess James will add some support for that via the console. I'll test it myself too with a riva128 PCI. Tony |
|
From: Miles L. <mil...@at...> - 2002-12-11 16:05:49
|
On Wed, 2002-12-11 at 04:49, Antonino Daplas wrote:
> On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> > Hi,
> >
> > I have tried getting rivafb to work in 2.5.51. It is much better
> > than before (thanks!). It compiles and sorta works.
> >
> > Here are the problems:
> >
> > When I run "fbset -a 640x480", I get display that fills
> > the screen and looks okay, but most of the characters are
> > flipped along the vertical axis, so they are backwards, so that:
> >
> > +---- ----+
> > | |
> > +--- becomes ---+
> > | |
> > | |
> >
> What's the hardware, is it on a big endian machine? I think there's a
> typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN). This should
> produce the "mirroring" effect.
CPU: AMD Athlon(tm) Processor stepping 01
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller (rev 25)
01:05.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256
DDR] (rev 10) (prog-if 00 [VGA])
Subsystem: VISIONTEK: Unknown device 000b
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fd000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at feaf0000 [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
> Secondly, a lot of the changes there are for riva128, which may not
> apply for all cards. Try doing fbset -accel false/true and see if
> there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
> and comment out the line with the FB_ACCELF_TEXT. This should force the
> hardware to do everything in software.
Thanks, I'll check this today.
Miles
|
|
From: Antonino D. <ad...@po...> - 2002-12-12 12:07:40
Attachments:
rivafb1.diff
|
On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> Hi,
>
> I have tried getting rivafb to work in 2.5.51. It is much better
> than before (thanks!). It compiles and sorta works.
>
Can you test the attached patch (rivafb1.diff)? It fixes some things:
1. double ioremap/request_mem_region of the framebuffer memory. Might
cause some initialization weirdness :-)
2. riva_hw.c is outdated (no support for NV_ARCH_20) which will crash
the GeForce3's (I think I read one report of that in the kernel mailing
list).
3. Matched the initialization ordering of rivafb in linux-2.4, except
that RivaGetConfig is executed at rivafb_open().
3. Not sure if the color problem will be fixed. Miles, are you by
offchance using bpp > 8? Because setting the DAC at 8 bpp should be a
very simple matter compared with directcolor which requires some
juggling acts
Also, you mentioned that everything is okay except the characters are
mirrored in the vertical axis, is this correct? Meaning colors are fine
etc. If this is the case, try this patch also:
diff -Naur linux-2.5.51/drivers/video/riva/fbdev.c linux/drivers/video/riva/fbdev.c
--- linux-2.5.51/drivers/video/riva/fbdev.c 2002-12-12 13:59:07.000000000 +0000
+++ linux/drivers/video/riva/fbdev.c 2002-12-12 13:59:30.000000000 +0000
@@ -917,9 +917,11 @@
size = width * h;
dat = cdat;
- for (i = 0; i < size; i++) {
- *dat = byte_rev[*dat];
- dat++;
+ if (par->riva.Architecture == NV_ARCH_03) {
+ for (i = 0; i < size; i++) {
+ *dat = byte_rev[*dat];
+ dat++;
+ }
}
switch (info->var.bits_per_pixel) {
Tony
|
|
From: James S. <jsi...@in...> - 2002-12-13 05:10:44
|
> Can you test the attached patch (rivafb1.diff)? It fixes some things: I tested the patch. The colors are still messed up :-( I'm running at 8 bpp mode. I applied the patch since it fixed some important things. I also add support and more functionality. I still have some to go. |
|
From: Antonino D. <ad...@po...> - 2002-12-13 06:40:11
|
On Fri, 2002-12-13 at 10:09, James Simmons wrote: > > > Can you test the attached patch (rivafb1.diff)? It fixes some things: > > I tested the patch. The colors are still messed up :-( I'm running at 8 > bpp mode. I applied the patch since it fixed some important things. > I also add support and more functionality. I still have some to go. > I'm confused too :-(. If I'm going to expect color problems, it's not at bpp8 since you don't really do anything except write to the DAC. And the fact that the driver works perfectly for the Riva128 (nvidia's first chipset) makes me wonder even more. Currently, I'm running everything with the riva128, directfb, xfbdev, even the xgamma utility works, flawlessly. The only thing I can think of that we're doing differently from the 2.4 driver is the save_vga() part in rivafb_open. Perhaps touching the vga registers somehow confuses the hardware. Unlikely, but maybe worth a try. How extensive is the color problem? Does it just affect the logo, or everything? Also, is the color problem present in both hardware and software mode (just do fbset -accel true/false to find out)? Is the vertical mirroring as reported by Miles still present? How about bpp16 or bpp32? How I would love to debug that, but I don't have the hardware :-( Tony |
|
From: Miles L. <mil...@at...> - 2002-12-13 07:19:13
|
On Friday, December 13, 2002, at 01:34 AM, Antonino Daplas wrote: > How extensive is the color problem? Does it just affect the logo, or > everything? Also, is the color problem present in both hardware and > software mode (just do fbset -accel true/false to find out)? Is the > vertical mirroring as reported by Miles still present? How about bpp16 > or bpp32? I have had mixed results with 2.5.51 (vanilla). I have booted once where I didn't see the mirroring. I have not had a chance to test your patch. Hopefully I'll have time tomorrow. Sorry for the delay. Miles |
Thanks for helping keep SourceForge clean.
X