[systemd-devel] Alienware graphics amplifier scancodes

[Mario Limonciello]

On 05/28/2015 11:48 AM, Lennart Poettering wrote:
> On Wed, 27.05.15 15:59, Mario Limonciello (mario_limonciello at dell.com) wrote:
>
> You are aware that the kernel has PCI hotplug support? It sounds
> really weird rebooting the machine due to hotplug events. That's not
> how these things are done...
>
> Are you sure the kernel folks would be happy with a patch that
> chickens out and instead of proper PCI hotplug just always reboots?
>
> Also, why map this to input events at all? If it's really deemed OK to
> do such a weird reboot-on-unplug logic, then this should probably be a
> uevent or so...
>
> But generally, this all appears very questionnable to me...
>
> Lennart
>
Hi Lennart,

Yes, I'm aware that PCI hotplug support is in the kernel.  The kernel 
doesn't panic on the PCIe device being removed from the bus, but the 
graphics driver and X don't continue working.  What should you really do 
then?  You can ask AMD and NVIDIA to fix the drivers and work with the X 
guys to handle the scenario cleanly, but what does that even mean?  You 
can't guarantee that there is another GPU to display things on.  X's 
architecture isn't cut out for GPU's disappearing and reappearing.

If it ends up in the kernel to reboot when the cable is unplugged, I 
don't really care if the event that the cable was unplugged gets relayed 
up to userspace, I was just looking to avoid the unknown keys message in 
dmesg.  It can be mapped to 'unknown' in this scenario.

As for the other two events (cable connect and disconnect button 
notification), these are supposed to be delivered to userspace for that 
app to notify the user what to do to make their hardware work depending 
on what they did.  This might be restarting the graphics server, might 
be installing a new driver from a graphics vendor, might be rebooting.  
It's something that userspace needs to tell someone to do.