Hi Luke, Le Sun, 24 Jul 2016 15:10:24 +0100 Luke Kenneth Casson Leighton <[email protected]> a écrit:
> > But an AZERTY EC firmware will require more than just rewriting the > > key code matrix: for instance, there is no "KEY_&" code, so that > > one will have to be emulated with a "modifier SHIFT + KEY_1" > > combination, and so on for the rest. Nothing unfeasible, mind you, > > or terribly difficult either. It'll just eat up a bit more > > resources than I initially thought it would; my ballpark estimate > > is about 256 added bytes for code plus 128 added bytes for > > read-only data in FLASH, and a few added bytes in RAM. > > hmm is KEY_& specific to azerty? Well, "KEY_&" does not exist, but it represents semantics of KEY_1 which are specific to AZERTY: while for QWERTY, "KEY_1" means "1" when unshifted and "!" when shifted, the same key in AZERTY means "&" when unshifted and "1" when shifted. USB HID has no key code for this; it is emulated at the OS layout level Which leads to a problem with keyboard-level AZERTY support: simply put, it can only be done for AZERTY keys or combinations whose meaning is also that of a USB HID keyboard key code plus possible modifier(s). For instance, a USBHID keyboard can emulate the French "&" by combining modifier "shift" plus key "7", and can emulate the French combination "shift &" by sending key "1" and releasing shift; but, for instance, "ù" cannot be emulated at all, as no QWERTY combination can produce it. It does not even have a key combination. It only appears on my screen because my OS knows that the code for the "quote" key should produce "ù". Note that basic emulation at keyboard level would be enough for the purpose of controlling a bootloader, where accented characters are not that important; suffice that letters, digits and punctuation are produced like an AZERTY user expects them to be. > > BTW: it might be a good idea to provide written instructions for > > people to reconfigure their NUCLEO board for EOMA-68 EC hardware > > compatibility by filling solder bridges SB62 and SB63, and clearing > > SB13, SB14 and SB21. Is there a separate EOMA-68 doc repo somewhere > > where I could put this, or can/should I create > > eoma68/laptop_15in_pcb2/doc/ under the eoma-firmware repo and put > > that info in there, say as a MarkDown format README-NUCLEO.md > > file? > > yeah drop it into the wiki, it's editable. suggest doing a #ifdef > STM32F072_NUCLEO (make -D ST.... option, not in the Makefile or source > code) Ok for "make -DSTM32F072_NUCLEO=1 and letting the Makefile pass that to the compiler (and also conditionally add chain2dfu to the source list). Amicalement, -- Albert. _______________________________________________ arm-netbook mailing list [email protected] http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to [email protected]
