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: 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.htm>
