On Fri, Jun 28, 2013 at 11:25 -0700, Dmitry Torokhov wrote: > > On Fri, Jun 28, 2013 at 08:35:42AM -0600, Stephen Warren wrote: > > On 06/28/2013 01:52 AM, Gerhard Sittig wrote: > > > > > > [ late reply, just catching up with the backlog ] > > > > > > On Mon, Jun 24, 2013 at 17:26 -0600, Stephen Warren wrote: > > >> > > >> [ ... sparse matrices, not all columns/rows populated ... ] > > > > >> On some Tegra boards, there end up > > >> being rather tri-angular keymaps, where key positions (0, 0), (0, 1), > > >> (0, 2), (1, 1), (1, 2), (2, 2) end up being used. In this scenario, > > >> detailed investigation of the keymap would reveal: > > >> > > >> * Only scan columns 0..2 > > >> * For column 0, scan rows 0..2 > > >> * For column 1, scan rows 1..2 > > >> * For columm 2, scan row 2. > > > > > > That's another question I had. So far I was concerned with just > > > polling or scanning the relevant columns, while all the rows for > > > a given column were queried (as the driver always used to do). > > > > > > Now you raise the question of whether rows should get queried as > > > well depending on whether "a key may sit there". It wasn't the > > > exact question I raised, but I added a comment to the spot where > > > input subsystem events get generated: Is the driver expected to > > > emit events for matrix positions where no key map entry exists? > > > > I would assume there is no need to, but I don't know for sure. Perhaps > > Dmitry can answer that? > > It really depends whether the driver can absolutely be sure that the key > is not there or if it might be. Because keymaps are configurable from > userspace the driver should not make this decision based on keymap > itself. > > When you scan a matrix and come upon the "pressed key" condition, you > supposed to emit EV_MSC/MSC_SCAN, followed by appropriate EV_KEY/KEY_*. > Normally the "keys that aren't there" generate KEY_RESERVED events that > are simply dropped by input core (cause it is easier to implement). > MSC_SCAN events, however, reach the userspace intact. OK, so I understand that - filtering events based on the keymap entry being present would be inappropriate, the driver MUST emit key press events even if no key code is mapped to that position (especially since keymap entries may get modified at runtime) - it's perfectly appropriate for a driver to assume that _any_ intersection in the matrix _may_ carry a key, and scan for changes on that position, to derive input events (this is what the current implementation of the matrix driver does) - it's an _option_ whether the theoretically possible set of key positions further gets reduced to some "really physically present" and thus "to get scanned only" set, which currently isn't done and isn't mandatory, as in theory absent keys cannot lead to changes and thus should never result in input events So optionally reducing the set of "to get scanned" positions is some kind of micro-optimization (depending on the cost of GPIO access, or in the polling scenario depending on how many columns are empty). My patch did not introduce the filter with new keywords, it just made the existing driver use an existing DT parse routine which scans for already documented properties of the keymap helper. This simple approach assumes that the populated set always is in the range from 0 .. N-1, sparse layouts beyond that simple approach are possible and get processed correctly in the driver, but cannot get described in the device tree. Which still results in non-optimized but correct behaviour. Finer grained control beyond what my patch addresses would be possible but remain an option for later improvement (if desire is big enough to describe non-square layouts or sparse layouts where the gaps are in any arbitrary position). > Hope this helps. Yes, your response answers a question that I raised elsewhere in the form of a TODO comment, that now has become obsolete. I will reword it to not raise the question, but to mention that emitting input events for key positions even in the absence of a key code is not just desirable but actually required. Thank you! virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@xxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
