Bug 879691 - missing handling of "windows" key on Samsung 700T touch screen tablet
missing handling of "windows" key on Samsung 700T touch screen tablet
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-23 12:41 EST by Mads Kiilerich
Modified: 2013-01-19 22:32 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-19 22:32:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lshw and dmesg (101.91 KB, text/plain)
2012-11-23 12:41 EST, Mads Kiilerich
no flags Details

  None (edit)
Description Mads Kiilerich 2012-11-23 12:41:02 EST
Created attachment 650585 [details]
lshw and dmesg

When pressing the windows logo "home" button that is located below the display I get

atkbd serio0: Unknown key pressed (translated set 2, code 0xad on isa0060/serio0).
atkbd serio0: Use 'setkeycodes e02d <keycode>' to make it known.
kernel: atkbd serio0: Unknown key released (translated set 2, code 0xad on isa0060/serio0).
atkbd serio0: Use 'setkeycodes e02d <keycode>' to make it known.

I would expect it was mapped so it worked like a "windows" normal key. It is not obvious to me how that should be done, but I assume it should be done by udev rules and keymaps.

Also, pressing the 'Rotation lock' key found on the right side gives e027 / 0xa7.

systemd-195-7.fc18.i686
kernel-PAE-3.6.7-5.fc18.i686
Comment 1 Jóhann B. Guðmundsson 2012-11-23 13:20:11 EST
This is a kernel problem reassigning...
Comment 2 Lennart Poettering 2012-11-24 17:51:58 EST
(In reply to comment #1)
> This is a kernel problem reassigning...

Not really. Special keys we generally map in userspace using systemd/udev's keymap logic.

i.e. we'd need an entry here:

http://cgit.freedesktop.org/systemd/systemd/tree/keymaps

Plus a match here:

http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/keymap/95-keymap.rules

Mads, we kinda rely on patches for these kind of things since we lack the hw in question. Any chance you could cook something up?
Comment 3 Mads Kiilerich 2012-11-24 19:28:08 EST
Please give some advice:

* a new keymaps/samsung-700t should be introduced?

* what do you recommend matching on? ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="700T" ?

* what is the name of the windows/logo/super in keymaps files?

* same question with 'rotation lock' ... if there is such a concept at all?
Comment 4 Jóhann B. Guðmundsson 2012-11-24 22:18:43 EST
Looking at 95-keymap.rules there is no consistency upstream whether to use files or not since some udev rules there seem to just directly set the keymapping in the udev rule it self. 

What is sorely lacking is a simple tool that does all that for you for users when run ( basically does what http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/keymap/README.keymap.txt suggests )

A) ask the users to press a key and ask the user to select from vendor-specific keys what to map it to

B) creates the necessary udev rule(s) and file(s) and reloads the udev database and asks the users if the key(s) are correctly mapped now

C) Generate a patch and offers the user to submit the changes upstream or attach them on bug report.

Then we should be able to get more of these vendor-specific keymaps upstream and avoiding users from having to create hack unit like this to workaround it

[Unit]
Description=Set vendor specific keys 
After=systemd-user-sessions.service

[Service]
Type=oneshot
ExecStart=/bin/setkeycodes 0xfoo bar
RemainAfterExit=True

[Install]
WantedBy=graphical.target  

Mads if I'm not mistaken the super key a.k.a windows key is actually called leftmeta ( if on the left site ) and rightmeta if on the right side hence a rule like this could work ( if on the left site ) for the windows key I have no idea what rotation lock is.

ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="*700T*", RUN+="keymap $name 0xAD leftmeta"

( I think you can run "udevadm control --reload-rules" to see if it works )
Comment 5 Mads Kiilerich 2012-11-27 13:41:47 EST
(In reply to comment #4)
> ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*",
> ATTR{[dmi/id]product_name}=="*700T*", RUN+="keymap $name 0xAD leftmeta"

Thanks, I confirm that this works as expected.

Adding a keymap file just for one mapping would be overkill, so please just add it to 95-keymap.rules.

The key is a bit slow; it seems like "it" waits 0.5 s before sending the key code. (force_release doesn't help.)
A double click sends 0xDB (leftmeta) 0x0f (tab).
Holding it for 3 s sends 0xDB (leftmeta) 0x20 (d).
That seems like stupid windows-optimized firmware that it probable not is feasible to handle in a sensible way in linux.
Comment 6 Martin Pitt 2012-11-28 15:38:02 EST
(In reply to comment #4)
> Looking at 95-keymap.rules there is no consistency upstream whether to use
> files or not since some udev rules there seem to just directly set the
> keymapping in the udev rule it self.

There is no strict rule, but the convention is that if you need to just change one or two keys on a particular model, use the "inline" form, otherwise a separate key file.

(In reply to comment #5)
> (In reply to comment #4)
> > ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*",
> > ATTR{[dmi/id]product_name}=="*700T*", RUN+="keymap $name 0xAD leftmeta"
> 
> Thanks, I confirm that this works as expected.

Thanks for testing!

I committed this upstream:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=a5dea3d43b3866b48c66d6bef9663cf8372fd96c

And now that I wrote this I failed to supply --author to credit  Jóhann, I'm sorry! (it's getting late...)

> That seems like stupid windows-optimized firmware that it probable not is
> feasible to handle in a sensible way in linux.

Yeah, it's not possible to circumvent this with normal means; some ACPI table hacking might perhaps, but (1) this is over my head, and (2) we can't fix that in systemd.

I cannot change the status in RH bugzilla, so please someone else make the necessary adjustments.
Comment 7 Jóhann B. Guðmundsson 2012-11-28 17:25:20 EST
(In reply to comment #6)
> (In reply to comment #4)
> > Looking at 95-keymap.rules there is no consistency upstream whether to use
> > files or not since some udev rules there seem to just directly set the
> > keymapping in the udev rule it self.
> 
> There is no strict rule, but the convention is that if you need to just
> change one or two keys on a particular model, use the "inline" form,
> otherwise a separate key file.
> 
> (In reply to comment #5)
> > (In reply to comment #4)
> > > ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*",
> > > ATTR{[dmi/id]product_name}=="*700T*", RUN+="keymap $name 0xAD leftmeta"
> > 
> > Thanks, I confirm that this works as expected.
> 
> Thanks for testing!
> 
> I committed this upstream:
> 
> http://cgit.freedesktop.org/systemd/systemd/commit/
> ?id=a5dea3d43b3866b48c66d6bef9663cf8372fd96c
> 
> And now that I wrote this I failed to supply --author to credit  Jóhann, I'm
> sorry! (it's getting late...)

No worries it should not be a problem to revert that commit and resubmit it giving it credit where credit is due...
Comment 8 Fedora Update System 2013-01-14 09:08:32 EST
systemd-197-1.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-0655/systemd-197-1.fc18.1
Comment 9 Fedora Update System 2013-01-19 22:32:14 EST
systemd-197-1.fc18.1 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.