2009/8/10 Vladimir 'phcoder' Serbinenko <phco...@gmail.com>: >> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
