[Intel-gfx] Is there a way to determine which display is the laptop display?

[Alan Amaral]

Your idea about proxying the lid state to the drm connection state would be perfect.  Why leave the
display turned on when you can't see it anyway?  Closing the lid is pretty much equivalent to yanking
a monitor cable.
 
If that can't be done is there any chance something could be put into /sys/class/drm/card*_foo, like a
new entry for the laptop screen, such as /sys/class/drm/card0-LVDS-1/laptop_screen?  Could be created
only for the laptop screen, or for every output but only the laptop returns TRUE.
 
I've already got mapping from XRandR output names to drm output names (quite a bitch that was to
get working across all systems), so reading the contents of the sysfs file wouldn't be hard.
 
Thanks for the reply,
 
Al Amaral

________________________________

From: Adam Jackson [mailto:ajax at redhat.com]
Sent: Mon 2/6/2012 4:44 PM
To: Alan Amaral
Cc: intel-gfx at lists.freedesktop.org
Subject: Re: [Intel-gfx] Is there a way to determine which display is the laptop display?



On 2/2/12 4:28 PM, Alan Amaral wrote:
> With earlier hardware it was pretty easy to determine which display was the laptop display
> as it was usually (always?) "LVDS".  With new hardware it's sometimes an embedded display
> port (eDP) display, and I've seen at least one laptop which has the laptop monitor listed as simply
> Display Port (DP), although that may not have been an Intel machine.  In the DP case the laptop
> monitor can't be distinguished from a normal display port monitor.

If the driver isn't reporting an eDP display as eDP, the driver is broken.

> The current code I have uses some heuristics to figure out what outputs are available on the system,
> i.e. checks for LVDS, then eDP, then DP, and makes a guess as to which one is the laptop monitor,
> but in some cases, like the DisplayPort case I described above, it's impossible to know for sure, and
> if a future release changes the names it will fail.

The names won't change.  There might be some new embedded display
connectivity in the future with a new name, but that's something you'd
have to handle then anyway.

Ideally we'd come up with a way to proxy laptop lid state into DRM
connector state directly, but a) there's a lot of broken hardware in the
world and b) the kernel tends to stridently resist getting anything
right in kernelspace when it's easier to let people get it wrong in
userspace instead.  Yes I'm bitter.

- ajax


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120207/81472aa6/attachment.html>