Re: vmode & atyfb (fwd)

 >in the current kernels (2.2.18pre) and with the first ibook (ATI RAGE

quoted

Mobility,  not a Rage 128), there are several problems I am aware of :

- the color table is bad so there is some gitch on the console
colors. You may see in booting in level 3 (no X login) and trying a
make menuconfig. The only fix I have found was to reinitilise the
console with vmode (or fbset when you correct the second problem I am
reporting)

That's new. Did you ever had this problem before ? Can you track it down
to a specific kernel version ?

All the kernels I have tested have had this problem (i mean all -benh
kernels and the current 2.2.18pre). The problem is not obvious but is
shown in menuconfig and probably other curse based utilities.

quoted

- the geometry reported by the framebuffer is bad because the virtual
number of lines is very big (~2600). I have tracked the problem in
following code in aty_init() function :

     if (var.yres == var.yres_virtual) {
         u32 vram = (info->total_vram - (PAGE_SIZE << 2));
         var.yres_virtual = ((vram * 8) / var.bits_per_pixel) /
var.xres_virtual;
         if (var.yres_virtual < var.yres)
                 var.yres_virtual = var.yres;
     }

I'll see this with Geert, it may indeed be an atyfb bug

quoted

- there are some problems with the atyfb : it seems to be not working
with XFree-FB (hangs up). Also it hange when you try some simple
thing as copy from or to /dev/fb0 (hangup the system). I think there
are some problems with the starting and ending addresses of the
framebuffer.

I don't know for XFree-FB (it's possible that the old XFree-FB ATI
driver has troubles with the mobility chip). It should work with XF4.
Accessing /dev/fb0 can be dangerous since the chip's MMIO registers

are located at the end of the framebuffer.

the probleme here is that a simple user space command like cp
/dev/fb0 /dev/null may kill the system. Isn't it a poor design ?

quoted

In all of theses cases, the vmode utility is working when fbset is
not. Also I think vmode works when not using a dedicated framebuffer
driver (for example with video=ofonly), so it is a good utility to
tests new drivers or for fresh install.

vmode cannot work without a driver. All vmode does is to send an ioctl
that ends up to a call to the framebuffer set_disp routine, exactly
like fbset. The difference is that vmode us hard-coded mode values from
a table (in macmodes.c) and fbset uses values from /dev/fb.modes. fbset
also does more sanity check (your bug above).

Ben.

ok, so it may be a good idea to comment all theses things (I mean the
framebuffer stuff and all the commands associated with it). Currently
there is no real information about :

- fb drivers parameters (it is always possible to look at the source
code, but a clever approach would be to comment them)
- fb driver loading (for example in some kernels the driver may be
build as a module : how to load it at startup ?).
- add a comment in the readme for pmac-utils just to say vmode is
replace with fbset.
- in testing and developing, it seems we all have problems with fb,
of, XFree and XPmac interractions, so a little dev document may be
helpfull.

Regards,
--
-------------------------------------------------------
Alain RICHARD <mailto:alain.richard@equation.fr>
EQUATION SA <http://www.equation.fr/>
Tel : +33 477 79 48 00	 Fax : +33 477 79 48 01
Applications client/serveur, ingénierie réseau et Linux

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