That's really my point.
There _is_ one sort of detection you could do: look at the actual state of
the graphics chip.
In other words, exactly the case you mention: don't trust any BIOS tables
(they may not exist, and they _are_ broken in many cases) or silly EFI
information (I guarantee that any firmware info will eventually be buggy:
EFI is in no way going to be magically less buggy than BIOS tables have
been).
So what's left? You can still look at how the chip was programmed. If it's
driving the VGA port, you can be pretty sure that there's a monitor
attached. Sure, there might be something _else_ attached too, and I'm not
saying that you cannot try to probe other things, but right now it seems
that KMS totally throws away a free - and fairly reliable - piece of
information. And replaces it with very unreliable information that
definitely doesn't work.
I'm all for looking at many different places to find 'the truth', but I'm
very unhappy with KMS looks into BIOS tables, decides that there's a LVDS
panel attached (there isn't), and then disables the VGA port that drives
the monitor.
That doesn't help _anybody_. It just results in a black screen. And I
guarantee that this happens on several pieces of hardware, and no, it's
not all just "crap Apple and EFI". One of the pieces of hardware it
happens on is an Intel-only machine. Intel hardware, Intel firmware, Intel
motherboard, Intel _everything_. And yes, KMS decides to drive a
nonexistent LVDS display, rather than the one that the BIOS correctly
booted up with.
.. but if the BIOS drives one output, that should be a damn big hint that
you shouldn't then just randomly pick another one!
It sure as hell is a bigger hint than the ones you're using right now.
Which is kind of my point here. Why are you arguing against a known bug?
I want to repeat: it's not just Mac Mini.
The thing is, the BIOS _does_ report it to the hardware: you could just
read the hardware registers.
But no. Instead the Intel KMS code discards the hardware registers, and
reads the BIOS tables instead, finds a LVDS entry there, and uses that -
and disconnects the entry that _was_ driving the monitor.
Really. Do you seriously believe that because you found some random tables
in the BIOS memory, it's more reliable than "oh, the BIOS set the hardware
up to drive the SVDO output"?
That's what I find irritating. We _know_ BIOS tables are random crap. We
_know_ they are way less reliable than just asking the hardware where it
is. But KMS still trusts the VBT data more than the fact that the chip has
been programmed to output DVI/SVDO output.
Again, you say that, but you have absolutely nothing to back it up with.
Here's a counter-argument: we _know_ that it's not detectable whether
there's an LVDS panel is attached or not. So what should we do? Should we
turn off the VGA1 connection that we can see that the BIOS programmed, and
set things up for LVDS instead?
That's f*cking _stupid_. Go ahead and program the LVDS panel *too*, but
don't turn off the SDVO (or whatever) output that was also active!
And quite frankly, if the BIOS didn't turn on the panel, then maybe the
kernel shouldn't either. At least not until it gets a "lid open" event. So
even the "go ahead and program LVDS too" part is quite debatable.
In other words: it would be a lot saner to just keep whatever output mode
that the machine booted with. Then, change it ONLY IF YOU DETECT SOMETHING
ACTUALLY CHANGING.
Linus
--
