Comment 18 for bug 41355

Hello Rolf,

some of my patches to xorg-savage were recently added by Tormod Volden.
The path direction for s3switch is directly linked to that X server, as
they are interoperating closely (and need to do this, which will be one
of the targets of my work).

On my systems (HP XE3), I am testing all my patches in all-day use and
have not stumbled over any problems yet, but it seems that we need
someone with that special kind of Thinkpad mentioned in the bug report
to verify.

There are several ways how to deal with PAL/NTSC switching, as well as
TV swichting, in the future.

I think for the rest of the year, time will be a limit on my work, too,
as my "regular" work is quite exhaustive at least up to the end of November.

In the following, I have an excerpt of ideas on this topic which I sent
to Tormod some weeks ago.

It would be great if we could either make a common decision OR just
allow a solution to be established which is achieved first. Tormod
suggested to get into XRandR to migrate the s3switch features to this
logic, but that would result in a solution not really quick to implement
as it is a completely new topic.

-------------------------------

What I did in the meantime you can see in the attached patches. It was
all about inconsistencies related to output selection, s3switch
accomodation and video playback. The following goals are reached:

- before playing a video, the driver reads in the output config which
could have been modified due to Fn+Output key or s3switch. If TV or CRT
is on, the LCD expansion is avoided. Before this, video image on TV was
cropped due to false expansion.

- when the LCD is off, DPMS for the LCD is blocked. Before this, the
display would get corrupted on external (esp. TV) screen and the LCD got
into an undesired state of turning white. This was especially annoying
as e.g. the VLC player makes calls to DPMS before playing a video! I
think this was well-meant, but was destructive in case of our savage
driver. Now the driver is protected.

- at each mode switch, the driver reads in its current output
configuration and updates its list and flags. Up to now, a resolution
switch after changing output by key or s3switch caused the outputs to be
changed back to their previous state.

- when switching to text mode, the driver updates its config also and
restores the initial setting as intended.

HERE I HAVE AN IDEA FOR THE FUTURE: a new xorg.conf option which allows
enforcing to stay in the new output configuration also in text mode.

- the expansion code has now a condition for adding the famous "+7"
offset in case of a thinkpad 1400x1050 display. WE NEED A TESTER WITH A
THINKPAD T22 OR T23 EQUIPPED WITH THIS DISPLAY, not just because of this...

- the driver now prefers the BIOS configuration for selecting the TV
format, as most savage machines allow this.

IDEA: we should add an xorg.conf option allowing to prefer BIOS or xorg.conf

IDEA: we should decouple setting the TV format (option "PAL") from
enabling TV out. Up to now it is a silly mix that PAL also enables TV.

- the driver does not overwrite the TV format setting unnecessarily
anymore. On my system this seems to cause the system BIOS to be reset to
defaults after reboot - the exact conditions I still have to analyse.

- also the output device settings are only written if necessary in most
places.

- I added flags and masks to do more of this stuff the symbolic way.

- I corrected the meaning of "TvOn" to be "on", not "only".

- In contrast, the CrtOnly is always applied exclusively to be "only",
not "on".

- I added a function to calculate the need for the DuoView flag. Up to
now this was used rather uncoordinated - the logic has to be transferred
to the s3switch which currently throws this flag in always.

That should be all, more or less

For remaining uncertainties, see my "IDEA" marks. Additionally I
detected that my HP XE3's BIOS is a little over-correct: it clears the
DuoView flag whenever it is not necessary, and keeps it cleared when
attempting a mode switch back from text to graphics, even if we try to
activate it here again. This is one of the reasons why I'd like to
integrate a new xorg.conf option for keeping the active outputs also in
text mode.

Also my BIOS tends to reset itself to defaults if something happens
which it doesn't like. Currently it looks as if this reason mainly was
the writing of TV mode when the TV output was already active, so with
the current code I have not experienced it again.

-------------------------------

Best regards,

Hans-Juergen

Rolf Leggewie schrieb:
> Hans-Jürgen, any news on this?
>