EGL_MESA_screen_surface proposal

[Jon Smirl]

On Thu, 17 Mar 2005 12:29:16 +1100, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> I wouldn't do something as complex I suppose for EGL, but I would at
> least put clearly in the spec that doing a mode setting may not result
> in that actual mode beeing reallly set. That is the user is expected to
> re-query for the mode after setting it. The driver may have had to do
> something else at the last minute due to whatever internal problem,
> error, out of resource, etc...

I would flip this around. The modes can always be set. What fails it
attaching a surface to the mode. It's the surface that carries the
depth information and causes the bandwidth to be exceeded.

It might be worth looking at a model where mode and surface setting is
combined. Or mode sets are not applied until a surface set follows. I
don't like the transactional hole of setting the mode while still
using the old surface.

In another mail I tossed out the idea of adding a 'surface=name'
attribute to mode setting. fbdev would implement a special surface
named 'default' which would alway morph to match the mode. When DRM is
running 'default' would be replaced by named surfaces implementing
specific formats.
With this model when a mode is set in fbdev it would carry an implied
'surface=default'.

On another topic, if I understand my LCD correctly it is always
updating at 60Hz no matter what I set the refresh to. What it does is
let me update the buffer at 72Hz but it is still displayed at 60Hz.
60Hz doesn't flicker because LCDs don't use phosphors. Given this,
it's always best to update my display at 60Hz. All that happens at
72Hz is that 17% of the bits sent to the monitor never get displayed.


-- 
Jon Smirl
jonsmirl at gmail.com