On Wed, Oct 22, 2008 at 09:11:08PM +0200, Michael Schutte wrote: > First of all, I’ve been pretty busy lately, so please excuse me for > taking so long to reply.
No problem - happens to me all the time. > On Thu, Sep 25, 2008 at 10:06:30AM +0100, Colin Watson wrote: > > I've attached a patch which fixes the segfault by adding > > bounds-checking. I think this is a clear improvement over what's there > > now. However, it still isn't quite perfect, as there are still clashes > > between valid Unicode characters and special keysyms. For instance, > > U+FC00 ARABIC LIGATURE YEH WITH HAMZA ABOVE WITH JEEM ISOLATED FORM > > (never mind that you probably have only about a snowball's chance in > > hell of that working on the Linux console ...) comes out as KTYP(code) > > == 12 == KT_SLOCK and KVAL(code) == 0, so will be interpreted as SShift. > > Thanks for the patch; I’ve imported it into the Git repo for now. > Still, I’d rather have a deeper look and really fix the problem at its > root. > > > If all of the fake codes were within Unicode's private use range > > E000-F8FF, then I think this would work much better. It seems that this > > would just involve XORing with 0xE000 rather than 0xF000. However, I > > know that the Linux consolemap code interprets 0xF000-0xF0FF as > > "transparent Unicode" that gets mapped directly to font positions, and > > I'm not sure whether kbd relies on this, so I didn't want to just > > crudely substitute 0xE000 for 0xF000 across the board. I'd appreciate > > your advice here. > > This might just work, but I’m not sure I like the idea. I hope, no—I’m > sure there are more elegant solutions :-) Oh, certainly; I knew my patch and ideas were both imperfect. Actually, thinking about it, you ought to have 16 more bits to play with, and IIRC XKB uses 0x01000000. That's a bit of a hack too but perhaps a rather safer one! Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
