RANDR 1.3 specifies mandatory properties for outputs, ConnectorType and SignalFormat. However, the Intel driver doesn't expose these properties.
ConnectorType is the only robust way in which clients can detect the built-in display in laptops (where ConnectorType=Panel). Currently clients must resort to heuristics like "is the output name LVDS, Lvds, LCD, etc.?".
Clients? The driver itself needs that information rather than relying on heuristics like "is the output LVDS, eDP, MPPI, etc?"
Let me rephrase that.
The RANDR 1.3 spec says that ConnectorType and SignalFormat are mandatory properties. However, the Intel driver doesn't expose them at all. Since the driver must conform to the spec, this is a bug.
From the viewpoint of X clients, desktop managers sometimes need to know *what* outputs are. Is this a laptop's built-in LCD (so it has preference)? Is this HDMI (so probably a TV)?
For GNOME in particular, we need to know if an output corresponds to a laptop's built-in LCD. So far we have had to use a table of the various names that drivers give to built-in LCDs: LVDS, Lvds, LVDSn, LCD, etc. This is pretty unmaintainable, and it will break when laptop makers figure out a new connector type for the built-in screen.
The ConnectorType property was introduced to let clients avoid doing that stuff - it lets you say "if this property says Panel, then it *is* the built-in display". With this property, clients can reliably know what an output refers to.
Federico, I understood you well enough, I was just stating what was motivating me to fix this... :)
If I can move a few tables from the DDX to the i915.ko, that should make the code simpler *and* be useful for other applications.
Oh, perfect, thanks! This should make things more future-proof.
Ping :) We just ran into https://bugzilla.gnome.org/show_bug.cgi?id=670459 and needed a hack (another case of looking for "eDP" in the output's name) to work around this. Having the proper ConnectorType would have made this work automatically.
In KDE we are in the same situation, would be awesome if we could have this property exposed.
To put an example of why we need to know this:
-We want to turn the Panel output off when 2 screen are attached to the laptop and we do not have enough CRTC.