[ltp] Re: Comparison: rovclock and PowerPlay

[David Abrahams]

"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.

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