All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Campbell <jonathan@castus.tv>
To: linux-fbdev@vger.kernel.org
Subject: Re: efifb: patch to allow userspace to unbind efi framebuffer driver from VGA device
Date: Mon, 19 Aug 2013 06:34:49 +0000	[thread overview]
Message-ID: <5211BC89.90003@castus.tv> (raw)
In-Reply-To: <52119D6D.5070209@castus.tv>

Perfect!

I removed the request_mem_region from my bochsfb driver and coded it to 
allocate an aperture struct, then register_framebuffer(). It kicks efifb 
off just as you said. Thanks!

Jonathan Campbell
> Hi Jonathan,
>
> On Sun, 18 Aug 2013 21:22:05 -0700 Jonathan Campbell wrote:
>> This patch allows userspace to direct efifb to let go of the VGA device
>> and unregister it's framebuffer. As far as I can tell, the Linux kernel
>> framebuffer console knows to let go when efifb unregisters it's
>> framebuffer. The problem I'm trying to solve is that I need efifb so the
>> kernel can show it's status on-screen during boot, but then I need efifb
>> to step aside and let a better driver load and take the VGA device later
>> during boot up.
>>
>> The custom Linux distribution I've made for myself uses a userspace
>> program to "boot" secondary VGA devices and load both fbdev and drm/kms
>> drivers to bring video online. When I wrote this, I needed the ability
>> for efifb to let go so that it could load bochsfb to better use the VGA
>> output of VirtualBox and bochs. Without it, my console is stuck at
>> whatever video mode the UEFI BIOS happened to leave it at and the more
>> specialized driver cannot acquire the resources it needs to do it's work.
>>
>> The patch adds a sysfs device file "bind_fb" to the
>> /sys/bus/platform/devices/efifb.0 filesystem tree. Writing "1" causes it
>> to re-register the framebuffer, "0" to unregister. Checks are in place
>> to not register the framebuffer if already registered, etc.
> That is the wrong approach.
>
> On fbdev subsystem there is infrastructure for replacing generic
> firmware drivers with specialized drivers (as is called by KMS
> drivers).
>
> Have a look at remove_conflicting_framebuffers() and its use by KMS
> drivers (i915, radeon, nouveau, mgag200, cirrus).
>
> Unloading efifb should be able to happen automatically when
> loading/probing new driver, without userspace help (so it can work when
> both are built-in).
>
> Bruno
>
>
>> I realize it's not perfect and I wanted to know what I could do to
>> improve it and eventually make it to mainline.
>>
>> On a related issue, when will efifb make use of the Graphics Output
>> Protocol through UEFI to offer modesetting? Is that possible? If no
>> specialized drivers are available it'd be nice to at least have basic
>> modesetting as needed.


      parent reply	other threads:[~2013-08-19  6:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19  4:22 efifb: patch to allow userspace to unbind efi framebuffer driver from VGA device Jonathan Campbell
2013-08-19  5:51 ` Bruno Prémont
2013-08-19  6:34 ` Jonathan Campbell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5211BC89.90003@castus.tv \
    --to=jonathan@castus.tv \
    --cc=linux-fbdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.