diff for duplicates of <4EDFE259.9080201@nvidia.com> diff --git a/a/1.txt b/N1/1.txt index c1da7d8..515fccd 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -24,60 +24,3 @@ Simon, Sorry to keep pushing back on everything so much, but I don't believe the structure of this binding is correct. - ->From a purely HW perspective, the only thing that exists is a single -mapping from (row, col) to keycode. I believe that's all the KBC -driver's binding should define. - -I'll amend that slightly: keyboards commonly implement the Fn key -internally in HW, since it causes keys to emit completely different raw -codes, so I can see this driver wanting both keycode-plain and keycode-fn. - -However, keycode-shift and keycode-ctrl are purely SW concepts. As such, -they shouldn't be part of the KBC's own mapping table. Witness how the -kernel's Tegra KBC driver only contains the plain and fn tables (albeit -merged into a single array for ease of use), and the input core is what -interpets e.g. KEY_LEFTSHIFT as a modifier. - -So specifically what I'd like to see changed in this binding is: - -a) We need binding documentation for the Tegra KBC binding, in the same -style as found in the kernel's Documentation/devicetree/bindings. - -b) The Tegra KBC binding should include only the keycode-plain and -keycode-fn properties; nothing to do with shift/ctrl/alt/.... (Well, -also any standardized properties such as compatible, reg, interrupts). - -c) We need binding documentation for the data that is/could-be common -across multiple keyboards: i.e. what does each key code value represent; -which is KEY_A, KEY_LEFTSHIFT, etc.? These values should be common -across (1) all keyboards (2) some standardized meaning for DT that can -be used by U-Boot, the Linux kernel, etc. Perhaps there is already such -a standard? - -d) Shift/Ctrl/Alt/... modifier mapping tables should be specified by a -separate binding that can be common to any/all keyboards (probably the -same document as (b) above). The input to this table should be the raw -codes from keycode-plain/keycode-fn. The output would be the values sent -to whatever consumes keyboard input. The naming of these properties -should make it obvious that it's something not specific to Tegra's KBC, -and SW oriented. Perhaps something semantically similar to loadkeys' or -xkbcomp's input, although I haven't looked at those in detail. - -Linux probably wouldn't use (d), since it already has its own -SW-oriented methods of setting up such mapping tables. Although perhaps -in the future the default mappings could be set up from these properties. - -U-Boot would need (d), since AIUI, there is no handling of such a higher -layer of mapping tables there right now. - -Initially, the code to parse and implement the mappings in (d) could be -part of the Tegra KBC driver, if there's nowhere else to put it. I -simply want to ensure that the structure of the mapping table bindings -doesn't require them to be specific to Tegra KBC, or perpetually -implemented by the Tegra KBC driver even when/if U-Boot does acquire a -higher layer that deals with this kind of thing. That's because they're -SW concepts not part of the HW/HW-binding. - --- -nvpublic diff --git a/a/content_digest b/N1/content_digest index 99a0c00..9a2c972 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,15 +1,9 @@ "ref\01322881071-11148-1-git-send-email-sjg@chromium.org\0" "ref\01322881071-11148-5-git-send-email-sjg@chromium.org\0" - "ref\01322881071-11148-5-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org\0" - "From\0Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>\0" - "Subject\0Re: [PATCH 4/6] tegra: Add tegra keyboard support\0" + "From\0Stephen Warren <swarren@nvidia.com>\0" + "Subject\0[U-Boot] [PATCH 4/6] tegra: Add tegra keyboard support\0" "Date\0Wed, 07 Dec 2011 15:02:01 -0700\0" - "To\0Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>\0" - "Cc\0U-Boot Mailing List <u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org>" - devicetree-discuss <devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org> - Rakesh Iyer <riyer-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> - Tom Warren <TWarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> - " Albert ARIBAUD <albert.u.boot-LhW3hqR2+23R7s880joybQ@public.gmane.org>\0" + "To\0u-boot@lists.denx.de\0" "\00:1\0" "b\0" "On 12/02/2011 07:57 PM, Simon Glass wrote:\n" @@ -37,63 +31,6 @@ "Simon,\n" "\n" "Sorry to keep pushing back on everything so much, but I don't believe\n" - "the structure of this binding is correct.\n" - "\n" - ">From a purely HW perspective, the only thing that exists is a single\n" - "mapping from (row, col) to keycode. I believe that's all the KBC\n" - "driver's binding should define.\n" - "\n" - "I'll amend that slightly: keyboards commonly implement the Fn key\n" - "internally in HW, since it causes keys to emit completely different raw\n" - "codes, so I can see this driver wanting both keycode-plain and keycode-fn.\n" - "\n" - "However, keycode-shift and keycode-ctrl are purely SW concepts. As such,\n" - "they shouldn't be part of the KBC's own mapping table. Witness how the\n" - "kernel's Tegra KBC driver only contains the plain and fn tables (albeit\n" - "merged into a single array for ease of use), and the input core is what\n" - "interpets e.g. KEY_LEFTSHIFT as a modifier.\n" - "\n" - "So specifically what I'd like to see changed in this binding is:\n" - "\n" - "a) We need binding documentation for the Tegra KBC binding, in the same\n" - "style as found in the kernel's Documentation/devicetree/bindings.\n" - "\n" - "b) The Tegra KBC binding should include only the keycode-plain and\n" - "keycode-fn properties; nothing to do with shift/ctrl/alt/.... (Well,\n" - "also any standardized properties such as compatible, reg, interrupts).\n" - "\n" - "c) We need binding documentation for the data that is/could-be common\n" - "across multiple keyboards: i.e. what does each key code value represent;\n" - "which is KEY_A, KEY_LEFTSHIFT, etc.? These values should be common\n" - "across (1) all keyboards (2) some standardized meaning for DT that can\n" - "be used by U-Boot, the Linux kernel, etc. Perhaps there is already such\n" - "a standard?\n" - "\n" - "d) Shift/Ctrl/Alt/... modifier mapping tables should be specified by a\n" - "separate binding that can be common to any/all keyboards (probably the\n" - "same document as (b) above). The input to this table should be the raw\n" - "codes from keycode-plain/keycode-fn. The output would be the values sent\n" - "to whatever consumes keyboard input. The naming of these properties\n" - "should make it obvious that it's something not specific to Tegra's KBC,\n" - "and SW oriented. Perhaps something semantically similar to loadkeys' or\n" - "xkbcomp's input, although I haven't looked at those in detail.\n" - "\n" - "Linux probably wouldn't use (d), since it already has its own\n" - "SW-oriented methods of setting up such mapping tables. Although perhaps\n" - "in the future the default mappings could be set up from these properties.\n" - "\n" - "U-Boot would need (d), since AIUI, there is no handling of such a higher\n" - "layer of mapping tables there right now.\n" - "\n" - "Initially, the code to parse and implement the mappings in (d) could be\n" - "part of the Tegra KBC driver, if there's nowhere else to put it. I\n" - "simply want to ensure that the structure of the mapping table bindings\n" - "doesn't require them to be specific to Tegra KBC, or perpetually\n" - "implemented by the Tegra KBC driver even when/if U-Boot does acquire a\n" - "higher layer that deals with this kind of thing. That's because they're\n" - "SW concepts not part of the HW/HW-binding.\n" - "\n" - "-- \n" - nvpublic + the structure of this binding is correct. -d357f6733c70a671f23a7599d798718505a74014e68c1a19aa01a2056ea87831 +eca442a202e0d263c43d0d8ae42dd9c1e9e8e914dd185bea8c507e3abac2aea5
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.