[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert Millan
Subject: Re: Fwd: [PATCH 1/2] Framebuffer split
Date: Sun, 2 Aug 2009 23:43:52 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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 threads

Well, we have the possibility that video drivers are doing stuff in background,
but that's something entirely different I had in mind.  Please bear with me, I
missunderstood what you wrote :-)

> > Why is this chunk of code moved down?  AFAICS, this change only involves
> > adding an additional layer between it and the video backend.  Does this
> > make it conflict with something else?
> >
> I wanted to keep normal grub_printf as long as possible and after
> get_mode_and_fini grub_printf may be unfunctional.


> >> +#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 about renaming but to inform includes that
> grub_video_render_target is in fact grub_video_fbrender_target and so
> avoid warnings and casts.

I don't understand this.  If we want to settle with grub_video_render_target
why don't we just provide that function directly?  Or is this making room
for an additional layer later on?

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 your freedom: we
  still allow you to remove your data and not access it at all."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]