Hotplug blacklist and video devices

Why are all of the framebuffer drivers on the hotplug blacklist?

-- 
Jon Smirl
jonsmirl@gmail.com

Jon Smirl (jonsmirl@gmail.com) 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 [off-list ref] 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
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

On Fri, 2005-02-18 at 16:14 -0500, Jon Smirl wrote:

On Fri, 18 Feb 2005 16:08:22 -0500, Bill Nottingham [off-list ref] wrote:

quoted

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



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

On Fri, 18 Feb 2005 17:58:51 -0500, Michel Dänzer [off-list ref] wrote:

quoted

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
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

Jon Smirl [off-list ref] 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 | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

On Sat, 19 Feb 2005 12:29:13 +0000, Matthew Garrett
[off-list ref] wrote:

Jon Smirl [off-list ref] wrote:

quoted

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
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

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 | mjg59@srcf.ucam.org

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 (jonsmirl@gmail.com) 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