[systemd-devel] Alienware graphics amplifier scancodes
mario_limonciello at dell.com
Thu May 28 11:25:58 PDT 2015
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...
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.
More information about the systemd-devel