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 <benh@kernel.crashing.org> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/