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

Re: Test kernels for chipsfb (2400/3400)

[Benjamin Herrenschmidt]

On Thu, Dec 31, 1998, David Ray <daver@idiom.com> wrote:

>CC: Paul Mackerras <paulus@cs.anu.edu.au>
>----------
>Hi, I wanted to give an update with my pb2400 results with the latest kernels
>from Ben. My access to the computer & email is intermittent during these
weeks
>but I had a chance to check out the builds available on 12.31.1998. I tried
>Ben's experimental build with extra changes to chipsfb.c and ADB
changes, with
>the following results:

Tim released a new driver fixing even more problems. It should be
included in the main tree real soon now and it will be included in any
test kernel I post in the meantime (there is some more adb stuff in the
pipeline including MacX mice support).

>- Despite corrupted colors in X, I was still able to get around in X, see the
>cursor and type into terminal windows, etc. THE NEW TRACKPAD TAPPING CODE IS
>EXCELLENT!!!! Thank you!  To put it simply, this has almost the same trackpad
>behavior as the Trackpad Control Panel in MacOS 8.x. Thanks for providing the
>diff.

It's actually the same behaviour, this is handled by the trackpad itself
;-) My work was simply to give the correct values to the trackpad for
configuration and I used values "spied" from MacOS. There's also command
line tool for changing the config in progress here.

>Before the holiday season I was compiling my own kernels with the latest
>patches for chipsfb.c but I haven't been able to keep up with t he
latest over
>these last few weeks. Hopefully this email is useful in debugging the
problems
>with chipsfb.c. I'll try to update myself next week.

Things are moving quickly with the big merge almost finished, you may
just want to wait for the final 2.2 or a new pre-something, you'll get
the most up-to-date patches for chipsfb.
My ADB patches may or may not be part of 2.2.0, I have separated the
first set with little change to adb.c/.h on one side and a more complete
reorganisation of the adb stuff on other side. This should make the merge
more easy for the first one. I'm still testing things however, I don't
know when it will be fully ready (quite soon hopefully).


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

[David Ray]

Hi, I wanted to give an update with my pb2400 results with the latest kernels from Ben. My access to the computer & email is intermittent during these weeks but I had a chance to check out the builds available on 12.31.1998. I tried Ben's experimental build with extra changes to chipsfb.c and ADB changes, with the following results:

- video mode 16 has corrupted color on the console, but useable. Same results with nvvideo set to "color-mode-2" and "color-mode-3". Vmode 10 8 works fine.

- The Xpmac binary specially made for the pb2400/3400 would not run either in 8-bit or 16-bit mode. In both 8-bit and 16-bit the screen appeared to go black. In 16-bit there was a faint off-black appearance of xdm login screen but unusable. I tried it with nvvideo set to both "color-mode-2" and "color-mode-3", with no noticeable difference. Fortunately this Xpmac binary has a built-in kill switch with option-power, so it is easy to exit back to the console. This result is unusual because all other varianlts of kernel 2.1.130 allowed this Xpmac binary to work while the XF86_FBdev binary would not.

- The latest XF86_FBdev binary for LinuxPPC from the xfree86.org site works (for the first time ever on a pb2400) in 16-bit mode. But it is broken: the color balance is very corrupted.  I also tried this with nvvideo set to both "color-mode-2" and "color-mode-3", with no noticeable difference. Since 16-bit is also corrupted on the console, perhaps they are symptoms of a single problem. 

- Despite corrupted colors in X, I was still able to get around in X, see the cursor and type into terminal windows, etc. THE NEW TRACKPAD TAPPING CODE IS EXCELLENT!!!! Thank you!  To put it simply, this has almost the same trackpad behavior as the Trackpad Control Panel in MacOS 8.x. Thanks for providing the diff.


Before the holiday season I was compiling my own kernels with the latest patches for chipsfb.c but I haven't been able to keep up with t he latest over these last few weeks. Hopefully this email is useful in debugging the problems with chipsfb.c. I'll try to update myself next week.

-Dave


At 4:23 AM 12/24/98, Timothy A. Seufert wrote:
> 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 ]]

Test kernels for chipsfb (2400/3400)

[Benjamin Herrenschmidt]

I've uploaded two test kernels at:

<http://calvaweb.calvacom.fr/bh40/vmlinux_test.gz>
<http://calvaweb.calvacom.fr/bh40/vmlinux_test2.gz>

With a couple of additional fixes to chipsfb.c that I would like you to
test, especially in 16 bits mode. (Both console and X, and both XPmac and
XFBDev).

I expect the first one to work but I didn't test since I don't have a
machine with a CT65550 here. I am interested in knowing if the second one
works, it may, it may not.

Basically, the first one declares itself as a truecolor visual (no gamma)
to match the fact that we switch the gamma off on the chip, and the
second one declares itself as a directcolor, enables gamma, and adds one
or two things that may cause the gamma to work, but I'm not sure.

I'll post the patches later (they need cleanup) but in the meantime, I
would like some quick tests by PowerBook 2400/3400 owners.


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