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

[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

[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/

Problems setting up XF86Config for XFree86 4.0?

[john peter grimes]

Hi,
	I think I can't get 3.9.18 to run (although it built easily with
the patch from Kevin Hendricks) as I have misconfigured my XF86Config
file.  I would love to get 1024x1280@60Hz & 32bpp but right now I am
getting a misconfigured screen error (see very end of message) for any
res & bpp I try.
	I'll append my XF86Config file and log file.
	I have a powercenter with G3 upgrade, personally compiled
2.2.14pre9 with rage 128 support, rage 128gl pci card with 16mg vram,
optiquest Q71 monitor, alps adb glidepoint pointing device, and a standard
apple adb keyboard.
	At the least could people email me your working XF86Config from
3.9.18 (I already have Kevin's from 3.9.17 I think it was).
					much appreciated,
					john


********XF86Config file***************
# File generated by xf86config.

#
# Copyright (c) 1999 by The XFree86 Project, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
# THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
#
# Except as contained in this notice, the name of the XFree86 Project shall
# not be used in advertising or otherwise to promote the sale, use or other
# dealings in this Software without prior written authorization from the
# XFree86 Project.
#

# **********************************************************************
# Refer to the XF86Config(4/5) man page for details about the format of
# this file.
# **********************************************************************

# **********************************************************************
# Module section -- this  section  is used to specify
# which dynamically loadable modules to load.
# **********************************************************************
#
Section "Module"

# This loads the DBE extension module.

    Load        "dbe"  	# Double buffer extension

# This loads the miscellaneous extensions module, and disables
# initialisation of the XFree86-DGA extension within that module.
    SubSection  "extmod"
      Option    "omit xfree86-dga"   # don't initialise the DGA extension
    EndSubSection

# This loads the Type1 and FreeType font modules
    Load        "type1"
    Load        "freetype"

# This loads the GLX module
#    Load       "glx"

EndSection

# **********************************************************************
# Files section.  This allows default font and rgb paths to be set
# **********************************************************************

Section "Files"

# The location of the RGB database.  Note, this is the name of the
# file minus the extension (like ".txt" or ".db").  There is normally
# no need to change the default.

    RgbPath	"/usr/X11R6/lib/X11/rgb"

# Multiple FontPath entries are allowed (which are concatenated together),
# as well as specifying multiple comma-separated entries in one FontPath
# command (or a combination of both methods)
#
# If you don't have a floating point coprocessor and emacs, Mosaic or other
# programs take long to start up, try moving the Type1 and Speedo directory
# to the end of this list (or comment them out).
#

    FontPath   "/usr/X11R6/lib/X11/fonts/local/"
    FontPath   "/usr/X11R6/lib/X11/fonts/misc/"
    FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
    FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
    FontPath   "/usr/X11R6/lib/X11/fonts/Type1/"
    FontPath   "/usr/X11R6/lib/X11/fonts/Speedo/"
    FontPath   "/usr/X11R6/lib/X11/fonts/75dpi/"
    FontPath   "/usr/X11R6/lib/X11/fonts/100dpi/"

# The module search path.  The default path is shown here.

#    ModulePath "/usr/X11R6/lib/modules"

EndSection

# **********************************************************************
# Server flags section.
# **********************************************************************

Section "ServerFlags"

# Uncomment this to cause a core dump at the spot where a signal is
# received.  This may leave the console in an unusable state, but may
# provide a better stack trace in the core dump to aid in debugging

#    Option "NoTrapSignals"

# Uncomment this to disable the <Crtl><Alt><BS> server abort sequence
# This allows clients to receive this key event.

#    Option "DontZap"

# Uncomment this to disable the <Crtl><Alt><KP_+>/<KP_-> mode switching
# sequences.  This allows clients to receive these key events.

#    Option "Dont Zoom"

# Uncomment this to disable tuning with the xvidtune client. With
# it the client can still run and fetch card and monitor attributes,
# but it will not be allowed to change them. If it tries it will
# receive a protocol error.

#    Option "DisableVidModeExtension"

# Uncomment this to enable the use of a non-local xvidtune client.

#    Option "AllowNonLocalXvidtune"

# Uncomment this to disable dynamically modifying the input device
# (mouse and keyboard) settings.

#    Option "DisableModInDev"

# Uncomment this to enable the use of a non-local client to
# change the keyboard or mouse settings (currently only xset).

#    Option "AllowNonLocalModInDev"

EndSection

# **********************************************************************
# Input devices
# **********************************************************************

# **********************************************************************
# Core keyboard's InputDevice section
# **********************************************************************

Section "InputDevice"

    Identifier	"Keyboard1"
    Driver	"Keyboard"
# For most OSs the protocol can be omitted (it defaults to "Standard").
# When using XQUEUE (only for SVR3 and SVR4, but not Solaris),
# uncomment the following line.

#    Option     "Protocol"      "Xqueue"

    Option "AutoRepeat" "500 30"

# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
#    Option	"Xleds"      "1 2 3"

#    Option "LeftAlt"     "Meta"
#    Option "RightAlt"    "ModeShift"

# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults).  For example, for a non-U.S.
# keyboard, you will probably want to use:
#    Option "XkbModel"    "pc102"
# If you have a US Microsoft Natural keyboard, you can use:
#    Option "XkbModel"    "microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
#    Option "XkbLayout"   "de"
# or:
#    Option "XkbLayout"   "de"
#    Option "XkbVariant"  "nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
#    Option "XkbOptions"  "ctrl:swapcaps"

# These are the default XKB settings for XFree86
#    Option "XkbRules"    "xfree86"
#    Option "XkbModel"    "pc101"
#    Option "XkbLayout"   "us"
#    Option "XkbVariant"  ""
#    Option "XkbOptions"  ""

#    Option "XkbDisable"

    Option "XkbRules"	"xfree86"
    Option "XkbModel"	"pc101"
    Option "XkbLayout"	"us"

EndSection


# **********************************************************************
# Core Pointer's InputDevice section
# **********************************************************************

Section "InputDevice"

# Identifier and driver

    Identifier	"Mouse1"
    Driver	"mouse"
    Option "Protocol"    "Busmouse"
    Option "Device"      "/dev/adbmouse"

# When using XQUEUE, comment out the above two lines, and uncomment
# the following line.

#    Option "Protocol"	"Xqueue"

# Baudrate and SampleRate are only for some Logitech mice. In
# almost every case these lines should be omitted.

#    Option "BaudRate"	"9600"
#    Option "SampleRate"	"150"

# Emulate3Buttons is an option for 2-button Microsoft mice
# Emulate3Timeout is the timeout in milliseconds (default is 50ms)

#    Option "Emulate3Buttons"
#    Option "Emulate3Timeout"    "50"

# ChordMiddle is an option for some 3-button Logitech mice

#    Option "ChordMiddle"

EndSection


# **********************************************************************
# Other input device sections
# this is optional and is required only if you
# are using extended input devices.  This is for example only.  Refer
# to the XF86Config man page for a description of the options.
# **********************************************************************
#
# Section "InputDevice"
#    Identifier  "Mouse2"
#    Driver      "mouse"
#    Option      "Protocol"      "MouseMan"
#    Option      "Device"        "/dev/mouse2"
# EndSection
#
# Section "InputDevice"
#    Identifier "spaceball"
#    Driver     "magellan"
#    Option     "Device"        "/dev/cua0"
# EndSection
#
# Section "InputDevice"
#    Identifier "spaceball2"
#    Driver     "spaceorb"
#    Option     "Device"        "/dev/cua0"
# EndSection
#
# Section "InputDevice"
#    Identifier "touchscreen0"
#    Driver     "microtouch"
#    Option     "Device"        "/dev/ttyS0"
#    Option     "MinX"          "1412"
#    Option     "MaxX"          "15184"
#    Option     "MinY"          "15372"
#    Option     "MaxY"          "1230"
#    Option     "ScreenNumber"  "0"
#    Option     "ReportingMode" "Scaled"
#    Option     "ButtonNumber"  "1"
#    Option     "SendCoreEvents"
# EndSection
#
# Section "InputDevice"
#    Identifier "touchscreen1"
#    Driver     "elo2300"
#    Option     "Device"        "/dev/ttyS0"
#    Option     "MinX"          "231"
#    Option     "MaxX"          "3868"
#    Option     "MinY"          "3858"
#    Option     "MaxY"          "272"
#    Option     "ScreenNumber"  "0"
#    Option     "ReportingMode" "Scaled"
#    Option     "ButtonThreshold"       "17"
#    Option     "ButtonNumber"  "1"
#    Option     "SendCoreEvents"
# EndSection

# **********************************************************************
# Monitor section
# **********************************************************************

# Any number of monitor sections may be present

Section "Monitor"

    Identifier  "Optiquest"

# HorizSync is in kHz unless units are specified.
# HorizSync may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.
# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
# USER MANUAL FOR THE CORRECT NUMBERS.

    HorizSync   31.5 - 64.3

#    HorizSync	30-64         # multisync
#    HorizSync	31.5, 35.2    # multiple fixed sync frequencies
#    HorizSync	15-25, 30-50  # multiple ranges of sync frequencies

# VertRefresh is in Hz unless units are specified.
# VertRefresh may be a comma separated list of discrete values, or a
# comma separated list of ranges of values.
# NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
# USER MANUAL FOR THE CORRECT NUMBERS.

    VertRefresh 50-140

EndSection


# Device configured by xf86config:

Section "Device"
    Identifier  "r128"
    Driver      "r128"
    VideoRam    16384
    Option      "UseFBDev"
    Option      "HWcursor"
    BusID       "PCI:0:13:0"
    # Insert Clocks lines here if appropriate
EndSection


# **********************************************************************
# Screen sections
# **********************************************************************

# Any number of screen sections may be present.  Each describes
# the configuration of a single screen.  A single specific screen section
# may be specified from the X server command line with the "-screen"
# option.
Section "Screen"
    Identifier  "Screen 1"
    Device      "r128"
    Monitor     "Optiquest"
    DefaultDepth 32

    Subsection "Display"
        Depth       8
        Modes       "640x480"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       16
        Modes       "640x480" "800x600" "1024x768" "1280x1024"
#        ViewPort    0 0
    EndSubsection
    Subsection "Display"
        Depth       24
        Modes       "640x480" "1024x768"
        ViewPort    0 0
    EndSubsection
    Subsection "Display"
	Depth       32
	Modes 	    "1280x1024"
	ViewPort    0 0
    EndSubsection
EndSection

# **********************************************************************
# ServerLayout sections.
# **********************************************************************

# Any number of ServerLayout sections may be present.  Each describes
# the way multiple screens are organised.  A specific ServerLayout
# section may be specified from the X server command line with the
# "-layout" option.  In the absence of this, the first section is used.
# When now ServerLayout section is present, the first Screen section
# is used alone.

Section "ServerLayout"

# The Identifier line must be present
    Identifier  "Simple Layout"

# Each Screen line specifies a Screen section name, and optionally
# the relative position of other screens.  The four names after
# primary screen name are the screens to the top, bottom, left and right
# of the primary screen.  In this example, screen 2 is located to the
# right of screen 1.

    Screen "Screen 1"

# Each InputDevice line specifies an InputDevice section name and
# optionally some options to specify the way the device is to be
# used.  Those options include "CorePointer", "CoreKeyboard" and
# "SendCoreEvents".

    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"

EndSection


*******************Xfree86 log file


XFree86 Version 3.9.18 / X Window System
(protocol Version 11, revision 0, vendor release 6400)
Release Date: 21 February 2000
	If the server is older than 6-12 months, or if your card is newer
	than the above date, look for a newer version before reporting
	problems.  (see http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.14pre9 ppc [ELF]
Module Loader present
(==) Log file: "/var/log/XFree86.0.log", Time: Fri Feb 25 01:35:57 2000
(==) Using config file: "/etc/X11/XF86Config"
Markers: (--) probed, (**) from config file, (==) default setting,
         (++) from command line, (!!) notice, (II) informational,
         (WW) warning, (EE) error, (??) unknown.
(==) ServerLayout "Simple Layout"
(**) |-->Screen "Screen 1" (0)
(**) |   |-->Monitor "Optiquest"
(**) |   |-->Device "r128"
Layout "Simple Layout"
Screen: "Screen 1" (0):
	0 0
(**) |-->Input Device "Mouse1"
(**) |-->Input Device "Keyboard1"
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xfree86"
(**) XKB: rules: "xfree86"
(**) Option "XkbModel" "pc101"
(**) XKB: model: "pc101"
(**) Option "XkbLayout" "us"
(**) XKB: layout: "us"
(**) FontPath set to "/usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/"
(**) RgbPath set to "/usr/X11R6/lib/X11/rgb"
(==) ModulePath set to "/usr/X11R6/lib/modules"
(--) using VT number 7

(II) Module ABI versions:
	XFree86 ANSI C Emulation: 0.1
	XFree86 Video Driver: 0.1
	XFree86 XInput driver : 0.0
	XFree86 Server Extension : 0.0
	XFree86 Font Renderer : 0.0
(II) Loader running on linux
(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
(II) Module bitmap: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 1.0.0
	Module class: XFree86 Font Renderer
	ABI class: XFree86 Font Renderer, version 0.0
(II) Loading font Bitmap
(II) LoadModule: "pcidata"
(II) Loading /usr/X11R6/lib/modules/libpcidata.a
(II) Module pcidata: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 0.1.0
	ABI class: XFree86 Video Driver, version 0.1
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:0b:0: chip 106b,0001 card 0000,0000 rev 03 class 06,00,00 hdr 00
(II) PCI: 00:0d:0: chip 1002,5245 card b530,0408 rev 00 class 03,00,00 hdr 00
(II) PCI: 00:0f:0: chip 1045,c861 card 1045,c861 rev 10 class 0c,03,10 hdr 00
(II) PCI: 00:10:0: chip 106b,0002 card 0000,0000 rev 02 class ff,00,00 hdr 00
(II) PCI: End of PCI scan
(II) LoadModule: "scanpci"
(II) Loading /usr/X11R6/lib/modules/libscanpci.a
(II) Module scanpci: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 0.1.0
	ABI class: XFree86 Video Driver, version 0.1
(II) UnloadModule: "scanpci"
(II) Unloading /usr/X11R6/lib/modules/libscanpci.a
(--) PCI: (0:13:0) ATI Rage 128 RE rev 0, Mem @ 0x88000000/26, 0x80804000/14, I/O @ 0x0400/8
(II) Addressable bus resource ranges are
	[0] -1	0x00000000 - 0xffffffff (0x0) MXB
	[1] -1	0x00000000 - 0xffffffff (0x0) IXB
(II) OS-reported resource ranges:
(II) Active PCI resource ranges:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x80800000 - 0x80ffffff (0x800000) MXBE
	[2] -1	0x80820000 - 0x8083ffff (0x20000) MXB(B)
	[3] -1	0x80804000 - 0x80807fff (0x4000) MXB(B)
	[4] -1	0x88000000 - 0x8bffffff (0x4000000) MXB(B)
	[5] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
(II) PCI Memory resource overlap reduced 0x80800000 from 0x80ffffff to 0x80803fff
(II) Active PCI resource ranges after removing overlaps:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x80800000 - 0x80803fff (0x4000) MXBE
	[2] -1	0x80820000 - 0x8083ffff (0x20000) MXB(B)
	[3] -1	0x80804000 - 0x80807fff (0x4000) MXB(B)
	[4] -1	0x88000000 - 0x8bffffff (0x4000000) MXB(B)
	[5] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
(II) OS-reported resource ranges after removing overlaps with PCI:
(II) All system resource ranges:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x80800000 - 0x80803fff (0x4000) MXBE
	[2] -1	0x80820000 - 0x8083ffff (0x20000) MXB(B)
	[3] -1	0x80804000 - 0x80807fff (0x4000) MXB(B)
	[4] -1	0x88000000 - 0x8bffffff (0x4000000) MXB(B)
	[5] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
(II) LoadModule: "dbe"
(II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a
(II) Module dbe: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 1.0.0
	Module class: XFree86 Server Extension
	ABI class: XFree86 Server Extension, version 0.0
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "extmod"
(II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a
(II) Module extmod: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 1.0.0
	Module class: XFree86 Server Extension
	ABI class: XFree86 Server Extension, version 0.0
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension DPMS
(II) Loading extension FontCache
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) LoadModule: "type1"
(II) Loading /usr/X11R6/lib/modules/fonts/libtype1.a
(II) Module type1: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 1.0.0
	Module class: XFree86 Font Renderer
	ABI class: XFree86 Font Renderer, version 0.0
(II) Loading font Type1
(II) Loading font CID
(II) LoadModule: "freetype"
(II) Loading /usr/X11R6/lib/modules/fonts/libfreetype.a
(II) Module freetype: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 1.1.7
	Module class: XFree86 Font Renderer
	ABI class: XFree86 Font Renderer, version 0.0
(II) Loading font FreeType
(II) LoadModule: "r128"
(II) Loading /usr/X11R6/lib/modules/drivers/r128_drv.o
(II) Module r128: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 3.0.0
	Module class: XFree86 Video Driver
	ABI class: XFree86 Video Driver, version 0.1
(II) LoadModule: "mouse"
(II) Loading /usr/X11R6/lib/modules/input/mouse_drv.o
(II) Module mouse: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 1.0.0
	Module class: XFree86 XInput Driver
	ABI class: XFree86 XInput driver, version 0.0
(II) r128: Driver for ATI Rage 128 chipset: ATI Rage 128 RE (PCI),
	ATI Rage 128 RF (AGP), ATI Rage 128 RK (PCI), ATI Rage 128 RL (AGP),
	ATI Rage 128 Pro PF (AGP)
setting up HOST: 0
pciIo_MemAccessDisable: 0x06800
r128 instances found: 1
r128 instances found: 1
(--) Chipset ATI Rage 128 RE (PCI) found
r128: card at 0:13:0 is claimed by a Device section
xf86AllocateScreen - xf86Screens[0]->pScreen = (nil)
(II) resource ranges after xf86ClaimFixedResources() call:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x80800000 - 0x80803fff (0x4000) MXBE
	[2] -1	0x80820000 - 0x8083ffff (0x20000) MXB(B)
	[3] -1	0x80804000 - 0x80807fff (0x4000) MXB(B)
	[4] -1	0x88000000 - 0x8bffffff (0x4000000) MXB(B)
	[5] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
(II) to be registered later:
	[0] 0	0x000b8000 - 0x000bffff (0x8000) MSB
	[1] 0	0x000b0000 - 0x000b7fff (0x8000) MSB
	[2] 0	0x000a0000 - 0x000affff (0x10000) MSB
	[3] 0	0x000003c0 - 0x000003df (0x20) ISB
	[4] 0	0x000003b0 - 0x000003bb (0xc) ISB
(II) NonSys:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXB
	[1] -1	0x80800000 - 0x80803fff (0x4000) MXB
(II) avoid:
(II) prefetchable Memory:
	[0] -1	0x00000000 - 0xffffffff (0x0) MXB
(II) MEM/IO:
	[0] -1	0x00000000 - 0xffffffff (0x0) MXB
	[1] -1	0x00000000 - 0xffffffff (0x0) IXB
(II) own:
	[0] -1	0x80804000 - 0x80807fff (0x4000) MXB
	[1] -1	0x00000400 - 0x000004ff (0x100) IXB
(II) own:
	[0] -1	0x80804000 - 0x80807fff (0x4000) MXB
(II) own:
(II) own:
(II) own:
(II) own:
(II) resource ranges after probing:
	[0] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[1] -1	0x80800000 - 0x80803fff (0x4000) MXBE
	[2] -1	0x80820000 - 0x8083ffff (0x20000) MXB(B)
	[3] -1	0x80804000 - 0x80807fff (0x4000) MXB(B)
	[4] -1	0x88000000 - 0x8bffffff (0x4000000) MXB(B)
	[5] 0	0x000a0000 - 0x000affff (0x10000) MSB
	[6] 0	0x000b0000 - 0x000b7fff (0x8000) MSB
	[7] 0	0x000b8000 - 0x000bffff (0x8000) MSB
	[8] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[9] 0	0x000003b0 - 0x000003bb (0xc) ISB
	[10] 0	0x000003c0 - 0x000003df (0x20) ISB
(II) Setting vga for screen 0.
Enable access 0
pciSetBusAccess: route VGA to bus 0
pciIo_MemAccessEnable: 0x06800
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/X11R6/lib/modules/libvgahw.a
(II) Module vgahw: vendor="The XFree86 Project"
	compiled for 3.9.18, module version = 0.1.0
	ABI class: XFree86 Video Driver, version 0.1
(II) r128(0): PCI bus 0 card 13 func 0
(II) Resources after driver initialization
	[0] 0	0x80804000 - 0x80807fff (0x4000) MSB
	[1] 0	0x88000000 - 0x8bffffff (0x4000000) MSB
	[2] -1	0xf3000000 - 0xf3ffffff (0x1000000) MXBE
	[3] -1	0x80800000 - 0x80803fff (0x4000) MXBE
	[4] -1	0x80820000 - 0x8083ffff (0x20000) MXB(B)
	[5] -1	0x80804000 - 0x80807fff (0x4000) MXB(B)
	[6] -1	0x88000000 - 0x8bffffff (0x4000000) MXB(B)
	[7] 0	0x000a0000 - 0x000affff (0x10000) MSB
	[8] 0	0x000b0000 - 0x000b7fff (0x8000) MSB
	[9] 0	0x000b8000 - 0x000bffff (0x8000) MSB
	[10] 0	0x00000400 - 0x000004ff (0x100) ISB
	[11] -1	0x00000400 - 0x000004ff (0x100) IXB(B)
	[12] 0	0x000003b0 - 0x000003bb (0xc) ISB
	[13] 0	0x000003c0 - 0x000003df (0x20) ISB
(EE) r128(0): Given depth (32) is not supported by r128 driver
(II) UnloadModule: "r128"
(II) UnloadModule: "vgahw"
(II) Unloading /usr/X11R6/lib/modules/libvgahw.a
pciIo_MemAccessDisable: 0x06800
pciIo_MemAccessDisable: 0x06800
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

When reporting a problem related to a server crash, please send
the full server output, not just the last messages.
This can be found in the log file "/var/log/XFree86.0.log".

Entering SETUP state
Enable access -252645136
pciIo_MemAccessDisable: 0x06800




           John Grimes - Mission Planner for Chandra X-Ray Telescope
Phone 	(H) 617-591-1393	(W) 617-496-7663	(Fax) 617-495-7356
Email 	me@johngrimes.com	Web	http://www.johngrimes.com
Pager	1-800-473-6312 		Alphanumeric  4736312@mobilecomm.net)


** 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

[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

[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/