Latest working kernel version: 2.6.23.14 Earliest failing kernel version: 2.6.24 Distribution: Archlinux and others Hardware Environment: i386 Software Environment: Console, it does not matter if the console is in UTF8 or non-UTF8 Problem Description: The kernel does not generate a valid compose table Steps to reproduce: Kernel 2.6.23 if we run: dumpkeys --compose-only > file ; vim file compose '´' 'A' to 'Á' compose '´' 'a' to 'á ' etc .... Kernel 2.6.24, if we run: dumpkeys ---compose-only > file ; vim file compose '´' 'A' to 'ÿ' compose '´' 'a' to 'ÿ' compose '´' 'e' to 'ÿ' compose '´' 'i' to 'ÿ' ..... ... etc .... Always --> ÿ With "loadkeys -u us" or "loadkeys -u defkeymap" this problem does not exist. Because us.map.gz include : keymaps 0-2,4-6,8-9,12 alt_is_meta include "qwerty-layout" include "linux-with-alt-and-altgr" include "compose.latin1" <-------------- Compose include "euro1.map" strings as usual ..... But with others keymaps, Eg; "es.map.gz" not include "compose.latin1" use compose the kernel but in kernel 2.6.24 no exist valid compose in the kernel. Thanks.
I think that the problem has begun with this patch: http://lkml.org/lkml/2007/10/18/475
I can confirm the bug, but reading again the source code, I don't see why that should fail: either you left the user map and then conv_uni_to_8bit will assume latin1, or you changed the user map, and conv_uni_to_8bit will follow... I'm digging a bit.
Created attachment 15111 [details] Fix (not tested) Aaargl, stupid signed chars... int c = 'é' produces a negative value... The attached (untested) patch should just work fine.
Ok, thanks!
Ok, tested, it works indeed. Stupid C language... Submitting to appropriate lists & people.
The patch seems to work well for me, Thank you!