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
pgptFEOTO18fW.pgp
Description: signature