linux-fbdev-devel — linux-fbdev mailing list for project developers

[Linux-fbdev-devel] Re: Driver specific options

[Petr V. <VAN...@vc...>]

On 14 Nov 01 at 9:35, James Simmons wrote:
> static struct {
>         const char *name;
>         int (*init)(void);
>         int (*setup)(char*);
> } fb_drivers[] __initdata = {
> 
> to:
> 
> static struct {
>         struct fb_info* (*init)(void);
>         int (*setup)(char*);
> } fb_drivers[] __initdata = {

I think that it is much easier to create an

int is_it_a_general_framebuffer_option(struct fb_info* fbi, 
                 const char* option);
                
and then in driver do:

while ((this_opt = strsep(&options, ",")) != NULL) {
   if (!*this_opt) continue;
   if (is_it_a_general_framebuffer_option(fbi, this_opt)) continue;
   if (strcmp(this_opt, "....")) ...
}

In such case you have much better control over specified options
command line, you can parse some options in special way, you can
specify fbdev own defaults for fb_info fields, ... And you do not
have to change API. But I think that you all know my position very well.
                                        Petr Vandrovec
                                        van...@vc...

[Linux-fbdev-devel] Driver specific options

[James S. <jsi...@tr...>]

I have started to make "global" options more specific to the driver. For
example to invert the color map. It would be really nice if we asked to
invert the colormap for certain framebuffer drivers. Alot of drivers do
this in their own setup functions. What I was thinking was to put these
"general" options in video_setup and call them from their. This would work
if we can pass strut fb_info to these general functions i.e
fb_invert_cmap(struct fb_info). In order to do this tho I need the struct
fb_info for that frmaebuffer. So I like to suggest for a solution in 2.5.X
is to change 

static struct {
        const char *name;
        int (*init)(void);
        int (*setup)(char*);
} fb_drivers[] __initdata = {

to:

static struct {
        struct fb_info* (*init)(void);
        int (*setup)(char*);
} fb_drivers[] __initdata = {

We don't need the name field since this is already in struct fb_info. What
do you think?

 

[Linux-fbdev-devel] Re: Who has a PPC?

[James S. <jsi...@tr...>]

> >Who has tried ruby on a PowerPPC?
> 
> So far I only was able to make sure it compiles the input layer (but the 
> PPC part of the input layer is nearly the same in 2.4 already), for using 
> it I would need a working aty128fb. Unfortunately I have absolutely no time 
> to dig into aty128fb to fix it :-(.

No problem. I have a ati 128 at home. I can convert it tonight. Today I'm
going to work on the Voodoo 1 card. Plus I'm going to add code to make
things more modular. 

TODO for today:

Add code to map a framebuffer to create a new VT.

Make fbcon modular. 


P.S
  Which tree are you using for the PPC?

Re: [Linux-fbdev-devel] (no subject)

[Geert U. <ge...@li...>]

On Wed, 14 Nov 2001, Robert Schwebel wrote:
> On Tue, 13 Nov 2001, James Simmons wrote:
> > As some of you know I have been working on a new console system for
> > 2.5.X.
>
> This might be a good opportunity to throw in some remarks from the
> embedded front. I currently have the problem that I would like to attach a
> Displaytech 64128a LCD to an embedded machine running Linux. The problem
> with these displays is that they have their own controller which is
> accessable through an 8 bit parallel port and some control lines, so it
> does not have any memory mappable frame buffer.
>
> Nevertheless, it would be great to write a framebuffer driver for that
> beast, because then I could use all kinds of "normal" libraries ontop of
> that device, e.g. svgalib, Qt-Embedded, MicroWindows or whatsoever. I'm no
> expert in the current FB interface, but it looks to me that there is no
> mechanism for devices like that. I can imagine to write something like the
> virtual vfb driver, but there is still a mechanism missing that can be
> used to tell the driver that the frame is "dirty" and it has to be
> transferred by the driver into the display.
>
> Any ideas how this could be done, either with the existing interface or
> with possible improvements in the new API are welcome.

The method used in vga256fb (fake a frame buffer, use MMU tricks) can be used
here. Search the list archives for more info.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] (no subject)

[Robert S. <ro...@sc...>]

Hello James,

On Tue, 13 Nov 2001, James Simmons wrote:
> As some of you know I have been working on a new console system for
> 2.5.X.

This might be a good opportunity to throw in some remarks from the
embedded front. I currently have the problem that I would like to attach a
Displaytech 64128a LCD to an embedded machine running Linux. The problem
with these displays is that they have their own controller which is
accessable through an 8 bit parallel port and some control lines, so it
does not have any memory mappable frame buffer.

Nevertheless, it would be great to write a framebuffer driver for that
beast, because then I could use all kinds of "normal" libraries ontop of
that device, e.g. svgalib, Qt-Embedded, MicroWindows or whatsoever. I'm no
expert in the current FB interface, but it looks to me that there is no
mechanism for devices like that. I can imagine to write something like the
virtual vfb driver, but there is still a mechanism missing that can be
used to tell the driver that the frame is "dirty" and it has to be
transferred by the driver into the display.

Any ideas how this could be done, either with the existing interface or
with possible improvements in the new API are welcome.

Robert
--=20
 +--------------------------------------------------------+
 |             Dipl.-Ing. Robert Schwebel                 |
 | Pengutronix - Linux Solutions for Science and Industry |
 |  Braunschweiger Stra=DFe 79, 31134 Hildesheim, Germany   |
 |     Phone: +49-5121-28619-0  Fax: +49-5121-28619-4     |
 +--------------------------------------------------------+

[Linux-fbdev-devel] Fwd: modular modedb

[Jani M. <ja...@as...>]

Sorry if you received this before, but I sent it yesterday and it didn't show 
up in the mail archives.


Hi
as far as I can see a fb module cannot take advantage of modedb since
the modes are tagged as __initdata.If I am not missing something
what do you guys think would be a good solution for this?
I thought of making modedb compilable as a module (easy) or
having that initdata before the list of modes become nothing if there is
a module which uses it (have a new config option to say that modedb is needed
as a module)
I am writing a driver for Trident Blade3D cards by the way and intend to post
it for code review and testing in the next couple of days.

Thanks,
Jani.

Please leave me in CC:

-------------------------------------------------------

[Linux-fbdev-devel] (no subject)

[James S. <jsi...@tr...>]

Hi!

   As some of you know I have been working on a new console system for
2.5.X. Now that 2.5.X is very very close I really like to work together
with various people from various trees to pull this together. The two
biggest changes I have done is:

1) A new fbdev api with is much simpler and allows fbdev devices to exist
   without a console system. Nice for embedded devices.

2) We also will be moving the various input devices including keyboards
   over to the input api. 

3) Also I plan to work on a new serial api based on Russell King's work to
   work nicely with the input layer. The serial layer will be more like
   the parallel port layer.

So what I need is the latest drivers from people so they can be ported
over. I also want to know what people needed for the fbdev layer as well
as the input layer. I see some email about DDC support for example. Please
let me know what you need. Thank you. 

[Linux-fbdev-devel] modular modedb

[Jani M. <ja...@as...>]

Hi
as far as I can see a fb module cannot take advantage of modedb since
the modes are tagged as __initdata.If I am not missing something
what do you guys think would be a good solution for this?
I thought of making modedb compilable as a module (easy) or
having that initdata before the list of modes become nothing if there is 
a module which uses it (have a new config option to say that modedb is needed 
as a module)
I am writing a driver for Trident Blade3D cards by the way and intend to post 
it for code review and testing in the next couple of days.

Thanks,
Jani.

Please leave me in CC:

[Linux-fbdev-devel] Re: Scaling registers on r128

[Michel <mic...@ii...>]

Adrian Cox wrote:
> 
> This patch to aty128fb is experimental, and intended for the brave.
> 
> The attached patch turns on the panel scaling registers of the R128.
> I've run this on my iBook2, and I've been able to display 640x480 and
> 800x600 modes on the panel successfully.
> 
> The panel sizes are currently hardwired on the iBook. This code will
> benefit greatly from a reliable means to find the panel size.
> 
> This has revealed problems in the X server: if the XF86Config-4
> specifies 800x600 and the current console is in 1024x768, the display
> is broken.

Does switching resolutions in X fix it again?

> This looks like a generic problem in fbdevhw based Xservers, as
> I saw something similar on 69030.

Yes, I suspect some fbdevHW functions return information about the
current console mode instead of the one the X server wants to set up.
I'm not sure how to fix, you seem to be working a lot with that code
recently so I expect you to find a way. :)


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

[Linux-fbdev-devel] Re: Scaling registers on r128

[Benjamin H. <be...@ke...>]

>This patch to aty128fb is experimental, and intended for the brave.
>
>The attached patch turns on the panel scaling registers of the R128.
>I've run this on my iBook2, and I've been able to display 640x480 and
>800x600 modes on the panel successfully.
>
>The panel sizes are currently hardwired on the iBook. This code will
>benefit greatly from a reliable means to find the panel size.
>
>This has revealed problems in the X server: if the XF86Config-4
>specifies 800x600 and the current console is in 1024x768, the display is
>broken. This looks like a generic problem in fbdevhw based Xservers, as
>I saw something similar on 69030.

great. I'm working on some way to probe the panel type on those
machines as it doesn't seem to follow any standard. Once don

Ben.

[Linux-fbdev-devel] Scaling registers on r128

[Adrian C. <ad...@hu...>]

This patch to aty128fb is experimental, and intended for the brave.

The attached patch turns on the panel scaling registers of the R128. 
I've run this on my iBook2, and I've been able to display 640x480 and 
800x600 modes on the panel successfully.

The panel sizes are currently hardwired on the iBook. This code will 
benefit greatly from a reliable means to find the panel size.

This has revealed problems in the X server: if the XF86Config-4 
specifies 800x600 and the current console is in 1024x768, the display is 
broken. This looks like a generic problem in fbdevhw based Xservers, as 
I saw something similar on 69030.

-- 
Adrian Cox   http://www.humboldt.co.uk/

[Linux-fbdev-devel] EDID -> var

[Ani J. <aj...@sh...>]

Attatched is a portable kernel edid parser I've put together recently.
This converts an EDID mode (first one only by  default)
into a fb_var_screenfino mode.

This is a portable method because its up to the driver to get the EDID
from its various methods (DPMI, OpenFirmware device node, DDC/i2c), the
driver can then use:

int parse_edid(unsigned char *edid, fb_var_screeninfo *var);

which will parse and convert the EDID's mode into var.

This adds another layer for a "valid" mode to be used, ie:
1) use user's argument (either modedb or driver dependent modeline)
2) use EDID
3) use default mode


This is ofcourse only useful if the EDID is available but this shouldn't
be a problem with many of todays boards.


Comments appreciated,

ani

Re: [Linux-fbdev-devel] Re: Help from Gurus on modes and timing and frame buffers needed!

[James S. <jsi...@tr...>]

> Given all the cruft about video modes & flat panels lately, what about
> adding some generic fbdev mode management (extending modedb) this way:
> All driver that know how to retreive DDC/EDID informations or the old
> mac mode sense pins, provide this to the modedb module.
> 
> This module is responsible for using that info and command line infos
> to produce a sensible default display mode. It has a userland interface
> to make these infos easily available to candidate mode switchers (like
> MOL for example, but also a distribution XFree autoconfig tool).
> 
> It also has an event interface for drivers that can autodetect hotplug
> and unplug of the video connector. Actually, it could be in a more
> central place in fbdev arch and also do heads management.
> 
> In this case, drivers would register potential "heads" (connectors)
> indicating if they are independant or not (can only do mirroring), and
> if something is actually connected to them (most cards seem to be able
> to tell it).
> 
> We can have things like mirror-only heads that can have a different
> mode timing, our current interface doesn't seem really nice for it.
> This is classical on some laptops where the LCD is at 60hz, but you
> can mirror with a better refresh rate.
> 
> What do you think ?

That is what fbmon.c was made for!!!!!!! I agree we do need this kind of
functionality. Since this is a 2.5.X issue we can place it in the
linuxconsole project CVS. Their I'm working on the new fbdev api. I'm
willing to test it out. 

P.S

   Another issue is backlights and frontlights. I like to hammer something
out for that as well. I also already have hooks for power management as
well that feed up into the console layer. Also having fbdev doing power
management allows fbdev to exist without the console layer. 

[Linux-fbdev-devel] Re: Help from Gurus on modes and timing and frame buffers needed!

[Kevin B. H. <khe...@iv...>]

Hi Ben,

Sounds like the right solution to me.  I have code to parse the EDID 
correctly (given it has been read into a file as it is when OF does it). 
Since OF is not setting up my monitor properly and I need something like 
this,  my idea was much simpler.  I was just going to change the Radeon 
panel_yres parameter into a USE_EDID flag that would be used to trigger a 
parsing of the EDID info from the file put there by OF.  All of this would 
be done internal to the radeonfb.c driver.
  
But that would not be the more complete solution you are sugggesting, it 
would not handle the hot-plug events, etc., different heads, etc.

So your solution sounds like a better overall way of integrating things 
rather than the piecemeal way things are beig done now.

My 2 cents.

Kevin
 


> Given all the cruft about video modes & flat panels lately, what about
> adding some generic fbdev mode management (extending modedb) this way:
> All driver that know how to retreive DDC/EDID informations or the old
> mac mode sense pins, provide this to the modedb module.
>
> This module is responsible for using that info and command line infos
> to produce a sensible default display mode. It has a userland interface
> to make these infos easily available to candidate mode switchers (like
> MOL for example, but also a distribution XFree autoconfig tool).
>
> It also has an event interface for drivers that can autodetect hotplug
> and unplug of the video connector. Actually, it could be in a more
> central place in fbdev arch and also do heads management.
>
> In this case, drivers would register potential "heads" (connectors)
> indicating if they are independant or not (can only do mirroring), and
> if something is actually connected to them (most cards seem to be able
> to tell it).
>
> We can have things like mirror-only heads that can have a different
> mode timing, our current interface doesn't seem really nice for it.
> This is classical on some laptops where the LCD is at 60hz, but you
> can mirror with a better refresh rate.
>
> What do you think ?
>
> I beleive the first step is to add some kind of DDC/EDID parser to
> modedb that returns a matching mode entry and maybe merge the old
> mac-sensing codes into it (using a table mac-mode -> modedb mode).
>
>
> Ben.

[Linux-fbdev-devel] Re: Help from Gurus on modes and timing and frame buffers needed!

[Benjamin H. <be...@ke...>]

Given all the cruft about video modes & flat panels lately, what about
adding some generic fbdev mode management (extending modedb) this way:
All driver that know how to retreive DDC/EDID informations or the old
mac mode sense pins, provide this to the modedb module.

This module is responsible for using that info and command line infos
to produce a sensible default display mode. It has a userland interface
to make these infos easily available to candidate mode switchers (like
MOL for example, but also a distribution XFree autoconfig tool).

It also has an event interface for drivers that can autodetect hotplug
and unplug of the video connector. Actually, it could be in a more
central place in fbdev arch and also do heads management.

In this case, drivers would register potential "heads" (connectors)
indicating if they are independant or not (can only do mirroring), and
if something is actually connected to them (most cards seem to be able
to tell it).

We can have things like mirror-only heads that can have a different
mode timing, our current interface doesn't seem really nice for it.
This is classical on some laptops where the LCD is at 60hz, but you
can mirror with a better refresh rate.

What do you think ?

I beleive the first step is to add some kind of DDC/EDID parser to modedb
that returns a matching mode entry and maybe merge the old mac-sensing codes
into it (using a table mac-mode -> modedb mode).


Ben.

[Linux-fbdev-devel] [patch] matroxfb_base.c compiler warning

[nicholas b. <da...@tr...>]

fixes annoying compile warning about suggested parens around assignment
used as truth value in drivers/video/matrox/matroxfb_base.c:

--- drivers/video/matrox/matroxfb_base.c.orig	Thu Nov  8 11:48:50 2001
+++ drivers/video/matrox/matroxfb_base.c	Thu Nov  8 11:46:27 2001
@@ -2355,7 +2355,7 @@
 	if (!options || !*options)
 		return 0;
 
-	while (this_opt = strsep(&options, ",")) {
+	while ( (this_opt = strsep(&options, ",")) ) {
 		if (!*this_opt) continue;
 
 		dprintk("matroxfb_setup: option %s\n", this_opt);

-- 
nicholas black (da...@tr...)   head developer, trellis network security
"c has types for a reason.  c++ improved the type system for a reason.  perl
 and php programs have run-time failures for a reason." - lkml

[Linux-fbdev-devel] aty128fb gamma table

[<SWE...@ao...>]

Hi-
In recent kernels (for the last month or so I think it's been), aty128fb has refused to set gamma table entries above number 32 when in 24bpp/32bpp modes. Looking at the sources it looks like this restriction was set with 16bpp in mind (since only 32 gamma entries make sense in 16bpp), but whoever added that restriction didn't take into account that in 24bpp and 32bpp all 256 gamma table entries make sense.
I'm using the normal colormap setting code to install the gamma table, which I guess is a slight misnomer on my part, but is there another way of accessing the gamma table or is this really the bug it seems to be? If it's a bug, looking through the source I was able to get the results I wanted by vastly simplifying aty128_setcolreg(), but that probably broke something else, so I'm not really sure what the proper action is to fix in this case.

Also, all kernels i've tried to date have a minor bug in fbcon_clear (not just aty128fb this time of course) where issuing a clear command on the virtual terminal will go ahead and clear the screen even if the terminal is supposed to be in graphics mode (where all other terminal activity is ignored). Are there plans to fix this one? It's a one-line patch and I sent it in about 4 months ago, but it got ignored.

Thanks in advance,
-Woodley

Re: [Linux-fbdev-devel] ctfb Version 0.52

[tea a. <th...@ag...>]

3rd try... (sorry)

http://www.visuelle-maschinen.de/ctfb/fb/drivers/ctfb/ctfb0.52.tgz

Am Tuesday 06 November 2001 09:43, schrieb tea age: / On Tuesday 06 November 
2001 09:43, tea age wrote:
> Sorry, it was the wron link. This one should work:
>
> http://www.visuelle-maschinen.de/public_ftp/fb/drivers/ctfb/ctfb0.52.tgz
>
> Am Monday 05 November 2001 13:51, schrieb tea age: / On Monday 05 November
>
> 2001 13:51, tea age wrote:
> > ftp://visuelle@www.visuelle-maschinen.de/public_ftp/fb/drivers/ctfb/ctfb0
> >.5 2.tgz
> >
> > Changes:
> >
> > Bugfix for Module Compilation.
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

[Linux-fbdev-devel] Parallel LCD

[Robert S. <ro...@sc...>]

Hi,

did anybody ever write a FB driver for these small monochrome graphical
LCD panels with a parallel interface? I have a Displaytech 64128A with
128x64 pixels, but there are lots of similar displays out there with the
same controller. Would be nice to hear from other people's experiences.

Robert
--=20
 +--------------------------------------------------------+
 |             Dipl.-Ing. Robert Schwebel                 |
 |      Linux Solutions for Science and Industry          |
 |  Braunschweiger Stra=DFe 79, 31134 Hildesheim, Germany   |
 |     Phone: +49-5121-28619-0  Fax: +49-5121-28619-4     |
 +--------------------------------------------------------+

Re: [Linux-fbdev-devel] ctfb Version 0.52

[tea a. <th...@ag...>]

Sorry, it was the wron link. This one should work:

http://www.visuelle-maschinen.de/public_ftp/fb/drivers/ctfb/ctfb0.52.tgz

Am Monday 05 November 2001 13:51, schrieb tea age: / On Monday 05 November 
2001 13:51, tea age wrote:
> ftp://visuelle@www.visuelle-maschinen.de/public_ftp/fb/drivers/ctfb/ctfb0.5
>2.tgz
>
> Changes:
>
> Bugfix for Module Compilation.

[Linux-fbdev-devel] ctfb Version 0.52

[tea a. <th...@ag...>]

ftp://visuelle@www.visuelle-maschinen.de/public_ftp/fb/drivers/ctfb/ctfb0.52.tgz

Changes: 

Bugfix for Module Compilation.

[Linux-fbdev-devel] About the vfb (fwd)

[Geert U. <ge...@li...>]

---------- Forwarded message ----------
Date: Fri, 2 Nov 2001 11:25:22 +0800
From: hbxia <hb...@dt...>
To: Gee...@cs...
Subject: About the vfb

  Now I am porting the Qt, and I want to enable the vfb of linux.
  I enabled the vfb and build the kernel of linux-2.4.2. When I type "append="video=vfb:" " to the section of lilo, My kernel can't start.
If I don't type the "append="viedo=vfb"" to the lilo, the kernel can start.
  I don't know the reason.
  Can you tell me the reason, and give me a solution of the problem.
  Thanks you!

[Linux-fbdev-devel] Two Riva TNT2 cards: Oops

[Carlo E. P. <fl...@fl...>]

Dear framebuffer friends,

intending to explore the possibilty of using two framebuffers handled
by two separate video cards, I equipped a machine with two Riva TNT2
cards, one PCI and the other AGP. They appear at lspci -v as:

01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev
15) (prog-if 00 [VGA])
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10
        Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
        Memory at d4000000 (32-bit, prefetchable) [size=32M]
        Expansion ROM at ddaf0000 [disabled] [size=64K]
        Capabilities: [60] Power Management version 1
        Capabilities: [44] AGP version 2.0

and 

00:05.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev
15) (prog-if 00 [VGA])
        Subsystem: Palit Microsystems Inc.: Unknown device 002d
        Flags: 66Mhz, medium devsel, IRQ 10
        Memory at df000000 (32-bit, non-prefetchable) [disabled] [size=16M]
        Memory at d8000000 (32-bit, prefetchable) [disabled] [size=32M]
        Expansion ROM at deff0000 [disabled] [size=64K]
        Capabilities: [60] Power Management version 1

Loading the rivafb module gives no bad feelings. I get:

rivafb: RIVA MTRR set to ON
Console: switching to colour frame buffer device 100x37
rivafb: PCI nVidia NV4 framebuffer ver 0.9.2a (RIVA-VTNT2, 32MB @ 0xD4000000)
rivafb: RIVA MTRR set to ON
rivafb: PCI nVidia NV4 framebuffer ver 0.9.2a (RIVA-VTNT2, 32MB @ 0xD8000000)

and /proc/fb contains 

0 RIVA-VTNT2
1 RIVA-VTNT2

as expected. 

Then, if I run fbset -fb /dev/fb1 i get 

mode "800x600-60"
    # D: 40.000 MHz, H: 37.879 kHz, V: 60.317 Hz
    geometry 800 600 800 600 8
    timings 25000 88 40 23 1 128 4
    hsync high
    vsync high
    accel true
    rgba 6/0,6/0,6/0,0/0
endmode

(with /dev/fb0 the rgba line is 8/0,8/0,8/0,0/0).

If I try to run any kind of program that sets the characteristics of
the framebuffer, I get an OOPS of the kind:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

CPU:    0
EIP:    0010:[<d09236a2>]
EFLAGS: 00010246
eax: 01d905c0   ebx: 0fffffff   ecx: 00000020   edx: 00000000
esi: 00000000   edi: 01d905c0   ebp: 00000000   esp: cd6cbb5c
ds: 0018   es: 0018   ss: 0018
Process fbset (pid: 524, stackpage=cd6cb000)
Stack: 0fffffff 0000000f 00000000 00000080 c0218c09 cc18e000 c91a1000 c0121b83
       001379a0 c0121b96 c0271b30 ceec9880 ced3b300 00000001 00000000 00009bcd
       00000003 c92c2880 00000000 00000020 00000000 00000002 00000010 d0923a5c
Call Trace: [<c0218c09>] [<c0121b83>] [<c0121b96>] [<d0923a5c>] [<d09241a6>]
   [<d0924263>] [<d0926b6c>] [<d0920b56>] [<d0921910>] [<d0927c40>] [<c01c2ba9>]
   [<d0927c40>] [<c011eb82>] [<c011ec6b>] [<c013acd7>] [<c0106c3b>]
Code: f7 fe b9 0a 00 00 00 69 c9 40 42 0f 00 89 44 24 2c 89 c8 99

>>EIP; d09236a2 <[rivafb]nv4CalcArbitration+92/350>   <=====
Trace; c0218c08 <mmx_copy_page+28/30>
Trace; c0121b82 <filemap_nopage+102/3e0>
Trace; c0121b96 <filemap_nopage+116/3e0>
Trace; d0923a5c <[rivafb]nv4UpdateArbitrationSettings+fc/140>
Trace; d09241a6 <[rivafb]CalcStateExt+66/2c0>
Trace; d0924262 <[rivafb]CalcStateExt+122/2c0>
Trace; d0926b6c <[rivafb]reg_template+cc/bc0>
Trace; d0920b56 <[rivafb]riva_load_video_mode+266/2c0>
Trace; d0921910 <[rivafb]rivafb_set_var+420/440>
Trace; d0927c40 <[rivafb]riva_fb_ops+0/40>
Trace; c01c2ba8 <fb_ioctl+168/5e0>
Trace; d0927c40 <[rivafb]riva_fb_ops+0/40>
Trace; c011eb82 <do_no_page+52/e0>
Trace; c011ec6a <handle_mm_fault+5a/c0>
Trace; c013acd6 <sys_ioctl+166/180>
Trace; c0106c3a <system_call+32/38>
Code;  d09236a2 <[rivafb]nv4CalcArbitration+92/350>
00000000 <_EIP>:
Code;  d09236a2 <[rivafb]nv4CalcArbitration+92/350>   <=====
   0:   f7 fe                     idiv   %esi   <=====
Code;  d09236a4 <[rivafb]nv4CalcArbitration+94/350>
   2:   b9 0a 00 00 00            mov    $0xa,%ecx
Code;  d09236a8 <[rivafb]nv4CalcArbitration+98/350>
   7:   69 c9 40 42 0f 00         imul   $0xf4240,%ecx,%ecx
Code;  d09236ae <[rivafb]nv4CalcArbitration+9e/350>
   d:   89 44 24 2c               mov    %eax,0x2c(%esp,1)
Code;  d09236b2 <[rivafb]nv4CalcArbitration+a2/350>
  11:   89 c8                     mov    %ecx,%eax
Code;  d09236b4 <[rivafb]nv4CalcArbitration+a4/350>
  13:   99                        cltd   

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

Well, what happens is that in
/usr/src/linux/drivers/video/riva/riva_hw.c, function
nv4CalcArbitration is called with structure arb containing (at least)
the field called pclk_freq set to 0. Since this value is used as a
dividend in multiple places, the obvious disaster happens. 

Now, I don't have the slightest idea about what this functons does. I
tried to add printk's to see values,  and the machine locked solid at
loading the module. I tried to return if the value was 0, and the
machine entered a strange catatonic status where the keyboard seemed
to be still alive (NumLock led turning on and off) but the keyboard's
stuff seemed not to reach the machine. 

Well, I am confident that you will immediately understand what's going
on. For me, it's a mistery... 

A couple of further informations: I can generate the above OOPS
infinite times and the machine itself does not crash. Only, if I run
again fbset -fb /dev/fb1 after at least one oops, the values of tne
rgba line return changed, to various values. Now:

    rgba 8/16,8/8,8/0,0/0

Is the list the right address for my request, or do I have to trace
the maintainer of the Riva module?

Thanks in advance...

Carlo

PS the PCI card has TV out. Is there some hope to have it working
(under framebuffer - I don't care about X)?

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fl...@fl...             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

Re: [Linux-fbdev-devel] Corrupt palette when Xfbdev is launched from Virtual Console

[James S. <jsi...@tr...>]

> I am having a problem running Xfbdev when launched from the virtual
> console. My problem is that X comes up with the palette set incorrectly.
> Examples of this are that the normal default grey dimpled back ground is
> displayed in dark blue.
> If I boot linux using the serial console and then launch Xfbdev, X comes up
> with all the colours correct.

Can you run fbset to give use info? Run it on the console before running X, 
in X windows, on the console after you exit X windows. 

This should clear some things up.

[Linux-fbdev-devel] Corrupt palette when Xfbdev is launched from Virtual Console

[<Adr...@ta...>]

I am having a problem running Xfbdev when launched from the virtual
console. My problem is that X comes up with the palette set incorrectly.
Examples of this are that the normal default grey dimpled back ground is
displayed in dark blue.
If I boot linux using the serial console and then launch Xfbdev, X comes up
with all the colours correct.

Has anyone seen any problem like this before and knows how I might fix it ?
Anyone have any ideas what may be going wrong ?

Relevant details are :

MIPS platform, 2.4.2 kernel
using clgen framebuffer, 8 bpp, 640x480
Xfbdev compiled from X Windows 4.01, " tiny X " framebuffer server.

If boot with console=ttySx, and run X, X comes up with correct colours /
palette

If boot with, no console defined or console=tty0 and run X. X comes up with
incorrect colours.

Thx