[systemd-devel] Alienware graphics amplifier scancodes

[Mario Limonciello]

Hi David,

On 06/04/2015 01:31 AM, David Herrmann wrote:
> Hi
>
> On Thu, Jun 4, 2015 at 12:50 AM, Mario Limonciello
> <mario_limonciello at dell.com> 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.