RE: [Linux-fbdev-devel] API prototype doc

[Sottek, M. J <mat...@in...>]

>> The dri works this way already but on a per client basis, we need
>> it on a per VT basis.

>All commands your fbdev API presents are not context sensitive.
>At least it looks that way to me. After console switch all
>on-screen and off-screen memory is lost. 

I wasn't really talking about my API, but rather _any_ future API.

Specifying context isn't necessary as it is with the dri because we
only save state on a VT basis. The di knows which VT you are on
and tells the driver to restore the correct settings. If we are
only talking about mode/display settings the di layers of both my
API and all current API's already send enough information to
accomplish this task.  If we are talking about advanced acceleration
then another VT private data structure needs to be sent as well.

On screen memory isn't required to be restored in most virtualizatons.
As long as the "rules" include that the application may be required to
refresh the entire screen at any time. Offscreen memory can either
obey the same "rules" or be allocated to specific VT's. It is
easiest to say that all memory on or off screen has to be refreshed
if it is "dirty". My API allows the client app to detect that the
surfaces are dirty and the client would then refresh them. We would
need to add in the signals so that the app doesn't have to poll
the status.

>Only thing we can do is that if app told us that it uses new semantic 
>(/dev/null mmap replacing, f.e.), after framebuffer returns back it 
>must confirm it with some action (mmaping of /dev/fb, or some fb API 
>action), and until it confirms it, decline to execute any of commands
>submitted, as it is 100% sure that app did not restore its context yet.

Good idea, once the app gets the signal it should send a command down
to tell the driver that it has populated all of the "content".

Note the difference between "Context" and "Content". The driver can
restore the context. That includes the mode/display settings. The
size/location of command buffers. The cursor settings. (and if you
want to include advanced acceleration in the mix, it could include
the size/location of textures, video surfaces, etc). The problem is
that while we can restore all of the "Context" the "Content" is
something the driver would not have.
 "Content" is the contents of the frambuffer, cursor, and offscreen
textures or scratch memory. The app has to put that all back.