Bug 90689 - [PATCH] Add support for alienware gfx amplifier
Summary: [PATCH] Add support for alienware gfx amplifier
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-28 00:00 UTC by Mario Limonciello
Modified: 2015-06-17 17:01 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
patch adding these keycodes (1.27 KB, text/plain)
2015-05-28 00:00 UTC, Mario Limonciello
Details

Description Mario Limonciello 2015-05-28 00:00:49 UTC
Created attachment 116105 [details]
patch adding these keycodes

Some Alienware notebooks and desktops support an external graphics
housing called the "Alienware Graphics Amplifier". It allows the usage
of a larger or more modern graphics card than your gaming PC would
already support.  In order to provide a good experience, systems that
support it can provide notification to the OS via the scancodes on the
the keyboard controller of events related to the cable.

The following 4 events are supported (and the presumed OS response):
* Cable plugged in (An app on the existing display or terminal would
tell the user to reboot the system to activate)
* Undock cable pressed (An app would let the user know to reboot the
system to complete undock process; also when supported by GFX driver,
driver can clean up and work without a reboot)
* Surprise removal of cable (System reboots).

For the cable plug events I've mapped over to prog1/prog2.  If there is a better option for these, please adjust accordingly.

The surprise removal of the cable causes the GPU drivers to get in a very bad state.  X continues to run,  but plugging the cable back in or restarting X to use a different GPU doesn't fix it.
You can't tell the user to save their game status or anything else useful, so it makes most sense to reboot or shutdown the machine.

I'm submitting a separate patch for the system reboot directly to the kernel via an i8042 filter.  In the event this is running on a kernel without that patch, sending KEY_POWER is the next best thing as it would shutdown if the system DE was configured to do this.
Comment 1 Mario Limonciello 2015-05-28 00:01:45 UTC
#udevadm info /dev/input/event3

P: /devices/platform/i8042/serio0/input/input3/event3
N: input/event3
S: input/by-path/platform-i8042-serio-0-event-kbd
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-0-event-kbd
E: DEVNAME=/dev/input/event3
E: DEVPATH=/devices/platform/i8042/serio0/input/input3/event3
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_PATH=platform-i8042-serio-0
E: ID_PATH_TAG=platform-i8042-serio-0
E: ID_SERIAL=noserial
E: KEYBOARD_KEY_8a=ejectcd
E: KEYBOARD_KEY_bf=!prog1
E: KEYBOARD_KEY_c1=!prog2
E: KEYBOARD_KEY_c2=!power
E: MAJOR=13
E: MINOR=67
E: SUBSYSTEM=input
E: USEC_INITIALIZED=4613
E: XKBLAYOUT=us
E: XKBMODEL=pc105
Comment 2 Lennart Poettering 2015-06-17 17:01:10 UTC
A patch for this has been merged upstream a few days ago.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.