linuxdc-dev

[linuxdc-dev][PATCH] maple keyboard fix

[Robert L. <rm...@te...>]

In 2.4.15-pre7, the following change to include/asm-sh/string.h were
merged:

-#define __HAVE_ARCH_MEMSCAN
-#define memscan memchr

This was a Good Thing, since the two function are not specified to have
the same behavior.  memchr returns NULL on no match, and memscan returns
addr+1 if a match is not found.

The problem lies in that there is SH arch code that depended on the
false behavior of memscan -- that is, even though they called memscan,
they assumed it returned NULL on no match (since it was defined as
memchr which does just that).

At least one problem area was found: maple_keyb.c, and this was causing
my previously reported keyboard problem on my Dreamcast.

The attached patch fixes the problems.  There may be more.  _Please_
merge into CVS.

	Robert Love

Re: [linuxdc-dev][PATCH] maple keyboard fix

[M. R. B. <mr...@0x...>]

* Robert Love <rm...@te...> on Thu, Dec 06, 2001:

>=20
> The attached patch fixes the problems.  There may be more.  _Please_
> merge into CVS.

Applied to branch and head - thanks!

M. R.

> --- linux/drivers/char/maple_keyb.c.orig	Thu Dec  6 01:39:45 2001
> +++ linux/drivers/char/maple_keyb.c	Thu Dec  6 01:40:48 2001
> @@ -55,7 +55,7 @@
> =20
>  	for(i=3D2; i<8; i++) {
> =20
> -		if(kbd->old[i]>3&&memscan(kbd->new+2, kbd->old[i], 6)=3D=3DNULL) {
> +		if(kbd->old[i]>3&&memchr(kbd->new+2, kbd->old[i], 6)=3D=3DNULL) {
>  			if(dc_kbd_keycode[kbd->old[i]])
>  				input_report_key(dev,
>  						 dc_kbd_keycode[kbd->old[i]],
> @@ -65,7 +65,7 @@
>  				       kbd->old[i]);
>  		}
> =20
> -		if(kbd->new[i]>3&&memscan(kbd->old+2, kbd->new[i], 6)!=3DNULL) {
> +		if(kbd->new[i]>3&&memchr(kbd->old+2, kbd->new[i], 6)!=3DNULL) {
>  			if(dc_kbd_keycode[kbd->new[i]])
>  				input_report_key(dev,
>  						 dc_kbd_keycode[kbd->new[i]],

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[Robert L. <rm...@te...>]

On Thu, 2001-12-06 at 10:25, M. R. Brown wrote:

> > The attached patch fixes the problems.  There may be more.  _Please_
> > merge into CVS.
> 
> Applied to branch and head - thanks!

Thank you.  As SH users start using 2.4.15-pre7 and later kernels, they
may experience odd problems.  I wish I could give a formula for tracking
down if a specific issue is this memchr/memscan problem, but it can
manifest itself in a myriad of ways.

One thing to consider is that _all_ uses of memscan are either broken
now or where broken before the change.  I.e., they expected one of the
two behaviors at some point but got the other.  This means a global
audit of memscan use may be useful.

	Robert Love

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[Jeremy S. <js...@mv...>]

Robert Love wrote:

> Thank you.  As SH users start using 2.4.15-pre7 and later kernels, they
> may experience odd problems.  I wish I could give a formula for tracking
> down if a specific issue is this memchr/memscan problem, but it can
> manifest itself in a myriad of ways.
>
> One thing to consider is that _all_ uses of memscan are either broken
> now or where broken before the change.  I.e., they expected one of the
> two behaviors at some point but got the other.  This means a global
> audit of memscan use may be useful.

Sorry about missing that one.  In the linuxsh drop-in tree, maple_keyb.c
looks like the only file that references memscan; as far as I can tell the
only other reference in the entire linux tree is drivers/usb/usbkbd.c, the
driver that maple_keyb.c was based on.

--Jeremy Siegel

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[Robert L. <rm...@te...>]

On Thu, 2001-12-06 at 16:04, Jeremy Siegel wrote:

> Sorry about missing that one.  In the linuxsh drop-in tree, maple_keyb.c
> looks like the only file that references memscan; as far as I can tell the
> only other reference in the entire linux tree is drivers/usb/usbkbd.c, the
> driver that maple_keyb.c was based on.

Heh, nothing to apologize for.  Yah, it seems nothing else in SH uses
memscan.  Good.  drivers/usb/usbkbd does use it, and I bet that is a
bug.  Its in a conditional and since it always evaluates to true ...
whoops!  I think some other places do use it, though.  UDF and ext2, for
example, and it is legitimate.  If not we could rip it out of everything
and save some space.

	Robert Love

[linuxdc-dev]Some good news at last

[Adrian M. <ad...@mc...>]

Some good news...

My OSS sound driver for Dreamcast linux has at last got to first base - it 
will now respond to a cat somefile > /dev/dsp by outputting static.

http://www.mcmen.demon.co.uk/linuxdc/aica

The code will shortly go on the web site - but it's still a mess and 
shouldn't be considered anything other than a curiousity at the moment.

For those who are interested, I have to say that most credit must go to Dan 
Potter and his KOS code (and, I suppose, to Marcus Comstedt to whom Dan P. 
gives credit).

At the moment the "OSS driver" loads in the KOS soundstream code as a static 
array and then uses Dan's IPC mechanism to communicate.

There will need to be some hacking of Dan's code to make it comply to the OSS 
PI eventually - but that bit is all his code at the moment.

None of the ioctls are written and the architecture is all wrong now (it 
turns the SPU on and off between writes) - but at leasr I know it can work.

Feel a little proud for me - 7 months ago I had never written a line of C in 
my life (though i admit I had written many thousands of lines of C++, java 
and perl but they were all for the enemy's operating system).

Adrian