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

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 ? :)

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 ?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

-- 
Benjamin Herrenschmidt [off-list ref]



-------------------------------------------------------
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