Bug 617728

Summary: Laptop Display Switch Key Does Not Work
Product: Red Hat Enterprise Linux 6 Reporter: Ray Strode [halfline] <rstrode>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED NOTABUG QA Contact: desktop-bugs <desktop-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 595763 Environment:
Last Closed: 2010-07-23 19:56:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ray Strode [halfline] 2010-07-23 19:51:19 UTC
+++ This bug was initially created as a clone of Bug #595763 +++

Description of problem:
This is a generic bug about a display switch key not working on various new laptop models. The following blog entry has more details why the key does not work:

http://mjg59.livejournal.com/121851.html

As of RHEL 6.0 Snapshot 4 this is still an issue with RHEL 6.

--- Additional comment from ctatman on 2010-06-30 08:50:07 EDT ---

Dell reported this issue in bugzilla: 607761.  They consider this to be quite urgent and are requesting that it be fixed in RHEL6.  Reason given:  This is a hardware cert blocker for them.  Unless this is fixed, they will not be able to certify their new series of laptops with RHEL6, and will suffer monetary losses.


--- Additional comment from rstrode on 2010-07-23 12:10:14 EDT ---

I haven't tested the implemented feature as a whole.  I'll need to track down hardware that has this unfortunate Windows-P thing to do that.  Matthew or Cameron, can one of you help with that?  Also, in the mean time, for anyone willing to help, I'd appreciate testing of two things in gnome-settings-daemon-2.28.2-9.el6 :

1) That the 'can't type "p"' problem is fixed
2) That the initial reported problem is resolved

--- Additional comment from rstrode on 2010-07-23 13:31:27 EDT ---

Mark has set me up with a T410 that appears to have this behavior. I'll do some tests with it now.

--- Additional comment from rstrode on 2010-07-23 13:55:35 EDT ---

So the T410 isn't appropriate hardware after all.  fn-F7 emits XF86Display.

There is definitely a lingering problem in the patch though.  It's doing a synchronous d-bus call to itself which blocks until timeout (~25 seconds i think) since there's no way it can answer a call to itself while blocked.

I'll look into correcting that specific issue, but ideally I'm still going to need to obtain hardware that has the problem mentioned in comment 0.

--- Additional comment from rstrode on 2010-07-23 15:22:50 EDT ---

I'm building a new package that should take care of the blocking issue.

I've also talked to John Feeney.  He loaned me a laptop that may be susceptible to the problem mentioned in comment 0. I'll do some testing with it now.

--- Additional comment from rstrode on 2010-07-23 15:46:53 EDT ---

I've done some testing with John's Dell Precision M6500.

The patch works fine with the caveat that there seems to be an orthogonal nouveau driver issue that prevents it from detecting the monitor layout.  It thinks there is only one monitor hooked up, so hitting fn-F8 does initiate a cycle, but it just cycles back to the same configuration over and over again with each keypress.

I'll file that bug separately.

Comment 1 Ray Strode [halfline] 2010-07-23 19:53:16 UTC
On this machine, I'm stuck in "clone" mode, with a thick black margin around the output of the larger monitor.

The output of xrandr is:

Screen 0: minimum 1440 x 900, current 1440 x 900, maximum 1440 x 900
default connected 1440x900+0+0 0mm x 0mm
   1440x900        0.0* 


gnome-display-properties just shows one monitor that says "Unknown".

Comment 2 Ray Strode [halfline] 2010-07-23 19:56:40 UTC
Ah nevermind, false alarm.

I didn't have the nouveau driver installed.