Re: [systemd-devel] Alienware graphics amplifier scancodes
Hi On Thu, Jun 4, 2015 at 9:31 PM, Mario Limonciello mario_limoncie...@dell.com wrote: On 06/04/2015 01:31 AM, David Herrmann wrote: 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? I'm unsure what is a correct mapping. These scancodes are what we have specc'ed out the hardware to interpret. The Windows userspace app we use does pick up these scancodes to do the right user notification event and I'm looking to bring parity for that on the Linux side. As it turns out, the i8042 subsystem does not allow to easily hook into the key-mapping. Can you provide your hwdb entry via github.com/systemd/systemd please? Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Wed, Jun 03, 2015 at 05:43:16PM -0500, Mario Limonciello wrote: Hi Greg, On 05/28/2015 03:30 PM, Greg KH wrote: On Thu, May 28, 2015 at 01:53:57PM -0500, Mario Limonciello 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. True. 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.. And how does other operating systems handle this? Hint, I don't imagine they reboot the box... greg k-h Sorry for taking so long to respond to this, I had clarified with HW marketing the expected experience on Win10 with the graphics amplifier on this hardware. Hot dock and undock is NOT supported. User must reboot for the internal dGPU to be used after a surprise unplug. If the cable was replugged after a surprise unplug there is no expectation that it continues to function. So the user must trigger the reboot, the kernel isn't going to do a shutdown automatically if the device is undocked or cable unplugged. If no other GPUs are on the system (such as dGPU not installed) then the system will need to be turned off and back on. That sounds like some broken hardware, hotplug GPU does work on Windows, if your drivers are written properly :) good luck! greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
Hi On Thu, Jun 4, 2015 at 12:50 AM, Mario Limonciello mario_limoncie...@dell.com wrote: On 05/29/2015 04:22 AM, Lennart Poettering wrote: On Thu, 28.05.15 13:53, Mario Limonciello (mario_limoncie...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
Hi David, On 06/04/2015 01:31 AM, David Herrmann wrote: Hi On Thu, Jun 4, 2015 at 12:50 AM, Mario Limonciello mario_limoncie...@dell.com wrote: 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 main reason those mappings provide value is that they're then keycodes that can be recognized by Xorg's evdev driver. X's driver doesn't recognize codes 255 (see bug 11227). The userspace application that will notify you how to do to make your Graphics Amplifier work after you plug it in or hit the undock button will be an Xorg app. It seems pretty clear from that bug that X won't be fixed, but Wayland and Mir will be able to handle this sufficiently. We won't be supporting gaming on Wayland or Mir until the drivers catch up and it provides a good experience. 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. They are configured to only match the Alienware DMI. Our specs for the hardware do outline what the scancodes are supposed to be and do. Per the discussion in this thread, a power down (or reboot) event for surprise undock is not popular even if it's what our hardware designers are intending, so I'm mostly concerned with the dock event and the undock button event as those I can do something with in an X userspace application. Regarding the PROG1 and PROG2 mappings I cannot see how they are any better than F21 and F23? Can you elaborate? I'm not sure how you were seeing these mapped to keycodes that correspond to F21/F23/F24. Without the patch they were showing up as dead scancodes to me that the kernel puts out messages for unknown keys in dmesg. Honestly, it doesn't matter to me what keycode they show up as as long as they show up in xev and don't clash with other things. If it's possible to get them mapped to F21/F23 and X can pick that up, I'm fine with that. I'm not an expert in this area and I don't want to step on toes doing the wrong thing for mapping the dock and planned-undock scancodes. 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? I'm unsure what is a correct mapping. These scancodes are what we have specc'ed out the hardware to interpret. The Windows userspace app we use does pick up these scancodes to do the right user notification event and I'm looking to bring parity for that on the Linux side. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
Hi Greg, On 05/28/2015 03:30 PM, Greg KH wrote: On Thu, May 28, 2015 at 01:53:57PM -0500, Mario Limonciello 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. True. 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.. And how does other operating systems handle this? Hint, I don't imagine they reboot the box... greg k-h Sorry for taking so long to respond to this, I had clarified with HW marketing the expected experience on Win10 with the graphics amplifier on this hardware. Hot dock and undock is NOT supported. User must reboot for the internal dGPU to be used after a surprise unplug. If the cable was replugged after a surprise unplug there is no expectation that it continues to function. If no other GPUs are on the system (such as dGPU not installed) then the system will need to be turned off and back on. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On 05/29/2015 04:22 AM, Lennart Poettering wrote: On Thu, 28.05.15 13:53, Mario Limonciello (mario_limoncie...@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. Thanks, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Thu, 28.05.15 13:25, Mario Limonciello (mario_limoncie...@dell.com) wrote: On 05/28/2015 11:48 AM, Lennart Poettering wrote: On Wed, 27.05.15 15:59, Mario Limonciello (mario_limoncie...@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? Hotplug graphics cards are not precisely new. This has been supported on Linux just fine for USB graphics cards, and why should PCI be any different? There are many better strategies for handling graphics card unplug than simply rebooting the system. A very simple one that is already vastly better is to simply let X die, and rely on gdm to bring up a new login. A much better one is to use a display server that actually has a sane strategy and can recover from graphics cards coming and going away. That's absolutely noch rocket science. Either way: simply rebooting is a completely weird choice. That's not how things are done on Linux. 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. Of course it is, see the support for USB graphics chips. And even if it wasn't: as long as the X server just dies userspace can still restart it with new gfx config in place. It's just wrong hardcoding your (incorrect) assumptions about supposedly crappy userspace into the kernel. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Thu, 28.05.15 13:53, Mario Limonciello (mario_limoncie...@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 Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Thu, May 28, 2015 at 01:53:57PM -0500, Mario Limonciello 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. True. 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.. And how does other operating systems handle this? Hint, I don't imagine they reboot the box... greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
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.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Thu, May 28, 2015 at 06:48:49PM +0200, Lennart Poettering wrote: On Wed, 27.05.15 15:59, Mario Limonciello (mario_limoncie...@dell.com) wrote: Hi, 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) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). The first three events I think it would make sense to assign to a keycode that a userspace application in X land can pickup and recognize, but I'm at a loss what makes most sense (prog1, prog2, prog3 maybe?). This userspace application hasn't yet been made or decided, I just want to pave the path for it first. The fourth event I'm submitting a kernel patch (https://lkml.org/lkml/2015/5/27/817) so that the kernel would issue a reboot when this was detected, so I believe it would make sense to mark it 'unknown' in systemd. Also, these don't show up in xev output, but they do show up in evtest. Can I get some advice on these? I'll gladly submit a bug with a patch afterward. 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? We are not happy with such a thing at all, I'll go respond to that kernel patch now, this is not an acceptable solution in any way. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On 05/28/2015 11:48 AM, Lennart Poettering wrote: On Wed, 27.05.15 15:59, Mario Limonciello (mario_limoncie...@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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
28.05.2015 01:59, Mario Limonciello wrote: Hi, 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) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). OK, so you have described GPU hotplug in detail. Please note that Alienware is not the only system that has a hot-pluggable GPU. My laptop, Sony VAIO VPC-Z23A4R, manufactured in 2012, also has a similar facility (the AMD GPU, including two additional outputs, is in the docking station), but AFAIK it is not based on scancodes. So maybe it makes sense to unify handling of the Undock buttons on these devices. Feel free to contact me via email or XMPP (same address) so that we can figure out how to make this possible. P.S. Under Windows 7, if the dock station is configured to be used for additional outputs only, it handles both docking and undocking without a reboot. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Thu, May 28, 2015 at 01:25:58PM -0500, Mario Limonciello wrote: 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? Fix the drivers. 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? It means it gets fixed. Why should your hardware be immune from this? I have hardware right here that does this properly, it's been working for many many years, this isn't new at all. You can't guarantee that there is another GPU to display things on. Yes you can. X's architecture isn't cut out for GPU's disappearing and reappearing. Yes it is, this does work. Please fix the drivers, that's the solution. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Alienware graphics amplifier scancodes
On Wed, 27.05.15 15:59, Mario Limonciello (mario_limoncie...@dell.com) wrote: Hi, 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) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). The first three events I think it would make sense to assign to a keycode that a userspace application in X land can pickup and recognize, but I'm at a loss what makes most sense (prog1, prog2, prog3 maybe?). This userspace application hasn't yet been made or decided, I just want to pave the path for it first. The fourth event I'm submitting a kernel patch (https://lkml.org/lkml/2015/5/27/817) so that the kernel would issue a reboot when this was detected, so I believe it would make sense to mark it 'unknown' in systemd. Also, these don't show up in xev output, but they do show up in evtest. Can I get some advice on these? I'll gladly submit a bug with a patch afterward. 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 -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Alienware graphics amplifier scancodes
Hi, 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) * Undock hotkey pressed (Same result as undock cable expected) * Surprise removal of cable (System immediately reboots). The first three events I think it would make sense to assign to a keycode that a userspace application in X land can pickup and recognize, but I'm at a loss what makes most sense (prog1, prog2, prog3 maybe?). This userspace application hasn't yet been made or decided, I just want to pave the path for it first. The fourth event I'm submitting a kernel patch (https://lkml.org/lkml/2015/5/27/817) so that the kernel would issue a reboot when this was detected, so I believe it would make sense to mark it 'unknown' in systemd. Also, these don't show up in xev output, but they do show up in evtest. Can I get some advice on these? I'll gladly submit a bug with a patch afterward. Thanks, -- *Mario Limonciello* *Dell*| EUC SW Dev Engineering ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
