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

Re: [Linux-fbdev-devel] 2.5 atyfb on Sparc question

[Sven L. <lu...@dp...>]

On Sun, Oct 13, 2002 at 01:08:08PM -0700, James Simmons wrote:
> 
> Sorry I have been going threw alot of chabnges recently. Try my lastest
> tree. I just updated it and I'm nearly done change the api.

BTW, i tried this WE to look at porting the pm3fb driver to the new API,
doing a complete rewrite (well, basically starting again from tridentff,
tdfxfb and skeletonfb, and getting the code as needed from current
pm3fb, which has a lot of unneeded stuff in it). I have not much time
though, so it will go slowly.

I thought i may as well write a little HOWTO or something such on the
way of doing this. Since i have not much fbdev writing experience, maybe
i am a good candidate for writing such a thing.

I wanted, in the first step, to do just a basic unaccelerated fbdev
driver, without mode changes and anything fancy, and once this works,
add things incrementally. I believe this approach will be good for
future fbdev driver writters.

Anyway, now for my question.

skeletonfb says that check_var, set_par, setcolreg, pan_display and
blank functions are optional or not required. Is that true, and in case
i don't want to provide them, whay do i put in the fb_ops structure ?

Later, in the fb_ops structure, only set_par, blank and pan_display are
labeled as optional.

Friendly,

Sven Luther

[Linux-fbdev-devel] Display driver.

[Sunil K. T <t.s...@bp...>]

Hi,
I am planning to write a display  driver for the chip(MD2406)  which is
having ARM7TDMI core.
This chip is having a display interface and JPEG engine.

The purpose is to take JPEG file from user space decode the JPEG file using
hardware decoder in the chip. Display the the jpeg file.

I would like to know from you experts, Should I go for Frame Buffer driver
for this function.

Its able to do the display of jpeg file only from the processor without
using linux.
I am new to display driver. Can I by pass frame buffer method and do the
SDRAM (Display ram) memory acesses directly and acomplish the task. I mean
can I do this driver by using ioctl, and write statement alone. As a normal
charactor driver.
Is there any problem in doing so.
Regards


SunilKumar.T
Sr. Design Engineer
Software and Embedded Systems Group,
BPL TELECOM LTD.
11th K. M., Bannerghatta Road,
Bangalore 560076.
Ph. No.91-80- 6589080 etx.2058

Re: [Linux-fbdev-devel] Re: fbdev changes.

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

On Mon, 14 Oct 2002, Petr Vandrovec wrote:
> On Sun, Oct 13, 2002 at 01:27:08PM -0700, James Simmons wrote:
> > Second change!! We need a uiversal cursor api. I purposed some time ago a
> > api but nothing happend.I like to resolve this final part to remove th
> > last bit of console crude from the fbdev layer.

  [...]

> And what is meaning of image when mask is 1? For b&w cursors
> we need 0, 1, transparent and inverse.

Note that not all hardware supports inverse.
And on some hardware the cursor palette is shared with the screen palette,
that's why I had fb_fix_cursorinfo.crsr_color[12] in the original cursor API.

E.g. Amiga graphics don't have inverse. There are 8 sprites, each can have 3
colors (+ transparency). The colors are shared with the screen palette (unless
your screen has at most 16 colors):
  - sprites 0 and 1: transparent, palette[17], palette[18], palette[19]
  - sprites 2 and 3: transparent, palette[21], palette[22], palette[23]
  - sprites 4 and 5: transparent, palette[25], palette[26], palette[27]
  - sprites 6 and 7: transparent, palette[29], palette[30], palette[31]
There's also a special mode to combine an even an odd sprite to form a 15-color
(+ transparency) sprite.

Yes, it can be difficult to find a _good_ API ;-)

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

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

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

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: lun, ott 14, 2002 at 12:35:07 +0200

Quoting Petr Vandrovec (van...@vc...):

> Really... I did not notice in your original email that it
> reports G400 as 2MB only device... Can you send me
> output of 'lspci -s X:Y.Z -vvvxxx' (where X:Y.Z is
> your G400 device, probably 1:00.0 or 2:00.0) with
> 2.4.19-pre10, and with Alan version? Alan's version
> uses data from BIOS to set memory type, and it
> apparently made mistake.

So, the output from 2.4.19-pre10 is

01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) (prog-if 00 [VGA])
	Subsystem: Matrox Graphics, Inc. Millennium G400 Dual Head Max
	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-
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at e8000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at e4000000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at e5000000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at e6000000 [disabled] [size=64K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00: 2b 10 25 05 02 00 90 02 04 00 00 03 08 40 00 00
10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 7d 21
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
40: 20 00 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
50: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 f0 22 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 02 00 20 00 03 02 00 1f 00 00 00 00 00 00 00 00

The output from 2.4.19-pre10-ac2 differs in only one number. Here is the diff:

--- lspciold	Mon Oct 14 07:30:53 2002
+++ lspcinew	Mon Oct 14 07:35:09 2002
@@ -17,7 +17,7 @@
 10: 08 00 00 e8 00 00 00 e4 00 00 00 e5 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 2b 10 7d 21
 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 10 20
-40: 20 00 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
+40: 20 08 04 00 00 3c 00 00 2b ff ff 2b 00 00 00 00
 50: 00 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

> In Alan's kernel you should have option to enable procfs
> interface - can you enable it and send me also
> contents of /proc/driver/mga/fb*/pins. It is binary
> file, if you want, you can parse it by matrox_pins
> from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest.

Info for the G400:

PINS from /proc/driver/mga/fb1/pins
  PINS:                          new, version 4.1, length 128
  DVD Info:                      FF
  Program date:                  C96C (2000-11-12)
  Program count:                 0003
  Product ID:                    0700
  Serial No:                     GAM73189        
  Part info:                     403   
  PCB info:                      38A4
  Max pixel VCO:                 360 MHz
  Max system VCO:                360 MHz
  Max CRTC1 VCO                  
    8bpp:                        360 MHz
    16bpp:                       360 MHz
    24bpp:                       360 MHz
    32bpp:                       360 MHz
  Max CRTC2 VCO                  
    16bpp:                       136 MHz
    32bpp:                       136 MHz
  OPTION flags:                  0xC2
  VGA Mode                       
    GClk VCO:                    328 MHz
    Reserved:                    29
    OPTION3 register:            0x0190A419
    MCTLWTST register:           0x20049911
    Clk1:                        standard
    Clk2:                        standard
  2D Mode                        
    GClk VCO:                    600 MHz
    Reserved:                    4B
    OPTION3 register:            0x019B8419
    MCTLWTST register:           0x20049911
  3D Mode                        
    GClk VCO:                    600 MHz
    Reserved:                    4B
    OPTION3 register:            0x019B8419
    MCTLWTST register:           0x20049911
  GClk Derate:                   FF
  MemRdBk:                       0C88
  MemRdBkMod:                    0C88
  VidCtrl:                       EE
  Factory options                
    Reference Freq:              27.000 MHz
    Memory size:                 32MB
    Memory type:                 SGLVTTL16
    MAVEN:                       present
    DVD:                         not present
    MJPEG:                       not present
    Decoder:                     not present
    Tuner:                       not present
    Audio:                       not present
    Panel Link:                  not present

I am also including info from the Millennium:

PINS from /proc/driver/mga/fb0/pins
  Product ID:                    0005
  Serial No:                     CAG81904  
  Manuf date:                    C0CC (1996-6-12)
  Manuf ID:                      0004
  PCB Info:                      49C3
  PMB Info:                      2642
  Ramdac speed:                  1
  Ramdac type:                   0
  Max PCLK:                      0
  Max LCLK:                      0
  ClkBase:                       5000
  Clk4MB:                        0
  Clk8MB:                        0
  ClkMod:                        0
  TestClk:                       0
  VGAFreq1:                      2517
  VGAFreq2:                      2832
  Program date:                  C4C8 (1998-6-8)
  Program count:                 5
  Ser No Ext:                    0F8B0000
  Feature flags:                 00000000
  VGA Clock:                     0
  Struct rev:                    0105
  Vid Ctrl:                      00
  Rsvd:                          00 00 00 00 00

Carlo

-- 
  *         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)

[Linux-fbdev-devel] Re: fbdev changes.

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

On Sun, Oct 13, 2002 at 01:27:08PM -0700, James Simmons wrote:

[Removed Linus from Cc. I'm sure that he is not interested...]

> code possible. The questions I have is should we move the agp code over to
> that directory. Should the DRI code move over directly or should we move
> DRI driver specific code into the same directory as the fbdev driver
> directories? For example in aty directory we have all the ati framebuffer
> and ATI dri code. What do you think?

I do not think that I want mga dri code in my directory... If anything,
then I want marvel video-in code in my directory...
 
> Second change!! We need a uiversal cursor api. I purposed some time ago a
> api but nothing happend.I like to resolve this final part to remove th
> last bit of console crude from the fbdev layer.
> 
> #define FB_CUR_SETCUR   0x01
> #define FB_CUR_SETPOS   0x02
> #define FB_CUR_SETHOT   0x04
> #define FB_CUR_SETCMAP  0x08
> #define FB_CUR_SETSHAPE 0x10
> #define FB_CUR_SETALL   0x1F
> 
> struct fbcurpos {
>         __u16 x, y;
> };
> 
> struct fbcursor {
>         __u16 set;              /* what to set */
>         __u16 enable;           /* cursor on/off */
>         struct fbcurpos pos;    /* cursor position */
>         struct fbcurpos hot;    /* cursor hot spot */
>         struct fb_cmap cmap;    /* color map info */
>         struct fbcurpos size;   /* cursor bit map size */
>         char *image;            /* cursor image bits */
>         char *mask;             /* cursor mask bits */
> };
> 
> If you have any suggestion please post you purpose struct. Thank you.

mask image is 1bpp, and width of image is derived from cmap? I.e.
cmap.start must be always 0, and cmap.len must be always power of 2?
In that case please make it impossible to set CMAP without SHAPE.
Is image/mask somehow aligned, or is 2x3 cursor just completely
stored in one byte?

In reality I think that you should just split it to 2 blocks:
enable/disable + position in one block (i.e. this changes when cursor
flashes or moves on the screen), and hotspot, cmap, size and image/mask
in second block (these change when cursor body changes).

And what is meaning of image when mask is 1? For b&w cursors
we need 0, 1, transparent and inverse.
					Thanks,
						Petr Vandrovec
						van...@vc...

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

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

On Sun, Oct 13, 2002 at 06:07:46PM +0200, Carlo E. Prelz wrote:
> 	Subject: Re: Mixing g400 dualhead and old Millennium.
> 	Date: dom, ott 13, 2002 at 04:56:04 +0200
> 
> Quoting Petr Vandrovec (van...@vc...):
> 
> > If you could print return value from register_framebuffer in 
> > matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
> > problem. Maybe that using non-ac kernel fixes problem too.
> 
> It never reaches register_framebuffer. It leaves dh_regit at tese
> lines:
> 
>         else if (ACCESS_FBINFO(video.len) < mem) {
>                 kfree(d);
>                 return -ENOMEM;
>         }
> 
> ACCESS_FBINFO(video.len) is 2097152. Mem is 8388608.

Really... I did not notice in your original email that it
reports G400 as 2MB only device... Can you send me
output of 'lspci -s X:Y.Z -vvvxxx' (where X:Y.Z is
your G400 device, probably 1:00.0 or 2:00.0) with
2.4.19-pre10, and with Alan version? Alan's version
uses data from BIOS to set memory type, and it
apparently made mistake.

In Alan's kernel you should have option to enable procfs
interface - can you enable it and send me also
contents of /proc/driver/mga/fb*/pins. It is binary
file, if you want, you can parse it by matrox_pins
from ftp://platan.vc.cvut.cz/pub/linux/matrox-latest.
				Thanks,
					Petr Vandrovec
					van...@vc...

[Linux-fbdev-devel] [BK PATCHS] fbdev updates.

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

This is nearly the last of the fbdev api changes (90% of them). Alot of
driver fixes as well. The console related stuff in each fbdev driver
is nearly gone!!! Please do a pull. Thank you.

bk://fbdev.bkbits.net/fbdev-2.5

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

[Linux-fbdev-devel] fbdev changes.

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

Hi!

  The final changes to the fbdev layer are at hand. One of the last
changes I wanted to purpose was to create a console driectory in
drivers/video and move all console related stuff into that directory.
The next step was to move the dri stuff into that directory with the agp
code possible. The questions I have is should we move the agp code over to
that directory. Should the DRI code move over directly or should we move
DRI driver specific code into the same directory as the fbdev driver
directories? For example in aty directory we have all the ati framebuffer
and ATI dri code. What do you think?

Second change!! We need a uiversal cursor api. I purposed some time ago a
api but nothing happend.I like to resolve this final part to remove th
last bit of console crude from the fbdev layer.

The api I suggested was :


/*
 * hardware cursor control
 */

#define FB_CUR_SETCUR   0x01
#define FB_CUR_SETPOS   0x02
#define FB_CUR_SETHOT   0x04
#define FB_CUR_SETCMAP  0x08
#define FB_CUR_SETSHAPE 0x10
#define FB_CUR_SETALL   0x1F

struct fbcurpos {
        __u16 x, y;
};

struct fbcursor {
        __u16 set;              /* what to set */
        __u16 enable;           /* cursor on/off */
        struct fbcurpos pos;    /* cursor position */
        struct fbcurpos hot;    /* cursor hot spot */
        struct fb_cmap cmap;    /* color map info */
        struct fbcurpos size;   /* cursor bit map size */
        char *image;            /* cursor image bits */
        char *mask;             /* cursor mask bits */
};

If you have any suggestion please post you purpose struct. Thank you.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question

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

Sorry I have been going threw alot of chabnges recently. Try my lastest
tree. I just updated it and I'm nearly done change the api.

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

On Thu, 3 Oct 2002, Holzrichter, Bruce wrote:

> James,
>
> In a blast from the past, not sure if your still interested, but I have not
> had a whole lot of time to look at these, due to my job/life, etc,etc...
>
> If I apply the latest bk to it, I get the following compile error.  As I
> said, I haven't even had time to grep through the thing to even begin to
> look, but wanted to report them anyways...
>
> fbmem.c: In function `fbmem_read_proc':
> fbmem.c:380: structure has no member named `modename'
> make[2]: *** [fbmem.o] Error 1
> make[2]: Leaving directory `/home/bruce/sparctest/drivers/video'
> make[1]: *** [video] Error 2
> make[1]: Leaving directory `/home/bruce/sparctest/drivers'
> make: *** [drivers] Error 2
>
> Bruce H..
>
> > -----Original Message-----
> > From: James Simmons [mailto:jsi...@in...]
> > Sent: Thursday, August 22, 2002 3:22 PM
> > To: Holzrichter, Bruce
> > Cc: lin...@li...
> > Subject: RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question
> >
> >
> >
> > > > Oops. Fixed now.
> > > >
> > > Whoa, that was neat!  ;o)
> >
> > Can you try the latest changes in my BK tree.
> >
>

[Linux-fbdev-devel] endian problem ?

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

Ok, I've ported radeonfb, controlfb and platinumfb to the
new API (which is quite nice since allowed me to remove
a whole bunch of cruft from these drivers, good job !)

However, I'm having a problem: With controlfb and
radeonfb (couldn't test platinum yet but it's very similar
to controlfb), the console is fine in 8 bpp, but text is
plain blue in any higher bit depth (15, 16 or 32).

X with "fbdev" driver works fine, so I think setcolreg
works properly. All those drivers are set to DIRECTCOLOR
for these bit depth. Maybe I've missed something about
the pseudo_palette thing (is it documented somewhere ?)
or are there known endian bugs in the cfb_* routines ?

Ben.

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

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

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: dom, ott 13, 2002 at 04:56:04 +0200

Quoting Petr Vandrovec (van...@vc...):

> If you could print return value from register_framebuffer in 
> matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
> problem. Maybe that using non-ac kernel fixes problem too.

It never reaches register_framebuffer. It leaves dh_regit at tese
lines:

        else if (ACCESS_FBINFO(video.len) < mem) {
                kfree(d);
                return -ENOMEM;
        }

ACCESS_FBINFO(video.len) is 2097152. Mem is 8388608.

Carlo

-- 
  *         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)

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

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

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: dom, ott 13, 2002 at 04:56:04 +0200

Quoting Petr Vandrovec (van...@vc...):

> Strange, I'll have to look at 2.4.20-pre10-ac2 then. I do not
> remember sending anything special for 2.4.20 to Alan...

Pre10-ac2 has a matroxfb_base.c with Version: 1.64 2002/06/10. Simple
pre10 has Version: 1.62 2001/11/29.

> > matroxfb_crtc2: secondary head failed to register
> > matroxfb_crtc2: CRTC2 framebuffer failed to register
> 
> It can only happen if there is not enough memory (uh...) or if
> register_framebuffer() fails. And only way I can imagine is
> that you run out of possible framebuffers... Can you
> verify that /usr/src/linux/include/linux/fb.h contains
> '#define FB_MAX 32' and not some small value like '2' ?

Both versions have 32. 

> If you could print return value from register_framebuffer in 
> matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
> problem. Maybe that using non-ac kernel fixes problem too.

I will add a printk & will let you know.

Carlo

-- 
  *         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)

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

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

On Sun, Oct 13, 2002 at 04:15:16PM +0200, Carlo E. Prelz wrote:
> 
> I was having problems in compiling things in kernel. Eventually, it
> seems they were limited to compiling the latest 2.4.20-pre10-ac2
> patch, which contains a more recent version of your material. With
> that, both with modules and included in the kernel, I get the
> following messages (here with modules);

Strange, I'll have to look at 2.4.20-pre10-ac2 then. I do not
remember sending anything special for 2.4.20 to Alan...

> matroxfb_crtc2: secondary head failed to register
> matroxfb_crtc2: CRTC2 framebuffer failed to register

It can only happen if there is not enough memory (uh...) or if
register_framebuffer() fails. And only way I can imagine is
that you run out of possible framebuffers... Can you
verify that /usr/src/linux/include/linux/fb.h contains
'#define FB_MAX 32' and not some small value like '2' ?

> so that I cannot see the second head of the g400. With 2.4.19 and
> module loading, instead of the last two lines I get:
> 
> matroxfb_crtc2: secondary head of fb1 was registered as fb2
> 
> This is not urgent for me now. I still cannot see if the output is
> present on all outputs (somebody will have to physically check the
> monitor outputs, and that will hopefully happen sometimes tomorrow),
> but now the matroxset output looks very promising. 
> 
> In all cases, if you want me to do some tests or try some patch to see
> if the 'failed to register' situation can be fixed, just ask.

If you could print return value from register_framebuffer in 
matroxfb_dh_regit in matroxfb_crtc2.c, maybe it could reveal
problem. Maybe that using non-ac kernel fixes problem too.
						Petr Vandrovec
						van...@vc...

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

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

	Subject: Re: Mixing g400 dualhead and old Millennium.
	Date: dom, ott 13, 2002 at 02:13:24 +0200

Quoting Petr Vandrovec (van...@vc...):

> If it is G400, you must also insmod matroxfb_maven, otherwise
> there is no second output. 

Aha. That made the second output magically appear. Thanks!

> And you should build everything
> into kernel, not as a modules - you'll not have problem to find
> where secondary output lives then...

I was having problems in compiling things in kernel. Eventually, it
seems they were limited to compiling the latest 2.4.20-pre10-ac2
patch, which contains a more recent version of your material. With
that, both with modules and included in the kernel, I get the
following messages (here with modules);

PCI: Found IRQ 9 for device 00:0b.0
matroxfb: Matrox Millennium (PCI) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x6553)
matroxfb: framebuffer at 0xEB000000, mapped to 0xce8d0000, size 4194304
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
PCI: Enabling device 01:00.0 (0000 -> 0002)
matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x3270)
matroxfb: framebuffer at 0xE8000000, mapped to 0xcf0d6000, size 2097152
fb1: MATROX VGA frame buffer device
fb1: initializing hardware
i2c-core.o: adapter DDC:fb1 #0 on i2c-matroxfb registered as adapter 0.
i2c-core.o: adapter DDC:fb1 #1 on i2c-matroxfb registered as adapter 1.
i2c-core.o: adapter MAVEN:fb1 on i2c-matroxfb registered as adapter 2.
i2c-core.o: adapter DDC:fb0 #0 on i2c-matroxfb registered as adapter 3.
i2c-core.o: driver maven registered.
i2c-core.o: client [maven client] registered to adapter [MAVEN:fb1 on i2c-matroxfb](pos. 0).
matroxfb_crtc2: secondary head failed to register
matroxfb_crtc2: CRTC2 framebuffer failed to register

so that I cannot see the second head of the g400. With 2.4.19 and
module loading, instead of the last two lines I get:

matroxfb_crtc2: secondary head of fb1 was registered as fb2

This is not urgent for me now. I still cannot see if the output is
present on all outputs (somebody will have to physically check the
monitor outputs, and that will hopefully happen sometimes tomorrow),
but now the matroxset output looks very promising. 

In all cases, if you want me to do some tests or try some patch to see
if the 'failed to register' situation can be fixed, just ask.

Carlo

-- 
  *         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)

[Linux-fbdev-devel] Re: Mixing g400 dualhead and old Millennium.

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

On Sat, Oct 12, 2002 at 05:36:41PM +0200, Carlo E. Prelz wrote:
> Hello. I am trying to obtain a 'simple' system where 3 framebuffers
> output their images to three monitors (no TV output). In the past I
> was able to have 4 outputs using 4 old millenniums. Now I have to help
> a friend who lives 1000 kms from here, and who hasn't enough PCI slots
> (and would not find 3 millenniums anyway...) So, he found a dualhead
> AGP g400 (PCI ID 102b:0525) and an old Millennium (PCI ID 102b:0519,
> MGA 2064W).
> 
> Using kernel 2.4.19, and loading kernel modules in this order:
> 
> i2c-matroxfb
> matroxfb_base
> matroxfb_crtc2

If it is G400, you must also insmod matroxfb_maven, otherwise
there is no second output. And you should build everything
into kernel, not as a modules - you'll not have problem to find
where secondary output lives then...
 
> In all cases, it appears (when looking at the source of the driver)
> that the second head cannot be assigned this value, so that
> MATROXFB_GET_AVAILABLE_OUTPUTS is 0 for it. I can assign it to the
> first head, as follows
> 
> /usr/src/matroxset/matroxset -f /dev/fb2 -m 0
> /usr/src/matroxset/matroxset -f /dev/fb1 -m 4
> 
> but after that, too, MATROXFB_GET_AVAILABLE_OUTPUTS for the second
> head is 0. Or I can assign 1 to the second head, but then I cannot
> assign 4 to the first head, although it is allowed in
> MATROXFB_GET_AVAILABLE_OUTPUTS, because I can only assign a value to

Digital output and secondary output use same pins on G400, so you have
either one or another. On G450/G550 all three outputs are completely
independent, with proper cabling you can connect three monitors
to your Gx50 (of course, two of them will have same picture, but
it is enough if you are doing some presentations).
							Petr Vandrovec
					

[Linux-fbdev-devel] Mixing g400 dualhead and old Millennium.

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

Hello. I am trying to obtain a 'simple' system where 3 framebuffers
output their images to three monitors (no TV output). In the past I
was able to have 4 outputs using 4 old millenniums. Now I have to help
a friend who lives 1000 kms from here, and who hasn't enough PCI slots
(and would not find 3 millenniums anyway...) So, he found a dualhead
AGP g400 (PCI ID 102b:0525) and an old Millennium (PCI ID 102b:0519,
MGA 2064W).

Using kernel 2.4.19, and loading kernel modules in this order:

i2c-matroxfb
matroxfb_base
matroxfb_crtc2

I see the cards as follows:

PCI: Found IRQ 9 for device 00:0b.0
matroxfb: Matrox Millennium (PCI) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x6553)
matroxfb: framebuffer at 0xEB000000, mapped to 0xce875000, size 4194304
Console: switching to colour frame buffer device 80x30
fb0: MATROX VGA frame buffer device
PCI: Enabling device 01:00.0 (0000 -> 0002)
matroxfb: Matrox G400 (AGP) detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x26208)
matroxfb: framebuffer at 0xE8000000, mapped to 0xcf07b000, size 33554432
fb1: MATROX VGA frame buffer device
fb1: initializing hardware
i2c-core.o: adapter DDC:fb1 #0 on i2c-matroxfb registered as adapter 0.
i2c-core.o: adapter DDC:fb1 #1 on i2c-matroxfb registered as adapter 1.
i2c-core.o: adapter MAVEN:fb1 on i2c-matroxfb registered as adapter 2.
i2c-core.o: adapter DDC:fb0 #0 on i2c-matroxfb registered as adapter 3.
matroxfb_crtc2: secondary head of fb1 was registered as fb2

And I see the fb's: /proc/fb contains

0 MATROX VGA
1 MATROX VGA
2 MATROX CRTC2

The console is on the Millennium. The problem is that writing to
/dev/fb2 does not result in something appearing on the 2nd output of
the G400. Now, I must admit that my mind is not a little confused with
the usage and capacites of the matroxset utility, but here at home, I
was able to cleanly use the second output of my G450 with the
following code (run at boot time):

/usr/src/matroxset/matroxset -f /dev/fb1 -m 0
/usr/src/matroxset/matroxset -f /dev/fb0 -m 1
/usr/src/matroxset/matroxset -f /dev/fb1 -m 2

So, I tried the same on this remote machine (using /dev/fb1 and
/dev/fb2, of course). The third command is not successful. I explored
things a bit. I wrote a short program that calls 3 ioctls,
respectively 

MATROXFB_GET_OUTPUT_CONNECTION,
MATROXFB_GET_AVAILABLE_OUTPUTS and
MATROXFB_GET_ALL_OUTPUTS.

On my home machine, /dev/fb0 gives 1, 1 and 3, while /dev/fb1 gives 2,
2 and 3. I understand that these are bitmaps: all is good. On the
remote machine,

fb0 (millennium) gives 1, 1 and 1 (ok, only one output)
fb1 (g400 1st head) gives 1, 5 and 5
fb2 (g400 2nd head) gives 0, 0 and 5

So, it seems that the second bit is not available in the g400. In its
place, there seems to be a third bit, what in matroxfb.h is defined as
MATROXFB_OUTPUT_DFP; this, as far as I can see, relates to a digital
flat panel interface, some possible third output on the card (that I
cannot investigate since the card is far far away).

In all cases, it appears (when looking at the source of the driver)
that the second head cannot be assigned this value, so that
MATROXFB_GET_AVAILABLE_OUTPUTS is 0 for it. I can assign it to the
first head, as follows

/usr/src/matroxset/matroxset -f /dev/fb2 -m 0
/usr/src/matroxset/matroxset -f /dev/fb1 -m 4

but after that, too, MATROXFB_GET_AVAILABLE_OUTPUTS for the second
head is 0. Or I can assign 1 to the second head, but then I cannot
assign 4 to the first head, although it is allowed in
MATROXFB_GET_AVAILABLE_OUTPUTS, because I can only assign a value to
the primary head if the secondary head has no output assigned. 

I thought I may solve the problem by having the g400 card detected as
first and the Millennium as second, but this seems to be impossible,
since AGP is detected after PCI. 

Is this a bug? What can I do about it?

Thanks in advance...

Carlo

-- 
  *         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)

[Linux-fbdev-devel] Offerts : 7 euros sur Amazon.fr !

[Ok2mail.com <ama...@ok...>]

Faites-vous plaisir!

Ok2mail.com vous offre un cheque-cadeau de 7 euros, a depenser illico sur 
Amazon.fr!!!

Valable sur tout le catalogue Amazon.fr:
Livres, Musique, DVD, Video, Logiciels, Jeux Video.

Uniquement jusqu'au dimanche 27 octobre 2002. Profitez-en vite!

Pour cela, notez bien votre code de cheque-cadeau:

CATA-8BBCXF-YW2RA3

Vous entrerez ce code sur la page de paiement, dans la case reservee a cet 
effet.

Cliquez ici pour en profiter: 
http://www.amazon.fr/exec/obidos/redirect?tag=gcbuon2-21&path=tg/browse/-/405320

--------------------------------------------------------------------------
Votre cheque-cadeau est soumis aux conditions d'utilisation a consulter sur 
la page http://www.ok2mail.com/conditions_amazon.htm

Important: ces cheques-cadeaux sont limites a 1 par foyer fiscal et par 
adresse de livraison, a utiliser avant le 27 octobre 2002. La livraison est 
gratuite a partir de 20 euros d'achats en mode rapide en France 
metropolitaine.

Vous recevez cet e-mail de la part de Ok2mail.com. Si vous ne souhaitez 
plus recevoir d'offres speciales de notre part, rendez-vous sur: 
http://www.ok2mail.com/amazon/desinscription.htm

Re: [Linux-fbdev-devel] New API: porting docs ?

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

>Attached is tridentfb which works for the new API but only with cfb accels
>the native ones still need work.I'll send this in when that is fixed.
>You can look at it or do a diff against original tridentfb in current 2.5
>to see what's changed

Great, thanks, a diff is what I'm looking for actually :)

Ben.

Re: [Linux-fbdev-devel] New API: porting docs ?

[Sven L. <lu...@dp...>]

On Tue, Oct 08, 2002 at 03:16:04PM +0000, Jani Monoses wrote:
> 
> > Attached is tridentfb which works for the new API but only with cfb accels
> > the native ones still need work.I'll send this in when that is fixed.
> > You can look at it or do a diff against original tridentfb in current 2.5
> > to see what's changed
> 
> forgot it

Mmm, just a quick question.

Is it better to keep the tridentfb.h in drivers/video like you do, or
move it to include/video as is done in tdfxfb ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] New API: porting docs ?

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

> Attached is tridentfb which works for the new API but only with cfb accels
> the native ones still need work.I'll send this in when that is fixed.
> You can look at it or do a diff against original tridentfb in current 2.5
> to see what's changed

forgot it

Re: [Linux-fbdev-devel] New API: porting docs ?

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

Attached is tridentfb which works for the new API but only with cfb accels
the native ones still need work.I'll send this in when that is fixed.
You can look at it or do a diff against original tridentfb in current 2.5
to see what's changed
> 
> I was told some time back, that using tdfxfb.c as example is maybe more
> usefull than using skeletonfb.c.
> 
> Look at the lists archive for a previous thread on this same topic.
> 
> Friendly,
> 
> Sven Luther
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: [Linux-fbdev-devel] New API: porting docs ?

[Sven L. <lu...@dp...>]

On Tue, Oct 08, 2002 at 03:45:00AM +0800, Antonino Daplas wrote:
> On Sun, 2002-10-06 at 19:29, Benjamin Herrenschmidt wrote:
> > HI !
> > 
> > I have a whole bunch of fbdev's that need porting to the
> > new API that is currently in 2.5. Is there any kind of doc
> > available or a HOWTO explaining at least briefly what is
> > invovled ? (what changed and now ?)
> > 
> > Ben.
> 
> The most updated doc that I know of is skeletonfb.c.  

I was told some time back, that using tdfxfb.c as example is maybe more
usefull than using skeletonfb.c.

Look at the lists archive for a previous thread on this same topic.

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] [Patch 2] Console Rotation

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

On 8 Oct 2002, Antonino Daplas wrote:
> On Mon, 2002-10-07 at 04:41, Geert Uytterhoeven wrote:
> > The fillrect() for arbitrary bitdepths is in fbtest now. I also added fast
> > support for planar screens. Well, now I can start porting amifb to the accel
> > framework.
> > 
> I modified your fillrect for cfbfillrect.c.  Just added support for
> ROP_XOR.
> 
> Here's also some rudimentary benchmarks:
> 
> fill/copy a 256x256 rectangle 1000 times (8bpp):
> 
>                            old          new
> copyarea                   4.930s       5.151s
> fillrect(ROP_COPY)         0.136s       0.256s
> fillrect(ROP_XOR)          4.059s       3.903s

Yes, there is still room for optimization...

If next_line is a multiple of BYTES_PER_LONG, there's no need to recalculate
the first and last masks.
Even if next_line is not a multiple of BYTES_PER_LONG, the first and last masks
are periodic, and can be precalculated and put in a table (4 entries on 32-bit
and 8 entries on 64-bit).

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] New API: porting docs ?

[Antonino D. <ad...@po...>]

On Sun, 2002-10-06 at 19:29, Benjamin Herrenschmidt wrote:
> HI !
> 
> I have a whole bunch of fbdev's that need porting to the
> new API that is currently in 2.5. Is there any kind of doc
> available or a HOWTO explaining at least briefly what is
> invovled ? (what changed and now ?)
> 
> Ben.

The most updated doc that I know of is skeletonfb.c.  

Tony

Re: [Linux-fbdev-devel] [Patch 2] Console Rotation

[Antonino D. <ad...@po...>]

On Mon, 2002-10-07 at 04:41, Geert Uytterhoeven wrote:
> 
> The fillrect() for arbitrary bitdepths is in fbtest now. I also added fast
> support for planar screens. Well, now I can start porting amifb to the accel
> framework.
> 
I modified your fillrect for cfbfillrect.c.  Just added support for
ROP_XOR.

Here's also some rudimentary benchmarks:

fill/copy a 256x256 rectangle 1000 times (8bpp):

                           old          new
copyarea                   4.930s       5.151s
fillrect(ROP_COPY)         0.136s       0.256s
fillrect(ROP_XOR)          4.059s       3.903s

Tony