Qt and kde4libs don't support various multimedia keys

Bug #293213 reported by John Dong on 2008-11-03
122
This bug affects 9 people
Affects Status Importance Assigned to Milestone
Kubuntu Default Settings
Invalid
Undecided
Unassigned
kdelibs
Confirmed
Medium
Fedora
Fix Released
Medium
kde4libs (Ubuntu)
Medium
Unassigned
Nominated for Jaunty by unggnu
kubuntu-default-settings (Ubuntu)
Undecided
Unassigned
Nominated for Jaunty by unggnu
qt4-x11 (Ubuntu)
Medium
Unassigned
Nominated for Jaunty by unggnu

Bug Description

Binary package hint: kubuntu-default-settings

13:05 < jdong> state 0x0, keycode 233 (keysym 0x1008ff02,
               XF86MonBrightnessUp), same_screen YES,
13:05 < jdong> state 0x0, keycode 232 (keysym 0x1008ff03,
               XF86MonBrightnessDown), same_screen YES,

These are the brightness adjustment keys on my Macbook as reported by xev.

Yet /usr/share/kubuntu-default-settings/kubuntu.xmodmap remaps them as:

keycode 232 = XF86Stop
keycode 233 = XF86Forward

The result is that brightness keys do not work in Kubuntu.

IMO we shouldn't be blindly mapping keys like this that aren't standardized -- they should be per-keyboard quirks, not system-wide defaults!

Related branches

Kieran Hogg (xerosis) wrote :

Confirming this on my macbook too.

Changed in kubuntu-default-settings:
status: New → Confirmed
John Dong (jdong) wrote :

Even worse, I don't even know how to properly categorize this horrific brokenness, maybe an experienced QT4 soul can handle this:

Qt4 doesn't even capture the XF86MonBrightness* keys -- to the keyboard shortcut applet they don't exist (i.e. you can't grab those keys as shortcuts) -- the Qt4::Keys_* items don't exist for those keysyms either.

In addition, Kubuntu uses nonstandard hackish mappings XF86Launch4 and XF86Launch5 in Guidance for the other set of common brightness keys (mapped in xmodmap), and those are actually in Qt Key_Launch6 and Key_Launch7??

Something really weird and wacky is going on in the handling of brightness keys all the way down to the QT stack which, to this GNOME user, looks like resulted in a large stack of hacks to get to where we are today. IMO this needs to be fixed at the Qt level to recognize the XF86MonBrightness{Up,Down} keys properly, so that we can stop using Xmodmap hacks that incidentally don't seem to work!

Version: (using KDE 4.2.0)
OS: Linux
Installed from: Ubuntu Packages

Hi, Two of the function keys of my laptop which I use most are not working !!!

Fn + F3 - Standby
Fn + F4 - Switch display

HP/Compaq nc6400 laptop

When I try to press Fn + F3 for standby in the System Settings-> Global Keyboard Shortcuts -> Guidance Power Manager -> Standby -> Custom, I get the following error

"The key you just pressed isn't supported by Qt"

Both these keys are working fine in Ubuntu 8.10 Gnome that I have.
I have started using kde4 after 4.2 was released and I find it very compelling in terms of usability.

Thanks a lot...

sorry, i thought of mentioning the laptop model in the subject, to be more specific, but forgot. I couldn't find a way to change the bug title though !!

Just upgraded to KDE 4.2.0 (Fedora 10, using yum and the stable repositories) and I can confirm the user's problem.

I cannot use my FN keys to control the screen's brightness level any-longer (I have to use KDE power manager from the System tray to regulate it) and if I try to change the hotkeys for that as the previous user tried to I get his same error.

Same thing happens to me under KDE 4.2.00 in Kubuntu Jaunty Alpha 4 on an HP 6730b. I had Ubuntu Intrepid (8.10) installed previously and the function keys worked with Gnome in the same laptop.

Same here, on a Thinkpad R61, running Arch and KDEmod. If I try to set Fn+anything in System Settings > Input actions, the Qt error above pops up when I press the Fn key. Fn key is recognized by xev.

Same problem for me. Kubuntu 8.10 with Logitech Cordless Wave keyboard.

Some of the extra keys work fine, some give the "The key you just pressed isn't supported by Qt"-error, and some do nothing (but that is another problem).

Im also have same issue. "The key you just pressed isn't supported by Qt." getting this dialoge box when select fn keys

I also have this problem and search for a solution. I think this is Qt's bug, not KDE's. The key must be added to qt4/QtCore/qnamespace.h so that is can be recognized by a Qt program.

*** This bug has been confirmed by popular vote. ***

I can confirm this problem. Brightness keys doesn't work while they have
keycodes with Xev.

KeyRelease event, serial 35, synthetic NO, window 0x3000001,
    root 0xab, subw 0x0, time 999639, (-629,210), root:(458,235),
    state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown),
same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 35, synthetic NO, window 0x3000001,
    root 0xab, subw 0x0, time 1000020, (-629,210), root:(458,235),
    state 0x0, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp),
same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

It seems there is a bug entry in Qt's bug tracking about this problem: http://www.qtsoftware.com/developer/task-tracker/index_html?method=entry&id=230168

*** Bug 185453 has been marked as a duplicate of this bug. ***

Jonathan Thomas (echidnaman) wrote :
Changed in qt4-x11 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
unggnu (unggnu) wrote :

I can confirm this. When trying to assign the brightness keys to a keyboard shortcut the message: "The key you just pressed isn't supported by Qt" is displayed.

Since in Jaunty the /etc/acpi/sonybright.sh is removed so I can't change the backlight of my laptop with Kubuntu but in Ubuntu because later one supports my keys out of the box in guidance-power-manager. Changing the brightness in the KDE power plasmoid works fine so it is only a key problem.

xev definitely shows my keys as supported:
KeyRelease event, serial 35, synthetic NO, window 0x3000001,
    root 0xab, subw 0x0, time 999639, (-629,210), root:(458,235),
    state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown),
same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 35, synthetic NO, window 0x3000001,
    root 0xab, subw 0x0, time 1000020, (-629,210), root:(458,235),
    state 0x0, keycode 233 (keysym 0x1008ff02, XF86MonBrightnessUp),
same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

"2008-10-07 12:59 - Entry created: Task status changed to 'Open', Resolution set to 'Pending', Version found set to '4.4.3', Version for fix set to 'Not scheduled', Priority changed to 'No Priority'"

And it would seem TrollTech don't care ...

I guess one of the KDE devs which works for TrollTech or know some guys there should describe them the problem and the importance of it.

Changed in kubuntu-default-settings:
status: Unknown → Confirmed
Changed in fedora:
status: Unknown → In Progress

I have the same problem with my "Sleep" button which generates XF86Sleep. However, I get the same "not supported in Qt" message as ungnu, when I try to assign it...

Note that Qt #230168 is only about Cut, Copy and Paste keys, while this bug is wider.

Same for XF86Eject. Kubuntu Jaunty, KDE 4.2.2.

Same over here (standby and screen lock Fn keys are not supported).

It seems, mostly acpi event keys are affected by this issue.

Same for XF86AudioPause. Acer Aspire 5315, KDE 4.2.2, Arch Linux.

Pali (pali) wrote :

I have same problem with sleep button

Same problem here with Fn-F10 (eject) and Fn-F3 (battery).

It also happens on my multimedia keyboard. Many of the multimedia keys work, but these do not:

sleep, stop, reload, Tools, Explorer

Pressing any of these keys results in the same "QT not supported" message.

I'm running ubuntu 9.04 with kde 4.3beta and qt 4.5.1

Same problem with Sleep button on Kubuntu 9.04 kde 4.3beta qt 4.5.1

"Alt + Print Screen" is not supported either, while "Shift + Print Screen" and "Ctrl + Print Screen" are supported. (Kubuntu 9.04, KDE 4.2.3)

Changed in fedora:
status: In Progress → Fix Released

Please find attached a patch that enables the use of the following special laptop keys in Qt (and consequently also in KDE):

Further keys can be easily added if needed.

XF86MonBrightnessUp
XF86MonBrightnessDown
XF86Display
XF86Battery
XF86WLAN

I also submitted the patch upstream (to the Qt bug tracker).

BTW, if anybody would like to try this out, a patched Qt version is available on my PPA: https://launchpad.net/~thilo.ginkel/+archive/ppa

A couple of keys on my netbook also being affected I started to dig around to figure out where Qt needs to be changed to support them. The result is a patch, which adds support for the non-functional keys of my Samsung NC10. This probably does not solve all your key mapping issues, but should point out where their definition needs to be added. I also filed a bug upstream with Qt and attached my patch, but do not yet have a bug# for it that I could publish for your reference.

Created attachment 34170
Laptop keys patch for Samsung NC10

There is already an entry in Qt's bug tracking for this bug as I mentioned here, please do not open duplicates of Qt's bug entry 230168, it makes it difficult to track the bug. The bug is the same for all keys mentioned here, it is just a matter of adding the new non-working keys in the Qt's bug entry 230168, that will make it easier for the Qt developers to track the non-working keys. They already know about the problem, they are just being too slow to solve it.

Well, not being a Qt customer it is impossible for me to add extra information to an existing bug report. So, the only chance I have is to file a new one.

Perhaps somebody could complete the patch with any of the keys in /usr/share/X11/XKeysymDB? These are the keys supported by X and they should be supported by Qt either IMHO.

pauls (paulatgm) wrote :

Thilo, I just noticed your repo to test, but I'm using qt 4.5.1 already and your version is 4.5.0. Will your patched 4.5.0 work for kde 4.3 RC2, which had been using qt 4.5.1?

This is an important bug to me because it's basic functionality that I need, so I'd be interested in the patched qt4 that will work with kde 4.3 RC2.

regards

pauls (paulatgm) wrote :
pauls (paulatgm) wrote :

Thilo, I tried your patched qt 4.5.0 with kde 4.3rc3 and it does not solve the missing key shortcuts.

I also tried patching qt 4.5.1 and using it with kde 4.3rc3, but have the same problem.

Fn-F10 does not work to eject.

I don't think this bug has been properly triaged. It may be some other code in kde itself.

Paul, patching Qt is a prerequisite to solving the issue, but not sufficient. In addition, kde4libs also needs to be patched (in kdeui/util/kkeyserver_x11.cpp).

I tried applying this patch to qt 4.5.1 with kde 4.3rc3 and it fails to fix my particular key short cut problem. For me, the battery Fn-F3, eject Fn-F10, and usb keyboard sleep key still fail to function. I don't think you have properly identified the problem. Is there some other code to check?

(In reply to comment #25)

I didn't try the patch, but this might also be a more general KDE keyboard shortcut problem. I tried working around the problem by assigning the problematic keys (Expose, Dashboard and Eject on my Apple keyboard) to Launch0, Launch1 and Launch2 via xmodmap, but somehow only Launch0 works, the other two are ignored (even though I can assign them).

Jonathan Thomas (echidnaman) wrote :

K-D-S no longer ships the broken modmap.
The next Qt upload to Karmic will have a ton of new keycodes it supports.
Then all that's left is to patch kdelibs.

Changed in kubuntu-default-settings (Ubuntu):
status: Confirmed → Fix Released
Changed in qt4-x11 (Ubuntu):
status: Triaged → Fix Committed
Changed in kde4libs (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Jonathan Thomas (echidnaman) wrote :

Closing erroneous upstream bug watcher for Kubuntu Default Settings (should be kdelibs)

Changed in kubuntu-default-settings:
importance: Unknown → Undecided
status: Confirmed → New
status: New → Invalid
Changed in kde4libs (Ubuntu):
status: Confirmed → Triaged
Changed in kdelibs:
status: Unknown → Confirmed

I can add two XF86BrightnessAdjust keys to the list:

keycode 101 (keysym 0x1008ff3b, XF86BrightnessAdjust)
keycode 212 (keysym 0x1008ff3b, XF86BrightnessAdjust)

Both, as you can see, are recognised by xev (X.org 1.5.2), and both work in GNOME (2.26.3).

Using KDE 4.3 / openSUSE 11.1 / MacBook 4,1.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qt4-x11 - 4.5.2-0ubuntu3

---------------
qt4-x11 (4.5.2-0ubuntu3) karmic; urgency=low

  [ Jonathan Thomas ]
  * Change Vcs-Browser and Vcs-Bzr in debian/control
  * Add kubuntu_05_fix_arora_drag_crash.diff to stop QtWebkit from crashing
    when dragging things to the desktop (LP: #400794)
  * Add kubuntu_06_fix_webkit_mimetype_detection.diff to stop QtWebKit from
    trying to load mimetypes it doesn't know as images
  * Add 0286-fix-error-string.diff from kde-qt git
  * Add 0287-qmenu-respect-minwidth.diff from kde-qt git to fix the ugly
    Plasma task manager context menus
  * Add 0288-more-x-keycodes from kde-qt git to add support for more X
    keycodes to Qt (LP: #293213)

  [ Jonathan Riddell ]
  * Add pkg-config to libqt4-dev depends, see launchpad.net/bugs/410228

 -- Jonathan Thomas <email address hidden> Sun, 02 Aug 2009 20:03:52 -0400

Changed in qt4-x11 (Ubuntu):
status: Fix Committed → Fix Released

*** Bug 194166 has been marked as a duplicate of this bug. ***

Looks like upstream kde-qt landed support for extra keys recently, woo,
http://qt.gitorious.org/+kde-developers/qt/kde-qt/commits/patches/0288-more-x-keycodes

Changed in fedora:
status: Fix Released → Fix Committed
Changed in fedora:
status: Fix Committed → Fix Released
pauls (paulatgm) wrote :

Would appreciate getting this backported to kde 3.3 in jaunty .. any chance?

Jonathan Thomas (echidnaman) wrote :

Seeing as the KDE portion is yet to be done.... probably not.

I have the same problem with a Thinkpad X60s using KDE4.3.1 on openSUSE11.1.
The problem existed in 4.2 too.

In fact the Fn key is not recognised at all for a lot of the combinations. E.G
Fn+F2, Fn+F3, Fn+F4, Fn+F7, Fn+F9, Fn+F12. In Systemsettings when trying to enter a key combination to set a shortcut the Fn key is not recognised at all.

However it does work for some of the Fn combinations which I believe are controlled by the bios. E.G Fn+F5 (toggle radios), Fn+F7 (toggle external screen), Fn+ScrLk (toggle Numlock), Fn+PgUp (toggle thinklight), Fn+Home (increase screen brightness), Fn+End (decrease screen brightness).

These did work in Gnome so it seems to be a KDE thing. An explanation of the
Thinkpad Fn keys can be seen at
http://www.thinkwiki.org/wiki/How_to_get_special_keys_to_work.

If you require me to test or provide further info let me know.

Felix Geyer (debfx) on 2009-10-14
summary: - Qt doesn't support various multimedia keys, k-d-s has a broken modmap
+ Qt and kde4libs don't support various multimedia keys
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package kde4libs - 4:4.3.2-0ubuntu6

---------------
kde4libs (4:4.3.2-0ubuntu6) karmic; urgency=low

  [ Jonathan Riddell ]
  * Update kubuntu_74_hide_khtml_widgets.diff from
    http://websvn.kde.org/?revision=1033984&view=revision
    (LP: #447823)
  * Fix typo in 20_use_dejavu_as_default_font.diff, reported in
    http://bugs.debian.org/549308 "problems with konqueror default Fixed Font"

  [ Jonathan Thomas ]
  * Fix kubuntu_77_kglobalsettings_progagation_change.diff to prevent FTBFS

  [ Felix Geyer ]
  * Add kubuntu_80_kaction_qt_keys.diff to allow more Qt::Keys to be used
    as KAction shortcuts (LP: #293213)

 -- Felix Geyer <email address hidden> Thu, 15 Oct 2009 00:00:10 +0200

Changed in kde4libs (Ubuntu):
status: Triaged → Fix Released

Here's a patch from Kubuntu that adds key support in KDE (requires the Qt keycodes patch)
https://code.launchpad.net/~debfx/kdelibs/kaction-qt-keys/+merge/13388

unggnu (unggnu) wrote :

Thanks for the fix and it seems to work but it doesn't help in case of the brightness keys because there doesn't seem to be a short cut function in KDE 4 for it or do I miss something?
It is possible to change brightness with the power management applet but it doesn't have a key for it afaik.

Jonathan Thomas (echidnaman) wrote :

That'll need a fix in powerdevil itself to do brightness managing when the brightness button is pressed when the computer hardware itself doesn't do it. I think Felix is working on something to that effect.

unggnu (unggnu) wrote :

I can confirm that the brightness keys and changing brightness are working now in current Karmic.
Many thanks!

SVN commit 1060011 by mjansen:

Add new X11 Qt keys to KKeyServer
=================================

From http://reviewboard.kde.org/r/1950

Patch by Felix Geyer

If some of the bugs are not fixed by this patch please reopen. I couldn't
test most of them because i naturally have all of the keyboards / keys
available.

BUG: 166423
BUG: 180602
BUG: 182349
BUG: 182672
BUG: 183163
BUG: 183583
BUG: 183726
BUG: 192704
BUG: 196570
BUG: 205869
BUG: 212220

CCBUG: 181444
    The sleep button is now supported. Please close if fixed.

ADDED KEYS

XF86XK_AddFavorite 0x1008FF39
XF86XK_ApplicationLeft 0x1008FF50
XF86XK_ApplicationRight 0x1008FF51
XF86XK_AudioCycleTrack 0x1008FF9B
XF86XK_AudioForward 0x1008FF97
XF86XK_AudioRandomPlay 0x1008FF99
XF86XK_AudioRepeat 0x1008FF98
XF86XK_AudioRewind 0x1008FF3E
XF86XK_Away 0x1008FF8D
XF86XK_BackForward 0x1008FF3F
XF86XK_Battery 0x1008FF93
XF86XK_Bluetooth 0x1008FF94
XF86XK_Book 0x1008FF52
XF86XK_BrightnessAdjust 0x1008FF3B
XF86XK_Calculater 0x1008FF54
XF86XK_Calendar 0x1008FF20
XF86XK_CD 0x1008FF53
XF86XK_Clear 0x1008FF55
XF86XK_ClearGrab 0x1008FE21
XF86XK_Close 0x1008FF56
XF86XK_Community 0x1008FF3D
XF86XK_ContrastAdjust 0x1008FF22
XF86XK_Copy 0x1008FF57
XF86XK_Cut 0x1008FF58
XF86XK_Display 0x1008FF59
XF86XK_Documents 0x1008FF5B
XF86XK_DOS 0x1008FF5A
XF86XK_Eject 0x1008FF2C
XF86XK_Excel 0x1008FF5C
XF86XK_Explorer 0x1008FF5D
XF86XK_Finance 0x1008FF3C
XF86XK_Game 0x1008FF5E
XF86XK_Go 0x1008FF5F
XF86XK_Hibernate 0x1008FFA8
XF86XK_History 0x1008FF37
XF86XK_HotLinks 0x1008FF3A
XF86XK_iTouch 0x1008FF60
XF86XK_KbdBrightnessDown 0x1008FF06
XF86XK_KbdBrightnessUp 0x1008FF05
XF86XK_KbdLightOnOff 0x1008FF04
XF86XK_LightBulb 0x1008FF35
XF86XK_LogOff 0x1008FF61
XF86XK_MailForward 0x1008FF90
XF86XK_Market 0x1008FF62
XF86XK_Meeting 0x1008FF63
XF86XK_Memo 0x1008FF1E
XF86XK_MenuKB 0x1008FF65
XF86XK_MenuPB 0x1008FF66
XF86XK_Messenger 0x1008FF8E
XF86XK_MonBrightnessDown 0x1008FF03
XF86XK_MonBrightnessUp 0x1008FF02
XF86XK_Music 0x1008FF92
XF86XK_MySites 0x1008FF67
XF86XK_News 0x1008FF69
XF86XK_OfficeHome 0x1008FF6A
XF86XK_Option 0x1008FF6C
XF86XK_Paste 0x1008FF6D
XF86XK_Phone 0x1008FF6E
XF86XK_Pictures 0x1008FF91
XF86XK_PowerDown 0x1008FF21
XF86XK_PowerOff 0x1008FF2A
XF86XK_Reload 0x1008FF73
XF86XK_Reply 0x1008FF72
XF86XK_RotateWindows 0x1008FF74
XF86XK_RotationKB 0x1008FF76
XF86XK_RotationPB 0x1008FF75
XF86XK_Save 0x1008FF77
XF86XK_ScreenSaver 0x1008FF2D
XF86XK_Select 0x1008FFA0
XF86XK_Send 0x1008FF7B
XF86XK_Shop 0x1008FF36
XF86XK_Sleep 0x1008FF2F
XF86XK_Spell 0x1008FF7C
XF86XK_SplitScreen 0x1008FF7D
XF86XK_Subtitle 0x1008FF9A
XF86XK_Support 0x1008FF7E
XF86XK_Suspend 0x1008FFA7
XF86XK_TaskPane 0x1008FF7F
XF86XK_Terminal 0x1008FF80
XF86XK_Time 0x1008FF9F
XF86XK_ToDoList 0x1008FF1F
XF86XK_Tools 0x1008FF81
XF86XK_TopMenu 0x1008FFA2
XF86XK_Travel 0x1008FF82
XF86XK_UWB 0x1008FF96
XF86XK_Video 0x1008FF87
XF86XK_View 0x1008FFA1
XF86XK_WakeUp 0x1008FF2B
XF86XK_WebCam 0x1008FF8F
XF86XK_WLAN 0x1008FF95
XF86XK_Word 0x1008FF89
XF86XK_WWW 0x1008FF2E
XF86XK_Xfer 0x1008FF8A
XF86XK_ZoomIn 0x1008FF8B
XF86XK_ZoomOut 0x1008FF8C

 M +243 -52 kkeyserver_x11.cpp

WebSVN link: http://websvn.kde.org/?view=rev&revision=1060011

pauls (paulatgm) wrote :

Oddly enough, even with the latest kubuntu kde / qt packages installed, my plain old standard usb media keyboard still has keys that are not recognized. this is very disappointing, after what is now years of waiting....

regards,

Changed in kdelibs:
status: Confirmed → Fix Released
Changed in kdelibs:
importance: Unknown → Medium

I don't know if i should open a new bug, anyway "XF86TouchpadOn" isn't supported.

XF86TouchpadOff is not supported, either.

As stated in comment #32 you should reopen this bug instead of creating a new one about missing keysyms. Unfortunately Qt 4.7.1 does not provide the keys Qt::Key_Touchpad{Toggle,On,Off} so it is not possible to add them to kdelibs. I will reopen this bug until that is fixed.

Changed in kdelibs:
status: Fix Released → Confirmed

Created attachment 58731
Adds TouchpadToggle, TouchpadOn and TouchpadOff keys to qt

Here is a patch to add those keys to Qt. Now we need someone who can apply this patch to Qt.

Upstream bug entry:

http://bugreports.qt.nokia.com/browse/QTBUG-8956

Since that bug is there for almost a year without resolution I think there is little chances for my patch in #36 be applied.

Just thought I'd update something on this old one.

Related (former) Qt Task Tracker bug 230168 mentioned in comment 14 has now been moved to Qt's new bug tracker system and gotten a new ID.

You will now find it at https://bugreports.qt-project.org/browse/QTBUG-2925

Qt5 supports TouchpadToggle, TouchpadOn and TouchpadOff. For those of you using Qt 4.8 you can use http://tsdgeos.blogspot.com/2012/10/ktouchpadenabler-011-released.html as a workaround.

Hi, I would like to add that since a recent update (a few days ago), the fn + volume {up-down-off} have stopped working, as long as the play/stop/previous/next media keys.

I am using KDE 4.10.2 (Qt 4.8.4) on Fedora 18, kernel 3.9.2-200.fc18.x86_64 . my laptop is a Asus X73SV

Additional keys to be added:
Cancel
Find
Redo
Undo
SunProps
SunFront
SunOpen

Why not just add all keys that X supports ?

Can we add XF86AudioMicMute please? Gnome 3 can handle this key.

KeyRelease event, serial 42, synthetic NO, window 0x5600001,
    root 0x95, subw 0x0, time 51921175, (-1110,454), root:(588,477),
    state 0x0, keycode 198 (keysym 0x1008ffb2, XF86AudioMicMute), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

For anyone who stumbles upon this bug in quest of finding a solution to get the keys finally working, there is this utility - xbindkeys, which you can use until this bug gets resolved.

Changed in fedora:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

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