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 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 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
[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