patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kevin Hendricks]

[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]

Hi,

Yesterday the last Xfree4.0 snapshot was released (xf3.9.18).  Because of all
of the hard work of Kostas integrating powerpc changes into the official xf 4.0
tree, the xf3918 snapshot almost builds out of the box and provides wonderful
Rage128 acceleration at 16bpp and 32bpp.

The only changes needed were to xfree86.cf to add the r128 module to those being
built on powerpc and a patch to lnxResource.c provided by Kostas.

Will someone who understands PCI addressing and memory-mapped io, please look at
xc/programs/Xserver/hw/xfree86/os-support/linux/lnxResource.c and help us
figure out what really needs to be done here so that xf 4.0 final will build
completely out of the box.

Anyway,  I have attached the small patch needed.

With this patch XFree86 Xserver with full rage 128 acceleration is working
nicely on my B+W G3 right now with any recent kernel 2.2.15 kernel (ie. one
that includes Anthony's latest aty128fb.c kernel video driver).

Thanks Kostas and Anthony for your great work!

If anyone is interested, after some more testing, I will create a binary that
can be installed over XFree 3.3.X.  Just let me know if interested.

Thanks,

Kevin

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


[-- Attachment #2: xf3918_r128.diff.gz --]
[-- Type: application/x-gzip, Size: 1053 bytes --]

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kostas Gewrgiou]

On Thu, 24 Feb 2000, Kevin Hendricks wrote:

> Hi,
>
> Yesterday the last Xfree4.0 snapshot was released (xf3.9.18).  Because of all
> of the hard work of Kostas integrating powerpc changes into the official xf 4.0
> tree, the xf3918 snapshot almost builds out of the box and provides wonderful
> Rage128 acceleration at 16bpp and 32bpp.
>
> The only changes needed were to xfree86.cf to add the r128 module to those being
> built on powerpc and a patch to lnxResource.c provided by Kostas.
>
  Although xfree86 will build (and mostly work) with the provided patch for
lnxResource.c, the patch *is not* correct for ppc, we need to get the info
needed for it at runtime (ioBase etc etc..). Having iobase setup correctly
will allow us to use quite a few unsupported for now drivers (S3 etc..)

> Thanks,
>
> Kevin
>

 Kostas Gewrgiou


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kevin Hendricks]

Hi Kostas,

I previously I had updated only the Xfree86 and r128 drivers (I had been using
them installed over XFree 3.3.6) and it worked perfectly.  To see if the issue
with select vs poll and Netscape had been resolved I installed the full xf
3.9.18.

Although my X started up fine, the mouse was completely messed up (it thought
buttons were being pressed, etc).  This is with a usb mouse on B+W G3.

I looked at the xfree86 change log and noticed that there were alot of recent
changes to the mouse drivers (especially for ps2 and usb).

Have you synced your xf 3.9.18 since about Feb 17th or so (the date of the
last mouse change) and if so, have you had any problems with mouse drivers
using usb mice?

Thanks,

Kevin


--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kevin Hendricks]

Hi,

I have been looking at my mouse problems in XF 3.9.18 and put some debug
statements into Xserver/hw/xfree86/input/mouse/mouse.c to look at the raw
characters being read from /dev/usbmouse.

They seemed to pretty much be garabage and out of sync.  Sometimes the head of
the character buffer showed mouse button events and sometimes other buffer
positions showed the events.   Also, the mouse.c driver tries to read 4
characters from the usb mouse while the Xpmac mouse driver I wrote only reads 3
bytes at a time.

So the IMPS/2 protocol is just getting garbage to process into buttons, and dx,
dy, dz.

Is this a known problem?

I looked back to xf3.9.17 and it defaulted to my legacy mouse driver but xf
3.9.18 won't seem to do that  (the mouse module is forcibly loaded by XFree86
Xserver whether you want it to or not).

Any ideas here would be greatly appreciated?

Has anyone been able to get a usb mouse working with xf 3.9.18?

Thanks,

Kevin


--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Dan Bethe]

	Hi there Kevin.  Thanks for your good work.  I was wondering if we can
have similar benefits for users of ATI Rage LT Pro in the Powerbook G3
Series.
	And I assume that when you say you have full acceleration on Rage 128,
that this is just 2D acceleration.  And do you mean that the
acceleration implements all features of the card?  Or just that it's a
lot better than without acceleration support?
	I would be willing to help pay/motivate someone on a gift basis for 2D
and 3D acceleration of ATI Rage LT Pro.  I'm serious.
	I got either no response or no conclusive info from the people on the
fbdev mailing list, to whom I was originally pointed by someone on
linuxppc-dev.  The only other spot I can find for acceleration is
http://glx.on.openprojects.net.  The source rpm doesn't build for me,
and is blatantly hardcoded biased toward IA32.  It does list ATI Rage
LT and ATI "mobility", but I don't know what to do to get it to build
for me.
	What is ATI "mobility" anyway?

	Finally, here's a recent link to the ATI Linux developer kit:

http://www.ati.com/na/pages/resource_centre/dev_rel/linux.html

	And the recent Slashdot article about it, moderated up to useful
commentary:

http://slashdot.org/article.pl?sid=00/02/23/0848227&mode=nested

	Thank you!

=====
"Don't expect your own messiah; this neverworld which you desire is
only in your mind." -- http://www.dreamtheater.net/songb4.htm#IV5

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kevin Hendricks]

Hi Kostas,

> I have been looking at my mouse problems in XF 3.9.18 and put some debug
> statements into Xserver/hw/xfree86/input/mouse/mouse.c to look at the raw
> characters being read from /dev/usbmouse.

Well I have been looking at xfree86/input/mouse/mouse.c

The problem was in MouseReadInput().

What a HUGE KLUDGE!

This is some of the most whacked code I have ever seen.  Setting up tables with
wierd parameters just to try and use the exact same routine to handle all mice
regardless of how many characters they return, whether serial or bus or
whatever.

This in just simply incredibly bad coding.  It is unmaintainable since any
change will have to impact other mice or simply need another bad hack to work
around it.

The code they were using deliberately resulted in out of sync characters after
the very first call.

I hacked away most of the MouseReadInput() code and now things work as expected.

I will try to clean up my changes and put back most of what I hacked out so
that they can be integrated into the xfree86 tree in time for xfree 4.0 but
someone should really simplify it and stop trying to make one routine work for
every case (the tables simply could have pointed to individual routines).

Kevin

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Geert Uytterhoeven]

On Thu, 24 Feb 2000, Dan Bethe wrote:
> 	Hi there Kevin.  Thanks for your good work.  I was wondering if we can
> have similar benefits for users of ATI Rage LT Pro in the Powerbook G3
> Series.
> 	And I assume that when you say you have full acceleration on Rage 128,
> that this is just 2D acceleration.  And do you mean that the
> acceleration implements all features of the card?  Or just that it's a
> lot better than without acceleration support?
> 	I would be willing to help pay/motivate someone on a gift basis for 2D
> and 3D acceleration of ATI Rage LT Pro.  I'm serious.

For 2D acceleration, it looks like the ATI Mach64 is again accelerated in
XFree86 3.9.18. But I guess it doesn't work with fbdev yet, nor on big endian
machines.

So we need someone to dive into this...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- 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/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kostas Gewrgiou]

On Thu, 24 Feb 2000, Kevin Hendricks wrote:

> Hi,
>
> I have been looking at my mouse problems in XF 3.9.18 and put some debug
> statements into Xserver/hw/xfree86/input/mouse/mouse.c to look at the raw
> characters being read from /dev/usbmouse.
>
> They seemed to pretty much be garabage and out of sync.  Sometimes the head of
> the character buffer showed mouse button events and sometimes other buffer
> positions showed the events.   Also, the mouse.c driver tries to read 4
> characters from the usb mouse while the Xpmac mouse driver I wrote only reads 3
> bytes at a time.
>
> So the IMPS/2 protocol is just getting garbage to process into buttons, and dx,
> dy, dz.
>
> Is this a known problem?
>
  There were some changes recently in the mouse module in xfree, some PS/2
mice were broken for a while but that has been fixed before 3.9.18, I don't
a usb mouse at my mac so i can't help there but IMPS/2 works fine in my x86
machine.

> I looked back to xf3.9.17 and it defaulted to my legacy mouse driver but xf
> 3.9.18 won't seem to do that  (the mouse module is forcibly loaded by XFree86
> Xserver whether you want it to or not).
>
  I am not sure but i think that 3.9.17 was using the same code as well,
probably one of the changes in mouse.c broke something. Is it IMPS/2 the
right protocol for the ppc usb mice btw ? If our usb code uses 3 bytes
then its not using the IntelliMouse protocol (which is 4 bytes as i can
see in the code).

> Any ideas here would be greatly appreciated?

  Can you try with the other PS/2 protocols and if you still can't get
the mouse working try with older mouse code from 3.9.17 that will help
tracking down the problem.

> Has anyone been able to get a usb mouse working with xf 3.9.18?
>
> Thanks,
>
> Kevin
>

  Kostas Gewrgiou


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kevin_Hendricks]

[-- Attachment #1: Type: TEXT/plain, Size: 3592 bytes --]

Hi,

>  There were some changes recently in the mouse module in xfree, some PS/2
>mice were broken for a while but that has been fixed before 3.9.18, I don't
>a usb mouse at my mac so i can't help there but IMPS/2 works fine in my x86
>machine.

>From looking at mouse.c, either x86 IMPS/2 is very different from that used in
ppc or something else is messed up.

Here is the problem pieces of code:

First are the protocol parameters for IMPS2 which map to the IntelliMouse:


  {  0x08, 0x08, 0x00, 0x00,  4,   0x00, 0xff, MPF_NONE },  /* IntelliMouse */



Then in MouseReadInput() there is a check to see if the packet looks reasonable
to determine if things have gotten out of sync.

        /* Accept or reject the packet ? */
        if ((pBuf[0] & pMse->protoPara[0]) != pMse->protoPara[1] || baddata) {
#ifdef EXTMOUSEDEBUG
            if (pMse->inSync)
                ErrorF("mouse driver lost sync\n");
            ErrorF("skipping byte %02x\n",*pBuf);
#endif
            pMse->protoBufTail = --pBufP;
            for (j = 0; j < pBufP; j++)
                pBuf[j] = pBuf[j+1];
            pMse->inSync = 0;
            continue;
        }


But according to my specs on IMPS/2 the first character has the following binary
format:

0b00xy0321  with xy indicating movement in positive x or y direction of mouse
and 321 being the mouse buttons.  The later characters determine the dx, dy, and
dz values.

but the test for out of sync:

        if ((pBuf[0] & pMse->protoPara[0]) != pMse->protoPara[1] || baddata) {

             0b00xy0321 & 0x8 !=  0x8

This will result in deliberately throwing out the the current pBuf[0] since on a
good first character they can never be equal.

This was resulting in out of sync conditions completely since we were throwing
out perfectly good characters until we got one that randomly fit the sync
test!!!

I checked 3.9.17 and the values for the protocol parameters were in fact
different:

Here are the old ones:

  {  0xc0, 0x00, 0x00, 0x00,  4,   0x00, 0xff, MPF_NONE },  /* IntelliMouse */

These would work for my IMPS/2 mouse.

So because someone wanted this to work with their mouse (which has two extra
buttons) they had to change the first parameter from 0xc0 to 0x8 (because their
protocal mapped buttons 4 and 5 into those first two bits) but for some reason
they wanted or needed to always throw out the first character and then changed
the second parameter from 0x00 to 0x08.

This is simply not correct.  The IMPS/2 protocol I have seen does not have
buttons 4 and 5 and does not throw out one bad character at the beginning.

I have changed mouse.c to remove the "extra" buttons 4 and 5 and changed to the
correct out of sync parameter masks: { 0xc8, 0x00 ... and now it works fine with
3 or 4 bytes being read (the value for dz is optional).


So someone kludged it to work for their mouse and broke it for everyone else.

If IMPS/2 (nonserial) does indeed work on your x86 machine then something has
defintely changed!

I have attached my mouse.c patch and now finally with this patch in place,
everything is working on xf 3.9.18

The patch is attached:


Will you check this with your IMPS/2 (assuming it is non-serial since the IMPS/2
serial mice use a different code)?  If it works, please consider forwarding this
to the xfree lists for possible inclusion for xf 4.0.

Thanks,

Kevin

--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959

[-- Attachment #2: mouse_chg.patch.gz --]
[-- Type: APPLICATION/octet-stream, Size: 468 bytes --]

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kostas Gewrgiou]

On Sat, 26 Feb 2000, Kevin B. Hendricks wrote:

 Thats the responces i got back from the xfree list about the usb mouse
problems in 3.9.18, the bit about drivers/usb/mouse.c not setting the
the bit 3 correctly in the first data byte seems intresting, maybe the
problem is in our side ?

  Kostas

----------------------------------------------------------------------

>From yokota@zodiac.mech.utsunomiya-u.ac.jp Mon Feb 28 02:12:31 2000
Date: Sat, 26 Feb 2000 16:22:32 +0900
From: Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
Reply-To: devel@XFree86.Org
To: devel@XFree86.Org
Cc: yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject: Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc
     with r128 (fwd)

linuxppc doesn't have the PS/2 mouse port, does it?  Then, why do they
want to use the IMPS/2 protocol on the linuxppc machine?  If they are
trying to use the USB version of IntelliMouse, they shouldn't be needing
IMPS/2.

Anyway, if they somehow do use the PS/2 version of the IntelliMouse on
the PS/2 mouse port...

We need to know exact model of his mouse.  Some mice are not very
compatible with the others.  I have genuine MS IntelliMouse,
IntelliMouse Explorer, Wheel Mouse, IntelliMouse Trackball, and they
are all fine with 3.9.18.  But, as there are quite a number of
slightly different models of IntelliMouse, there may be some which
aren't so compatible with the others.

He is talking about the IMPS/2 spec.  AFAIK, Microsoft has not
released the official document describing the IntelliMouse protocol.
If he has the official spec, I would like to see it.

In any case, does anybody else has IntelliMouse which worked in 3.9.17
or before, but not in 3.9.18?  We broke IMPS/2 support somewhere
around 3.9.17d and it wasn't (supposedly) fixed until 3.9.17Z.  I
would like to believe 3.9.18 is OK with IMPS/2.

# Aha, maybe their mouse driver is trying to emulate the IMPS/2
# protocol, and does not quite get it right...

>But according to my specs on IMPS/2 the first character has the following bina
>ry
>format:
>
>0b00xy0321  with xy indicating movement in positive x or y direction of mouse
>and 321 being the mouse buttons.  The later characters determine the dx, dy, a
>nd
>dz values.

The first byte from the original IBM PS/2 mouse is

   bit 7  Y overflow
       6  X overflow
       5  sign Y
       4  sign X
       3  always 1
       2  always 0 (many 3 button PS/2 mouse uses this bit to indicate
          the middle button status)
       1  right butten
       0  left button

There have been some mice which do NOT set the bit 3, or use it
for other purposes.  But, IntelliMouse seem to always set the bit 3...

I wonder what document he is referring to and how he obtained it...

Kazu

----------------------------------------------------------------------

>  Hmm, what version of LinuxPPC is this? That probably is an old, twitchy
>USB stack. There will be a new version released shortly which should be
>better. The old versions only did imps2.

Ok, old code may be buggy.

>Could the bit3 not getting set
>be an endian issue?

Absolutely not.  It is definitely a emulator issue.

[...]
>  I'll see about slapping together a linux-usb input driver this weekend.
>That should make everybody happier.

I had a quick glance at Linux input driver suite 0.4.4 by Voltech
Pavlik.  It appears that it emulates IMPS/2 all right in mousedev.c;
we can expect this driver will work with the XFree86 mouse code.

In contrast, Linux 2.3.29's original drivers/usb/mouse.c does NOT set
the bit 3 correctly in the first data byte.  People in the linux/PPC
mailing list must have complained because of this...

I don't have a Linux/PPC box or Linux/i386 box here.  So, I cannot
verify the above findings.  But, I believe I am not very badly beside the
mark.

Kazu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kevin Hendricks]

Hi Kostas,

On Sun, 27 Feb 2000, Kostas Gewrgiou wrote:
> On Sat, 26 Feb 2000, Kevin B. Hendricks wrote:
>
>  Thats the responces i got back from the xfree list about the usb mouse
> problems in 3.9.18, the bit about drivers/usb/mouse.c not setting the
> the bit 3 correctly in the first data byte seems intresting, maybe the
> problem is in our side ?
>
>   Kostas

Okay, I have done some digging and sure enough Paul's latest stable tree (rsync
today) uses usb mouse.c (backported from an earlier version of 2.3.X?) and it
does *NOT* properly set bit 3 correctly (i.e. 0x8 is never or'd in (assuming
that is correct!)). So my current mouse patch for xf 3.9.18 is needed for the
2.2.X kernel series.

Next I went and looked at Paul's 2.3.XX development tree (rsynced as I write
this) and the mousedev.c file does literally or in 0x8 to the first character.

So this looks like a ppc specific kernel bug in the stable tree in that it does
not properly meet the imps/2 mouse specifications.  Interestingly, until the
change from XFree 3.9.17 to XFree 3.9.18, the old way of checking the first
character for out of sync worked fine for us, it is only the new way (since
they added extra buttons) that has become a problem.

So the key is to get a patch into Paul's stable tree that simply "or's in" 0x8
into the first character (the one showing buttons pressed) so that it matches
what is being done in the 2.3.X series.

I will try to get a patch that does just that and send it to Paul.

Also, I will look at the Xpmac usb mouse code and the Mac-On-Linux mouse code
(which is what I based the Xpmac code) to make sure any kernel change does not
mess up Mac-On-Linux and Xpmac.

I still think the XFree 86 mouse code is a nightmare but the problem does seem
to lie in our stable kernel series.

Thanks for you help resolving this!!!!

Take care,

Kevin


--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: patch to get latest XFree 4.0 snapshot (xf3918) to work on ppc with r128

[Kevin Hendricks]

Hi Jack,

>     I am not sure if this may become a problem but be aware that the
> usb code from linux-pmac-devel is broken on the Sawtooth G4's and the
> newer portables. So you may want to be careful when you backport any
> of that into the linux-pmac-stable tree.

Actually, I won't actually backport anything from 2.3.X.  The problem is that
the XFree 4.0 Xservers expect bit 3 to always be set in the first character
read from the input buffer of the mouse doing IMPS/2 otherwise it assumes
something got out of sync and throws that character out.

So to make XF 4.0 work with linuxpmac 2.2.X kernels all we have to do in "or" in
0x8 (to set bit 3) on the first character so that it correctly does IMPS/2
(2.3.X already has this fix in place).

--- drivers/usb/mouse.c.prev    Fri Mar  3 17:18:37 2000
+++ drivers/usb/mouse.c Fri Mar  3 17:19:56 2000
@@ -183,6 +183,7 @@
                switch (state) {
                case 0: { /* buttons and sign */
                        int buttons = mouse->buttons;
+                        buttons = buttons | 0x08; // set bit 3 to fit imps/2
                        mouse->buttons = 0;
                        if (mouse->dx < 0)
                                buttons |= 0x10;


I still need to recompile and check this with an unpatched XFree 4.0 Xserver
but this should do the trick.

Thanks,

Kevin

 --
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario  N6A-3K7  CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/