| Summary: | Add mute key of Gigabyte U2442 to the force release list | ||
|---|---|---|---|
| Product: | systemd | Reporter: | phw <ph.wolfer> |
| Component: | general | Assignee: | Zbigniew Jedrzejewski-Szmek <zbyszek> |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | treat GIGABYTE U2442 like i1520M | ||
Created attachment 83637 [details] [review] treat GIGABYTE U2442 like i1520M Does the keyboard work properly with the following patch? (Note that systemd-206 or later is required, since there have been significant changes in the area of keyboard mappings lately.) To test, you can apply the patch to 60-keyboard.hwdb as installed in the filesystem, and do 'udevadm --debug hwdb --update', and reboot. Thanks for the quick response and the patch. I have updated to systemd 206, removed the custom udev rule I had used and followed your instructions. Works as expected. The only thing I noticed that the patch would apply the force release to all the keys mute (0xa0), volume up (0xb0), and volume down (0xae). For my keyboard only the mute key is affected, though, and I had applied the force-release only to that key. Don't know how harmful it is to apply the force-release also to the other two buttons. (In reply to comment #2) > The only thing I noticed that the patch would apply the force release to all > the keys mute (0xa0), volume up (0xb0), and volume down (0xae). For my > keyboard only the mute key is affected, though. I modified the patch to only modify mute. Applied in http://cgit.freedesktop.org/systemd/systemd/commit/?id=0787758. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I have a GIGABYTE U2442 laptop. It's mute key (0xa0) should be added to the force-release list. Other media keys seem to work fine. The laptop can be identified via ATTR{[dmi/id]sys_vendor}=="GIGABYTE", ATTR{[dmi/id]product_name}=="U2442" I don't know how general this issue is and if this could be extended to other models of the same vendor.