Re: Build failed on latest ELKS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Juan,

Thanks for your explanation. It is clear that C source files should be
only in single-byte ASCII with charcode < 127 to avoid any problem
with the build tools.

My previous question is actually not related to character encoding for
C source files, but rather for the character encoding in the scancode
tables.

When you say " Replacing 'é' wilth '\202'", what exact pagecode with
single bytes are you refering to ? The link you provided has no
reference to any official pagecodes. Should it be IBM 437 or 850,
Windows 1252, IANA 8859-1 ?

This is important to ensure consistency between the character encoding
by the keyboard driver and the character rendering in the display
driver, because glyph bitmaps are indexed on the character code.

One needs this information to fix the tables in keys-*.h.

MFLD




2016-05-18 22:27 GMT+02:00 Juan Perez-Sanchez <lithoxs@xxxxxxxxx>:
> Hello Marc:
>
> You are right. I should say "grep". I guess you will use the
> "keys-be.h" file. The arrays in the
> tables in this file are unsigned char, so you would use 'a', 'b' etc
> for initializers. For nonprinting chars you would use '\xxx', but 0xxx
> works equally well.
>
> The encoding should be plain ascii. See
>
> http://www.cdrummond.qc.ca/cegep/informat/Professeurs/Alain/files/ascii.htm
>
> Here, the first table is "plain ascii". The second table is the
> "extended ascii". The BCC compiler
> ignores the extended ascii chars.
>
> For example, in your case, the fourth char in the first table is 'é'
> and there is a 130 in that position of the file "keys-be.h". Replacing
> 'é' wilth '\202' you use only plain ascii chars.
>
>
> On Wed, May 18, 2016 at 2:37 PM, Marc-F. LUCCA-DANIAU <mfld.fr@xxxxxxxxx> wrote:
>> Hello Juan,
>>
>> Thanks for pointing the previous report.
>>
>> I guess you meant ""grep" does not like it", and octal as "0xxx" in C files,
>> not "\xxx" as in shell.
>>
>> Adding option -a to grep gives a correct Config.in, but one thing stills not
>> clear for me:
>> do you know what is the code page that is supposed to be used to encode the
>> characters in the keys-*.h ?
>>
>> In the IBM PS/2 BIOS TechRef, I see no clue about this encoding, just a
>> Keycode / ASCII table with US keyboard layout.
>>
>> MFLD
>>
>>
>>
>> Le 17/05/2016 22:15, Juan Perez-Sanchez a écrit :
>>>
>>> Hello,
>>>
>>> This problem (with possible workaround) was reported in:
>>>
>>> http://www.spinics.net/lists/linux-8086/msg00675.html
>>>
>>> The problem is that keymap tables use "extended ascii" characters,
>>> this is, codes greater than 127, and current "make" don't like it. For
>>> example, accented a is written as 'á' and should be written as'\341'.
>>>
>>> This include files are C code and should use plain ascii. However,
>>> this is a lot of work.
>>>
>>> Juan
>>>
>>>
>>> On Tue, May 17, 2016 at 7:37 AM, Marc-F. LUCCA-DANIAU <mfld.fr@xxxxxxxxx>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I just took the latest version of ELKS from Jody's GIT master branch, and
>>>> I
>>>> got an issue while building ELKS.
>>>> I am using the "build.sh" script for the newbie I am :-)
>>>>
>>>>
>>>> With default configuration, build fails because the following file is
>>>> malformed:
>>>> /home/mfld/advantech/elks/elks/arch/i86/drivers/char/KeyMaps/keymaps.h:
>>>> /* Automatically created - do not edit */
>>>>
>>>> #include "Fichier"        /* binaire    keys-be.h correspondant */
>>>> #include "Fichier"        /* binaire    keys-de.h correspondant */
>>>> #include "Fichier"        /* binaire    keys-es.h correspondant */
>>>> #include "Fichier"        /* binaire    keys-it.h correspondant */
>>>> #include "Fichier"        /* binaire    keys-se.h correspondant */
>>>> #include "Fichier"        /* binaire    keys-uk.h correspondant */
>>>> #include "keys-dv.h"        /* DV    Dvorak       */
>>>> #include "keys-us.h"        /* US    American     */
>>>>
>>>> (I am using a Gentoo configured in French, so the french strings)
>>>>
>>>>
>>>> This file came from the malformed Config.in:
>>>> # Automatically created - do not edit.
>>>>
>>>> choice 'XT Keyboard support'            \
>>>>      "keys-be.h correspondant    CONFIG_KEYMAP_binaire    \
>>>>       keys-de.h correspondant    CONFIG_KEYMAP_binaire    \
>>>>       keys-es.h correspondant    CONFIG_KEYMAP_binaire    \
>>>>       keys-it.h correspondant    CONFIG_KEYMAP_binaire    \
>>>>       keys-se.h correspondant    CONFIG_KEYMAP_binaire    \
>>>>       keys-uk.h correspondant    CONFIG_KEYMAP_binaire    \
>>>>       Dvorak         CONFIG_KEYMAP_DV    \
>>>>       American       CONFIG_KEYMAP_US"        American
>>>>
>>>> # EOF.
>>>>
>>>>
>>>> Error went away after changing the kernel configuration:
>>>> Select console driver: from <Direct> to <BIOS>
>>>>
>>>>
>>>> I am not at ease with the Config.in generation, any idea here ?
>>>>
>>>> MFLD
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel]     [Linux ia64]     [DCCP]     [Linux for ARM]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux