Hi David,
On 06/04/2015 01:31 AM, David Herrmann wrote:
Hi
On Thu, Jun 4, 2015 at 12:50 AM, Mario Limonciello
<[email protected]> wrote:
systemd is not really in the business of remapping scancodes. Sure,
the hwdb provides remappings, but this is only to fixup devices that
the kernel cannot fix (usually devices which are handled by generic
drivers).
In your case, you use the serio-input driver, which is also a generic
driver so I wouldn't oppose adding your proposed mappings. However, I
cannot see why your mapping provides any value. You remap F21 / F23 /
F24 to PROG1 / PROG2 / POWER.
The main reason those mappings provide value is that they're then
keycodes that can be recognized by Xorg's evdev driver. X's driver
doesn't recognize codes >255 (see bug 11227). The userspace application
that will notify you how to do to make your Graphics Amplifier work
after you plug it in or hit the undock button will be an Xorg app.
It seems pretty clear from that bug that X won't be fixed, but Wayland
and Mir will be able to handle this sufficiently. We won't be
supporting gaming on Wayland or Mir until the drivers catch up and it
provides a good experience.
The only added value is F24 to POWER
mapping, which might even break systems as KEY_POWER is marked as "SC
System Power Down". Hence, it might get assigned the same behavior as
the system power key.
They are configured to only match the Alienware DMI. Our specs for the
hardware do outline what the scancodes are supposed to be and do.
Per the discussion in this thread, a power down (or reboot) event for
surprise undock is not popular even if it's what our hardware designers
are intending, so I'm mostly concerned with the dock event and the
undock button event as those I can do something with in an X userspace
application.
Regarding the PROG1 and PROG2 mappings I cannot see how they are any
better than F21 and F23? Can you elaborate?
I'm not sure how you were seeing these mapped to keycodes that
correspond to F21/F23/F24. Without the patch they were showing up as
dead scancodes to me that the kernel puts out messages for unknown keys
in dmesg.
Honestly, it doesn't matter to me what keycode they show up as as long
as they show up in xev and don't clash with other things. If it's
possible to get them mapped to F21/F23 and X can pick that up, I'm fine
with that.
I'm not an expert in this area and I don't want to step on toes doing
the wrong thing for mapping the dock and planned-undock scancodes.
Last but not least: Did you try fixing the alienware x86-platform
driver to provide the correct mappings instead of adding a user-space
fixup?
I'm unsure what is a "correct" mapping. These scancodes are what we
have specc'ed out the hardware to interpret. The Windows userspace app
we use does pick up these scancodes to do the right user notification
event and I'm looking to bring parity for that on the Linux side.
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
