Why are all of the framebuffer drivers on the hotplug blacklist?
--
Jon Smirl
[email protected]
Jon Smirl ([email protected]) said:
> Why are all of the framebuffer drivers on the hotplug blacklist?
Well, that probably depends on your distribution. :)
Under Fedora (and RHEL), they're there because we generally
don't want to load them unless the user asked for them.
Bill
On Fri, 18 Feb 2005 16:08:22 -0500, Bill Nottingham <[email protected]> wrote:
> Under Fedora (and RHEL), they're there because we generally
> don't want to load them unless the user asked for them.
Is there a specific reason why they are blocked?
For example I'm looking at making changes to DRM such that DRM will
require the corresponding framebuffer driver to be loaded. If you back
up further this is part of fixing X so that it won't mess with the
hardware from user space. Mode setting would come from the framebuffer
driver instead of the X 2D XAA driver.
--
Jon Smirl
[email protected]
On Fri, 2005-02-18 at 16:14 -0500, Jon Smirl wrote:
> On Fri, 18 Feb 2005 16:08:22 -0500, Bill Nottingham <[email protected]> wrote:
> > Under Fedora (and RHEL), they're there because we generally
> > don't want to load them unless the user asked for them.
>
> Is there a specific reason why they are blocked?
One reaseon might be that the framebuffer devices can cause problems,
e.g. with proprietary X drivers.
> For example I'm looking at making changes to DRM such that DRM will
> require the corresponding framebuffer driver to be loaded.
Ignoring my suspicion that people won't like stuff getting forced down
their throats like this (why would a DRM _require_ a framebuffer
device?), does the hotplug blacklisting of the framebuffer devices
matter at all if the DRM depends on them, i.e. won't they be loaded
regardless when the DRM is loaded?
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer
On Fri, 18 Feb 2005 17:58:51 -0500, Michel D?nzer <[email protected]> wrote:
> > For example I'm looking at making changes to DRM such that DRM will
> > require the corresponding framebuffer driver to be loaded.
>
> Ignoring my suspicion that people won't like stuff getting forced down
> their throats like this (why would a DRM _require_ a framebuffer
> device?), does the hotplug blacklisting of the framebuffer devices
> matter at all if the DRM depends on them, i.e. won't they be loaded
> regardless when the DRM is loaded?
There is no mechanism for getting a hotplug remove event into a driver
like DRM that doesn't attach to the PCI device.
--
Jon Smirl
[email protected]
Jon Smirl <[email protected]> wrote:
> For example I'm looking at making changes to DRM such that DRM will
> require the corresponding framebuffer driver to be loaded. If you back
> up further this is part of fixing X so that it won't mess with the
> hardware from user space. Mode setting would come from the framebuffer
> driver instead of the X 2D XAA driver.
Please don't until all the framebuffer drivers are able to deal with
suspend and resume (which will also require some mechanism to switch
backlights back on). Currently, it's far easier to restore some amount
of state on a standard VGA or VESA mode. There's no real support for
doing so with most accelerated framebuffers.
--
Matthew Garrett | [email protected]
On Sat, 19 Feb 2005 12:29:13 +0000, Matthew Garrett
<[email protected]> wrote:
> Jon Smirl <[email protected]> wrote:
>
> > For example I'm looking at making changes to DRM such that DRM will
> > require the corresponding framebuffer driver to be loaded. If you back
> > up further this is part of fixing X so that it won't mess with the
> > hardware from user space. Mode setting would come from the framebuffer
> > driver instead of the X 2D XAA driver.
>
> Please don't until all the framebuffer drivers are able to deal with
> suspend and resume (which will also require some mechanism to switch
> backlights back on). Currently, it's far easier to restore some amount
> of state on a standard VGA or VESA mode. There's no real support for
> doing so with most accelerated framebuffers.
I didn't say make framebuffer depend on DRM, you can still unload DRM
before suspend. It's the other way around DRM needs framebuffer.
Suspend/resume are part of this. In the current model there is no way
for the DRM driver to see the suspend/resume events. I haven't tried
it but I suspect a suspend/resume with DRM running has a bad outcome
right now.
--
Jon Smirl
[email protected]
On Sat, 2005-02-19 at 10:56 -0500, Jon Smirl wrote:
> I didn't say make framebuffer depend on DRM, you can still unload DRM
> before suspend. It's the other way around DRM needs framebuffer.
> Suspend/resume are part of this. In the current model there is no way
> for the DRM driver to see the suspend/resume events. I haven't tried
> it but I suspect a suspend/resume with DRM running has a bad outcome
> right now.
Right. But for most machines, it's not possible to successfully resume
if an accelerated framebuffer driver is loaded. Until that's fixed,
tying DRM functionality to the framebuffer will make it impractical to
use DRM on laptops. That's a regression from the current situation.
--
Matthew Garrett | [email protected]
Jon Smirl wrote:
>I didn't say make framebuffer depend on DRM, you can still unload DRM
>before suspend. It's the other way around DRM needs framebuffer.
>
Only if you want to see the output, surely? I have an application which
doesn't need a framebuffer (or more strictly, scan-out), but does use DRM.
J
Jon Smirl ([email protected]) said:
> Is there a specific reason why they are blocked?
>
> For example I'm looking at making changes to DRM such that DRM will
> require the corresponding framebuffer driver to be loaded. If you back
> up further this is part of fixing X so that it won't mess with the
> hardware from user space. Mode setting would come from the framebuffer
> driver instead of the X 2D XAA driver.
If it's a hard module dep, I don't see how that would be a problem;
that would ignore the blacklist.
Bill