On 05/28/2015 11:48 AM, Lennart Poettering wrote:
On Wed, 27.05.15 15:59, Mario Limonciello ([email protected]) 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.
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
