On Fri, Aug 14, 2009 at 3:23 PM, Vladimir 'phcoder'
Serbinenko wrote:
> Framebuffer patch comitted and I removed framebuf branch on my repo.
>>
>> OK, I did not get why fbfill.h of the three private headers.
>>
>> Perhaps fbutil.h which already declares blit_info would be a better place
>> then.
>
Framebuffer patch comitted and I removed framebuf branch on my repo.
>
> OK, I did not get why fbfill.h of the three private headers.
>
> Perhaps fbutil.h which already declares blit_info would be a better place
> then.
>
I haven't looked in depth how private headers were organised, I just
moved t
2009/8/14 Vladimir 'phcoder' Serbinenko :
> On Fri, Aug 14, 2009 at 2:13 AM, Michal Suchanek wrote:
>> 2009/8/13 Vladimir 'phcoder' Serbinenko :
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
encapsu
On Fri, Aug 14, 2009 at 2:13 AM, Michal Suchanek wrote:
> 2009/8/13 Vladimir 'phcoder' Serbinenko :
>>> 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
2009/8/14 Michal Suchanek :
> 2009/8/13 Vladimir 'phcoder' Serbinenko :
>>> 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
2009/8/13 Vladimir 'phcoder' Serbinenko :
>> 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 oppositio
On Thu, Aug 13, 2009 at 10:36:37PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > Please go ahead (I assume it raises no warnings and it's well tested).
> I tested the latest version with gfxterm and xnu loader. I use
> previous version in my daily bootloader. I'll run another series of
> tests be
> Please go ahead (I assume it raises no warnings and it's well tested).
I tested the latest version with gfxterm and xnu loader. I use
previous version in my daily bootloader. I'll run another series of
tests before comitting.
>
> One small detail:
>
>> + grub_free (mode_list);
>> + mode_list =
On Thu, Aug 13, 2009 at 05:59:11PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > 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
> 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.
On Wed, Aug 12, 2009 at 3:17 PM, Michal Suchanek wrote:
> 2009/8/10 Vladimir 'phcoder' Serbinenko :
>>> 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 wh
2009/8/12 Vladimir 'phcoder' Serbinenko :
> On Wed, Aug 12, 2009 at 3:08 PM, Michal Suchanek wrote:
>> 2009/8/10 Vladimir 'phcoder' Serbinenko :
>>> On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanek wrote:
Yes, but set_viewport works on the active target. You create an
offscreen target and
2009/8/10 Vladimir 'phcoder' Serbinenko :
>> 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_targe
On Wed, Aug 12, 2009 at 3:08 PM, Michal Suchanek wrote:
> 2009/8/10 Vladimir 'phcoder' Serbinenko :
>> On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanek wrote:
>>> Yes, but set_viewport works on the active target. You create an
>>> offscreen target and set it as the active target and want to set the
2009/8/10 Vladimir 'phcoder' Serbinenko :
> On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanek wrote:
>> Yes, but set_viewport works on the active target. You create an
>> offscreen target and set it as the active target and want to set the
>> viewport on it. Depending on its size this function eithe
> 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
2009/8/10 Vladimir 'phcoder' Serbinenko :
> On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanek wrote:
>> Yes, but set_viewport works on the active target. You create an
>> offscreen target and set it as the active target and want to set the
>> viewport on it. Depending on its size this function eithe
On Mon, Aug 10, 2009 at 4:38 PM, Michal Suchanek wrote:
> Yes, but set_viewport works on the active target. You create an
> offscreen target and set it as the active target and want to set the
> viewport on it. Depending on its size this function either needlessly
> limits you to the current screen
2009/8/10 Vladimir 'phcoder' Serbinenko :
>>
>>
>> 2009/8/10 Vladimir 'phcoder' Serbinenko :
As I understand it the code checks the bounds against the active
videomode and then sets the viewport on the active render target.
Since the active render target can be arbitrarily set b
>
>
> 2009/8/10 Vladimir 'phcoder' Serbinenko :
>>>
>>> As I understand it the code checks the bounds against the active
>>> videomode and then sets the viewport on the active render target.
>>> Since the active render target can be arbitrarily set by the user (to,
>>> say an offscreen bitmap for r
2009/8/10 Vladimir 'phcoder' Serbinenko :
> On Sun, Aug 9, 2009 at 1:55 PM, Michal Suchanek wrote:
>> Hello,
>>
>> both in the previous complete patch and Vladimir's git repository
>> introduce a grub_video_rect_t type.
> This is from Collin's double buffering patch.
OK, let's drop rectangles from
On Sun, Aug 9, 2009 at 1:55 PM, Michal Suchanek wrote:
> Hello,
>
> both in the previous complete patch and Vladimir's git repository
> introduce a grub_video_rect_t type.
This is from Collin's double buffering patch.
> The other thing that bothers me is that the video drivers fill in the
> render
>
> As I understand it the code checks the bounds against the active
> videomode and then sets the viewport on the active render target.
> Since the active render target can be arbitrarily set by the user (to,
> say an offscreen bitmap for rendering the terminal text) I do not see
> how these two p
Hello,
both in the previous complete patch and Vladimir's git repository
introduce a grub_video_rect_t type.
Is there some intention to change the interface to use this structure?
I was looking at the the various places that use points and
rectangles. It's quite inconsistent and unclear now.
Th
2009/8/8 Michal Suchanek :
> Hello
>
> I cannot get any sense of these patches "with moving code around
> omitted" so I tried the git repository in Vladimir's signature.
>
> Maybe I am missing something but the function of this code escapes me:
>
> static grub_err_t
> grub_video_vbe_set_viewport (u
Hello
I cannot get any sense of these patches "with moving code around
omitted" so I tried the git repository in Vladimir's signature.
Maybe I am missing something but the function of this code escapes me:
static grub_err_t
grub_video_vbe_set_viewport (unsigned int x, unsigned int y,
>> >> +#define grub_video_render_target grub_video_fbrender_target
>> >
>> > If we want to rename this function, I'd rather do it all the way than
>> > keeping a compatibility macro. But then, I'd also prefer if this is
>> > done separately from the rest (either before or after).
>> >
>> It's not
On Sat, Aug 01, 2009 at 05:10:30PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > Btw, if I understand correctly, we have a race condition right now. As a
> > bugfix it'd be better to merge this separately from the interface redesign
> > if
> > possible.
> race condition? We don't even have thre
On Sat, Aug 01, 2009 at 05:17:32PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Sat, Aug 1, 2009 at 5:14 PM, Michal Suchanek wrote:
> > 2009/8/1 Robert Millan :
> > I guess the current initialization is somewhat fishy. I haven't looked
> > at the code so far but the way it works is odd. When I
On Sat, Aug 1, 2009 at 5:10 PM, Vladimir 'phcoder'
Serbinenko wrote:
> Ok, I will try to split while keeping patch functional.
Done
>> --
>> Robert Millan
>>
>> The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>> how) you may access your data; but nobody's threatening yo
2009/8/1 Vladimir 'phcoder' Serbinenko :
> On Sat, Aug 1, 2009 at 5:14 PM, Michal Suchanek wrote:
>> 2009/8/1 Robert Millan :
>> I guess the current initialization is somewhat fishy. I haven't looked
>> at the code so far but the way it works is odd. When I change output
>> to gfxterm it apparently
On Sat, Aug 1, 2009 at 5:14 PM, Michal Suchanek wrote:
> 2009/8/1 Robert Millan :
> I guess the current initialization is somewhat fishy. I haven't looked
> at the code so far but the way it works is odd. When I change output
> to gfxterm it apparently tries to initialize the vbe graphics but it
>
2009/8/1 Robert Millan :
> On Mon, Jul 27, 2009 at 12:06:17AM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> grub_err_t (*get_info) (struct grub_video_mode_info *mode_info);
>>
>> + grub_err_t (*get_info_and_fini) (struct grub_video_mode_info *mode_info,
>> + void
>
> I see that returning framebuffer address and finishing the video subsystem
> must be together, but is there a reason to couple this with getting mode_info
> ?
When designing this part I thought of accelerated graphics. Before
loading the OS they would switch to standard framebuffer mode this m
On Sat, Aug 01, 2009 at 04:50:59PM +0200, Michal Suchanek wrote:
> 2009/8/1 Robert Millan :
> > On Fri, Jul 31, 2009 at 10:31:07PM +0200, Vladimir 'phcoder' Serbinenko
> > wrote:
> >> > Well, that fits the definition of backend.
> >> >
> >> But there are other backends too - network backend, openg
On Mon, Jul 27, 2009 at 12:06:17AM +0200, Vladimir 'phcoder' Serbinenko wrote:
>grub_err_t (*get_info) (struct grub_video_mode_info *mode_info);
>
> + grub_err_t (*get_info_and_fini) (struct grub_video_mode_info *mode_info,
> +void **framebuffer);
> +
> [...]
2009/8/1 Robert Millan :
> On Fri, Jul 31, 2009 at 10:31:07PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> > Well, that fits the definition of backend.
>> >
>> But there are other backends too - network backend, opengl backend, ...
>> Framebuffer is a term often used to designated memory ranged w
On Fri, Jul 31, 2009 at 10:31:07PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > Well, that fits the definition of backend.
> >
> But there are other backends too - network backend, opengl backend, ...
> Framebuffer is a term often used to designated memory ranged which is
> mapped to the screen.
> Well, that fits the definition of backend.
>
But there are other backends too - network backend, opengl backend, ...
Framebuffer is a term often used to designated memory ranged which is
mapped to the screen.
May we stop discussing about names and rather either commit or discuss
technical details
On Tue, Jul 28, 2009 at 11:21:56PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Tue, Jul 28, 2009 at 7:50 PM, Robert Millan wrote:
> > On Mon, Jul 27, 2009 at 12:06:17AM +0200, Vladimir 'phcoder' Serbinenko
> > wrote:
> >> Removed parts which are purely moving code around (of course it will
>
On Tue, Jul 28, 2009 at 7:50 PM, Robert Millan wrote:
> On Mon, Jul 27, 2009 at 12:06:17AM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Removed parts which are purely moving code around (of course it will
>> be restored on commit).
>
> This is not a full review of the patch, just a quick overview
On Mon, Jul 27, 2009 at 12:06:17AM +0200, Vladimir 'phcoder' Serbinenko wrote:
> Removed parts which are purely moving code around (of course it will
> be restored on commit).
This is not a full review of the patch, just a quick overview. But I have
a few comments:
- The "fb" naming is confusi
On Fri, Jul 24, 2009 at 1:41 AM, Pavel Roskin wrote:
> On Thu, 2009-07-23 at 11:52 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Hello. Here is a framebuffer split which has already been discussed.
>> This patch contains some code by Collin D Bennett in addition to my
>> code. Sorry for compressio
On Thu, 2009-07-23 at 11:52 +0200, Vladimir 'phcoder' Serbinenko wrote:
> Hello. Here is a framebuffer split which has already been discussed.
> This patch contains some code by Collin D Bennett in addition to my
> code. Sorry for compression but maillist server doesn't accept it otherwise
Please
44 matches
Mail list logo
