RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 617728 - Laptop Display Switch Key Does Not Work
Summary: Laptop Display Switch Key Does Not Work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: xorg-x11-drv-nouveau
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Ben Skeggs
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-23 19:51 UTC by Ray Strode [halfline]
Modified: 2010-07-23 19:56 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 595763
Environment:
Last Closed: 2010-07-23 19:56:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.