Re: [HINTS] Re: More radeonfb fixes

thanks a lot, this patch solved my quite annoying framebuffer problems with the
stock 2.4.21rc1 radeonfb driver on ATI Radeon 7000 w/ 64MB RAM :-).

Good ;)

If you are interested in some bugreports and don't want to read the following
semi-minihowto, please just look for the [PERHAPS-BUGREPORT] string.

In order to give advice to the fellow googlers possibly seeing this in
archives: if you have annoying long delays when switching between consoles or
the video mode you specify on the cmdline carefully results in just an ugly
mess,

Known. I have to work on this next

[PERHAPS-BUGREPORT]

  - BE CAREFUL when specifying depth! This is basically where I was most burnt,
    I kept specifying 24 but for some strange reason, this did very strange
    things here. If you will specify some other depth (8,15,16,32,...), you may
    experience problems with cursor (or it just won't work at all ;) --- it
    could have different colors (which will change by time), eventually
    disappearing completely (this could mean it just went black..?).

    The best solution is probably not to specify the depth at all. Apparently,
    24 is used by default, but it seems to work when chosen defaultly :^).

8 is the default and works fine. 15,16 and 32 work but the cursor isn't
properly rendered, this is a known fbdev problem in 2.4, I'll probably
fix it by implementing HW cursor support in radeonfb. 24 bpp is a weird
mode that isn't really supported by the driver

* when you will have your Radeon in some weird state (after trying to run some
  svgalibish application or naively selecting vesa video output in mplayer or
  so..), you can either:

[PERHAPS-BUGREPORT]

  - startx or switch to X and back if you have it already running. This will
    repair it, but it won't reset all the flags (ie. accel), so you will get
    delays when switching to the affected console caused by video mode changes.

  - fbset on the affected console, which will also properly reset all these
    flags. You can obviously first get usable console by letting X to reset it
    and then running fbset on it, if you like to see what are you typing. Note
    that you should reset the console to the same mode you are running on the
    other consoles, otherwise you won't get rid of that delays.

What is a bug ? the delays ? The fact that some apps leave garbage ? The
former is normal when an actual mode switch occurs. The later is a
problem with apps that bang the HW (and with X as well in some cases as
it will occasionally fuck up the accel engine configuration).

The problem is that currently, the fbcon/fbdev interface doesn't provide
a hook for fbdev's to force a restore of the mode & engine setting when
an app leaves the KD_GRAPHICS mode.
 

[PERHAPS-BUGREPORT]

* you will have that ugly video mode change also the first time you switch to
  some console. This appears to be a bug, I think it could be fixed quite
  easily. You can either live with it or fix it or workaround it by doing
  something smart with for, seq and chvt in your rc scripts (let this be a
  homework ;-).

The "new" consoles aren't initialized, thus the driver do a mode change
when switching to them. Well... I can try to fix that...

It is just a mix of generic fb usage advices and Radeon-specific ones... well,
what I had to discover by myself in the last few hours ;-). Perhaps it could
find a comfortable place in Documentation/fb/, dunno.

Kind regards,

-- 
Benjamin Herrenschmidt [off-list ref]