Patchwork Revert "UBUNTU: SAUCE: Don't register vga16fb framebuffer if other framebuffers are present"

login
register
mail settings
Submitter Chase Douglas
Date May 20, 2010, 4:44 p.m.
Message ID <1274373865-5711-1-git-send-email-chase.douglas@canonical.com>
Download mbox | patch
Permalink /patch/53093/
State Accepted
Delegated to: Leann Ogasawara
Headers show

Comments

Chase Douglas - May 20, 2010, 4:44 p.m.
This reverts commit a3ce60db76c222c030b5837112e779b8630d0746.

This was a one-time fix for Lucid because we will not be using vga16fb
in Maverick. Thus, we should drop it.

Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
---
 drivers/video/vga16fb.c |   10 ----------
 1 files changed, 0 insertions(+), 10 deletions(-)
Leann Ogasawara - May 21, 2010, 12:49 a.m.
Applied to Maverick master.  As a side note, we were planning on
dropping this per our UDS Ubuntu delta review, so thanks for saving me
the extra work :)

Leann
Eric Miao - May 21, 2010, 1:14 a.m.
On Fri, May 21, 2010 at 12:44 AM, Chase Douglas
<chase.douglas@canonical.com> wrote:
> This reverts commit a3ce60db76c222c030b5837112e779b8630d0746.
>
> This was a one-time fix for Lucid because we will not be using vga16fb
> in Maverick. Thus, we should drop it.
>

Just wondering, since some one from OEM team noted that vga16fb being always
loaded, and I asked smb/apw for a little bit about this. By not
removing MODULE_ALIAS
and keep vga16fb as a module will still get this loaded (and fb
registered) by default.

And I'm curious how this is solved in Maverick by not using vga16fb (I know the
screen can be setup by grub but we still need a fb there?)
Chase Douglas - May 21, 2010, 12:07 p.m.
On Fri, 2010-05-21 at 09:14 +0800, Eric Miao wrote:
> On Fri, May 21, 2010 at 12:44 AM, Chase Douglas
> <chase.douglas@canonical.com> wrote:
> > This reverts commit a3ce60db76c222c030b5837112e779b8630d0746.
> >
> > This was a one-time fix for Lucid because we will not be using vga16fb
> > in Maverick. Thus, we should drop it.
> >
> 
> Just wondering, since some one from OEM team noted that vga16fb being always
> loaded, and I asked smb/apw for a little bit about this. By not
> removing MODULE_ALIAS
> and keep vga16fb as a module will still get this loaded (and fb
> registered) by default.

That's a good point. I was assuming we would get rid of vga16fb in
Maverick, but I guess we never discussed that at UDS. If we don't remove
vga16fb then we may actually want this patch still. The Nouveau folks
won't help anyone who has both nouveau and vga16fb loaded at the same
time, for example.

Scott, should we remove vga16fb altogether?

> And I'm curious how this is solved in Maverick by not using vga16fb (I know the
> screen can be setup by grub but we still need a fb there?)

We'll be using vesafb in Maverick instead of vga16fb.

-- Chase
Scott James Remnant - May 24, 2010, 9:22 a.m.
On Fri, 2010-05-21 at 08:07 -0400, Chase Douglas wrote:

> On Fri, 2010-05-21 at 09:14 +0800, Eric Miao wrote:
> > On Fri, May 21, 2010 at 12:44 AM, Chase Douglas
> > <chase.douglas@canonical.com> wrote:
> > > This reverts commit a3ce60db76c222c030b5837112e779b8630d0746.
> > >
> > > This was a one-time fix for Lucid because we will not be using vga16fb
> > > in Maverick. Thus, we should drop it.
> > >
> > 
> > Just wondering, since some one from OEM team noted that vga16fb being always
> > loaded, and I asked smb/apw for a little bit about this. By not
> > removing MODULE_ALIAS
> > and keep vga16fb as a module will still get this loaded (and fb
> > registered) by default.
> 
> That's a good point. I was assuming we would get rid of vga16fb in
> Maverick, but I guess we never discussed that at UDS. If we don't remove
> vga16fb then we may actually want this patch still. The Nouveau folks
> won't help anyone who has both nouveau and vga16fb loaded at the same
> time, for example.
> 
> Scott, should we remove vga16fb altogether?
> 
We discussed it in the GRUB/Framebuffer conversation - the plan is to
have GRUB set a video mode and use vesafb or efifb, rather than vga16fb

So you can drop the patch that adds aliases to vga16fb and the load
order patch.

Scott
Chase Douglas - May 24, 2010, 1:19 p.m.
On Mon, 2010-05-24 at 10:22 +0100, Scott James Remnant wrote:
> On Fri, 2010-05-21 at 08:07 -0400, Chase Douglas wrote:
> > 
> > Scott, should we remove vga16fb altogether?
> > 
> We discussed it in the GRUB/Framebuffer conversation - the plan is to
> have GRUB set a video mode and use vesafb or efifb, rather than vga16fb
> 
> So you can drop the patch that adds aliases to vga16fb and the load
> order patch.

Thanks for the confirmation. Can we remove the aliases now, or do we
need to wait until the grub framebuffer stuff is in place?

-- Chase

Patch

diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 3affd2a..7774da4 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1354,16 +1354,6 @@  static int __devinit vga16fb_probe(struct platform_device *dev)
 
 	vga16fb_update_fix(info);
 
-	/*
-	 * Ubuntu: Don't register vga16fb if another fb exists. Bad interactions
-	 * can occur.
-	 */
-	if (num_registered_fb > 0) {
-		printk(KERN_NOTICE "vga16fb: not registering due to another "
-		       "framebuffer present\n");
-		goto err_check_var;
-	}
-
 	if (register_framebuffer(info) < 0) {
 		printk(KERN_ERR "vga16fb: unable to register framebuffer\n");
 		ret = -EINVAL;