linux-kernel - Re: [PATCH] Kernel fbcon UNICODE font support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 28 Nov 2010 14:50:49 +0800
From:	microcai <microcai@...oraproject.org>
To:	Samuel Thibault <samuel.thibault@...-lyon.org>,
	microcai <microcai@...oraproject.org>,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>,
	linuxconsole-dev@...ts.sourceforge.net
Subject: Re: [PATCH] Kernel fbcon UNICODE font support

2010/11/27 Samuel Thibault <samuel.thibault@...-lyon.org>:
> Hello,
>
> Microcai, le Fri 26 Nov 2010 13:53:45 +0800, a écrit :
>>  I know there are most people speaking only English, and never meet
>> non-ASCII characters on console. But, hey , what about others ?
>
> Well, you can't deny that there _is_ some support for non-ASCII. But
> just at most 512 glyphs and single width, indeed.
>
>>  The first thing I need to handle is that, currently there is no room
>> for adding UNICODE font, only 8bit for characters, how can you do?
>
> (or 9bit, but no more indeed)
>
>>  Also , some characters are double-width. So the solution is  make an
>> backing store. 0xFE and 0xFF stands for character value store else
>> where, and 0xFF means , left-half of the else where character, and 0xFE
>> means right-half of the else where character.
>>
>>  This is a basic solution, the best is that making vc->vc_screenbuf
>> store full UNICODE/attribute value, But changing it may break some
>> drivers, so , currently I won't try that way.
>
> I'd much prefer the full unicode way, however.  Trying to hack around
> with 0xFE/0xFF will just bring hard-to-fix bugs, while it's quite easy
> to make sure we capture not-up-to-date drivers by changing field names
> for instance.  I'd say we should first do that, and then it'll be
> easy to move the old vgaposition/glyph translation cruft into the few
> drivers that need it.  Yes, this seems to be the hard way.  But that's
> the short-term hard then mid-term easy way, which is way easier to
> accept than the short-term easy then mid/long-term tedious way that you
> propose.
>

I did more work,and found that , VGA console (non framebuffer) realy
need 8bit/8bit attrib/char , because that's how text mode VGA cards
interpreter them. changing to full type will break VGA drivers.
So, I add an u32 * unichars to con_putcs() parameter list, VGA drivers
just ignore that parameter , but fbcon can use it instead of unsigned
short *s as real char value. And allocate an backing store buffer to
store full UNICODE characters.
Also , I delete vc_hi_font_mask, VGA hardware that support 512 font
chars turn to use u32*unichars passed to con_putcs()

Will that acceptable ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/