Re: [Linux-fbdev-devel] [CONFIG_FB_NVIDIA] Mirrored characters on the console on a G5

[Antonino A. Daplas <adaplas@ho...>]

On Friday 15 April 2005 00:52, Francois wrote:
> Hi Tony,
>
> > Only characters are mirrored, and not the entire row (ie, row starts at
> > the left side, and not at the right)?
>
> Only the characters (so I can't look in a mirror and have a "normal" screen
> :-).
>
> > Can you try fbset -accel false and see if it helps?
>
> Right on the spot! I can now switch between mirrored and not mirrored.

You can also append this when you boot:

video=nvidiafb:noaccel

so you don't have to do an fbset -accel false each time.

>
> > I think rivafb supports this particular chipset, but without
> > acceleration.
>
> Actually my X display is garbled with rivafb (with which console
> characters are fine). With fb_nvidia, X seems to work fine independently
> of whether the acceleration is switched on or off (some screen size and
> frequency issues needs tuning though).
>
> > If it does, this is a problem with nvidia's imageblit function which
> > converts big-endian bitmaps to little endian?  Perhaps the help
> > reverse_order() is not needed for your arch.  Can you comment out calls
> > to reverse_order() in drivers/video/nvidia/nv_accel.c?
>
> I'll try this and I'll get back to you this the results.
>

I'll wait, thanks.

Tony

Re: [Linux-fbdev-devel] Re: 2.6.12-rc1-mm2 -- nvidiafb driver gives black screen

[Antonino A. Daplas <adaplas@ho...>]

On Friday 15 April 2005 01:13, Jean Delvare wrote:
> Hi Tony,
>
> > This patch will always limit the amount of video RAM to remap at
> > 128 MiB.
>
> I don't much get the idea. What are you trying to prevent?

I'm preventing ioremap failures when the driver tries to remap a large
chunk of the graphics aperture.

>
> 128 MiB seems a rather low limit. Graphics adapters with 256 MiB, 512
> MiB or even 640 MiB exist, and I see little reason why it would stop
> increasing.

For fbcon use, such a large amount of RAM does not help significantly
with performance.  Also, nvidiafb cannot use the entire video RAM as
framebuffer space since it's 2D drawing functions are limited by the
clipping coordinates which is set at 0x7fff, x and y, ie, one can only do
blits within the range of 0x0-0x7fff.

Tony

Re: [Linux-fbdev-devel] Re: 2.6.12-rc1-mm2 -- nvidiafb driver gives black screen

[Antonino A. Daplas <adaplas@ho...>]

On Friday 15 April 2005 01:06, Jean Delvare wrote:
> Hi Tony,
>
> > As for the i2c problem, this is probably due to a misplaced label in
> > the failure path, and the reason why I had a difficult time
> > reproducing this bug. When nvidiafb failed with the ioremap, it
> > skipped deletion of the i2c busses causing the crash whenever the bus
> > created by nvidiafb is read.  The fix is also included in this patch.
>
> Exactly what I suspected from the very beginning, but I did not
> investigate the error path back then - in fact I can't remember Miles
> telling me that the the driver was actually not working for him. Thanks

He didn't.  I just assumed that it did because he also reported that nvidiafb
failed to load due to an ioremap problem (too much video RAM).

> a lot for confirming and fixing the problem.

Well, not yet confirmed, I'll wait for Miles to do so.

Tony

Re: [Linux-fbdev-devel] Re: 2.6.12-rc1-mm2 -- nvidiafb driver gives black screen

[Antonino A. Daplas <adaplas@ho...>]

On Friday 15 April 2005 02:19, Miles Lane wrote:
> Perhaps I am mistaken, but I thought Andrew wanted to see the nvidiafb
> driver work with a default X86 kernel configuration (which allows for
> up to 128M to be allocated).  Is the driver attempting to allocate
> exactly 128M because that is how much video ram is present in my video
> card?
>

Not allocation, as standalone cards have already a fixed amount of RAM. The
patch will limit the amount of video RAM that the kernel can access to a
maximum of 128 MiB.

> If lots of video cards exist that have more than 128M of video ram,
> won't we be seeing many boot problems with the default kernel
> configuration?  Does this point to a problem in the kernel design?  Is
> this limitation in the kernel's default configuration advantageous?
>

The patch is a short-term workaround where cards with large amounts
of video RAM eat a large amount of the kernel's address space.

What I intend to do is to mimic what radeonfb is doing. Ie, info->screen_size
points to the actual vram, while fix->smem_len points to ioremapped area only.
I'll do some testing first since nvidiafb uses the last chunk of the ioremapped
vram for the DMA buffer, and I don't know the consequence if this buffer is
unintentionally exported to user space, from the security point of view.

Tony

[Linux-fbdev-devel] [2.6 patch] drivers/video/intelfb/intelfbdrv.h

[Adrian Bunk <bunk@st...>]

Ingo Oeser noticed that all that intelfbdrv.h contains are prototypes 
for static functions - and such prototypes don't belong into header 
files.

This patch therefore removes drivers/video/intelfb/intelfbdrv.h and 
moves the prototypes to intelfbdrv.c .

Signed-off-by: Adrian Bunk <bunk@...>

---

This patch was already sent on:
- 20 Mar 2005

 drivers/video/intelfb/intelfbdrv.c |   40 ++++++++++++++++-
 drivers/video/intelfb/intelfbdrv.h |   68 -----------------------------
 2 files changed, 39 insertions(+), 69 deletions(-)

--- linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.c.old	2005-03-20 03:39:30.000000000 +0100
+++ linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.c	2005-03-20 03:44:03.000000000 +0100
@@ -135,9 +135,47 @@
 #endif
 
 #include "intelfb.h"
-#include "intelfbdrv.h"
 #include "intelfbhw.h"
 
+
+static void __devinit get_initial_mode(struct intelfb_info *dinfo);
+static void update_dinfo(struct intelfb_info *dinfo,
+			 struct fb_var_screeninfo *var);
+static int intelfb_get_fix(struct fb_fix_screeninfo *fix,
+			   struct fb_info *info);
+
+static int intelfb_check_var(struct fb_var_screeninfo *var,
+			     struct fb_info *info);
+static int intelfb_set_par(struct fb_info *info);
+static int intelfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+			     unsigned blue, unsigned transp,
+			     struct fb_info *info);
+
+static int intelfb_blank(int blank, struct fb_info *info);
+static int intelfb_pan_display(struct fb_var_screeninfo *var,
+			       struct fb_info *info);
+
+static void intelfb_fillrect(struct fb_info *info,
+			     const struct fb_fillrect *rect);
+static void intelfb_copyarea(struct fb_info *info,
+			     const struct fb_copyarea *region);
+static void intelfb_imageblit(struct fb_info *info,
+			      const struct fb_image *image);
+static int intelfb_cursor(struct fb_info *info,
+			   struct fb_cursor *cursor);
+
+static int intelfb_sync(struct fb_info *info);
+
+static int intelfb_ioctl(struct inode *inode, struct file *file,
+			 unsigned int cmd, unsigned long arg,
+			 struct fb_info *info);
+
+static int __devinit intelfb_pci_register(struct pci_dev *pdev,
+					  const struct pci_device_id *ent);
+static void __devexit intelfb_pci_unregister(struct pci_dev *pdev);
+static int __devinit intelfb_set_fbinfo(struct intelfb_info *dinfo);
+
+
 /*
  * Limiting the class to PCI_CLASS_DISPLAY_VGA prevents function 1 of the
  * mobile chipsets from being registered.
--- linux-2.6.11-mm4-full/drivers/video/intelfb/intelfbdrv.h	2005-03-16 18:55:25.000000000 +0100
+++ /dev/null	2005-03-19 22:42:59.000000000 +0100
@@ -1,68 +0,0 @@
-#ifndef _INTELFBDRV_H
-#define _INTELFBDRV_H
-
-/*
- ******************************************************************************
- * intelfb
- *
- * Linux framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G
- * integrated graphics chips.
- *
- * Copyright © 2004 Sylvain Meyer
- *
- * Author: Sylvain Meyer
- *
- ******************************************************************************
- *    This program is free software; you can redistribute it and/or modify
- *    it under the terms of the GNU General Public License as published by
- *    the Free Software Foundation; either version 2 of the License, or
- *    (at your option) any later version.
- *
- *    This program is distributed in the hope that it will be useful,
- *    but WITHOUT ANY WARRANTY; without even the implied warranty of
- *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *    GNU General Public License for more details.
- *
- *    You should have received a copy of the GNU General Public License
- *    along with this program; if not, write to the Free Software
- *    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
-static void __devinit get_initial_mode(struct intelfb_info *dinfo);
-static void update_dinfo(struct intelfb_info *dinfo,
-			 struct fb_var_screeninfo *var);
-static int intelfb_get_fix(struct fb_fix_screeninfo *fix,
-			   struct fb_info *info);
-
-static int intelfb_check_var(struct fb_var_screeninfo *var,
-			     struct fb_info *info);
-static int intelfb_set_par(struct fb_info *info);
-static int intelfb_setcolreg(unsigned regno, unsigned red, unsigned green,
-			     unsigned blue, unsigned transp,
-			     struct fb_info *info);
-
-static int intelfb_blank(int blank, struct fb_info *info);
-static int intelfb_pan_display(struct fb_var_screeninfo *var,
-			       struct fb_info *info);
-
-static void intelfb_fillrect(struct fb_info *info,
-			     const struct fb_fillrect *rect);
-static void intelfb_copyarea(struct fb_info *info,
-			     const struct fb_copyarea *region);
-static void intelfb_imageblit(struct fb_info *info,
-			      const struct fb_image *image);
-static int intelfb_cursor(struct fb_info *info,
-			   struct fb_cursor *cursor);
-
-static int intelfb_sync(struct fb_info *info);
-
-static int intelfb_ioctl(struct inode *inode, struct file *file,
-			 unsigned int cmd, unsigned long arg,
-			 struct fb_info *info);
-
-static int __devinit intelfb_pci_register(struct pci_dev *pdev,
-					  const struct pci_device_id *ent);
-static void __devexit intelfb_pci_unregister(struct pci_dev *pdev);
-static int __devinit intelfb_set_fbinfo(struct intelfb_info *dinfo);
-
-#endif