On Monday 13 September 2004 03:21 pm, Alex Deucher wrote: > How would any of these plans handle power management and ACPI events? > I'd like to be able to suspect my laptop with the DRI enabled, or have > the DDX (or whatever) handle acpi lid and button events or put the > chip into various power modes. > Don't know how this is handled in Linux, but the plan for FreeBSD is to have a generic video driver attach to the card ie. vga0. Then an acpi_video driver as well as a DRM module driver could attach onto vga0.
vga0
|
+-- drm0 (DRM hardware driver)
|
+-- acpi_video0 (would handle things like VESA adapter shutoff, brightness
control, and any other ACPI related display stuff)
You would then be able to use the normal ACPI framework provided to handle
events(devd) and/or ioctl() or twiddle a sysctl value to put the device into
different states. This setup is primarily intended for laptop users since
they are the ones that have the ACPI video extensions.
> Alex
>
> On Mon, 13 Sep 2004 08:20:58 -0700 (PDT), Linus Torvalds
>
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 13 Sep 2004, Vladimir Dergachev wrote:
> > > The overlay window is currently using part of what is being proposed by
> > > "multiple drivers" proponents. It has to make engine queiscent so it
> > > can write data directly to the video memory. It does *not* have to save
> > > the state.
> >
> > It doesn't even really need to make the engine quiesce.
> >
> > If two subsystems are aware of the locking rules (and the helper driver
> > obviously doesn't much care), they can just design their own handoff
> > trivially. For example, it might make sense to make the "wait for the
> > engine to stop" be the responsibility of the side that actually _needs_
> > it, namely the PIO user.
> >
> > So if both users use the engine, not PIO, there's no need to ever stop
> > the engine. In my example of how to use the locking, it looked something
> > like this:
> >
> > if (get_lock(data->gfx.accelerator)) {
> > /* Somebody else used the engine, need to re-load cached
> > index */ mydev->offset = readl(mydev->mmio + OFFSET_PORT); }
> > OUT_RING(mydev, cmd);
> > OUT_RING(mydev, arg);
> > put_lock(data->gfx.accelerator);
> >
> > See? You can have two clients doing accelerator things, and they _never_
> > wait for anything (well, obviously "OUT_RING()" needs to wait for the
> > buffer to be empty enough ;).
> >
> > They still need to know whether there was a previous user, because
> > efficient command filling does require that you don't read the "where is
> > the command buffer end" thing all the time, so that's why you have to
> > cache that one in real RAM instead of reading it from the card every op.
> > And because you cache it, you have to update your cache if somebody else
> > uses the engine.
> >
> > Now, a PIO writer would look different
> >
> > if (get_lock(data->gfx.accelerator)) {
> > /* Somebody else used the engine, need to quiesce */
> > wait_for_engine_idle(mydev);
> > }
> > outl(cmd, mydev->pio + OFFSET_CMD);
> > ...
> > put_lock(data->gfx.accelerator);
> >
> > and here if we switch back and forth between a client that uses
> > synchronous commands (ie normally PIO) rather than the engine, then yes,
> > we'd obviously halt the engine all the time. But hey, you can't avoid
> > that: if you want good performance with most modern chips, you do all
> > your work with the engine, not with synchronous commands.
> >
> > > So, as Jon rightly points out the "multiple drivers" scheme only makes
> > > sense in the current usage patter - you either use X or framebuffer,
> > > never both at the same time and you consider a few seconds per switch
> > > normal.
> >
> > I disagree. You can use a combination of X, framebuffer and "special
> > clients", where the special client can be _exactly_ things like video
> > overlays etc.
> >
> > Now, obviously we'd wish that X has support for video overlays directly,
> > and thus you wouldn't even need to switch between clients at that level,
> > but there are certainly cases where you may end up with an "external
> > client". It might be some very card-specific thing that X or DRM just
> > doesn't support yet, so you whip up a quick client for just that.
> >
> > For example (and this may be a horribly _bad_ example, for all I know),
> > let's say that somebody decides that they want to do a DirectX library,
> > and all the DRM people just throw their hands up in horror and say "over
> > my dead body".
> >
> > In that case you have two choices: kill the DRM people and dance on their
> > graves, or just say "ok, I'll make this other client that does the
> > DirectX interfaces". And the thing is, it shouldn't fundamentally not
> > work. As far as I can tell, with some rudimentary locking support like
> > the above (the trivial part) and some memory management support (the
> > _hard_ part), you should be able to have the two clients work together
> > quite well.
> >
> > And yes, I realize that this is what DRM already does internally. I
> > agree. I applaud it. I'm saying that if we moved that internal locking to
> > be _external_, so that other clients can use it too, then fbcon and DRM
> > and some random new subsystem could all live together in peace and
> > harmony.
> >
> > Now, let's all sit around the fire and sing Kumbaya.
> >
> > Linus
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
> --
> _______________________________________________
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Anish Mistry
pgp0eVgPPoK6y.pgp
Description: signature
