On Saturday 06 November 2004 08:37, Benjamin Herrenschmidt wrote:

On Fri, 2004-11-05 at 13:15 +0100, Geert Uytterhoeven wrote:

quoted

On Fri, 5 Nov 2004, Benjamin Herrenschmidt wrote:

quoted

quoted

But every existing application that uses (shiver) the kernel headers
will break after this change...

Geert, can you explain the whole story please ?

The story about the +1 or the story about the breakage?

The Story About The +1
----------------------
Since the VESA levels do not provide a way to blank (`make it black') the
screen, the +1 is introduced. Hence 0 means unblank, 1 means black
screen, 2 means lowest power save level, and so on...

So why don't we have a nice set of #define's or an enum at least
describing those ? :)

quoted

The Story About The Breakage
----------------------------
Every application that passes VESA_*+1 will break when recompiled, since
(most of) the VESA_* values are incremented by 1 by the patch.

What patch ? Mine ? It doesn't increment the VESA values, it just clamps
the max. But then, everything seem to be totally inconsistent. So can we
instead define a  set of FB_BLANK_**** values to use and have fbcon
convert VESA->FB_BLANK and FBIOBLANK pass FB_BLANK_* as-is, thus the
drivers would switch/case on those and no more +1 games ?

Currently, yes, the patch will break many drivers:

VESA_POWERDOWN + 1 is interpreted by most drivers as
VESA_POWERDOWN. If clamped, it will be misinterpreted as
VESA_HSYNC_SUSPEND.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click