| Message ID | 1274373865-5711-1-git-send-email-chase.douglas@canonical.com |
|---|---|
| State | Accepted |
| Delegated to: | Leann Ogasawara |
| Headers | show |
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
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?)
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
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
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
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;
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(-)