Re:Test kernels for chipsfb (2400/3400)

Re:Test kernels for chipsfb (2400/3400)

[David Ray]

At 5:21 AM 12/23/98, Benjamin Herrenschmidt wrote:
> I've uploaded two test kernels at:
> 
> <http://calvaweb.calvacom.fr/bh40/vmlinux_test.gz>
> <http://calvaweb.calvacom.fr/bh40/vmlinux_test2.gz>


I just tested these 2 kernels on my Powerbook 2400. The first kernel (vmlinux_test.gz) worked perfectly in 8-bit and 16-bit mode, both in the console (run level 3) as well as in X.

The second kernel (vmlinux_test2.gz) worked in the console at both depths, but X failed to work in either depth. The screen went black. I had to use the key combination option-power to kill X.

These were both with the 2400/3400 enhanced version of X from inria.fr.

The XF86_FBDev from the recent 3.3.3 release fails to work on any kernel I have tried on my PB 2400, including 2.1.115, and 2.1.130. Somebody posted to the list on Dec 15 claiming that the amount of VRAM is hard coded into chipsfb.c and this value doesn't match the correct amount -- and this is why XF86_FBDev doesn't work on a PB 2400. They posted a patch to chipsfb.c that raised the VRAM that X thought it had. They they claimed fixed the problem with XF86_FBDev at least partially. I haven't had time yet to try that patch myself. I believe you can find a copy of that post in the archives.

-Dave

PS I'm off the list for a couple weeks during the holidays, so please copy me by personal email for any email/postings about the Chips 65550 issue. Thanks.




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Test kernels for chipsfb (2400/3400)

[Benjamin Herrenschmidt]

I got a first round of feedback and I uploaded 2 new test kernels:

 <http://calvaweb.calvacom.fr/bh40/vmlinux_test3.gz>
 <http://calvaweb.calvacom.fr/bh40/vmlinux_test4.gz>

(the first one uses truecolor for chipsfb, the second directcolor). offb
is "fixed" to disable the ATI kuldge when not in 8 bits (apparently
breaks some models like PowerBook G3 Series) so "No video driver" should
work all the time again.

Note that those kernel will do funny things with your ADB like
auto-setting handler IDs of mice to 2 or 4 (depending on what the mouse
supports) and detecting the powerbook trackball. All this is quite
verbose (lots of printks) and I would like to know if it breaks
something. The result of those changes should be that now, mice should
use better capabilities by default and mousemode should not be necessary
most of the time.
Note also that the trackpad tapping is partially implemented (you will be
able to click by tapping but sometimes it behaves strangely).

I'll post cleaned up patches for all this later today or later this week.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Test kernels for chipsfb (2400/3400)

[Timothy A. Seufert]

At 10:00 AM +0100 12/23/98, Benjamin Herrenschmidt wrote:
>I got a first round of feedback and I uploaded 2 new test kernels:
>
> <http://calvaweb.calvacom.fr/bh40/vmlinux_test3.gz>
> <http://calvaweb.calvacom.fr/bh40/vmlinux_test4.gz>
>
>(the first one uses truecolor for chipsfb, the second directcolor). offb
>is "fixed" to disable the ATI kuldge when not in 8 bits (apparently
>breaks some models like PowerBook G3 Series) so "No video driver" should
>work all the time again.

On my 2400, test3 works okay for the console (8 & 16 bit) and Xpmac3400 (16
bit).  XF68FBDev is still screwed up in 16 bit, though -- the colors are
all wrong.  Also, XF68FBDev repeatably crashes on the first attempt to run
it after booting, but subsequent runs succeed.

I didn't try test4 because it failed to uncompress.

>Note that those kernel will do funny things with your ADB like
>auto-setting handler IDs of mice to 2 or 4 (depending on what the mouse
>supports) and detecting the powerbook trackball. All this is quite
>verbose (lots of printks) and I would like to know if it breaks
>something. The result of those changes should be that now, mice should
>use better capabilities by default and mousemode should not be necessary
>most of the time.
>Note also that the trackpad tapping is partially implemented (you will be
>able to click by tapping but sometimes it behaves strangely).
>
>I'll post cleaned up patches for all this later today or later this week.

I haven't tried to test any of these things.

I did notice that one thing was broken, compared to the 2.1.130 kernels
I've been compiling for myself from the vger cvs tree.  Paul's "snooze"
program does not successfully put the powerbook into sleep mode with your
test3 kernel.  The screen blanks, but the sleep light never starts
blinking, as if the machine hangs in the middle of the process of going to
sleep.  Keyboard reset seems to be the only way out.  I looked at the
source code for snooze and it's bonehead simple -- opens /dev/pmu, does a
sync(), then uses an ioctl on /dev/pmu to sleep the machine.  So this must
be a kernel bug.


I'm going to be away from email the next few days for Christmas.  However,
that also means I may have some spare time to try to work on patching up
chipsfb to work for all situations myself.  I also went and printed myself
a copy of the enormous C&T65550 datasheet, so now I have register specs for
everything and may get brave and try to implement some acceleration
functions for the console.

  Tim Seufert

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: Test kernels for chipsfb (2400/3400)

[Benjamin Herrenschmidt]

On Thu, Dec 24, 1998, Timothy A. Seufert <tas@mindspring.com> wrote:


>I did notice that one thing was broken, compared to the 2.1.130 kernels
>I've been compiling for myself from the vger cvs tree.  Paul's "snooze"
>program does not successfully put the powerbook into sleep mode with your
>test3 kernel.  The screen blanks, but the sleep light never starts
>blinking, as if the machine hangs in the middle of the process of going to
>sleep.  Keyboard reset seems to be the only way out.  I looked at the
>source code for snooze and it's bonehead simple -- opens /dev/pmu, does a
>sync(), then uses an ioctl on /dev/pmu to sleep the machine.  So this must
>be a kernel bug.

Yep, this kernel is not really meant for everyday use, I just wanted some
feedback about the chipsfb. The sleep is broken because I'm working on it
(trying to adapt it to newer PowerBooks, unsucessfully for the moment)
and when I compiled those test kernels, the sleep code was a rest of some
tests I made and is absolutely not functional.
>
>I'm going to be away from email the next few days for Christmas.  However,
>that also means I may have some spare time to try to work on patching up
>chipsfb to work for all situations myself.  I also went and printed myself
>a copy of the enormous C&T65550 datasheet, so now I have register specs for
>everything and may get brave and try to implement some acceleration
>functions for the console.

Ok. The main changes I made were to add a compile option for either using
DIRECTCOLORS or TRUECOLORS. Since you disable the colormap in 16 bits,
then it's TRUECOLOR. If you don't it's DIRECTCOLORS.

In TRUECOLOR, you must have the code is setcolorreg update the cfb16 data
with the default colors. In direct colors, it should contain (regno <<
10) | (regno | 5) | regno. I'm sending you in a separate mail my modified
version of chipsfb.

I've not yet identified the problem with XFBDev and 15 bits, but I do
have the same pr oblem with my fixed offb.c too, I'll have a look at it.



-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

[PATCH] Trackpad support for PowerBook

[Benjamin Herrenschmidt]

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

Enclosed is a patch to drivers/macintosh/mac_keyb.c which does the following:

 - All mouse handlers IDs are changed to 4 or 2 if possible to enable
full features of most mice. Keyboards are changed to 3 or 5 (I think
those are the good handler IDs for extended keyboards but this could be
double checked)
 
 - The PowerBook trackpad is detected and initialized to full features
(clicking, dragging and drag lock). I'll make a command line tool for
changing it's settings later via /dev/adb.

 - Button 2 of the trackpad is "hacked" to be button 1 so that tapping
(button 2) and pressing the real button (button 1) do the same thing,
like MacOS. This behaviour could be improved to something configurable by
the user (maybe using tapping for button 1 and real button for button 2
?) but I don't know what is the best way to add a runtime-configurable
setting to mac_keyb.c... Maybe some special ioctls to adbmouse.c, but we
would have to export the configuration globals (or accessor functions)
from mac_keyb.c.

 - Adds a placeholder function for the front-panel buttons of the
powerbook G3 series.

I think the patch can be included "as is" (after some testings of
course). The improvements can always be added later.


[-- Attachment #2: trackpad.patch.gz --]
[-- Type: application/octet-stream, Size: 1883 bytes --]

[PATCH] Trackpad support for PowerBook

[Benjamin Herrenschmidt]

Enclosed is a patch to drivers/macintosh/mac_keyb.c which does the following:

 - All mouse handlers IDs are changed to 4 or 2 if possible to enable
full features of most mice. Keyboards are changed to 3 or 5 (I think
those are the good handler IDs for extended keyboards but this could be
double checked)
 
 - The PowerBook trackpad is detected and initialized to full features
(clicking, dragging and drag lock). I'll make a command line tool for
changing it's settings later via /dev/adb.

 - Button 2 of the trackpad is "hacked" to be button 1 so that tapping
(button 2) and pressing the real button (button 1) do the same thing,
like MacOS. This behaviour could be improved to something configurable by
the user (maybe using tapping for button 1 and real button for button 2
?) but I don't know what is the best way to add a runtime-configurable
setting to mac_keyb.c... Maybe some special ioctls to adbmouse.c, but we
would have to export the configuration globals (or accessor functions)
from mac_keyb.c.

 - Adds a placeholder function for the front-panel buttons of the
powerbook G3 series.

I think the patch can be included "as is" (after some testings of
course). The improvements can always be added later.




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

[PATCH] Trackpad support for PowerBook

[Benjamin Herrenschmidt]

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

Enclosed is a patch to drivers/macintosh/mac_keyb.c which does the following:

 - All mouse handlers IDs are changed to 4 or 2 if possible to enable
full features of most mice. Keyboards are changed to 3 or 5 (I think
those are the good handler IDs for extended keyboards but this could be
double checked)
 
 - The PowerBook trackpad is detected and initialized to full features
(clicking, dragging and drag lock). I'll make a command line tool for
changing it's settings later via /dev/adb.

 - Button 2 of the trackpad is "hacked" to be button 1 so that tapping
(button 2) and pressing the real button (button 1) do the same thing,
like MacOS. This behaviour could be improved to something configurable by
the user (maybe using tapping for button 1 and real button for button 2
?) but I don't know what is the best way to add a runtime-configurable
setting to mac_keyb.c... Maybe some special ioctls to adbmouse.c, but we
would have to export the configuration globals (or accessor functions)
from mac_keyb.c.

 - Adds a placeholder function for the front-panel buttons of the
powerbook G3 series.

I think the patch can be included "as is" (after some testings of
course). The improvements can always be added later.



[-- Attachment #2: trackpad.patch.gz --]
[-- Type: application/octet-stream, Size: 1883 bytes --]