Re: Fwd: [PATCH 1/2] Framebuffer split

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 12, 2009 at 3:17 PM, Michal Suchanek<address@hidden> wrote:
> 2009/8/10 Vladimir 'phcoder' Serbinenko <address@hidden>:
>>> I would like a video_fb function like
>>> grub_video_fb_create_render_target_from_buffer(void * buffer, int
>>> allocated, const grub_video_mode_info_t * mode_info)
>> Well this is pretty much what we do directly. New fields can be added
>> to fbrender_target with no problem. (btw currently driver manages only
>> screen render target and completely delegates other functions to
>> video_fb)
>>> I am sure that for doing transparent rotation in video_fb
>>> encapsulation is good. I can do without it or patch it in with the
>>> rotation if I get it into working state.
>> Actually it's enough to follow simple rules like
>> blitting target on target isn't rotated but coordinates are adjusted
>
>> framebuffer can apply any transformation, not just rotation w/o driver
>> to know.
>
> Obviously, the video_fb can do anything (within reason - it needs to
> follow the current interface) behind the driver's back as long as
> there is working encapsulation in place.
Considering that vbe.c and sdl.c currently aren't affected a lot
whether there is or there isn't encapsulation in place, I'm ok tih
encapsulating it but if any driver needs the breach of encapsulation
it will be broken and I'll post no opposition to it.
I'll do the encapsulation tomorrow.
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git