Test kernels for chipsfb (2400/3400)

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 [email protected] ]]

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:[email protected]>
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 [email protected] ]]

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.

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 [email protected] ]]

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.

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:[email protected]>
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 [email protected] ]]

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.