On Monday 13 September 2004 04:41 pm, Alex Deucher wrote:
> On Mon, 13 Sep 2004 16:35:51 -0400, Anish Mistry <[EMAIL PROTECTED]> wrote:
> > 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.
>
> how would that integrate/communicate with X?  I guess that's something
> to think about...
>
Not sure, I'm pretty much just regurgitating what was mentioned on one of the 
freebsd mailing lists a couple months ago.

> Alex
>
> > > 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

-- 
Anish Mistry

Attachment: pgptFEOTO18fW.pgp
Description: signature

Reply via email to