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/
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
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 ml...@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
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
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 |
| d...@debian.org | | dm...@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
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 ml...@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
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.
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
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 -- ge...@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
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.
> >
> > 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.
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.
> >
> > 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
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 -- ge...@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
Geert Uytterhoeven
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer 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.
> > >
> > > 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 :-(