On Tue, Aug 08, 2000 at 02:35:19PM +0200, Geert Uytterhoeven wrote:
Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
the DSP registers is part of the video mode initialization and thus is the
sole responsability of the frame buffer device, when running in `fbdev' mode.
Yes. The server shows the SAME behavior using the fbdev driver and
the ati driver. Also, as a note, the 3.3.6 XF68FB_Dev server with ati
accel also does the same thing! So there's some code that's getting
used by all three that is wrong?
I'm a little confused as to where the problem lies...
--
Josh
6B21489A | GnuPG ID/Fingerprint | huber@mclx.com |
61F0 6138 BE7B FEBF A223 E9D1 BFE1 2065 6B21 489A
On Tue, Aug 08, 2000 at 02:35:19PM +0200, Geert Uytterhoeven wrote:
quoted
Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
the DSP registers is part of the video mode initialization and thus is the
sole responsability of the frame buffer device, when running in `fbdev' mode.
Yes. The server shows the SAME behavior using the fbdev driver and
the ati driver. Also, as a note, the 3.3.6 XF68FB_Dev server with ati
accel also does the same thing! So there's some code that's getting
used by all three that is wrong?
I'm a little confused as to where the problem lies...
An X server does:
1. video mode programming
2. color map setting
3. accel engine setup
4. accel engine programming
A `hardware banging' X server does all 4 of them by banging the hardware.
An X-server in fbdev mode must use ioctl() for 1 and 2, and use hardware
banging for 3 and 4.
Playing with the DSP registers is definitely part of 1, so the X server must
not touch those registers when in fbdev mode. Probably there's some code to
change the DSP registers in the accel engine setup code in both 3.3.6 and 4.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/
From: Michael Schmitz <hidden> Date: 2000-08-08 16:54:34
quoted
Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
the DSP registers is part of the video mode initialization and thus is the
sole responsability of the frame buffer device, when running in `fbdev' mode.
Yes. The server shows the SAME behavior using the fbdev driver and
the ati driver. Also, as a note, the 3.3.6 XF68FB_Dev server with ati
accel also does the same thing! So there's some code that's getting
used by all three that is wrong?
Both the fbdev and ati driver use the fbdvhw functions to do mode init and
the like. So it seems the bug is in the kernel driver (sorry Geert).
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Is this XF4.0.1 in `fbdev' mode? If yes, it's a bug in the X server. Setting
the DSP registers is part of the video mode initialization and thus is the
sole responsability of the frame buffer device, when running in `fbdev' mode.
Yes. The server shows the SAME behavior using the fbdev driver and
the ati driver. Also, as a note, the 3.3.6 XF68FB_Dev server with ati
accel also does the same thing! So there's some code that's getting
used by all three that is wrong?
Both the fbdev and ati driver use the fbdvhw functions to do mode init and
the like. So it seems the bug is in the kernel driver (sorry Geert).
I don't see how it can be in the kernel driver, if running 3.3.6 XF68FB_Dev
changes the contents of the DSP registers.
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-09 20:20:49
quoted
Both the fbdev and ati driver use the fbdvhw functions to do mode init and
the like. So it seems the bug is in the kernel driver (sorry Geert).
I don't see how it can be in the kernel driver, if running 3.3.6 XF68FB_Dev
changes the contents of the DSP registers.
Which doesn't use any fbdev IOCTLs to do mode init (via setting the var
screeninfo), I gather?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Both the fbdev and ati driver use the fbdvhw functions to do mode init and
the like. So it seems the bug is in the kernel driver (sorry Geert).
I don't see how it can be in the kernel driver, if running 3.3.6 XF68FB_Dev
changes the contents of the DSP registers.
Which doesn't use any fbdev IOCTLs to do mode init (via setting the var
screeninfo), I gather?
It's the _fbdev_ server, so it does use the ioctl()s.
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/