Video out hot key sends super + p + return on many upcoming Dell & HP systems

Reported by Chris Coulson on 2010-03-16
212
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Linux
Invalid
Undecided
Unassigned
OEM Priority Project
High
Chris Van Hoof
gnome-settings-daemon
Fix Released
Medium
gnome-settings-daemon (Ubuntu)
Low
Martin Pitt
Declined for Lucid by Rick Spencer
Maverick
Low
Martin Pitt
Natty
Low
Martin Pitt
linux (Ubuntu)
Undecided
Unassigned
Declined for Lucid by Rick Spencer
Maverick
Undecided
Unassigned
Natty
Undecided
Unassigned

Bug Description

The Fn+F8 key combination on my Dell E5500 does not work in Lucid (this key combination should be able to switch video modes). Debugging with "xev", it seems that the key combination is mapped to the letter "p" at the X layer. Debugging further down the stack shows that the scancode from Fn+F8 also matches that of the "p" key.

This combination worked properly in Karmic.

Using "showkey -k", the keycodes are as follows:

[p] = 25
[Fn]+[F8] = 25 (although I also see keycode 125 as I press F8, and I see 125 release as I let go of the Fn key)

Using "showkey -s", the scancodes are as follows:

[p] = 0x19 0x99
[Fn]+[F8] = 0x19 0x99 (although I also see "0xE0 0x5B" as I press F8, and I see "0xE0 0xDB" as I release Fn)

ProblemType: Bug
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.21.
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: chr1s 4010 F.... pulseaudio
 /dev/snd/controlC1: chr1s 4010 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xf6afc000 irq 21'
   Mixer name : 'Intel G45 DEVCTG'
   Components : 'HDA:111d76b2,10280263,00100302 HDA:80862802,80860101,00100000'
   Controls : 22
   Simple ctrls : 11
Card1.Amixer.info:
 Card hw:1 'U0x46d0x9a4'/'USB Device 0x46d:0x9a4 at usb-0000:00:1a.7-3.3, high speed'
   Mixer name : 'USB Mixer'
   Components : 'USB046d:09a4'
   Controls : 2
   Simple ctrls : 1
Card1.Amixer.values:
 Simple mixer control 'Mic',0
   Capabilities: cvolume cvolume-joined cswitch cswitch-joined penum
   Capture channels: Mono
   Limits: Capture 0 - 14
   Mono: Capture 0 [0%] [23.75dB] [on]
Date: Tue Mar 16 10:26:43 2010
DistroRelease: Ubuntu 10.04
HibernationDevice: RESUME=UUID=762f3439-67ac-4828-aa94-caf2a2ba0f9a
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
LiveMediaBuild: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
MachineType: Dell Inc. Latitude E5500
Package: linux-image-2.6.32-16-generic 2.6.32-16.25
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.32-16-generic root=UUID=4ce5e12b-6e82-4fa4-90ff-7d9859d7504e ro quiet splash
ProcEnviron:
 LANG=en_GB.utf8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-16.25-generic
Regression: Yes
RelatedPackageVersions: linux-firmware 1.32
Reproducible: Yes
SourcePackage: linux
TestedUpstream: No
Uname: Linux 2.6.32-16-generic x86_64
dmi.bios.date: 11/05/2009
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A15
dmi.board.name: 0DW635
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA15:bd11/05/2009:svnDellInc.:pnLatitudeE5500:pvr:rvnDellInc.:rn0DW635:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude E5500
dmi.sys.vendor: Dell Inc.

Chris Coulson (chrisccoulson) wrote :
Nicolò Chieffo (yelo3) wrote :

Similar hardware (Latitude E6400), same problem.
The correct keycode is 227 (of course without 25)

This needs an upstream bug I think

Kai Jauch (kaijauch) wrote :

Oh boy. I don't think this is a linux bug, this is intentional (Dell's intention).

I just did a BIOS update on my Dell Latitude E6400 from version A14 to A20. Version A20 doesn't generate keycode 227 anymore (as it did with A14), it generates super-p (windows key + p). Super-p ("p" as in projector, I guess) on Windows 7 (and probably Vista) pops up a dialog in which you can choose whether you want to clone the display, only activate the internal/external one or extend the desktop over both displays. AFAICT this method has the benefit of the user being able to specifically select the desired configuration without having to cycle through them one at a time, as it was the case with the original "display toggle key".

The output of xev supports that. It reports:
KeyPress event, serial 36, synthetic NO, window 0x5000001,
    root 0xb5, subw 0x0, time 582754, (489,-484), root:(492,187),
    state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 36, synthetic NO, window 0x5000001,
    root 0xb5, subw 0x0, time 582754, (489,-484), root:(492,187),
    state 0x40, keycode 33 (keysym 0x70, p), same_screen YES,
    XLookupString gives 1 bytes: (70) "p"
    XmbLookupString gives 1 bytes: (70) "p"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x5000001,
    root 0xb5, subw 0x0, time 582794, (489,-484), root:(492,187),
    state 0x40, keycode 33 (keysym 0x70, p), same_screen YES,
    XLookupString gives 1 bytes: (70) "p"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x5000001,
    root 0xb5, subw 0x0, time 583392, (489,-484), root:(492,187),
    state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Before this BIOS update there never was a way to tell whether the user was still holding down the fn key when he released f8, this was an instantaneous DisplayToggle Press+Release, no matter how long you actually pressed it. Now this is possible, as fn gets mapped to Super_L if you press fn-f8.

So this is a gnome-settings-daemon bug? super+p needs to be mapped to
display switch?

No, it's not a gnome-settings-daemon bug. I can confirm what Kai wrote, but I get the correct scan-codes when I downgrade to Karmic's kernel, without making any other changes

Nicolò Chieffo (yelo3) wrote :

Anyway gnome-settings-daemon could popup the monitor preferences application with super+f8 key combination

Changed in linux:
importance: Unknown → Undecided
status: Unknown → New
status: New → Invalid
Nicolò Chieffo (yelo3) wrote :

I meant Super+P, sorry

Chris Coulson (chrisccoulson) wrote :

Now you are confusing 2 separate issues on the same report. I don't care about Super+P opening the monitor preferences, and that is completely orthogonal to my original bug report. I want Fn+F8 to switch video modes just like it did in Karmic. That is what my bug report is about

Changed in gnome-settings-daemon (Ubuntu):
status: New → Invalid
affects: gnome-settings-daemon → null
Changed in null:
importance: Unknown → Undecided
status: Unknown → New
Nicolò Chieffo (yelo3) wrote :

To tell the truth, this is easy to workaround:
- start gnome-keybinding-properties
- click add
- type a name (for example "monitor properties")
- type the command: gnome-display-properties
- setup the keyboard shortcut ("Mod4+P")

Changed in null:
status: New → Invalid

Well, but if the behavior was changed in the BIOS to match windows 7,
this is a solution

Note that the kernel reported this every time I pressed fn-f8 with BIOS version A14:
[12675.498941] dell-wmi: Unknown key 42 pressed

It doesn't do that with A20.

2.6.31-20-generic (Karmic)
A14: "dell-wmi: Unknown key 42 pressed", (immediate) keypress/-release of keycode 227 is generated twice
A20: "dell-wmi: Unknown key 42 pressed", (immediate) keypress/-release of keycode 227 is generated twice

2.6.32-16-generic (Lucid)
A14: "dell-wmi: Unknown key 42 pressed", (immediate) keypress/-release of keycode 227 is generated twice
A20: no messages from dell-wmi, keypress/-release of super_l + p once (super_l release when fn is released, p release when f8 is released)

Kai Jauch (kaijauch) wrote :

I think I found the reason for the different behaviour of 2.6.31 and 2.6.32.

According to:
http://support.euro.dell.com/support/downloads/download.aspx?c=de&cs=debsdt1&l=de&s=bsd&releaseid=R231574&SystemID=LAT_E6400&servicetag=&os=WLH&osl=ge&deviceid=15569&devlib=0&typecnt=0&vercnt=11&catid=-1&impid=-1&formatcnt=0&libid=1&typeid=-1&dateid=-1&formatid=-1&fileid=333175

Dell added support for Windows 7 with BIOS version A15 for the Latitude E6400. A14 + kernel 2.6.32 caused fn-f8 to be reported as keycode 227.
Kernel 2.6.31 claims to support the ACPI interface for Vista, 2.6.32 claims to support the ACPI interface for Win7.

linux-2.6.31/drivers/acpi/acpica/uteval.c:
static struct acpi_interface_info acpi_interfaces_supported[] = {
        /* Operating System Vendor Strings */

        {"Windows 2000", ACPI_OSI_WIN_2000}, /* Windows 2000 */
        {"Windows 2001", ACPI_OSI_WIN_XP}, /* Windows XP */
        {"Windows 2001 SP1", ACPI_OSI_WIN_XP_SP1}, /* Windows XP SP1 */
        {"Windows 2001.1", ACPI_OSI_WINSRV_2003}, /* Windows Server 2003 */
        {"Windows 2001 SP2", ACPI_OSI_WIN_XP_SP2}, /* Windows XP SP2 */
        {"Windows 2001.1 SP1", ACPI_OSI_WINSRV_2003_SP1}, /* Windows Server 2003 SP1 - Added 03/2006 */
        {"Windows 2006", ACPI_OSI_WIN_VISTA}, /* Windows Vista - Added 03/2006 */

linux-2.6.32/drivers/acpi/acpica/uteval.c:
static struct acpi_interface_info acpi_interfaces_supported[] = {
        /* Operating System Vendor Strings */

        {"Windows 2000", ACPI_OSI_WIN_2000}, /* Windows 2000 */
        {"Windows 2001", ACPI_OSI_WIN_XP}, /* Windows XP */
        {"Windows 2001 SP1", ACPI_OSI_WIN_XP_SP1}, /* Windows XP SP1 */
        {"Windows 2001.1", ACPI_OSI_WINSRV_2003}, /* Windows Server 2003 */
        {"Windows 2001 SP2", ACPI_OSI_WIN_XP_SP2}, /* Windows XP SP2 */
        {"Windows 2001.1 SP1", ACPI_OSI_WINSRV_2003_SP1}, /* Windows Server 2003 SP1 - Added 03/2006 */
        {"Windows 2006", ACPI_OSI_WIN_VISTA}, /* Windows Vista - Added 03/2006 */
        {"Windows 2006.1", ACPI_OSI_WINSRV_2008}, /* Windows Server 2008 - Added 09/2009 */
        {"Windows 2006 SP1", ACPI_OSI_WIN_VISTA_SP1}, /* Windows Vista SP1 - Added 09/2009 */
        {"Windows 2009", ACPI_OSI_WIN_7}, /* Windows 7 and Server 2008 R2 - Added 09/2009 */

If the OS claims to support the Vista interface, the BIOS reports fn-f8 as keycode 227.
If the OS claims to support the Win7 interface, the BIOS reports fn-f8 as Super_L + p.

Conclusion: No bug in Linux, the BIOS just (intentionally) reports fn-f8 differently for Vista and Win7. Which would indicate that Super + p is a feature that was introduced with Win7 :)

As I suspect that more and more newer laptops are going to default to this behaviour, you would have to either quirk those to convert Super_L + p to DISPLAYTOGGLE (which is not feasible), or have everything that previously only reacted on DISPLAYTOGGLE to also react on Super_L + p. But that's out of scope for this bug report.

Jeremy Foshee (jeremyfoshee) wrote :

Chris,
    I am adding this to my list for Team review.

Thanks!

~JFo

Changed in linux (Ubuntu):
status: New → Confirmed
Chase Douglas (chasedouglas) wrote :

As Kai Jauch has pointed out, this appears to be the new behavior associated with Windows 7, and the BIOS is just throwing key codes to match. Thus, gnome needs to handle the proper interpretation of the key presses. I don't know exactly what package in gnome handles the key codes, but gnome-settings-daemon looks like it's close to the action.

Changed in gnome-settings-daemon (Ubuntu):
status: Invalid → Confirmed
Changed in linux (Ubuntu):
status: Confirmed → Invalid
Chris Coulson (chrisccoulson) wrote :

This new behaviour is so incredibly wrong. Changing the shortcut in g-s-d would break every other piece of hardware, and we can't start adding multiple shortcuts to special-case different types of hardware.

Changed in gnome-settings-daemon (Ubuntu):
status: Confirmed → Won't Fix

To tell the truth, capplets-data should contain something about the
default keybindings

Well, so everything is invalid...
OT: might I ask you if fn+f10 (which should be sysreq) works? In my case it is mapped to "print".

Cristian KLEIN (cristiklein) wrote :

Just a quick note: comment #3 and #12 are also relevant to Dell Latitude E4300.

Jerone Young (jerone) on 2010-04-17
summary: - Fn+F8 key combination doesn't work on Dell E5500
+ Fn+F8 key combination doesn't work on Dell E5500, Studio XPS 1558, &
+ upcoming Dell systems
Changed in gnome-settings-daemon (Ubuntu):
status: Won't Fix → Confirmed
summary: - Fn+F8 key combination doesn't work on Dell E5500, Studio XPS 1558, &
- upcoming Dell systems
+ Video out hot key combination doesn't work on Dell E5500, Studio XPS
+ 1558, Inspiron 15 & many upcoming Dell systems
summary: - Video out hot key combination doesn't work on Dell E5500, Studio XPS
- 1558, Inspiron 15 & many upcoming Dell systems
+ Video out hot key sends super + p on Dell E5500, Studio XPS 1558,
+ Inspiron 15 & many upcoming Dell systems

Patch to Gnome-settings-daemon to add support for super (windows key) + p key combination. This is against gnome-settings-daemon on 10.04.

This was written by Micheal Terry in Canoncial oem serivces. There has been some testing. Will report back with extensive testing shortly.

This is now officially the way Dell will be treating the video out hot key on many (if not all) Dell machines moving forward.

Jerone Young (jerone) on 2010-04-18
summary: - Video out hot key sends super + p on Dell E5500, Studio XPS 1558,
- Inspiron 15 & many upcoming Dell systems
+ Video out hot key sends super + p + return on Dell E5500, Studio XPS
+ 1558, Inspiron 15 & many upcoming Dell systems
tags: added: patch

Well there is an issue here found after testing. It's not good either.

 Actually fixing gnome-settings-daemon may not be the best solution. There are 2 thinings.
         1) Even with Mike's Patch (great patch) .. the way it works is when you press the hot key it first sends super+p. Then a small delay & then sends are return key. The problem here is users gets a return key press that can have unintended consequences. We can't catch that return either. So if a user is doing something they will get a return key press, which could have all sorts of side effects that the user would not want.

         2) Apparently the Dell bios only does this only for OSes that identify themselves as Windows 7.. it does an acpi query. Of course Linux says I am Windows 7. But under Windows Vista the key only sends a video out key press (as normal).

           The best way to get around this issue (till Dell decides to fix their bios), is to pass acpi_osi="Windows 2006" on the kernel command line. So Linux says I'm Windows Vista.

   Chatting with Dell now about this.

Chris Coulson (chrisccoulson) wrote :

g-s-d is almost certainly the wrong place to fix this anyway. At some point in the stack, Super+P should map to the same X keysym that the keys on every other piece of hardware that exists map to (whether that is in the kernel or xkeyboard-config, I'm not sure). But adding hardware-dependant hacks like this to something at the level of g-s-d just seems wrong to me

Jerone Young (jerone) on 2010-04-19
summary: Video out hot key sends super + p + return on Dell E5500, Studio XPS
- 1558, Inspiron 15 & many upcoming Dell systems
+ 1558, Inspiron 15 & many upcoming Dell systems & HP machines

@Chris
         Well the specification comes from Microsoft. It states the bios will send Super + P .. wait .5 seconds and then send a return. If another keypress happens in between that .5 seconds the bios is not to send the return.

         What this is doing is bringing up the windows video dialogue and pressing enter on it.

         For Ubuntu & Linux distros this brings up an interesting situation.

summary: - Video out hot key sends super + p + return on Dell E5500, Studio XPS
- 1558, Inspiron 15 & many upcoming Dell systems & HP machines
+ Video out hot key sends super + p + return on many upcoming Dell & HP
+ systems
Jerone Young (jerone) on 2010-04-19
Changed in linux:
status: Invalid → Confirmed
Jerone Young (jerone) wrote :

I've created a short video simulating this action and showing how it works under Windows 7.

http://www.youtube.com/watch?v=SADwRRoHsgs

Michael Terry (mterry) wrote :

Chris, regarding your statement about g-s-d being the wrong place, I initially tended to agree. But after talking with pitti, it appears the Linux input stack is not meant to be able to 'merge' keypresses like Super_L+p into a different press. It's only really good at translating one press into another. So the ideal solution (udev mapping) seems not workable.

So we have to do it in desktop-space. Then, my gut reaction is to add an entry to the GNOME Keybindings screen that defaults to Mod4+p for switching video mode, because hardcoding a keybinding in g-s-d that normally would be available for users to use seems bad. But... this is a BIOS hardcoded key press. Allowing the user to change 'video-switch' to a different key would just be letting the user break their 'display' keyboard key. Seems like it should be at least as hardcoded as the previous VIDEOSWITCHMODE presses were.

So that led me to the g-s-d patch you see above.

Jerone Young (jerone) wrote :

Hi everyone. Here is the Microsoft presentation with more info on this behavior:

http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/MBL-T579_WH08.pptx

See slides 21 - 22 & 36 specifically.

Michael Terry (mterry) wrote :

One interesting issue that I don't think has been mentioned is that mutter grabs and blocks the use of the Super key. So in mutter, my patch won't work. And any attempt to share Super key will fail.

Specifically, mutter's default value for /apps/mutter/general/overlay_key is Super_L. Mutter grabs this key and won't let go (so g-s-d never sees press). The overlay_key is not used directly by mutter, but does get passed along to gnome-shell which uses it for something (presumably to pull down its HUD/overlay? I haven't used it yet).

So, mutter needs to use a different key if we fix this bug. Also, anyone else in the world that relies on the keypress Super+p, since Windows/BIOS now mandates the behavior of it.

Pat McGowan (pat-mcgowan) wrote :

@Jerone
I have a BIOS that displays this behavior, but it does not issue a return. I see the sequence in comment 3.

@Michael
Windows waits for a release of the Super key to show the start menu, allowing other combinations to work. If Mutter behaved similarly your patch would be fine, although perhaps not what was desired.

Peter Clifton (pcjc2) wrote :

Some one needs to hit (sue) Microsoft with a clue-bat. Why couldn't they spec the machine's BIOS to emit the proper ACPI notification, and respond to that to bring up the video dialogue? WTF..

Colin King (colin-king) wrote :

Using acpi_osi="Windows 2006" may address this issue, but I've already seen one BIOS that this fails on, so it's not a generic solution.

Using acpi_osi=\"!Windows 2009\" maybe better temporary workaround for now, but it will fail when the kernel gets upgraded and includes the names of newer Windows.

It's going to turn out very ugly if we carry on using this method of disabling this Windows 7 feature in the BIOS.

I've looked at a couple of DSDT tables and found that when Windows 7 is matched in the ACPI _OSI() method the embedded controller is tweaked to enable this Windows 7 feature to emit the key sequence. The exact implementation will vary from BIOS to BIOS, so it's really quite ugly.

Russ Dill (russ-dill) wrote :

#22, do you think you could provide a link to that spec?

Colin King (colin-king) wrote :

Slide #36 of http://download.microsoft.com/download/5/E/6/5E66B27B-988B-4F50-AF3A-C2FF1E62180F/MBL-T579_WH08.pptx does state that it is *highly recommended* for PC System Manufacturers to modify the ACPI hotkey to generate the Windows 7 projection hot key - it does not however state it is *mandatory*. However, one would expect that BIOSes will start to come out with the feature by default even though it's and optional feature because of the pressure to comply with the recommendations from Microsoft.

MatthiasA (themaze) wrote :

This bug also affects my Dell Precision M4400 on Lucid. Fn F8 worked in Karmic.
Is there a workaround like a "nvidia-displaytoggle" command or something?

Kamal Mostafa (kamalmostafa) wrote :

@MatthiasA - There is a workaround -- boot with this kernel option (see comment #29): acpi_osi=\"!Windows 2009\"

Please try that on your Precision M4400 to verify that it fixes the problem and is indeed the same bug. Feedback to this bug report will be appreciated.

imahon (i-mahon) wrote :

I also have a Dell Precision M4400 (BIOS A16)

Using acpi_osi=\"Windows 2006\" had no effect.

Using acpi_osi=\"!Windows 2009\" works for me.

jfding (jfding) wrote :

HP Mini210 netbook has the same issue.
acpi_osi="!Windows 2009" works for me.

Ketil Malde (ketil-ii) wrote :

HP Pavillion dm1 has this as well - hitting Fn-F2 pops up the run command dialog, which under my Xmonad setup is bound to Win-p.

MatthiasA (themaze) wrote :

I tried acpi_osi=\"!Windows 2009\" on my Dell M4400 with ubuntu 10.04 64bit and it did not work.

(In grub I hit "e", entered acpi_osi=\"!Windows 2009\" into the last line and started ubuntu with Strg+x)

In Ubuntu the Video out hot key produces the letter "p" in Applications like Open Office and MS Office 2007.

I will try acpi_osi="!Windows 2009" as jfding wrote.

MatthiasA (themaze) wrote :

acpi_osi="!Windows 2009" did not work either.

@imahon: What exactly did you do to get Fn + F8 working again?

Jerone Young (jerone) wrote :

I now have exactly how this hot key works.

Scenero 1:
          When video out hotkey pressed.
          Send Windows (Super) + P
          Wait 0.5 seconds
          If no key is pressed send return key. If any key is pressed do not send anything.

Scenerio 2:
          User holds video out hotkey
          Keep sending Windows(Super) + P till user lets go.
          When user done holding wait 0.5 seconds.
          If no key is pressed send return key. If any key is pressed do not send anything.

Jerone Young (jerone) wrote :

So my exact description is directly from the internal only (sadly) specification data sheet. But I'm being shown by folks at least on the Dell 1558 this is not the exact behavior. So looking for more sampling.

Kamal Mostafa (kamalmostafa) wrote :

For the record, my Dell Studio 1558 (BIOS version A04) does not behave exactly as described in comment #39...

I find that if I press the video out key just once (or if I press it multiple times, but wait at least a few seconds between each press) then I never get the weird injected <Enter> after the Super + P sequence. (In a terminal window, this just looks like I've typed a lower-case 'p'). However, if I press the video out key more than once in quick succession, then about 0.5 seconds after I stop pressing it I do get a single injected <Enter>.

To summarize, I only ever get the weird injected <Enter> if I press video out more than once in a short timeframe.

Jerone Young (jerone) on 2010-05-13
Changed in linux (Ubuntu):
status: Invalid → Confirmed
tf (dr-tomas) wrote :

The patch in comment 19 does not address the problem of the injected Enter, which will end up in the currently focused application; you will need to grab Enter when getting the Super+P keycode.

MatthiasA (themaze) wrote :

Kamal Mostafa wrote me a Mail on how to set the grub boot option correctly

After adding acpi_osi=\"!Windows 2009\" at the and of the "linux" line the key works again.
Thanks a lot for this work around!

(Notebook: Dell M4400, Bios A19, Ubuntu 10.04 x64)

Andy Whitcroft (apw) wrote :

@Jerone -- the microsoft document you linked to slide 36 does imply that the BIOS key should do the same thing as the Win-P key. It is not at all clear that it intends that the BIOS should _send_ the Win-P key. It cirtainly does not recommend that they send a return sometime later to accept the dialog? Even if one is very charitable and interpret those words to mean the Win-P should be produced for Win7 the return behaviour is not sensible nor apparently required.

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Low
Tony Espy (awe) on 2010-06-21
Changed in oem-priority:
status: New → Confirmed
importance: Undecided → High
Shih-Yuan Lee (fourdollars) wrote :

Here is another workaround I found.
/apps/metacity/keybinding_commands/command_1 "gnome-terminal --geometry 0x0 --hide-menubar -x xdotool key XF86Display"
/apps/metacity/global_keybindings/run_command_1 "<Mod4>p"

acpi_osi=\"!Windows 2009\" worked for me.

Dell Latitude E6410.

houbahop69 (gerard-f-vidal) wrote :

Adding acpi_osi=\"!Windows 2009\" at the and of the "linux" line the Fn key works again.
Thanks a lot for this work around!

(Notebook: Dell Precision M2400, Ubuntu 10.04 x64)

After an update the trick was lost so I changed the following line in the file /etc/default/grub
GRUB_CMDLINE_LINUX="quiet"
to
GRUB_CMDLINE_LINUX="quiet acpi_osi=\\\"!Windows 2009\\\""

It works fine for Fn F8 and there are no more problems with update-grub

Jerone Young (jerone) wrote :

To summarize the work arounds proposed.

1) Adding acpi_osi=!Windows 2009 to kernel command line (via grub)
 * The best work around currently. Works for everything.
 * This is dependent on the bios identifying and not doing Win+P+(?delay Return) for other operating system

2) Set keybindings for metacity for Win+P
* Comment #45
* Issue here is that is does not catch rouge return .. that may or may not come around
* Only for win managers using metacity

2) Patch to gnome-settings daemon
*Comment #19
*Issue here is that is does not catch rouge return .. that may or may not come around
*Only will work out if gnome-settings daemon is running

jlgoolsbee (jlgoolsbee) wrote :

Thanks to all for your work on this issue; just recently ran into this on an E6510 and I used fix #1 from comment #48 successfully.

However, I see at the top of the bug report that a true fix for this was declined for Lucid, and was instead pushed to Maverick. Isn't this the kind of thing that could/should be rolled into an LTS point-release?

Sebastien Bacher (seb128) wrote :
Changed in gnome-settings-daemon:
status: Unknown → Confirmed
Changed in gnome-settings-daemon:
importance: Unknown → Medium
tags: removed: regression-potential
Martin Pitt (pitti) wrote :

Upstream g-s-d has a patch for this now which will need some cleanup for trunk, but should do fine for maverick.

Changed in linux (Ubuntu):
status: Confirmed → Invalid
Changed in gnome-settings-daemon (Ubuntu):
status: Confirmed → Triaged
Changed in oem-priority:
assignee: nobody → Canonical Platform QA Team (canonical-platform-qa)
Pedro Villavicencio (pedro) wrote :

Based on the comment from Martin i'm approving the nomination for Maverick, thanks all.

Changed in gnome-settings-daemon (Ubuntu Maverick):
status: New → Triaged
importance: Undecided → Low
assignee: nobody → Canonical Desktop Team (canonical-desktop-team)
Changed in oem-priority:
assignee: Canonical Platform QA Team (canonical-platform-qa) → nobody
Changed in linux (Ubuntu Maverick):
status: New → Invalid
Changed in gnome-settings-daemon (Ubuntu Maverick):
assignee: Canonical Desktop Team (canonical-desktop-team) → Martin Pitt (pitti)
Changed in gnome-settings-daemon:
status: Confirmed → Fix Released
Martin Pitt (pitti) wrote :

The upstream patches are rather intrusive, they aren't really appropriate for SRUing. Mike's patch looks more suitable for an SRU. Has this ever been tested on the maverick package? I prepared a test package for maverick in my SRU test PPA (https://aunchpad.net/~pitti/+archive/sru-test), could someone please install that on an affected system and check whether it works? If so, I'll upload it to maverick-proposed.

Changed in gnome-settings-daemon (Ubuntu Maverick):
status: Triaged → In Progress
Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: Triaged → In Progress
Kai Jauch (kaijauch) wrote :

gnome-settings-daemon 2.32.0-0ubuntu3.1~test1 from your PPA works fine on my Dell Latitude E6400 (BIOS version A20, which is not the latest one available) with Maverick.

Fn+F8 cycles through the different output combinations and I didn't see any keypresses passed to active text fields (neither characters nor returns).

Martin Pitt (pitti) wrote :

Thanks! Uploaded to maverick-proposed, it needs someone else from ~ubuntu-sru to review/ack now.

Accepted gnome-settings-daemon into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in gnome-settings-daemon (Ubuntu Maverick):
status: In Progress → Fix Committed
tags: added: verification-needed
Chris Van Hoof (vanhoof) on 2010-11-12
Changed in oem-priority:
assignee: nobody → Chris Van Hoof (vanhoof)
status: Confirmed → Fix Committed
Kamal Mostafa (kamalmostafa) wrote :

I confirm that gnome-settings-daemon (2.32.0-0ubuntu3.1) in maverick-proposed fixes the problem on Dell Studio 1558. Monitor output switching behaves correctly and no more stray "Super+p" is injected. Thanks!

Leonid Malashev (lm1024) wrote :

I'm using Ubuntu 10.10 (maverick) on my laptop HP Probook 4520s and I have a similar problem, but switching between monitors with a combination of keys Fn + F4.
Is it possible to solve for my laptop?

Thanks in advance.

Kent Baxley (kentb) wrote :

Confirmed that this update fixes the issue on a Dell Latitude E4310 as well as other Latitude models.

Don Murray (donaldm314) wrote :

Updated /etc/default/grub as described in #47. This work-around fixed Fn+F8 on a Dell M4400 (BIOS A16) running 2.6.32-25-generic.

Martin Pitt (pitti) on 2010-11-19
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 2.32.0-0ubuntu3.1

---------------
gnome-settings-daemon (2.32.0-0ubuntu3.1) maverick-proposed; urgency=low

  * Add 45_support_new_video_key.patch: Have "Super+P" trigger a video mode
    switch. Newer Dell and HP systems have a rather broken BIOS (due to a
    misunderstanding of the spec) which causes FN+F8 to send the literal
    Super+P scan codes instead of a proper KEY_VIDEOMODE scan code.
    Patch by Mike Terry, thanks! (LP: #539477)
 -- Martin Pitt <email address hidden> Fri, 12 Nov 2010 11:38:29 +0100

Changed in gnome-settings-daemon (Ubuntu Maverick):
status: Fix Committed → Fix Released
Chris Van Hoof (vanhoof) on 2010-11-19
Changed in oem-priority:
status: Fix Committed → Fix Released

Just a heads up,

I use Xmonad as the Gnome window manager and this patch somewhat broke Xmonad for me. Xmonad, by default, uses a combination of "Mod+p" (what "Mod" is is configurable, in my case I've set it to the Super_L) to open the Gnome run dialog. So after getting the latest updates, pressing "Super+p" just flashes the screen briefly and does not open the Gnome run application dialog, as it did before. I assume that this is the new assumed behavior, related to video modes.

This machine is _not_ a Dell or a HP laptop. It's a self-built desktop with Asus P5Q, Intel Q9550, Nvidia GTX 260 using the Nvidia proprietary drivers.

So is there any way to disable this new behavior, or is it really hard-coded to gnome-settings-daemon? I can live with having to use a different key combination to start programs, but would really like to use "Super+p" in the future too, as my fingers are somewhat used to that particular combination.

Frank (luxeven) wrote :

And another heads up,

I have a Dell Studio 1558 and use Gnome with Gnome-Do. I couple of days ago I connected an external monitor for the first time and maybe also tried Fn+F1 to activate the VGA port. After doing that (and rebooting various times) Super+P does not launch Gnome-Do anymore as I configured it before but only removes my mouse arrow for parts of a second. If start Gnome-Do through the menu, change the key to start Gnome-Do to e.g. to Super+J, close Gnome-Do, reopen and configure it back to Super+P it works again. When I then use Fn+F1 it also opens Gnome-Do.
Unfortunately this all only lasts until the next reboot and then I can start reconfiguring Gnome-Do once again.

Shimon Rura (shimon) wrote :

Sakumatti Luukkonen: I had a similar problem -- I use Super+p frequently as a custom keyboard binding (switching workspaces). Since my latest apt-get upgrade this resulted in screen flicker or unwanted resolution changes, as well as preventing the keypress from reaching my window manager. Thanks for helping me narrow down the issue to gnome-settings-daemon!

I found the following workaround. Using gconf-editor, find the following conf key:
/apps/gnome_settings_daemon/plugins/xrandr/active
And set it to false (not checked). The change should be effective immediately after the edit.

This may disable other useful behavior, but I haven't personally noticed any ill effects. I could imagine it might impact settings proper display settings on login, though.

Frank (luxeven) wrote :

Shimon, thanks for this advise which I just tried and at least I have Gnome-Do catch my Super+p again. Fn+F1 obviously still emitts the same code (why should that change) and opens Gnome-Do but I can live with that. Thanks!

fantasai (fantasai) wrote :

I use Super+P for switching windows, and the fix here broke that. Comment #64 lets me work around that, but it seems like the wrong way to fix the problem.

thedward (thedward) wrote :

I am another victim of the chosen fix.

I use Super+P as a custom binding.

Could this at least be made configurable?

I've recompiled without the patch, but I hope
I don't have to maintain my own version.

Martin Pitt (pitti) on 2010-12-09
Changed in gnome-settings-daemon (Ubuntu Natty):
status: In Progress → Fix Committed

Again, the super+p keybinding is broken for all user applications when running gnone-settings-daemon, and the option to fix the problem is not discoverable (and may have other side effects). I disabled all the keybindings in gnome-keybinding-properties and performed various other hair-pulling before discovering the cause was this "fix". The committed patch causes a frustrating regression.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 2.32.1-0ubuntu3

---------------
gnome-settings-daemon (2.32.1-0ubuntu3) natty; urgency=low

  [ Sebastien Bacher ]
  * debian/rules: list the objects to build before the libraries to fix the
    build issues which was workarounded in the previous upload (lp: #676519)

  [ Martin Pitt ]
  * Add 45_support_new_video_key.patch: Have "Super+P" trigger a video mode
    switch. Newer Dell and HP systems have a rather broken BIOS (due to a
    misunderstanding of the spec) which causes FN+F8 to send the
    literal Super+P scan codes instead of a proper KEY_VIDEOMODE scan
    code. Patch by Mike Terry, thanks! (LP: #539477)
 -- Martin Pitt <email address hidden> Sun, 09 Jan 2011 07:13:47 -0600

Changed in gnome-settings-daemon (Ubuntu Natty):
status: Fix Committed → Fix Released
johnny (rtlnts-ubt) wrote :

[ Cross-post from bug 694910 comment 6: https://bugs.launchpad.net/gnome-settings-daemon/+bug/694910/comments/6 ]

Fix for bug 539477 broke my usage of Mod4-P (incidentally, on a Lenovo laptop). What's the reason for the "Won't Fix" status here?

This is extremely unexpected and annoying behavior. Stealing existing user shortcuts and making them not configurable is unacceptable. Just because some Dell/HP laptops have a certain behavior is not a valid reason for having one of your most heavily used shortcuts in your IDE do something else all of a sudden. Also consider it unacceptable to be asked to change my existing, heavily day-to-day used shortcuts.

=JeffH (jeff-hodges) wrote :

Why was distributing the fix for this apparently "Declined for Lucid" ?

Why can't the gnome-settings-daemon (g-s-d, gsd) fix be backported to 10.04 ? It's a LTS release and I assume there's a bunch of folks who'll use it well into 2012.

thanks,

=JeffH

Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
James M. Leddy (jm-leddy) wrote :

Marking invalid in linux because this was fixed in g-s-d.

Changed in linux:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.