Control fb problem on 8500

Control fb problem on 8500

[Kevin M. Myer]

Hello,

A couple of issues have cropped up with my PowerMac 8500.  I am running
Paulus' 2.4.0-test6 kernel and my console has developed a sort of mirror
image on the far right one-eighth of the screen.  Basically, everything on
the screen is mirrored in that eighth of the screen albeit much
smaller.  For example, as I type this, tiny white lines are being drawn to
my right.  If I were to `ls --color` a directory, different color lines
show up.  This behaviour wasn't there in Paulus' 2.4.0-test1-ac21 kernel
of a few rsyncs ago.

Secondly, the video chip doesn't show up on the PCI bus.  Although XFree86
4.0 apparently supports the controlfb (which is what the 8500 has), it
also needs a BusID to be used.  Am I out of luck with using XFree86 4.0 or
newer with my machine?  Or generically, is anyone without a card on the
PCI bus out of luck?

Thanks,

Kevin

--
Kevin M. Myer
Systems Administrator
Lancaster-Lebanon Intermediate Unit 13
(717)-560-6140


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel D nzer]

"Kevin M. Myer" wrote:

> Secondly, the video chip doesn't show up on the PCI bus.  Although XFree86
> 4.0 apparently supports the controlfb (which is what the 8500 has), it
> also needs a BusID to be used.  Am I out of luck with using XFree86 4.0 or
> newer with my machine?  Or generically, is anyone without a card on the
> PCI bus out of luck?

No, the contrary, you're very lucky! :)

As the chip doesn't show up, the X server can't deactivate it. So you don't
need to specify a bus ID (which would prevent the server of disabling the chip ;).


Michel

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Lanners]

Hi there,

On  15 Aug, this message from Kevin M. Myer echoed through cyberspace:
> A couple of issues have cropped up with my PowerMac 8500.  I am running
> Paulus' 2.4.0-test6 kernel and my console has developed a sort of mirror
> image on the far right one-eighth of the screen.  Basically, everything on
> the screen is mirrored in that eighth of the screen albeit much
> smaller.  For example, as I type this, tiny white lines are being drawn to
> my right.  If I were to `ls --color` a directory, different color lines
> show up.  This behaviour wasn't there in Paulus' 2.4.0-test1-ac21 kernel
> of a few rsyncs ago.

I've seen this too; but have no explanation. It might be caused by
hardware running on the limit of it's spec; control is quite picky in
this respect. But then again, something changed that made the problems
apear...

> Secondly, the video chip doesn't show up on the PCI bus.  Although XFree86
> 4.0 apparently supports the controlfb (which is what the 8500 has), it
> also needs a BusID to be used.  Am I out of luck with using XFree86 4.0 or
> newer with my machine?  Or generically, is anyone without a card on the
> PCI bus out of luck?

Since control has its own dedicated PCI-like bus (Apple calls it a
'VCI'), it will not show up as a PCI device unless you use a PCI-patched
kernel. The missing BusID is not a problem for XF4, rest assured.
However, XF4 does not support control directly, but rather through the
generic framebuffer driver.

See my page:

http://www.cpu.lu/~mlan/linux/dev/xf4.html

on how to get XF4 to work with control.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Lanners]

Hi there,

On  15 Aug, this message from Kevin M. Myer echoed through cyberspace:
> A couple of issues have cropped up with my PowerMac 8500.  I am running
> Paulus' 2.4.0-test6 kernel and my console has developed a sort of mirror
> image on the far right one-eighth of the screen.  Basically, everything on
> the screen is mirrored in that eighth of the screen albeit much
> smaller.  For example, as I type this, tiny white lines are being drawn to
> my right.  If I were to `ls --color` a directory, different color lines
> show up.  This behaviour wasn't there in Paulus' 2.4.0-test1-ac21 kernel
> of a few rsyncs ago.

I was able to boot a 2.4.0-t6 kernel tonight (it's like once in a
million boots for me right now with 2.4.0) and experienced the same
problem; although I had only like 6-8 pairs of single-pixel horizontal
lines, maybe 150 or so pixels long, on the right edge of the screen.

Those lines mirrored image content from the left side of the screen, at
the same height, and around 150 pixels inside the screen. I could also
verify that those 'lines' are not part of the pixel data in VRAM, but
are only added on-screen by control.

I've also had a look at what changed on control from earlier versions,
and found only the pitch of the lines that changed.

In fact, before, the line length was exactly hpixels * bytes/pixel,
whereas now there's an additional 0x20 bytes in each line. I have not
been able to boot a 2.4.0 kernel with any fix applied, but you could try
and build a version without those 0x20 bytes added (they are found in a
few spots inside controlfb.c).

As to why these 0x20 bytes were added, anybody know an explanation? And,
if they do serve a purpose (I suppose so ;-), it would be better to add
the exact number of bytes as a #define somewhere...

Thanks

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Daniel Jacobowitz]

On Fri, Aug 18, 2000 at 11:02:25PM +0200, Michel Lanners wrote:
> I've also had a look at what changed on control from earlier versions,
> and found only the pitch of the lines that changed.
>
> In fact, before, the line length was exactly hpixels * bytes/pixel,
> whereas now there's an additional 0x20 bytes in each line. I have not
> been able to boot a 2.4.0 kernel with any fix applied, but you could try
> and build a version without those 0x20 bytes added (they are found in a
> few spots inside controlfb.c).
>
> As to why these 0x20 bytes were added, anybody know an explanation? And,
> if they do serve a purpose (I suppose so ;-), it would be better to add
> the exact number of bytes as a #define somewhere...

*sigh*

I have no idea where this came from, but 0x20 means it has something to
do with cursor support, I'd bet.  I seem to recall someone talking
about that a few months ago... that is how hardware cursor is generally
implemented, by a 32 pixel block at the end of the scanline.

Dan
the underactive and out of touch controlfb maintainer

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Lanners]

Hi all,

On  18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
>> In fact, before, the line length was exactly hpixels * bytes/pixel,
>> whereas now there's an additional 0x20 bytes in each line. I have not
>> been able to boot a 2.4.0 kernel with any fix applied, but you could try
>> and build a version without those 0x20 bytes added (they are found in a
>> few spots inside controlfb.c).
>>
>> As to why these 0x20 bytes were added, anybody know an explanation? And,
>> if they do serve a purpose (I suppose so ;-), it would be better to add
>> the exact number of bytes as a #define somewhere...
>
> *sigh*
>
> I have no idea where this came from, but 0x20 means it has something to
> do with cursor support, I'd bet.  I seem to recall someone talking
> about that a few months ago... that is how hardware cursor is generally
> implemented, by a 32 pixel block at the end of the scanline.

That's what I was thinking about. However, I'm not sure that XFree
supports a display with discontiguous lines in video memory. I think I
read that somewhere in some mailing list or X doc... Can any of the
XFree specialists confirm?

My XFree 4.0 goes into an infinite loop eating CPU time when I boot a
2.4.0 kernel. Xpmac does work, but with the artifact described in my
previous mail.

Anyway, going the way of supporting the hardware cursor is good, but
we're not there yet ;-)

> Dan
> the underactive and out of touch controlfb maintainer


Michel,
the underactive and out of touch planb maintainer ;-)

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Benjamin Herrenschmidt]

>
>My XFree 4.0 goes into an infinite loop eating CPU time when I boot a
>2.4.0 kernel. Xpmac does work, but with the artifact described in my
>previous mail.
>
>Anyway, going the way of supporting the hardware cursor is good, but
>we're not there yet ;-)

I have this exact same problem with XF4 on my Pismo (r128) with any 2.4.
The X server dies in this infinite loop and a black screen. Theo only way
I found to get the screen back is to telnet into the box, kill -9 the X
server, and launch Xpmac. This seems to restore the console system into a
working state.

I don't know what's up yet.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 hangs on 2.4 kernel (was: Re: Control fb problem on 8500)

[Michel Lanners]

On  19 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>My XFree 4.0 goes into an infinite loop eating CPU time when I boot a
>>2.4.0 kernel. Xpmac does work, but with the artifact described in my
>>previous mail.
>
> I have this exact same problem with XF4 on my Pismo (r128) with any 2.4.
> The X server dies in this infinite loop and a black screen. Theo only way
> I found to get the screen back is to telnet into the box, kill -9 the X
> server, and launch Xpmac. This seems to restore the console system into a
> working state.

Ahh, so that problem is not control-specific.

> I don't know what's up yet.

Are you using the new input layer from bk? I'm not; I use Paul's devel
tree, which doesn't include that part yet.

Strange...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 hangs on 2.4 kernel (was: Re: Control fb problem on 8500)

[Martin Costabel]

Michel Lanners wrote:
>
> On  19 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
> >>My XFree 4.0 goes into an infinite loop eating CPU time when I boot a
> >>2.4.0 kernel. Xpmac does work, but with the artifact described in my
> >>previous mail.
> >
> > I have this exact same problem with XF4 on my Pismo (r128) with any 2.4.
> > The X server dies in this infinite loop and a black screen. Theo only way
> > I found to get the screen back is to telnet into the box, kill -9 the X
> > server, and launch Xpmac. This seems to restore the console system into a
> > working state.
>
> Ahh, so that problem is not control-specific.

Just for the record: I have no such problem on my 6400 with valkyriefb
and Franz's XF4.0.1 RPMs.

> > I don't know what's up yet.
>
> Are you using the new input layer from bk? I'm not; I use Paul's devel
> tree, which doesn't include that part yet.

I am using both Paul's devel tree and the bk tree with the new input
layer (like right now). I usually use 8 bit color, sometimes 15 bit. I
had no luck with 16 bit, and more is not supported by my video card.

BTW, what's the story with the new input layer. It looks like
drivers/input has disappeared from Ben's tree?

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: XF4 hangs on 2.4 kernel (was: Re: Control fb problem on 8500)

[Kostas Gewrgiou]

On Sat, 19 Aug 2000, Michel Lanners wrote:

>
> On  19 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
> >>My XFree 4.0 goes into an infinite loop eating CPU time when I boot a
> >>2.4.0 kernel. Xpmac does work, but with the artifact described in my
> >>previous mail.
> >
> > I have this exact same problem with XF4 on my Pismo (r128) with any 2.4.
> > The X server dies in this infinite loop and a black screen. Theo only way
> > I found to get the screen back is to telnet into the box, kill -9 the X
> > server, and launch Xpmac. This seems to restore the console system into a
> > working state.
>
> Ahh, so that problem is not control-specific.
>
> > I don't know what's up yet.
>
  I had the same problem, for me it went away after i disabled xfs
i didn't had any time yet to check whats going on (i am in vacations)
but i'll try to see whats wrong once i am back.

 Kostas


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Geert Uytterhoeven]

On Sat, 19 Aug 2000, Michel Lanners wrote:
> On  18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
> >> In fact, before, the line length was exactly hpixels * bytes/pixel,
> >> whereas now there's an additional 0x20 bytes in each line. I have not
> >> been able to boot a 2.4.0 kernel with any fix applied, but you could try
> >> and build a version without those 0x20 bytes added (they are found in a
> >> few spots inside controlfb.c).
> >>
> >> As to why these 0x20 bytes were added, anybody know an explanation? And,
> >> if they do serve a purpose (I suppose so ;-), it would be better to add
> >> the exact number of bytes as a #define somewhere...
> >
> > *sigh*
> >
> > I have no idea where this came from, but 0x20 means it has something to
> > do with cursor support, I'd bet.  I seem to recall someone talking
> > about that a few months ago... that is how hardware cursor is generally
> > implemented, by a 32 pixel block at the end of the scanline.
>
> That's what I was thinking about. However, I'm not sure that XFree
> supports a display with discontiguous lines in video memory. I think I
> read that somewhere in some mailing list or X doc... Can any of the
> XFree specialists confirm?

I can speak for XFree86 3.x only, not for 4.x.

The only way to work with this is to make xres_virtual = xres+0x20. But then
XFree86 will draw into the cursor region, too.

Alternatively you can modify the XFree86 cfb code to remove the assumption
that the line_length is based on the virtual horizontal resolution.

Gr{oetje,eeting}s,

				    Geert (also underactive and out of touch)

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michael Schmitz]

> > That's what I was thinking about. However, I'm not sure that XFree
> > supports a display with discontiguous lines in video memory. I think I
> > read that somewhere in some mailing list or X doc... Can any of the
> > XFree specialists confirm?
>
> I can speak for XFree86 3.x only, not for 4.x.
>
> The only way to work with this is to make xres_virtual = xres+0x20. But then
> XFree86 will draw into the cursor region, too.

I think it used to work without such a hack - some old m68k Macs had the
video scan lines start every 1024 bytes but the actual xres was smaller.
I'll have to look at the macfb code to see what xres_virtual was set to.
I'm sure the X server didn't draw to the offscreen region as that would
have caused a bus error (at least the earlier 3.3.x versions didn't.
Later X versions drawing beyond xres would in fact explain bus errors
some people saw ...).

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Michael Schmitz wrote:
>
> > > That's what I was thinking about. However, I'm not sure that XFree
> > > supports a display with discontiguous lines in video memory. I think I
> > > read that somewhere in some mailing list or X doc... Can any of the
> > > XFree specialists confirm?
> >
> > I can speak for XFree86 3.x only, not for 4.x.
> >
> > The only way to work with this is to make xres_virtual = xres+0x20. But
> > then XFree86 will draw into the cursor region, too.
>
> I think it used to work without such a hack - some old m68k Macs had the
> video scan lines start every 1024 bytes but the actual xres was smaller.
> I'll have to look at the macfb code to see what xres_virtual was set to.
> I'm sure the X server didn't draw to the offscreen region as that would
> have caused a bus error (at least the earlier 3.3.x versions didn't.
> Later X versions drawing beyond xres would in fact explain bus errors
> some people saw ...).

X 4.0 distincts 3 values:

'xres'	- physical horizontal resolution of the current mode.

virtualX - horizontal resolution of the virtual screen. Never changes during a
screen's life.

displayWidth - the length in pixels of each scanline in memory.


Unfortunately, the fbdev driver still assumes that displayWidth == virtualX,
and most other drivers have adapted that assumption (for most of them it's
right though :) .


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Geert Uytterhoeven]

On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> Michael Schmitz wrote:
> > > > That's what I was thinking about. However, I'm not sure that XFree
> > > > supports a display with discontiguous lines in video memory. I think I
> > > > read that somewhere in some mailing list or X doc... Can any of the
> > > > XFree specialists confirm?
> > >
> > > I can speak for XFree86 3.x only, not for 4.x.
> > >
> > > The only way to work with this is to make xres_virtual = xres+0x20. But
> > > then XFree86 will draw into the cursor region, too.
> >
> > I think it used to work without such a hack - some old m68k Macs had the
> > video scan lines start every 1024 bytes but the actual xres was smaller.
> > I'll have to look at the macfb code to see what xres_virtual was set to.
> > I'm sure the X server didn't draw to the offscreen region as that would
> > have caused a bus error (at least the earlier 3.3.x versions didn't.
> > Later X versions drawing beyond xres would in fact explain bus errors
> > some people saw ...).
>
> X 4.0 distincts 3 values:
>
> 'xres'	- physical horizontal resolution of the current mode.
>
> virtualX - horizontal resolution of the virtual screen. Never changes during a
> screen's life.
>
> displayWidth - the length in pixels of each scanline in memory.

I guess this doesn't change during the screen's life neither.

> Unfortunately, the fbdev driver still assumes that displayWidth == virtualX,
> and most other drivers have adapted that assumption (for most of them it's
> right though :) .

Yuk, so we not only have depth/bits_per_pixel mixups but also
virtualX/displayWidth mixups :-(

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michael Schmitz]

> > > The only way to work with this is to make xres_virtual = xres+0x20. But
> > > then XFree86 will draw into the cursor region, too.
> >
> > I think it used to work without such a hack - some old m68k Macs had the
> > video scan lines start every 1024 bytes but the actual xres was smaller.
> > I'll have to look at the macfb code to see what xres_virtual was set to.
> > I'm sure the X server didn't draw to the offscreen region as that would
> > have caused a bus error (at least the earlier 3.3.x versions didn't.
> > Later X versions drawing beyond xres would in fact explain bus errors
> > some people saw ...).
>
> X 4.0 distincts 3 values:
>
> 'xres'	- physical horizontal resolution of the current mode.
>
> virtualX - horizontal resolution of the virtual screen. Never changes during a
> screen's life.
>
> displayWidth - the length in pixels of each scanline in memory.
>
>
> Unfortunately, the fbdev driver still assumes that displayWidth == virtualX,
> and most other drivers have adapted that assumption (for most of them it's
> right though :) .

The right assumption would be displayWidth == fix.line_length/bpp (using
xres_virtual would have been some horrible kludge). Now where in the pScrn
struct does the fb.fix struct hide?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Michel Lanners wrote:

> On  18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
> >> In fact, before, the line length was exactly hpixels * bytes/pixel,
> >> whereas now there's an additional 0x20 bytes in each line. I have not
> >> been able to boot a 2.4.0 kernel with any fix applied, but you could try
> >> and build a version without those 0x20 bytes added (they are found in a
> >> few spots inside controlfb.c).
> >>
> >> As to why these 0x20 bytes were added, anybody know an explanation? And,
> >> if they do serve a purpose (I suppose so ;-), it would be better to add
> >> the exact number of bytes as a #define somewhere...
> >
> > *sigh*
> >
> > I have no idea where this came from, but 0x20 means it has something to
> > do with cursor support, I'd bet.  I seem to recall someone talking
> > about that a few months ago... that is how hardware cursor is generally
> > implemented, by a 32 pixel block at the end of the scanline.
>
> That's what I was thinking about. However, I'm not sure that XFree
> supports a display with discontiguous lines in video memory. I think I
> read that somewhere in some mailing list or X doc... Can any of the
> XFree specialists confirm?

It does support that, if not directly then certainly via shadowfb. Maybe the
shadowfb RefreshArea function would have to be modified to take account of
this.


> My XFree 4.0 goes into an infinite loop eating CPU time when I boot a
> 2.4.0 kernel.

Works fine here. I don't use the RPM stuff, stock 4.0.1/DRI .


The other Michel,
who once thought he was the glint maintainer


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Michel Dänzer wrote:
>
> Michel Lanners wrote:
>
> > On  18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
> > >> In fact, before, the line length was exactly hpixels * bytes/pixel,
> > >> whereas now there's an additional 0x20 bytes in each line. I have not
> > >> been able to boot a 2.4.0 kernel with any fix applied, but you could try
> > >> and build a version without those 0x20 bytes added (they are found in a
> > >> few spots inside controlfb.c).
> > >>
> > >> As to why these 0x20 bytes were added, anybody know an explanation? And,
> > >> if they do serve a purpose (I suppose so ;-), it would be better to add
> > >> the exact number of bytes as a #define somewhere...
> > >
> > > *sigh*
> > >
> > > I have no idea where this came from, but 0x20 means it has something to
> > > do with cursor support, I'd bet.  I seem to recall someone talking
> > > about that a few months ago... that is how hardware cursor is generally
> > > implemented, by a 32 pixel block at the end of the scanline.
> >
> > That's what I was thinking about. However, I'm not sure that XFree
> > supports a display with discontiguous lines in video memory. I think I
> > read that somewhere in some mailing list or X doc... Can any of the
> > XFree specialists confirm?
>
> It does support that, if not directly then certainly via shadowfb. Maybe the
> shadowfb RefreshArea function would have to be modified to take account of
> this.

That's not even needed, the fbdev driver is just broken. Line 430:

	pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */

is indeed wrong. virtualX is obvious, but displayWidth should be the memory
pitch of a scanline.

Now you just have to find out where to get the correct value for displayWidth.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Geert Uytterhoeven]

On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> That's not even needed, the fbdev driver is just broken. Line 430:
>
> 	pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
>
> is indeed wrong. virtualX is obvious, but displayWidth should be the memory
> pitch of a scanline.
>
> Now you just have to find out where to get the correct value for displayWidth.

I suppose

    if (fix.line_length)
	pScrn->displayWidth = fix.line_length*8/var.bits_per_pixel;
    else
	pScrn->displayWidth = var.xres_virtual;

should work fine, except on hardware were fix.line_length*8/var.bits_per_pixel
might not be integer (e.g. if 1280x1024x24 mode requires a line_length of
4096).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Geert Uytterhoeven wrote:
>
> On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> > That's not even needed, the fbdev driver is just broken. Line 430:
> >
> >       pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
> >
> > is indeed wrong. virtualX is obvious, but displayWidth should be the
> > memory pitch of a scanline.
> >
> > Now you just have to find out where to get the correct value for
> > displayWidth.
>
> I suppose
>
>     if (fix.line_length)
>         pScrn->displayWidth = fix.line_length*8/var.bits_per_pixel;
>     else
>         pScrn->displayWidth = var.xres_virtual;
>
> should work fine, except on hardware were
> fix.line_length*8/var.bits_per_pixel might not be integer (e.g. if
> 1280x1024x24 mode requires a line_length of 4096).

I've thought of this as well. The problem is that the mode hasn't been
initialized when displayWidth is set and used.

The best I can think of ATM is the attached patch. This should make it work
with ShadowFB, which is on by default anyway.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

[-- Attachment #2: fbdev.diff --]
[-- Type: text/plain, Size: 2224 bytes --]

diff -ru ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c
--- ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c	Mon Jul  3 09:04:53 2000
+++ xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.c	Mon Aug 21 12:01:10 2000
@@ -419,6 +419,13 @@
 }

 int
+fbdevHWGetLineLength(ScrnInfoPtr pScrn)
+{
+	fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);
+	return fPtr->fix.line_length;
+}
+
+int
 fbdevHWGetType(ScrnInfoPtr pScrn)
 {
 	fbdevHWPtr fPtr = FBDEVHWPTR(pScrn);
diff -ru ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h
--- ../xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h	Sun May 28 01:32:00 2000
+++ xc/programs/Xserver/hw/xfree86/fbdevhw/fbdevhw.h	Mon Aug 21 11:57:01 2000
@@ -14,6 +14,7 @@

 char* fbdevHWGetName(ScrnInfoPtr pScrn);
 int   fbdevHWGetDepth(ScrnInfoPtr pScrn);
+int   fbdevHWGetLineLength(ScrnInfoPtr pScrn);
 int   fbdevHWGetType(ScrnInfoPtr pScrn);
 int   fbdevHWGetVidmem(ScrnInfoPtr pScrn);

diff -ru ../xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c
--- ../xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c	Sun Jun 18 16:23:22 2000
+++ xc/programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c	Mon Aug 21 14:36:29 2000
@@ -138,6 +138,7 @@

 	"fbdevHWGetName",
 	"fbdevHWGetDepth",
+	"fbdevHWGetLineLength",
 	"fbdevHWGetVidmem",

 	/* colormap */
@@ -426,7 +427,14 @@
 	if (NULL == pScrn->modes)
 		fbdevHWUseBuildinMode(pScrn);
 	pScrn->currentMode = pScrn->modes;
-	pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
+
+	if (fPtr->shadowFB)
+		pScrn->displayWidth = pScrn->virtualX;	/* ShadowFB handles this correctly */
+	else
+		/* FIXME: this doesn't work for all cases, e.g. when each scanline
+			has a padding which is independent from the depth (controlfb) */
+		pScrn->displayWidth = fbdevHWGetLineLength(pScrn)/(fbdevHWGetDepth(pScrn) >> 3);
+
 	xf86PrintModes(pScrn);

 	/* Set display resolution */
@@ -512,7 +520,7 @@
 	unsigned char *src, *dst;

 	Bpp = pScrn->bitsPerPixel >> 3;
-	FBPitch = pScrn->displayWidth * Bpp;
+	FBPitch = fbdevHWGetLineLength(pScrn);

 	while(num--) {
 		width = (pbox->x2 - pbox->x1) * Bpp;

Re: Control fb problem on 8500

[Geert Uytterhoeven]

On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> Geert Uytterhoeven wrote:
> > On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> > > That's not even needed, the fbdev driver is just broken. Line 430:
> > >
> > >       pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
> > >
> > > is indeed wrong. virtualX is obvious, but displayWidth should be the
> > > memory pitch of a scanline.
> > >
> > > Now you just have to find out where to get the correct value for
> > > displayWidth.
> >
> > I suppose
> >
> >     if (fix.line_length)
> >         pScrn->displayWidth = fix.line_length*8/var.bits_per_pixel;
> >     else
> >         pScrn->displayWidth = var.xres_virtual;
> >
> > should work fine, except on hardware were
> > fix.line_length*8/var.bits_per_pixel might not be integer (e.g. if
> > 1280x1024x24 mode requires a line_length of 4096).
>
> I've thought of this as well. The problem is that the mode hasn't been
> initialized when displayWidth is set and used.

So the X server initializes the internal screen structures before it even knows
that it can use them later?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Geert Uytterhoeven wrote:
>
> On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> > Geert Uytterhoeven wrote:
> > > On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> > > > That's not even needed, the fbdev driver is just broken. Line 430:
> > > >
> > > >       pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong
> > > > */
> > > >
> > > > is indeed wrong. virtualX is obvious, but displayWidth should be the
> > > > memory pitch of a scanline.
> > > >
> > > > Now you just have to find out where to get the correct value for
> > > > displayWidth.
> > >
> > > I suppose
> > >
> > >     if (fix.line_length)
> > >         pScrn->displayWidth = fix.line_length*8/var.bits_per_pixel;
> > >     else
> > >         pScrn->displayWidth = var.xres_virtual;
> > >
> > > should work fine, except on hardware were
> > > fix.line_length*8/var.bits_per_pixel might not be integer (e.g. if
> > > 1280x1024x24 mode requires a line_length of 4096).
> >
> > I've thought of this as well. The problem is that the mode hasn't been
> > initialized when displayWidth is set and used.
>
> So the X server initializes the internal screen structures before it even
> knows that it can use them later?

Yes. This really seems to be a rather serious design flaw - the driver is
assumed to know at any time whether it can cope with what the user wants and
how.

Anyway, what do you think about the patch I posted? Michel, can you please try
it? I don't think having to use ShadowFB with the fbdev driver is too bad
because it should generally enhance performance :) If the patch is okay, I'll
submit it to XFree86.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Geert Uytterhoeven]

On Tue, 22 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> Geert Uytterhoeven wrote:
> > On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> > > I've thought of this as well. The problem is that the mode hasn't been
> > > initialized when displayWidth is set and used.
> >
> > So the X server initializes the internal screen structures before it even
> > knows that it can use them later?
>
> Yes. This really seems to be a rather serious design flaw - the driver is
> assumed to know at any time whether it can cope with what the user wants and
> how.

Yes indeed.

> Anyway, what do you think about the patch I posted? Michel, can you please try
> it? I don't think having to use ShadowFB with the fbdev driver is too bad
> because it should generally enhance performance :) If the patch is okay, I'll
> submit it to XFree86.

I never read any XFree86 4.0 code.

I know ShadowFB is faster for machines without hardware acceleration. But is
it also faster with hardware acceleration?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Geert Uytterhoeven wrote:

> > Anyway, what do you think about the patch I posted? Michel, can you please
> > try it? I don't think having to use ShadowFB with the fbdev driver is too
> > bad because it should generally enhance performance :) If the patch is
> > okay, I'll submit it to XFree86.
>
> I never read any XFree86 4.0 code.
>
> I know ShadowFB is faster for machines without hardware acceleration. But is
> it also faster with hardware acceleration?

ShadowFB and hardware acceleration are mutually exclusive (except for hardware
cursor and other things I am forgetting). With ShadowFB, the framebuffer is in
main RAM and only the updated parts are copied to video RAM.

However, as the fbdev driver has no acceleration, this doesn't matter, and
ShadowFB is a win in most cases. And for the other drivers which use fbdevhw,
the assumption 'displayWidth == virtualX' holds, so they work correctly
without ShadowFB.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Lanners]

On  22 Aug, this message from Michel Dänzer echoed through cyberspace:
> Geert Uytterhoeven wrote:
>> I never read any XFree86 4.0 code.
>>
>> I know ShadowFB is faster for machines without hardware acceleration. But is
>> it also faster with hardware acceleration?
>
> ShadowFB and hardware acceleration are mutually exclusive (except for hardware
> cursor and other things I am forgetting). With ShadowFB, the framebuffer is in
> main RAM and only the updated parts are copied to video RAM.
>
> However, as the fbdev driver has no acceleration, this doesn't matter, and
> ShadowFB is a win in most cases. And for the other drivers which use fbdevhw,
> the assumption 'displayWidth == virtualX' holds, so they work correctly
> without ShadowFB.

Hm, speaking of hardware cursor. Since this all started on exactly that
issue.... supposing someone actually finds out how control's hardware
cursor works, and supposing someone would actually take the time to
implement this, wouldn't we need to provide a XFree driver as well? I
guess plain fbdevhw doesn't support hw cursor...

In that event, would it be possible to address the above-mentioned flaw
in XFree in that particular driver, or is the problem more geneic (i.e.
littered throughout the source tree)?

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Michel Lanners wrote:

> supposing someone actually finds out how control's hardware cursor works,
> and supposing someone would actually take the time to implement this,
> wouldn't we need to provide a XFree driver as well? I guess plain fbdevhw
> doesn't support hw cursor...

Don't think that there are fbdev ioctls to control it either.


> In that event, would it be possible to address the above-mentioned flaw
> in XFree in that particular driver, or is the problem more geneic (i.e.
> littered throughout the source tree)?

No, the driver can handle it very easily by setting pScrn->displayWidth to the
correct value.

The problem with the fbdev driver is that it should know that value before it
possibly can (before the mode is initialized).


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Geert Uytterhoeven]

On Tue, 22 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
> Michel Lanners wrote:
> > supposing someone actually finds out how control's hardware cursor works,
> > and supposing someone would actually take the time to implement this,
> > wouldn't we need to provide a XFree driver as well? I guess plain fbdevhw
> > doesn't support hw cursor...
>
> Don't think that there are fbdev ioctls to control it either.

Actually there are, but they are highly experimental since about 4 years :-)
Only Amifb should support them more or less.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Lanners]

Hi all,

On  22 Aug, this message from Michel Dänzer echoed through cyberspace:
>> > > I suppose
>> > >
>> > >     if (fix.line_length)
>> > >         pScrn->displayWidth = fix.line_length*8/var.bits_per_pixel;
>> > >     else
>> > >         pScrn->displayWidth = var.xres_virtual;
>> > >
>> > > should work fine, except on hardware were
>> > > fix.line_length*8/var.bits_per_pixel might not be integer (e.g. if
>> > > 1280x1024x24 mode requires a line_length of 4096).
>> >
>> > I've thought of this as well. The problem is that the mode hasn't been
>> > initialized when displayWidth is set and used.
>>
>> So the X server initializes the internal screen structures before it even
>> knows that it can use them later?
>
> Yes. This really seems to be a rather serious design flaw - the driver is
> assumed to know at any time whether it can cope with what the user wants and
> how.
>
> Anyway, what do you think about the patch I posted? Michel, can you please try
> it?

I'll try to get some time next weekend to do so. I need to get new X
sources (4.0.1), and I need to do that at work rather than via my ISDN
dial-up ;-)

> I don't think having to use ShadowFB with the fbdev driver is too bad
> because it should generally enhance performance :)

I guess control is the exception. I found out it isn't worth the memory
impact. I once ran a complete x11perf run comparing with and without
shadowfb, and with shadowfb was overall slower. Some operations were
faster, though, but not in general.

I suppose this is because main memory isn't faster on my box than access
to the VRAM. Both are accessed via a 50 MHz bus, and are of the same
basic type (plain old DRAM, that is).

I'll let you know....

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Michel Lanners wrote:

> > I don't think having to use ShadowFB with the fbdev driver is too bad
> > because it should generally enhance performance :)
>
> I guess control is the exception. I found out it isn't worth the memory
> impact. I once ran a complete x11perf run comparing with and without
> shadowfb, and with shadowfb was overall slower. Some operations were
> faster, though, but not in general.

Oh no. This is very bad.


> I suppose this is because main memory isn't faster on my box than access
> to the VRAM. Both are accessed via a 50 MHz bus, and are of the same
> basic type (plain old DRAM, that is).

Indeed, this breaks the basic assumption behind ShadowFB, that main RAM is
very fast compared to video RAM. The situation is similar for Amigas :-/


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and The DRI Project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michael Schmitz]

> > > I don't think having to use ShadowFB with the fbdev driver is too bad
> > > because it should generally enhance performance :)
> >
> > I guess control is the exception. I found out it isn't worth the memory
> > impact. I once ran a complete x11perf run comparing with and without
> > shadowfb, and with shadowfb was overall slower. Some operations were
> > faster, though, but not in general.
>
> Oh no. This is very bad.

But that was on 4.0, not 4.0.1, right? shadowfb on 4.0 fbdev treated me to
a ~5sec delay on logout while that nice grey pattern was drawn line by
line. Someone said it was due to a bug in shadowfb... and I'd assume it
was fixed in 4.0.1.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michel Dänzer]

Michael Schmitz wrote:
>
> > > > I don't think having to use ShadowFB with the fbdev driver is too bad
> > > > because it should generally enhance performance :)
> > >
> > > I guess control is the exception. I found out it isn't worth the memory
> > > impact. I once ran a complete x11perf run comparing with and without
> > > shadowfb, and with shadowfb was overall slower. Some operations were
> > > faster, though, but not in general.
> >
> > Oh no. This is very bad.
>
> But that was on 4.0, not 4.0.1, right? shadowfb on 4.0 fbdev treated me to
> a ~5sec delay on logout while that nice grey pattern was drawn line by
> line. Someone said it was due to a bug in shadowfb... and I'd assume it
> was fixed in 4.0.1.

This is GNOME, right? There has been discussion about that on an XFree86 list
(if it was Xpert, you can search the archive if you like), it's a GNOME bug.
It used stippled rectangles to draw that, which led to the whole rectangle
area being considered updated and copied from the shadow framebuffer to the
real one.


Michel


--
Earthling Michel Dänzer (MrCooper)  \  CS student and free software enthusiast
Debian GNU/Linux (powerpc,i386) user \   member of XFree86 and the DRI project

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Michael Schmitz]

> > It does support that, if not directly then certainly via shadowfb. Maybe the
> > shadowfb RefreshArea function would have to be modified to take account of
> > this.
>
> That's not even needed, the fbdev driver is just broken. Line 430:
>
> 	pScrn->displayWidth = pScrn->virtualX; /* FIXME: might be wrong */
>
> is indeed wrong. virtualX is obvious, but displayWidth should be the memory
> pitch of a scanline.

That would indeed be silly.

> Now you just have to find out where to get the correct value for displayWidth.

Something like xres*bpp/8 ??

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[David Riley]

Daniel Jacobowitz wrote:
>
> On Fri, Aug 18, 2000 at 11:02:25PM +0200, Michel Lanners wrote:
> > I've also had a look at what changed on control from earlier versions,
> > and found only the pitch of the lines that changed.
> >
> > In fact, before, the line length was exactly hpixels * bytes/pixel,
> > whereas now there's an additional 0x20 bytes in each line. I have not
> > been able to boot a 2.4.0 kernel with any fix applied, but you could try
> > and build a version without those 0x20 bytes added (they are found in a
> > few spots inside controlfb.c).
> >
> > As to why these 0x20 bytes were added, anybody know an explanation? And,
> > if they do serve a purpose (I suppose so ;-), it would be better to add
> > the exact number of bytes as a #define somewhere...
>
> *sigh*
>
> I have no idea where this came from, but 0x20 means it has something to
> do with cursor support, I'd bet.  I seem to recall someone talking
> about that a few months ago... that is how hardware cursor is generally
> implemented, by a 32 pixel block at the end of the scanline.

The extra 32 bytes are indeed for a hardware cursor.  On the Mac OS,
when any of the programs I write that write directly to the screen go
awry (the address offset messes up and sends gobblety-gook all over the
screen) there is a column of scrambled pixels that follows cursor motion
(horizontally, anyway; when I move the cursor up and down, the random
bits get overwritten with clear space).  This is highly suggestive of a
hardware cursor.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[William H. Schultz]

For all of you saying that controlfb is broken...  I rsynced the
bitkeeper tree a few days ago, got it to compile, booted, etc...
however:  I have a voodoo3 card, and it is set as my main display.  The
voodoo3 was ignored, and the video went straight to the built in
controlfb on my 8500.  It worked just fine, and it worked the best it's
worked in quite some time.  I had no video artifacts at all, and
everything worked...  nice and smooth...  etc....  etc...

But the only way for me to use the voodoo3 (which is the card supporting
my BIG monitor) is to completely disable the video drivers from Boot
X...  odd quirk...

but now...  the bitkeeper tree doesn't compile again...  can't find
adbhid.o...  another story...



Hank

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Benjamin Herrenschmidt]

>
>but now...  the bitkeeper tree doesn't compile again...  can't find
>adbhid.o...  another story...

When did you resync ? This was fixed yesterday...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[Geert Uytterhoeven]

On Tue, 22 Aug 2000, William H. Schultz wrote:
> For all of you saying that controlfb is broken...  I rsynced the
> bitkeeper tree a few days ago, got it to compile, booted, etc...
> however:  I have a voodoo3 card, and it is set as my main display.  The
> voodoo3 was ignored, and the video went straight to the built in
> controlfb on my 8500.  It worked just fine, and it worked the best it's
> worked in quite some time.  I had no video artifacts at all, and
> everything worked...  nice and smooth...  etc....  etc...
>
> But the only way for me to use the voodoo3 (which is the card supporting
> my BIG monitor) is to completely disable the video drivers from Boot
> X...  odd quirk...

So your voodoo3 does work with offb (video=ofonly or `no video driver')?

In that case I'd expect it to work as well without `no video driver', since
that would mean controlfb takes the control hardware, and offb takes what's
left (i.e. the voodoo3).

Or are you using the 2.2.x bk tree and not 2.3.x?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Control fb problem on 8500

[William H. Schultz]

Geert Uytterhoeven wrote:
>
> On Tue, 22 Aug 2000, William H. Schultz wrote:
> > For all of you saying that controlfb is broken...  I rsynced the
> > bitkeeper tree a few days ago, got it to compile, booted, etc...
> > however:  I have a voodoo3 card, and it is set as my main display.  The
> > voodoo3 was ignored, and the video went straight to the built in
> > controlfb on my 8500.  It worked just fine, and it worked the best it's
> > worked in quite some time.  I had no video artifacts at all, and
> > everything worked...  nice and smooth...  etc....  etc...
> >
> > But the only way for me to use the voodoo3 (which is the card supporting
> > my BIG monitor) is to completely disable the video drivers from Boot
> > X...  odd quirk...
>
> So your voodoo3 does work with offb (video=ofonly or `no video driver')?
>
> In that case I'd expect it to work as well without `no video driver', since
> that would mean controlfb takes the control hardware, and offb takes what's
> left (i.e. the voodoo3).
>
> Or are you using the 2.2.x bk tree and not 2.3.x?
>
> Gr{oetje,eeting}s,
>
>                                                 Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> 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

I'm using the 2.3 tree --  2.4.0-test7 (yesterday's rsync).

While booting, it seems to recognize that there are two video cards--it
lists /dev/fb0 and /dev/fb1 during bootup, but /proc/fb only lists the
one currently being used.

The way I had it originally set to boot up was video=tdfxfb and it's
settings (which probably defaulted back to offb anyway).  With test7,
that little bit of text that pops up before the penguin shows up on the
voodoo, but it then swaps over to control.  Everything completes from
there and X starts up.  When I choose 'no video driver' I get my voodoo.

They both work, and it seems that if someone only had the built in
hardware (on the 8500) that it would work fine.  On the other hand, the
kernel no longer fully accepts that there are two frame buffers.
Several versions back, X was able to start up on both screens, but it no
longer will--and I think /proc/fb may have the explanation.


Hank

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/