[kbd] unicode option for not working correctly since commit: bad17ea03

[Felix Janda]

Michal Soltys wrote:
> On 2016-09-20 01:58, Felix Janda wrote:
> > Michal Soltys wrote:
> > [..]
> >> On pre-2.0 versions all will be working fine (or to be precise,
> >> pre-commit I bisected). After that commit some will be failing. If you
> >> do setfont -m 8859-2 - this will provide the workaround.
> > 
> > It might be useful to further bisect: I can see that compilation of
> > dumpkeys will fail directly after commit
> > 
> > http://git.kernel.org/cgit/linux/kernel/git/legion/kbd.git/commit/?id=3fdbff332a6ef88a2447584c47a8616dceb19548
> > 
> > (e.g. because of missing lk_list_charsets). But is it in this situation
> > maybe still possible to directly build loadkeys ("make loadkeys" in the
> > src directory)?
> > 
> 
> The last commit that did compile (where it was working fine) was:
> 
> http://git.kernel.org/cgit/linux/kernel/git/legion/kbd.git/commit/?id=8d37c0e76fdb487845da74bdf0bbce13eebf7596
> 
> (so directly preceeding the one you mentioned)
> 
> And since:
> 
> http://git.kernel.org/cgit/linux/kernel/git/legion/kbd.git/commit/?id=bad17ea033bf571e03b05e1330e81e6238fd61f0
> 
> loadkeys -u have issues

I understand that.

It would just be nice to see more clearly which of the two commits
causes the issue. (I think the compilation failure is unrelated to your
issue.)

So, with the broken commit, does only the compilation of dumpkeys fail
or also something else? If only dumpkeys fails, it should be no problem
to build loadkeys, and you could test if already that commit breaks
loadkeys.

Felix