[systemd-devel] Alienware graphics amplifier scancodes

[David Herrmann]

Hi

On Thu, Jun 4, 2015 at 12:50 AM, Mario Limonciello
<mario_limonciello at dell.com> wrote:
>
>
> On 05/29/2015 04:22 AM, Lennart Poettering wrote:
>>
>> On Thu, 28.05.15 13:53, Mario Limonciello (mario_limonciello at dell.com)
>> wrote:
>>
>>>
>>> On 05/28/2015 01:46 PM, Greg KH wrote:
>>>>>
>>>>> You
>>>>>>
>>>>>> can't guarantee that there is another GPU to display things on.
>>>>
>>>> Yes you can.
>>>
>>> Wait, what?  No, you can't.
>>>
>>> 1) Not everyone has multiple monitors plugged into multiple GPU's.
>>>
>>> 2) The system ships with a dGPU and supports an xGPU.  If you remove the
>>> dGPU from the chassis, all you have is the xGPU.  If you unplug xGPU,
>>> there's nothing left..
>>
>> gdm has multi seat support btw: it will spawn X servers on all seats
>> capable of graphics. if you unplug all graphics cards than this simply
>> means that your number of graphics-capable seats went from > 0 to
>> 0. That's all. And if you plug in a graphics card then, then it goes
>> from 0 to 1 again and you get a fresh new login prompt on it.
>>
>> Lennart
>>
> Lennart,
>
> The kernel bits and discussion around hot unplug aside, can you please add
> support to systemd to map the scan codes?  For the other scenarios such as
> the cable being connected and the disconnect button being pressed userspace
> will need to provide a notification to the user what to do next.  I've added
> the details (and a proposed patch) to bug 90689.  If these are also
> controversial, I'd like to know what else you have in mind.

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

Regarding the PROG1 and PROG2 mappings I cannot see how they are any
better than F21 and F23? Can you elaborate?

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?

Thanks
David