From: Daniel Jacobowitz <hidden> Date: 2000-08-19 06:47:49
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/
From: Michel Lanners <hidden> Date: 2000-08-19 07:18:19
Hi all,
On 18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
quoted
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-08-19 11:59:29
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/
On 18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
quoted
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-08-19 13:20:10
Michel Lanners wrote:
On 18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
quoted
quoted
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/
From: Michel Lanners <hidden> Date: 2000-08-19 14:15:08
On 19 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
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/
From: David Riley <hidden> Date: 2000-08-19 14:40:44
Daniel Jacobowitz wrote:
On Fri, Aug 18, 2000 at 11:02:25PM +0200, Michel Lanners wrote:
quoted
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/
From: Martin Costabel <hidden> Date: 2000-08-19 15:16:29
Michel Lanners wrote:
On 19 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
quoted
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.
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-08-21 08:57:48
Michel Dänzer wrote:
Michel Lanners wrote:
quoted
On 18 Aug, this message from Daniel Jacobowitz echoed through cyberspace:
quoted
quoted
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/
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/
From: Michael Schmitz <hidden> Date: 2000-08-21 11:25:11
quoted
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/
From: Michael Schmitz <hidden> Date: 2000-08-21 11:33:04
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-08-21 13:14:38
Geert Uytterhoeven wrote:
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
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
From: Michel D�nzer <hidden> Date: 2000-08-21 13:19:11
Michael Schmitz wrote:
quoted
quoted
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/
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
Michael Schmitz wrote:
quoted
quoted
quoted
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/
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
Geert Uytterhoeven wrote:
quoted
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
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/
From: Michael Schmitz <hidden> Date: 2000-08-21 17:11:45
quoted
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-08-22 08:33:31
Geert Uytterhoeven wrote:
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
Geert Uytterhoeven wrote:
quoted
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
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/
On Tue, 22 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
Geert Uytterhoeven wrote:
quoted
On Mon, 21 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-08-22 10:14:27
Geert Uytterhoeven wrote:
quoted
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/
From: Michel Lanners <hidden> Date: 2000-08-22 21:10:41
Hi all,
On 22 Aug, this message from Michel Dänzer echoed through cyberspace:
quoted
quoted
quoted
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/
From: Michel Lanners <hidden> Date: 2000-08-22 21:15:29
On 22 Aug, this message from Michel Dänzer echoed through cyberspace:
Geert Uytterhoeven wrote:
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-08-22 21:55:19
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/
From: Michel D�nzer <hidden> Date: 2000-08-22 22:39:52
Michel Lanners wrote:
quoted
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/
From: Michael Schmitz <hidden> Date: 2000-08-23 08:11:04
quoted
quoted
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/
From: Michel D�nzer <hidden> Date: 2000-08-23 08:21:46
Michael Schmitz wrote:
quoted
quoted
quoted
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/
On Tue, 22 Aug 2000, Michel [iso-8859-1] Dänzer wrote:
Michel Lanners wrote:
quoted
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/
On 19 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
quoted
quoted
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.
quoted
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/