[PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Mikael Pettersson]

To: davem@davemloft.net
Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net

In recent sparc64 kernels, starting a 32-bit mode X server on
a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
an Ultra5, results in the kernel complaining:

ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0

That's FBIOGTYPE and FBIOGATTR. These errors occur because
kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
arch/sparc64/kernel/ioctl32.c handled them for all devices,
but 2.6.15-rc2 dropped that support and changed SPARC-only
framebuffer drivers like ffb.c to set up ->compat_ioctl methods
pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
However, drivers for framebuffers like the Mach64 that can exist
on both SPARCs and non-SPARCs were not adjusted, so in sparc64
kernels SPARC-specific framebuffer ioctls on Mach64 devices are
no longer accepted from 32-bit mode processes. Hence the errors.

The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
to sbusfb_compat_ioctl when running in a sparc64 kernel with
compatibility for sparc32 user-space, and to compile and link
sbuslib.o with the frambuffer driver.

A complication is that sbuslib.c doesn't compile on non-SPARC
machines, so we must be careful to only enable it in the case
described above. That's why the patch puts an ugly "if" statement
in the Makefile.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>

--- linux-2.6.17/drivers/video/Makefile.~1~	2006-07-05 21:47:50.000000000 +0200
+++ linux-2.6.17/drivers/video/Makefile	2006-07-05 22:19:00.000000000 +0200
@@ -32,6 +32,9 @@ obj-$(CONFIG_FB_MATROX)		  += matrox/
 obj-$(CONFIG_FB_RIVA)		  += riva/ vgastate.o
 obj-$(CONFIG_FB_NVIDIA)		  += nvidia/
 obj-$(CONFIG_FB_ATY)		  += aty/ macmodes.o
+ifeq ($(CONFIG_SPARC64)-$(CONFIG_COMPAT),y-y)
+  obj-$(CONFIG_FB_ATY)		  += sbuslib.o
+endif
 obj-$(CONFIG_FB_ATY128)		  += aty/ macmodes.o
 obj-$(CONFIG_FB_RADEON)		  += aty/
 obj-$(CONFIG_FB_SIS)		  += sis/
--- linux-2.6.17/drivers/video/aty/atyfb_base.c.~1~	2006-07-05 21:47:50.000000000 +0200
+++ linux-2.6.17/drivers/video/aty/atyfb_base.c	2006-07-05 22:26:04.000000000 +0200
@@ -82,6 +82,9 @@
 #ifdef __sparc__
 #include <asm/pbm.h>
 #include <asm/fbio.h>
+#if defined(CONFIG_SPARC64) && defined(CONFIG_COMPAT)
+#include "../sbuslib.h"
+#endif
 #endif
 
 #ifdef CONFIG_ADB_PMU
@@ -298,6 +301,9 @@ static struct fb_ops atyfb_ops = {
 	.fb_pan_display	= atyfb_pan_display,
 	.fb_blank	= atyfb_blank,
 	.fb_ioctl	= atyfb_ioctl,
+#if defined(CONFIG_SPARC64) && defined(CONFIG_COMPAT)
+	.fb_compat_ioctl = sbusfb_compat_ioctl,
+#endif
 	.fb_fillrect	= atyfb_fillrect,
 	.fb_copyarea	= atyfb_copyarea,
 	.fb_imageblit	= atyfb_imageblit,

[PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Mikael Pettersson]

To: davem@davemloft.net
Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net

In recent sparc64 kernels, starting a 32-bit mode X server on
a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
an Ultra5, results in the kernel complaining:

ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0

That's FBIOGTYPE and FBIOGATTR. These errors occur because
kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
arch/sparc64/kernel/ioctl32.c handled them for all devices,
but 2.6.15-rc2 dropped that support and changed SPARC-only
framebuffer drivers like ffb.c to set up ->compat_ioctl methods
pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
However, drivers for framebuffers like the Mach64 that can exist
on both SPARCs and non-SPARCs were not adjusted, so in sparc64
kernels SPARC-specific framebuffer ioctls on Mach64 devices are
no longer accepted from 32-bit mode processes. Hence the errors.

The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
to sbusfb_compat_ioctl when running in a sparc64 kernel with
compatibility for sparc32 user-space, and to compile and link
sbuslib.o with the frambuffer driver.

A complication is that sbuslib.c doesn't compile on non-SPARC
machines, so we must be careful to only enable it in the case
described above. That's why the patch puts an ugly "if" statement
in the Makefile.

Signed-off-by: Mikael Pettersson <mikpe@it.uu.se>

--- linux-2.6.17/drivers/video/Makefile.~1~	2006-07-05 21:47:50.000000000 +0200
+++ linux-2.6.17/drivers/video/Makefile	2006-07-05 22:19:00.000000000 +0200
@@ -32,6 +32,9 @@ obj-$(CONFIG_FB_MATROX)		  += matrox/
 obj-$(CONFIG_FB_RIVA)		  += riva/ vgastate.o
 obj-$(CONFIG_FB_NVIDIA)		  += nvidia/
 obj-$(CONFIG_FB_ATY)		  += aty/ macmodes.o
+ifeq ($(CONFIG_SPARC64)-$(CONFIG_COMPAT),y-y)
+  obj-$(CONFIG_FB_ATY)		  += sbuslib.o
+endif
 obj-$(CONFIG_FB_ATY128)		  += aty/ macmodes.o
 obj-$(CONFIG_FB_RADEON)		  += aty/
 obj-$(CONFIG_FB_SIS)		  += sis/
--- linux-2.6.17/drivers/video/aty/atyfb_base.c.~1~	2006-07-05 21:47:50.000000000 +0200
+++ linux-2.6.17/drivers/video/aty/atyfb_base.c	2006-07-05 22:26:04.000000000 +0200
@@ -82,6 +82,9 @@
 #ifdef __sparc__
 #include <asm/pbm.h>
 #include <asm/fbio.h>
+#if defined(CONFIG_SPARC64) && defined(CONFIG_COMPAT)
+#include "../sbuslib.h"
+#endif
 #endif
 
 #ifdef CONFIG_ADB_PMU
@@ -298,6 +301,9 @@ static struct fb_ops atyfb_ops = {
 	.fb_pan_display	= atyfb_pan_display,
 	.fb_blank	= atyfb_blank,
 	.fb_ioctl	= atyfb_ioctl,
+#if defined(CONFIG_SPARC64) && defined(CONFIG_COMPAT)
+	.fb_compat_ioctl = sbusfb_compat_ioctl,
+#endif
 	.fb_fillrect	= atyfb_fillrect,
 	.fb_copyarea	= atyfb_copyarea,
 	.fb_imageblit	= atyfb_imageblit,

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Antonino A. Daplas]

Mikael Pettersson wrote:
> To: davem@davemloft.net
> Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
> Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
> 
> In recent sparc64 kernels, starting a 32-bit mode X server on
> a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
> an Ultra5, results in the kernel complaining:
> 
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0
> 
> That's FBIOGTYPE and FBIOGATTR. These errors occur because
> kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
> framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
> arch/sparc64/kernel/ioctl32.c handled them for all devices,
> but 2.6.15-rc2 dropped that support and changed SPARC-only
> framebuffer drivers like ffb.c to set up ->compat_ioctl methods
> pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
> However, drivers for framebuffers like the Mach64 that can exist
> on both SPARCs and non-SPARCs were not adjusted, so in sparc64
> kernels SPARC-specific framebuffer ioctls on Mach64 devices are
> no longer accepted from 32-bit mode processes. Hence the errors.
> 
> The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
> to sbusfb_compat_ioctl when running in a sparc64 kernel with
> compatibility for sparc32 user-space, and to compile and link
> sbuslib.o with the frambuffer driver.
> 
> A complication is that sbuslib.c doesn't compile on non-SPARC
> machines, so we must be careful to only enable it in the case
> described above. That's why the patch puts an ugly "if" statement
> in the Makefile.

Why not something like this?

1. In Kconfig

config FB_SBUSLIB
tristate
default n

Then all the sbus drivers will have this:

select FB_SBUSLIB

and atyfb will have this

select FB_SBUSLIB if SPARC64 && COMPAT

2. In Makefile
obj-$(CONFIG_FB_SBUSLIB)  += sbuslib.o

3. In sbuslib.h

#ifdef CONFIG_COMPAT
int sbusfb_compat_ioctl(...);
#else
#define sbusfb_compat_ioctl NULL;
#endif

This way, we can also eliminate all the #ifdef CONFIG_COMPAT in all the
cg* drivers and atyfb.

Tony

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Antonino A. Daplas]

Mikael Pettersson wrote:
> To: davem@davemloft.net
> Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
> Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
> 
> In recent sparc64 kernels, starting a 32-bit mode X server on
> a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
> an Ultra5, results in the kernel complaining:
> 
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
> ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0
> 
> That's FBIOGTYPE and FBIOGATTR. These errors occur because
> kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
> framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
> arch/sparc64/kernel/ioctl32.c handled them for all devices,
> but 2.6.15-rc2 dropped that support and changed SPARC-only
> framebuffer drivers like ffb.c to set up ->compat_ioctl methods
> pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
> However, drivers for framebuffers like the Mach64 that can exist
> on both SPARCs and non-SPARCs were not adjusted, so in sparc64
> kernels SPARC-specific framebuffer ioctls on Mach64 devices are
> no longer accepted from 32-bit mode processes. Hence the errors.
> 
> The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
> to sbusfb_compat_ioctl when running in a sparc64 kernel with
> compatibility for sparc32 user-space, and to compile and link
> sbuslib.o with the frambuffer driver.
> 
> A complication is that sbuslib.c doesn't compile on non-SPARC
> machines, so we must be careful to only enable it in the case
> described above. That's why the patch puts an ugly "if" statement
> in the Makefile.

Why not something like this?

1. In Kconfig

config FB_SBUSLIB
tristate
default n

Then all the sbus drivers will have this:

select FB_SBUSLIB

and atyfb will have this

select FB_SBUSLIB if SPARC64 && COMPAT

2. In Makefile
obj-$(CONFIG_FB_SBUSLIB)  += sbuslib.o

3. In sbuslib.h

#ifdef CONFIG_COMPAT
int sbusfb_compat_ioctl(...);
#else
#define sbusfb_compat_ioctl NULL;
#endif

This way, we can also eliminate all the #ifdef CONFIG_COMPAT in all the
cg* drivers and atyfb.

Tony

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Mikael Pettersson]

On Thu, 06 Jul 2006 09:01:04 +0800, Antonino A. Daplas wrote:
>Mikael Pettersson wrote:
>> To: davem@davemloft.net
>> Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
>> Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
>> 
>> In recent sparc64 kernels, starting a 32-bit mode X server on
>> a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
>> an Ultra5, results in the kernel complaining:
>> 
>> ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
>> ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0
>> 
>> That's FBIOGTYPE and FBIOGATTR. These errors occur because
>> kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
>> framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
>> arch/sparc64/kernel/ioctl32.c handled them for all devices,
>> but 2.6.15-rc2 dropped that support and changed SPARC-only
>> framebuffer drivers like ffb.c to set up ->compat_ioctl methods
>> pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
>> However, drivers for framebuffers like the Mach64 that can exist
>> on both SPARCs and non-SPARCs were not adjusted, so in sparc64
>> kernels SPARC-specific framebuffer ioctls on Mach64 devices are
>> no longer accepted from 32-bit mode processes. Hence the errors.
>> 
>> The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
>> to sbusfb_compat_ioctl when running in a sparc64 kernel with
>> compatibility for sparc32 user-space, and to compile and link
>> sbuslib.o with the frambuffer driver.
>> 
>> A complication is that sbuslib.c doesn't compile on non-SPARC
>> machines, so we must be careful to only enable it in the case
>> described above. That's why the patch puts an ugly "if" statement
>> in the Makefile.
>
>Why not something like this?
>
>1. In Kconfig
>
>config FB_SBUSLIB
>tristate
>default n
>
>Then all the sbus drivers will have this:
>
>select FB_SBUSLIB
>
>and atyfb will have this
>
>select FB_SBUSLIB if SPARC64 && COMPAT
>
>2. In Makefile
>obj-$(CONFIG_FB_SBUSLIB)  += sbuslib.o
>
>3. In sbuslib.h
>
>#ifdef CONFIG_COMPAT
>int sbusfb_compat_ioctl(...);
>#else
>#define sbusfb_compat_ioctl NULL;
>#endif

That could work. But it's a much larger patch than mine,
and I don't want to go around hacking random other stuff
just to repair atyfb. It's up the the Powers That Be to
decide whether a local fix or a global one is most appropriate.

>This way, we can also eliminate all the #ifdef CONFIG_COMPAT in all the
>cg* drivers and atyfb.

That would require sbuslib.h to be completely benign on
non-SPARC machines. If it is, great, but I can't currently
guarantee that it is.

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Mikael Pettersson]

On Thu, 06 Jul 2006 09:01:04 +0800, Antonino A. Daplas wrote:
>Mikael Pettersson wrote:
>> To: davem@davemloft.net
>> Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
>> Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
>> 
>> In recent sparc64 kernels, starting a 32-bit mode X server on
>> a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
>> an Ultra5, results in the kernel complaining:
>> 
>> ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
>> ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0
>> 
>> That's FBIOGTYPE and FBIOGATTR. These errors occur because
>> kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
>> framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
>> arch/sparc64/kernel/ioctl32.c handled them for all devices,
>> but 2.6.15-rc2 dropped that support and changed SPARC-only
>> framebuffer drivers like ffb.c to set up ->compat_ioctl methods
>> pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
>> However, drivers for framebuffers like the Mach64 that can exist
>> on both SPARCs and non-SPARCs were not adjusted, so in sparc64
>> kernels SPARC-specific framebuffer ioctls on Mach64 devices are
>> no longer accepted from 32-bit mode processes. Hence the errors.
>> 
>> The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
>> to sbusfb_compat_ioctl when running in a sparc64 kernel with
>> compatibility for sparc32 user-space, and to compile and link
>> sbuslib.o with the frambuffer driver.
>> 
>> A complication is that sbuslib.c doesn't compile on non-SPARC
>> machines, so we must be careful to only enable it in the case
>> described above. That's why the patch puts an ugly "if" statement
>> in the Makefile.
>
>Why not something like this?
>
>1. In Kconfig
>
>config FB_SBUSLIB
>tristate
>default n
>
>Then all the sbus drivers will have this:
>
>select FB_SBUSLIB
>
>and atyfb will have this
>
>select FB_SBUSLIB if SPARC64 && COMPAT
>
>2. In Makefile
>obj-$(CONFIG_FB_SBUSLIB)  += sbuslib.o
>
>3. In sbuslib.h
>
>#ifdef CONFIG_COMPAT
>int sbusfb_compat_ioctl(...);
>#else
>#define sbusfb_compat_ioctl NULL;
>#endif

That could work. But it's a much larger patch than mine,
and I don't want to go around hacking random other stuff
just to repair atyfb. It's up the the Powers That Be to
decide whether a local fix or a global one is most appropriate.

>This way, we can also eliminate all the #ifdef CONFIG_COMPAT in all the
>cg* drivers and atyfb.

That would require sbuslib.h to be completely benign on
non-SPARC machines. If it is, great, but I can't currently
guarantee that it is.

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[David Miller]

From: Mikael Pettersson <mikpe@it.uu.se>
Date: Thu, 6 Jul 2006 03:44:17 +0200 (MEST)

> That could work. But it's a much larger patch than mine,
> and I don't want to go around hacking random other stuff
> just to repair atyfb. It's up the the Powers That Be to
> decide whether a local fix or a global one is most appropriate.
 ...
> That would require sbuslib.h to be completely benign on
> non-SPARC machines. If it is, great, but I can't currently
> guarantee that it is.

I've been aware of these warnings for a long time, but I've
done nothing about it because the fix is much worse than the
cure.

The is no reason the mach64 driver should be aware in any way
of these SBUS framebuffer ioctls.

Either we can find a way to make X stop issuing these ioctls
or simply ignore the kernel message, which frankly is harmless.

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[David Miller]

From: Mikael Pettersson <mikpe@it.uu.se>
Date: Thu, 6 Jul 2006 03:44:17 +0200 (MEST)

> That could work. But it's a much larger patch than mine,
> and I don't want to go around hacking random other stuff
> just to repair atyfb. It's up the the Powers That Be to
> decide whether a local fix or a global one is most appropriate.
 ...
> That would require sbuslib.h to be completely benign on
> non-SPARC machines. If it is, great, but I can't currently
> guarantee that it is.

I've been aware of these warnings for a long time, but I've
done nothing about it because the fix is much worse than the
cure.

The is no reason the mach64 driver should be aware in any way
of these SBUS framebuffer ioctls.

Either we can find a way to make X stop issuing these ioctls
or simply ignore the kernel message, which frankly is harmless.

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Daniel Smolik]

Mikael Pettersson napsal(a):
> On Thu, 06 Jul 2006 09:01:04 +0800, Antonino A. Daplas wrote:
> 
>>Mikael Pettersson wrote:
>>
>>>To: davem@davemloft.net
>>>Subject: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer
>>>Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
>>>
>>>In recent sparc64 kernels, starting a 32-bit mode X server on
>>>a machine with a Mach64 framebuffer (CONFIG_FB_ATY_CT=y) like
>>>an Ultra5, results in the kernel complaining:
>>>
>>>ioctl32(X:1977): Unknown cmd fd(6) cmd(40584606){00} arg(ef8dd6d8) on /dev/fb0
>>>ioctl32(X:1977): Unknown cmd fd(6) cmd(40184600){00} arg(ef8dd6e0) on /dev/fb0
>>>
>>>That's FBIOGTYPE and FBIOGATTR. These errors occur because
>>>kernel 2.6.15-rc2 changed the way sparc64 handles SPARC-specific
>>>framebuffer ioctls from 32-bit processes: before 2.6.15-rc2
>>>arch/sparc64/kernel/ioctl32.c handled them for all devices,
>>>but 2.6.15-rc2 dropped that support and changed SPARC-only
>>>framebuffer drivers like ffb.c to set up ->compat_ioctl methods
>>>pointing to sbusfb_compat_ioctl in drivers/video/sbuslib.c.
>>>However, drivers for framebuffers like the Mach64 that can exist
>>>on both SPARCs and non-SPARCs were not adjusted, so in sparc64
>>>kernels SPARC-specific framebuffer ioctls on Mach64 devices are
>>>no longer accepted from 32-bit mode processes. Hence the errors.
>>>
>>>The fix is to make atyfb_base.c set up a ->compat_ioctl pointing
>>>to sbusfb_compat_ioctl when running in a sparc64 kernel with
>>>compatibility for sparc32 user-space, and to compile and link
>>>sbuslib.o with the frambuffer driver.
>>>
>>>A complication is that sbuslib.c doesn't compile on non-SPARC
>>>machines, so we must be careful to only enable it in the case
>>>described above. That's why the patch puts an ugly "if" statement
>>>in the Makefile.
>>
>>Why not something like this?
>>
>>1. In Kconfig
>>
>>config FB_SBUSLIB
>>tristate
>>default n
>>
>>Then all the sbus drivers will have this:
>>
>>select FB_SBUSLIB
>>
>>and atyfb will have this
>>
>>select FB_SBUSLIB if SPARC64 && COMPAT
>>
>>2. In Makefile
>>obj-$(CONFIG_FB_SBUSLIB)  += sbuslib.o
>>
>>3. In sbuslib.h
>>
>>#ifdef CONFIG_COMPAT
>>int sbusfb_compat_ioctl(...);
>>#else
>>#define sbusfb_compat_ioctl NULL;
>>#endif
> 
> 
> That could work. But it's a much larger patch than mine,
> and I don't want to go around hacking random other stuff
> just to repair atyfb. It's up the the Powers That Be to
> decide whether a local fix or a global one is most appropriate.
> 
> 
>>This way, we can also eliminate all the #ifdef CONFIG_COMPAT in all the
>>cg* drivers and atyfb.
> 
> 
> That would require sbuslib.h to be completely benign on
> non-SPARC machines. If it is, great, but I can't currently
> guarantee that it is.
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hi,
I have similar problem with my Raptor GFX (Permedia2). If I run 
Xserver in fb driver I get this:


ioctl32(Xorg:13334): Unknown cmd fd(7) cmd(40584606){00} arg(ff25bb9c) 
on /dev/fb0
ioctl32(Xorg:13334): Unknown cmd fd(7) cmd(40184600){00} arg(ff25bba4) 
on /dev/fb0

Is it same problem as in Atyfb ?

				Thanks
					Dan Smolik

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[David Miller]

From: Daniel Smolik <marvin@mydatex.cz>
Date: Thu, 06 Jul 2006 21:35:43 +0200

> I have similar problem with my Raptor GFX (Permedia2). If I run 
> Xserver in fb driver I get this:
> 
> 
> ioctl32(Xorg:13334): Unknown cmd fd(7) cmd(40584606){00} arg(ff25bb9c) 
> on /dev/fb0
> ioctl32(Xorg:13334): Unknown cmd fd(7) cmd(40184600){00} arg(ff25bba4) 
> on /dev/fb0
> 
> Is it same problem as in Atyfb ?

Yes, it is the same problem.

And I've used ATI R128 cards without Sun firmware on them too,
and they would cause the same messages.

It makes zero sense to put knowledge of this SBUS framebuffer
ioctl into every single framebuffer driver, because that is what
you would need to do in order to cover all possible cases.

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Daniel Smolik]

David Miller napsal(a):
> From: Daniel Smolik <marvin@mydatex.cz>
> Date: Thu, 06 Jul 2006 21:35:43 +0200
> 
> 
>>I have similar problem with my Raptor GFX (Permedia2). If I run 
>>Xserver in fb driver I get this:
>>
>>
>>ioctl32(Xorg:13334): Unknown cmd fd(7) cmd(40584606){00} arg(ff25bb9c) 
>>on /dev/fb0
>>ioctl32(Xorg:13334): Unknown cmd fd(7) cmd(40184600){00} arg(ff25bba4) 
>>on /dev/fb0
>>
>>Is it same problem as in Atyfb ?
> 
> 
> Yes, it is the same problem.
> 
> And I've used ATI R128 cards without Sun firmware on them too,
> and they would cause the same messages.
> 
> It makes zero sense to put knowledge of this SBUS framebuffer
> ioctl into every single framebuffer driver, because that is what
> you would need to do in order to cover all possible cases.

Thanks for answer. But what can we do with this problem ? Start 
communicate with video driver authors ?


			Regards
				Dan

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[David Miller]

From: Daniel Smolik <marvin@mydatex.cz>
Date: Fri, 07 Jul 2006 09:30:19 +0200

> Thanks for answer. But what can we do with this problem ? Start 
> communicate with video driver authors ?

For now just simply ignore the kernel message, it really
does no harm. :)

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Daniel Smolik]

David Miller napsal(a):
> From: Daniel Smolik <marvin@mydatex.cz>
> Date: Fri, 07 Jul 2006 09:30:19 +0200
> 
> 
>>Thanks for answer. But what can we do with this problem ? Start 
>>communicate with video driver authors ?
> 
> 
> For now just simply ignore the kernel message, it really
> does no harm. :)
I would like, but Xserver over fbdev doesn't work. Accelerated Xserver 
too because in Xorg is bug with multi PCI domain and driver doesn't 
recognize my Raptor card :-).

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[David Miller]

From: Daniel Smolik <marvin@mydatex.cz>
Date: Fri, 07 Jul 2006 12:09:15 +0200

> I would like, but Xserver over fbdev doesn't work. Accelerated Xserver 
> too because in Xorg is bug with multi PCI domain and driver doesn't 
> recognize my Raptor card :-).

Yes, these problems are known.

In fact I was playing with a Raptor card in an SB2500 just
the other week.

But those problems are totally unrelated to the ioctl messages.

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[Daniel Smolik]

David Miller napsal(a):
> From: Daniel Smolik <marvin@mydatex.cz>
> Date: Fri, 07 Jul 2006 12:09:15 +0200
> 
> 
>>I would like, but Xserver over fbdev doesn't work. Accelerated Xserver 
>>too because in Xorg is bug with multi PCI domain and driver doesn't 
>>recognize my Raptor card :-).
> 
> 
> Yes, these problems are known.
> 
> In fact I was playing with a Raptor card in an SB2500 just
> the other week.
> 
And have you this card used as console ? When I use this card as 
console in 2.4.x  work OK. But under 2.6.x work but font looks ugly 
and I cannot find solution.





> But those problems are totally unrelated to the ioctl messages.
Yes I know, but I hope that I can use Xserver over fb :-)



			Dan



> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.17 sparc64] 32-bit compat for Mach64 framebuffer

[David Miller]

From: Daniel Smolik <marvin@mydatex.cz>
Date: Fri, 07 Jul 2006 12:25:29 +0200

> And have you this card used as console ? When I use this card as 
> console in 2.4.x  work OK. But under 2.6.x work but font looks ugly 
> and I cannot find solution.

It works perfectly fine as a console, the X server is the thing
that doesn't work.