Bug 26738 - Should expose ConnectorType/SignalFormat properties for RANDR 1.3
Summary: Should expose ConnectorType/SignalFormat properties for RANDR 1.3
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 26736
  Show dependency treegraph
 
Reported: 2010-02-24 13:57 UTC by Federico Mena-Quintero
Modified: 2019-11-27 13:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Federico Mena-Quintero 2010-02-24 13:57:25 UTC
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.?".
Comment 1 Chris Wilson 2010-09-07 14:32:34 UTC
Clients? The driver itself needs that information rather than relying on heuristics like "is the output LVDS, eDP, MPPI, etc?"
Comment 2 Federico Mena-Quintero 2010-09-07 15:17:28 UTC
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.
Comment 3 Chris Wilson 2010-09-07 15:58:30 UTC
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.
Comment 4 Federico Mena-Quintero 2010-09-09 08:01:48 UTC
Oh, perfect, thanks!  This should make things more future-proof.
Comment 5 Federico Mena-Quintero 2012-02-23 12:12:54 UTC
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.
Comment 6 Alex Fiestas 2013-04-29 00:23:16 UTC
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.

Thanks !
Comment 7 Martin Peres 2019-11-27 13:27:44 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/4.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.