#20 ggiCheckMode with no mode to suggest.

[Peter Rosin]

There is a hole in the ggiCheckMode interface.

For the pathological case where a target has no
mode to suggest, there is no documented behaviour
for how ggiCheckMode should behave.

Worse yet, e.g. display-multi with two incompatible
targets (one palette-only, one truecolor-only)
suggests a mode which cannot be set in this case.

[chxxx]

Logged In: YES
user_id=51548

In display-multi/tile, etc., we should iterate over
all visuals.
Each child-visual has to suggest a mode at least,
thus it should be possible to find a common denominator.

[Nobody/Anonymous]

Logged In: NO

No, it is *not* always possible to find that common
denominator.

$ GGI_DISPLAY="multi:(palemu):(trueemu)" ./demo
running tests interactively.
LibGGI: No explicit target specified.
LibGGI: Try to use display-directx...
LibGGI: No explicit target specified.
LibGGI: Try to use display-directx...
Trying mode F1.[]
Suggested mode 1440x1080.V1440x1080.F1.D1x1.[C24/24]
LibGGI: Failed to set mode: 1440x1080.V1440x1080.F1.D1x1.
[C24/24]
Can't set mode
$

Yes, I know that this example is pathological, but
the same thing happens when e.g. visual 1 and 2 are
on different incompatible X-servers.

There is no specification on how ggiCheckMode should
behave in this case, so I don't know how to fix
display-multi/tile.

[Peter Rosin]

Logged In: YES
user_id=972775

Another example:

GGI_DISPLAY="multi:(x):(directx)" ./demo

fails because display-x and display-directx report
slightly different physical sizes, even when everything
else is compatible.

Suggestion: make ggiCheckMode and ggiSetMode in display-
multi restore GGI_AUTO in the size and dpp fields after
each call to a child target.

Pros: it makes the above work
Cons: ggiCheckMode will return GGI_AUTO in these fields.

See attached patch. Comments?

[Peter Rosin]

Relax requirements for ggiCheckMode in display-multi.

[chxxx]

Logged In: YES
user_id=51548

This patch makes the mode/testcase1 regression test fail.
I fear only a partial rework of the ggiCheckMode()
specification can fix this properly.

[Peter Rosin]

Logged In: YES
user_id=972775

I think we need to reserve one specific error code (e.g.
GGI_ENOTFOUND) for the case where no mode can be suggested,
or we could fill in the suggested mode with something
predetermined and impossible.

We also need to allow ggiCheckMode to return GGI_AUTO for
(at least) some fields (but of course recommend against
such practice, if it can be avoided).

At least that's the minimal interface changes I can
conjure to plug this interface hole.

[Peter Rosin]

Logged In: YES
user_id=972775

Consider this example output from the demo app:

"Visual size is 205 mm x 103 mm (0 means unknown)"

This little line hints that the regression test is too
sensitive about GGI_AUTO as size after a call to
ggiCheckMode, and that the multi-checkmode.patch is OK.

BTW, this message in the demo app predates the regression
test by many years.