[ltp] Re: Comparison: rovclock and PowerPlay

Alex Deucher linux-thinkpad@linux-thinkpad.org
Wed, 30 Aug 2006 09:33:00 -0400


On 8/30/06, David Abrahams <dave@boost-consulting.com> wrote:
> "Alex Deucher" <alexdeucher@gmail.com> writes:
>
> >> Am I using the "fn-F7 toggle" or the "ibm_acpi video toggles?"
> >> I would have assumed the latter, but then you mention the former
> >> further on.  Oh, the latter is the /proc/acpi/ibm/video stuff?
> >
> > It doesn't matter.  it all ends up calling function in the video bios.
> > configuring ibm_acpi to call into the bios rather than returning an
> > event and then pressing fn-F7 probably calls the same video bios
> > function as echoing "crt" or whatever to /proc/acpi/ibm/video.
>
> I'm still totally mystified as to why you think I've either
>
>   a. configured ibm_acpi to call into the bios rather than returning
>      an event, or
>
>   b. echoed "crt" or whatever to /proc/acpi/ibm/video.
>
> >> OK, then why do you think I'm using the former?  The ibm_acpi
> >> documentation says that when you enable that mask bit, it turns off
> >> the bios-based screen expansion function and turns on the ACPI event.
> >
> > exactly.  the key combos can either return acpi events, or they can
> > call functions in the bios depending on the machine specific acpi
> > configuration (the mask).
>
> Setting the mask to 0xffff causes _all_ of the key combos to return
> acpi events.
>
> >> Unless the docs are lying, something in fglrx is listening for the
> >> ACPI event and adjusting the screen, so isn't confused about
> >> anything.  It certainly knows which screens are enabled as
> >> demonstrated by
> >>
> >>   aticonfig --query-monitor
> >
> > I'm not familiar with fglrx, but I doubt this has anything to do
> > with acpi or the video bios at all, at least not directly.  I
> > suspect it just queries the hardware directly to see what's
> > attached, just like the opensource radeon driver does at startup.
>
> Okay.
>
> >> > all of those eventually call into the video bios which in turn
> >> > programs the video registers to produce the desired affect.  The X
> >> > driver does the same thing, only in the X driver we write directly
> >> > to the registers.
> >>
> >> Sorry to ask so many stupid questions, but I'm (a little too)
> >> literal-minded and you're leaving out many details I need to
> >> understand what you're saying.  Who's "we?"  Are you an ATI employee?
> >
> > no.  I'm an Xorg developer, and I've done a fair amount of work on the
> > radeon driver.
>
> Okay, thanks for spelling it out.
>
> >> >> >  so they are messing with register state without the other's
> >> >> >  knowledge.
> >> >>
> >> >> What registers?  What are the implications of this?
> >> >
> >> > There is a single set of registers that configures the video hardware.
> >> > if you call into the video bios (via ibm_acpi, or the bios, etc.) you
> >> > are changing the register state.
> >>
> >> I gather you're saying that the incantation above that changes the
> >> hotkey mask results in just such a call into the video bios via
> >> ibm_acpi?  I don't understand why it would have anything to do with
> >> the video bios, though, since its purpose is merely to expose
> >> keystrokes to the ACPI system.
> >
> > if you configure ibm_acpi to fall back to bios calls rather than
> > delivering acpi events, those bios calls are what configures the video
> > outputs.
>
> If anything, I did the opposite.
>
> > if you configure ibm_acpi to deliver events, then you need to have a
> > script or something to catch that event and do something with it.
>
> I do have just such a script (see my other posts), but by the time the
> script has been started, screen switching has already taken place.  I
> therefore conclude that something else is hooking into the event, and
> fglrx or atieventsd seem like the only reasonable candidates.
>
> >> > if you do that while X is running, X has no knowledge of what the
> >> > bios has just done and vice versa.  As such you might get into a
> >> > weird hardware state that could result in a lockup or an
> >> > undesireable behavior.  Generally it works ok though since the
> >> > fn-F7 toggle probably only messes a couple of output related
> >> > bits.
> >>
> >> I guess I still don't see where I've run afoul of the law here.
> >
> > I'm just talking in generalities regarding the interaction between
> > acpi, the video bios, and drivers such as radeon or fglrx.  There's
> > often a misconception as to how it all works.  I hope I've clarified
> > rather than muddied the water.
>
> I'm afraid not.  Most of the facts you're giving me about bios and
> drivers and acpi meet the expectations I had before you started, but
> you've left me with a concern -- unsubstantiated, so far -- that my
> setup may be doing something it shouldn't.
>

Your set up is probably fine.  As I said I was just talking in
generalities as to how all this stuff could/should/does work.

Alex

> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>