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

[Michal Suchanek]

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

Why would it not be rotated?

Depending on the direction of the two targets a transformation may apply.

> blitting non-target on target is rotated.

If non-target does not support rotation then there is no other
possibility, obviously.

> This way video adapter doesn't have to know about nature of blitting 
> operations.
> Anyway you need  to adjust width and height returned by mode_info.
> A function video_fb_transform_coordinates can do this. This way

Yes, it can. However, driver unaware of rotation won't use it which is
why I want it to be internal to video_fb at least for drivers that do
not implement any operations themselves.

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

Thanks

Michal