Bug 879691

This is a kernel problem reassigning...

(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?

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?

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 )

(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.

(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.

(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...

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

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.