You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(104) |
Sep
(68) |
Oct
(71) |
Nov
(9) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(14) |
Feb
(67) |
Mar
(50) |
Apr
(8) |
May
(39) |
Jun
(15) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(1) |
2003 |
Jan
|
Feb
(5) |
Mar
|
Apr
(4) |
May
(2) |
Jun
(18) |
Jul
(5) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(11) |
2004 |
Jan
(1) |
Feb
(5) |
Mar
(6) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2005 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(3) |
May
(7) |
Jun
(6) |
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
From: qxty <ec...@ya...> - 2008-09-08 07:30:52
|
1. Linux machine do not have X-Windows like servers, mobile phone, embed device 2. Domain's initial message, warnning and errors 3. System first setup, like Ubuntu, Arch 4. System configuration before X-Windows qxty 2008-09-08 发件人: Hawk 发送时间: 2008-09-08 15:06:26 收件人: qxty 抄送: zhcon-devel 主题: Re:[Zhcon-devel] Anyone interesting push chinese support in kernel Although I haven't read the document/codes you mentioned but I think this is a very good idea. Before we do such thing, can you or someone else tell me whether there is any application need for kernel support CJK? I will try to use my spare time to do some pre-study. But I can't promise the time I can spend on such things. 在2008-09-08,qxty <ec...@ya...> 写道: After read new kernel patches by http://zdbr.net.cn/download/utf8-kernel-2.6.25-core-1.patch.bz2 http://zdbr.net.cn/download/utf8-kernel-2.6.22.5-fonts-1.patch.bz2 It seems new kernel support CJK very good compared with 2.4.18/20. The only problem is font reading. Now GPL CJK pcf font called wenquanyi is ready, jfbterm's function can read pcf font. The future work should be how to read pcf font into kernel. "setfont" maybe a good example which how to do it. setfont is part of package kbd. It read psf font and put them in kernel. Our target should not be limited in CJK font display only. We may call it as "Big fontset support in linux kernel". ----------------------- Hu Yong 买房不必东奔西走,上房老大,看"二手房"网上房展会 |
From: Hawk <you...@16...> - 2008-09-08 07:06:13
|
Although I haven't read the document/codes you mentioned but I think this is a very good idea. Before we do such thing, can you or someone else tell me whether there is any application need for kernel support CJK? I will try to use my spare time to do some pre-study. But I can't promise the time I can spend on such things. 在2008-09-08,qxty <ec...@ya...> 写道: After read new kernel patches by http://zdbr.net.cn/download/utf8-kernel-2.6.25-core-1.patch.bz2 http://zdbr.net.cn/download/utf8-kernel-2.6.22.5-fonts-1.patch.bz2 It seems new kernel support CJK very good compared with 2.4.18/20. The only problem is font reading. Now GPL CJK pcf font called wenquanyi is ready, jfbterm's function can read pcf font. The future work should be how to read pcf font into kernel. "setfont" maybe a good example which how to do it. setfont is part of package kbd. It read psf font and put them in kernel. Our target should not be limited in CJK font display only. We may call it as "Big fontset support in linux kernel". ----------------------- Hu Yong |
From: qxty <ec...@ya...> - 2008-09-08 02:22:08
|
After read new kernel patches by http://zdbr.net.cn/download/utf8-kernel-2.6.25-core-1.patch.bz2 http://zdbr.net.cn/download/utf8-kernel-2.6.22.5-fonts-1.patch.bz2 It seems new kernel support CJK very good compared with 2.4.18/20. The only problem is font reading. Now GPL CJK pcf font called wenquanyi is ready, jfbterm's function can read pcf font. The future work should be how to read pcf font into kernel. "setfont" maybe a good example which how to do it. setfont is part of package kbd. It read psf font and put them in kernel. Our target should not be limited in CJK font display only. We may call it as "Big fontset support in linux kernel". ----------------------- Hu Yong |
From: Sunry C. <sun...@gm...> - 2007-11-06 07:03:23
|
$uname -a FreeBSD www.525183.com 6.2-STABLE FreeBSD 6.2-STABLE #8: Tue Sep 18 23:01:05 CST 2007 hp...@ww...:/usr/obj/usr/src/sys/MYKERNEL i386 PORTNAME= zhcon PORTVERSION= 0.2.5 PORTREVISION= 1 It caused segmentation fault while trying to run it. In my box it works if I change the zhcon.conf's setting about resolution from: x_resolution = 640 y_resolution = 480 color_depth = 4 to: x_resolution = 800 y_resolution = 600 color_depth = 4 while I saw the source code has updated to 0.2.6 |
From: <you...@16...> - 2007-08-12 15:07:43
|
[Send again, include zhc...@li...] Hi ejoy and ccpaging, I found a bug of Zhcon. When Zhcon uses framebuffer driver on direct color graphic card, it can't display color correctly, especially in 32bit mode. The reason is because Zhcon treat always colors as "true color" that are combined as R,G and B directly. However, in direct color mode, the R,G and B value send to the framebuffer driver is just the index to the color map. For example, in 32bit mode, if you want to use pure red as 0xff0000, it is correct in "true color" mode. However, for the graphic card as as ATI Radeon, they use "direct color" mechanism, the real color will be: red=red_color_map[0xff], blue=blue_color_map[0x00], green=green_color_map[0x00]. If the color_map is not correctly initialized, the real color will not be pure red. Hence there is two key steps must be taken: when initializing the framebuffer object, the 3 color maps should be correct initialized as: X_color_map[i]=i|i<<8, where X is red, green or blue. I have written a patch for 32bit direct color mode, as attachment. But the patch doesn't include the support of 16bit and 8bit direct mode. However the basic idea is the same. Please feel free to contac me if u have any question. BTW, I don't know whether this mail list can have attachment, so I list the content of the patch at the end of the email. Thanks & Regards, Hawk diff -Naur zhcon-0.2.6/src/display/fbdev.cpp zhcon-0.2.7/src/display/fbdev.cpp --- zhcon-0.2.6/src/display/fbdev.cpp 2007-06-19 09:34:37.000000000 +0800 +++ zhcon-0.2.7/src/display/fbdev.cpp 2007-08-05 00:44:33.000000000 +0800 @@ -26,6 +26,9 @@ #include <sys/ioctl.h> #include <sys/mman.h> #include <assert.h> +#include <linux/fb.h> + +#include <errno.h> #include "fbdev.h" #include "fblinear4.h" @@ -43,6 +46,10 @@ int FBDev::mpBufLen = 0; // FrameBuffer file handle int FBDev::mFd = -1; +struct fb_cmap *FBDev::cmap =NULL; +struct fb_cmap *FBDev::cmap_orig =NULL; +struct fb_fix_screeninfo FBDev::Finfo; +struct fb_var_screeninfo FBDev::Vinfo; unsigned long FBDev::mNextLine = 0; unsigned long FBDev::mNextPlane = 0; int FBDev::mCurrentMode = 0; @@ -59,7 +66,6 @@ 0x0000, 0xaaaa, 0x0000, 0xaaaa, 0x0000, 0xaaaa, 0x0000, 0xaaaa, 0x5555, 0xffff, 0x5555, 0xffff, 0x5555, 0xffff, 0x5555, 0xffff }; - #if defined(linux) #include <linux/fb.h> #define MAX_DEV_LEN 63 @@ -84,10 +90,22 @@ } rc = NORMAL; - static struct fb_fix_screeninfo Finfo; - static struct fb_var_screeninfo Vinfo; ioctl(mFd, FBIOGET_FSCREENINFO, &Finfo); ioctl(mFd, FBIOGET_VSCREENINFO, &Vinfo); + //In direct color mode, begin to create cmap, and its backup cmap_orig + if (Finfo.visual==FB_VISUAL_DIRECTCOLOR) + { + if ((cmap_orig=CreateCMAP())==(struct fb_cmap *)-1) + { + throw(runtime_error("Can't create color map")); + return FAILURE; + } + if ((cmap=CreateCMAP())==(struct fb_cmap *)-1) + { + throw(runtime_error("Can't create color map")); + return FAILURE; + } + } switch (Finfo.type) { case FB_TYPE_PACKED_PIXELS: // truecolor packed pixels rc = LinearSet(Vinfo); @@ -269,6 +287,13 @@ } FBDev::~FBDev() { + if (cmap) + fb_cmap_destroy(cmap); + if (cmap_orig) + { + ioctl(mFd,FBIOPUTCMAP, cmap_orig); + fb_cmap_destroy(cmap_orig); + } if (mpBuf != NULL) munmap(mpBuf, mpBufLen); if (mFd >= 0) @@ -292,4 +317,169 @@ #endif } +struct fb_cmap * FBDev::CreateCMAP(void) +{ + struct fb_cmap *pcmap=NULL; + int pcmaplen=256; + + /* check the existence of colormap */ + if (Finfo.visual == FB_VISUAL_MONO01 || + Finfo.visual == FB_VISUAL_MONO10 || + Finfo.visual == FB_VISUAL_TRUECOLOR) + return NULL; + + pcmap = (struct fb_cmap *)malloc(sizeof(struct fb_cmap)); + if (!pcmap) { + throw(runtime_error("pcmap malloc error\n")); + return (struct fb_cmap *)-1; + } + memset(pcmap, 0, sizeof(struct fb_cmap)); + + /* Allocates memory for a colormap */ + if (Vinfo.red.length) { + pcmap->red = (__u16 *) malloc(sizeof(__u16) * pcmaplen); + if (!pcmap->red) { + throw(runtime_error("red lut malloc error\n")); + return (struct fb_cmap *)-1; + } + } + if (Vinfo.green.length) { + pcmap->green = (__u16 *) malloc(sizeof(__u16) * pcmaplen); + if (!pcmap->green) { + if (Vinfo.red.length) + free(pcmap->red); + throw(runtime_error("green lut malloc error\n")); + return (struct fb_cmap *)-1; + } + } + if (Vinfo.blue.length) { + pcmap->blue = (__u16 *) malloc(sizeof(__u16) * pcmaplen); + if (!pcmap->blue) { + if (Vinfo.red.length) + free(pcmap->red); + if (Vinfo.green.length) + free(pcmap->green); + throw(runtime_error("blue lut malloc error\n")); + return (struct fb_cmap *)-1; + } + } + if (Vinfo.transp.length) { + pcmap->transp = (__u16 *) malloc(sizeof(__u16) * pcmaplen); + if (!pcmap->transp) { + if (Vinfo.red.length) + free(pcmap->red); + if (Vinfo.green.length) + free(pcmap->green); + if (Vinfo.blue.length) + free(pcmap->blue); + throw(runtime_error("transp lut malloc error\n")); + return (struct fb_cmap *)-1; + } + } + pcmap->len = pcmaplen; + if (ioctl(mFd, FBIOGETCMAP, pcmap)) { + throw(runtime_error(strerror(errno))); + fb_cmap_destroy(pcmap); + return (struct fb_cmap *)-1; + } + return pcmap; +} + +int FBDev::CopyCMAP(struct fb_cmap *cmap_dest, struct fb_cmap *cmap_src) +{ + int cmaplen=256; + + if ((!cmap_dest) || (!cmap_src)) + { + throw("Invalid Argument"); + return -1; + } + + if ((!cmap_src->red) && (cmap_dest->red)) + { + free(cmap_dest->red); + cmap_dest->red=NULL; + } + else if (cmap_src->red) + { + if (!cmap_dest->red) + { + if ((cmap_dest->red=(__u16 *)malloc(sizeof(__u16)*cmaplen))==NULL) + { + throw(runtime_error("Failed to malloc red lut!")); + return -1; + } + } + memcpy((__u8 *)cmap_dest->red,(__u8 *)cmap_src->red, sizeof(__u16)*cmaplen); + } + + if ((!cmap_src->green) && (cmap_dest->green)) + { + free(cmap_dest->green); + cmap_dest->green=NULL; + } + else if (cmap_src->green) + { + if (!cmap_dest->green) + { + if ((cmap_dest->green=(__u16 *)malloc(sizeof(__u16)*cmaplen))==NULL) + { + throw(runtime_error("Failed to malloc green lut!")); + return -1; + } + } + memcpy((__u8 *)cmap_dest->green,(__u8 *)cmap_src->green, sizeof(__u16)*cmaplen); + } + + if ((!cmap_src->blue) && (cmap_dest->blue)) + { + free(cmap_dest->blue); + cmap_dest->blue=NULL; + } + else if (cmap_src->blue) + { + if (!cmap_dest->blue) + { + if ((cmap_dest->blue=(__u16 *)malloc(sizeof(__u16)*cmaplen))==NULL) + { + throw(runtime_error("Failed to malloc blue lut!")); + return -1; + } + } + memcpy((__u8 *)cmap_dest->blue,(__u8 *)cmap_src->blue, sizeof(__u16)*cmaplen); + } + if ((!cmap_src->transp) && (cmap_dest->transp)) + { + free(cmap_dest->transp); + cmap_dest->transp=NULL; + } + else if (cmap_src->transp) + { + if (!cmap_dest->transp) + { + if ((cmap_dest->transp=(__u16 *)malloc(sizeof(__u16)*cmaplen))==NULL) + { + throw(runtime_error("Failed to malloc transp lut!")); + return -1; + } + } + memcpy((__u8 *)cmap_dest->transp,(__u8 *)cmap_src->transp, sizeof(__u16)*cmaplen); + } + cmap_dest->start=cmap_src->start; + cmap_dest->len=cmap_src->len; + return 0; +} + +void FBDev::fb_cmap_destroy(struct fb_cmap *cmap) +{ + if (cmap->red) + free(cmap->red); + if (cmap->green) + free(cmap->green); + if (cmap->blue) + free(cmap->blue); + if (cmap->transp) + free(cmap->transp); + free(cmap); +} diff -Naur zhcon-0.2.6/src/display/fbdev.h zhcon-0.2.7/src/display/fbdev.h --- zhcon-0.2.6/src/display/fbdev.h 2007-06-19 09:34:37.000000000 +0800 +++ zhcon-0.2.7/src/display/fbdev.h 2007-08-04 15:45:18.000000000 +0800 @@ -43,6 +43,9 @@ static OPEN_RC LinearSet( struct fb_var_screeninfo &Vinfo ); static void VGAPlaneSet( void ); static int mCurrentMode; // for FreeBSD + static struct fb_cmap * CreateCMAP(void); + static int CopyCMAP(struct fb_cmap *cmap_dest, struct fb_cmap *cmap_src); + static void fb_cmap_destroy(struct fb_cmap *cmap); protected: // mmap framebuffer address @@ -54,6 +57,10 @@ // FrameBuffer file handle static int mFd; static __u16 red16[],green16[],blue16[]; + static struct fb_fix_screeninfo Finfo; + static struct fb_var_screeninfo Vinfo; + static struct fb_cmap * cmap; + static struct fb_cmap * cmap_orig; }; #endif diff -Naur zhcon-0.2.6/src/display/fblinear32.cpp zhcon-0.2.7/src/display/fblinear32.cpp --- zhcon-0.2.6/src/display/fblinear32.cpp 2007-06-19 09:34:37.000000000 +0800 +++ zhcon-0.2.7/src/display/fblinear32.cpp 2007-08-04 16:36:23.000000000 +0800 @@ -20,6 +20,8 @@ #include <assert.h> #include "global.h" #include "fblinear32.h" +#include <linux/fb.h> +#include <sys/ioctl.h> FBLinear32::FBLinear32() { InitColorMap(); @@ -29,6 +31,20 @@ void FBLinear32::InitColorMap() { int i; __u32 red, green, blue; + + //Firstly we initialize the frame buffer's color map + if (cmap) + { + for (__u32 loop=0;loop<256;loop++) + { + cmap->red[loop]=cmap->green[loop]=cmap->blue[loop]=(loop|loop<<8); + } + if (ioctl(mFd, FBIOPUTCMAP, cmap)) + { + throw(runtime_error("Can't initialize the framebuffer's 32 bits color map.")); + } + } + // Then zhcon's color map for(i = 0; i < 16; i++) { red = red16[i]; green = green16[i]; |
From: chen c. <by...@gm...> - 2007-05-21 13:45:28
|
T2gsIHNvcnJ5LCBpbiB0aGUgY29kZSBpdCdzICIjaWZuZGVmIEhBVkVfR0dJX0xJQiIsIEkgbWlz dGFrZW4KIiNpZm5kZWYiIGZvciAiI2lmZGVmIi4KCkknbGwgdHJ5IHRvIGZpbmQgdGhlIHJlYXNv bi4uLgoKLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCkZyb206IGNoZW4g Y2hvbmcgPGJ5cmJ6ZGxAZ21haWwuY29tPgpEYXRlOiAyMDA3LTUtMjEgz8LO5zk6MzIKU3ViamVj dDogW1poY29uLWRldmVsXUFib3V0IGZhaWx1cmUgb2Ygemhjb24gdW5kZXIgWC13aW5kb3csIHdp dGggR0dJIHN1cHBvcnQKVG86IHpoY29uLWRldmVsQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAoKCldp dGggIlpoYW5nIExlIidzIGd1aWRhbmNlLCBJIHRyaWVkIHRvIHJ1biB6aGNvbiB1bmRlciBYLXdp bmRvdy4gIEF0CmZpcnN0LCBpdCBwcmludCB0aGUgZm9sbG93aW5nIG1lc3NhZ2U6Ci0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnJvb3RAdWJ1bnR1On4vemhjb24vc3Jj IyAuL3poY29uIC0tZHJ2PWdnaQp3YXJuaW5nISEhCi9kZXYvcHRzLzAgaXMgbm90IHJlYWwgdHR5 IG9yIHZjLCBhcmUgeW91ciBydW5uaW5nIHVuZGVyIFgtV2luZG93PwpsaWJnZ2kgc3VwcG9ydCBu b3QgY29tcGxpZWQgaW4sIGNhbiBub3QgcnVuIHVuZGVyIFgtV2luZG93LCBub3cgcXVpdAotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKVGhlbiBJIGluc3RhbGxlZCBh bGwgbGliZ2dpIHJlbGF0ZWQgcGFja2FnZXMsIGFuZCBkbwoiY29uZmlndXJlL21ha2UvbWFrZSBp bnN0YWxsIiBhIHNlY29uZCB0aW1lLCB0aGUgZm9sbG93aW5nIGlzIHRoZQpjb25maWd1cmUgcmVz dWx0OgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDb25maWd1cmF0 aW9uOgogICBUYXJnZXQgc3lzdGVtOiAgICAgICAgICAgICBpNjg2LXBjLWxpbnV4LWdudQogICBT b3VyY2UgY29kZSBsb2NhdGlvbjogICAgICAuCiAgIEMrKyBDb21waWxlcjogICAgICAgICAgICAg IGcrKwogICBDKysgQ29tcGlsZXIgZmxhZ3M6ICAgICAgICAgLWZ1bnNpZ25lZC1jaGFyIC1PMiAt bWFyY2g9aTY4NiAtRE5ERUJVRyAtV2FsbAogICBDICAgQ29tcGlsZXI6ICAgICAgICAgICAgICBn Y2MKICAgQyAgIENvbXBpbGVyIGZsYWdzOiAgICAgICAgIC1mdW5zaWduZWQtY2hhciAtTzIgLW1h cmNoPWk2ODYgLUROREVCVUcgLVdhbGwKICAgVkdBIHN1cHBvcnQ6ICAgICAgICAgICAgICAgeWVz CiAgIGdwbSBtb3VlcyBzdXBwb3J0OiAgICAgICAgIHllcwogICBsaWJnZ2kgc3VwcG9ydDogICAg ICAgICAgICB5ZXMKICAgdW5pY29uIHN1cHBvcnQ6ICAgICAgICAgICAgbm8KICAgemhjb24gYmlu YXJ5IGRpcjogICAgICAgICAgL3Vzci9sb2NhbC9iaW4KICAgemhjb24gZmlsZXMgZGlyOiAgICAg ICAgICAgL3Vzci9sb2NhbC9saWIvemhjb24KCkNvbmZpZyBjb21wbGV0ZSwgbm93IHR5cGUgbWFr ZSB0byBidWlsZCB6aGNvbi4KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCiBIb3dldmVyLCBpdCBmYWlsZWQgYWdhaW4gdW5kZXIgWC13aW5kb3csIHdpdGggdGhlIHNh bWUgZXJyb3IgbWVzc2FnZS4KVGhlbiBJIGNoZWNrZWQgdGhlIGNvZGUsIGFuZCBmb3VuZCB0aGUg Zm9sbG93aW5nIGNvZGUgaW4gdm9pZCBaaGNvbjo6SW5pdFR0eSgpOgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICBpZiAoIShzdHJuY21wKCIvZGV2L3R0eSIsIFR0 eU5hbWUsIDgpID09IDAgfHwKICAgICAgIHN0cm5jbXAoIi9kZXYvdmMvIiwgVHR5TmFtZSwgOCkg PT0gMCkpIHsKICAgICAgIGZwcmludGYoc3RkZXJyLCAid2FybmluZyEhIVxuIik7CiAgICAgICBm cHJpbnRmKHN0ZGVyciwgIiVzIGlzIG5vdCByZWFsIHR0eSBvciB2YywgYXJlIHlvdXIgcnVubmlu Zwp1bmRlciBYLVdpbmRvdz9cbiIsIFR0eU5hbWUpOwojaWZuZGVmIEhBVkVfR0dJX0xJQgogICAg ICAgZnByaW50ZihzdGRlcnIsICJsaWJnZ2kgc3VwcG9ydCBub3QgY29tcGxpZWQgaW4sIGNhbiBu b3QgcnVuCnVuZGVyIFgtV2luZG93LCBub3cgcXVpdFxuIik7CiAgICAgICBleGl0KDEpOwojZW5k aWYKICAgfQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKSGVyZSBJ IGhhdmUgYSBxdWVzdGlvbjoKCklzIHR0eS92YyBib3RoIGNvbmNlcHRzIG9mICB0dHktZW52aXJv bm1lbnQgKGNvbW1hbmQpLCBhbmQgb25seSBwdHkgaXMKcmVsYXRlZCB3aXRoIFgtd2luZG93PwoK SWYgeWVzLCB0aGVuIGZvciB0aGVzZSBjb2RlLCBob3cgd2UgY2FuIHVzZSBHR0kgdG8gc3VwcG9y dCBYLXdpbmRvdz8KSWYgbm8sIHRoZW4gd2hhdCBjYW4gYmUgdGhlIHJlYXNvbiB0aGF0IEkgY2Fu IG5vdCBydW4gemhjb24Kc3VjY2Vzc2Z1bGx5IHVuZGVyIFgtd2luZG93PwoKCgpTb3JyeSwgSSdt IHN0aWxsIG5vdCB2ZXJ5IGNsZWFyIHdpdGggdGhlc2UgY29uY2VwdHMuCg== |
From: chen c. <by...@gm...> - 2007-05-21 13:32:37
|
With "Zhang Le"'s guidance, I tried to run zhcon under X-window. At first, it print the following message: -------------------------------------------------------------------------------------------------- root@ubuntu:~/zhcon/src# ./zhcon --drv=ggi warning!!! /dev/pts/0 is not real tty or vc, are your running under X-Window? libggi support not complied in, can not run under X-Window, now quit -------------------------------------------------------------------------------------------------- Then I installed all libggi related packages, and do "configure/make/make install" a second time, the following is the configure result: -------------------------------------------------------------------------------------------------- Configuration: Target system: i686-pc-linux-gnu Source code location: . C++ Compiler: g++ C++ Compiler flags: -funsigned-char -O2 -march=i686 -DNDEBUG -Wall C Compiler: gcc C Compiler flags: -funsigned-char -O2 -march=i686 -DNDEBUG -Wall VGA support: yes gpm moues support: yes libggi support: yes unicon support: no zhcon binary dir: /usr/local/bin zhcon files dir: /usr/local/lib/zhcon Config complete, now type make to build zhcon. -------------------------------------------------------------------------------------------------- However, it failed again under X-window, with the same error message. Then I checked the code, and found the following code in void Zhcon::InitTty(): -------------------------------------------------------------------------------------------------- if (!(strncmp("/dev/tty", TtyName, 8) == 0 || strncmp("/dev/vc/", TtyName, 8) == 0)) { fprintf(stderr, "warning!!!\n"); fprintf(stderr, "%s is not real tty or vc, are your running under X-Window?\n", TtyName); #ifndef HAVE_GGI_LIB fprintf(stderr, "libggi support not complied in, can not run under X-Window, now quit\n"); exit(1); #endif } -------------------------------------------------------------------------------------------------- Here I have a question: Is tty/vc both concepts of tty-environment (command), and only pty is related with X-window? If yes, then for these code, how we can use GGI to support X-window? If no, then what can be the reason that I can not run zhcon successfully under X-window? Sorry, I'm still not very clear with these concepts. |
From: Zhang L. <zha...@gm...> - 2007-05-18 08:45:11
|
Hi, Thanks for you interest. zhcon can run under X-window via GGI now. Actually that's how I debug it in the last couple of release. But the color is a bit off and you have to input in another window. It'll be very cool if you can try porting it using SDL, which I believe will not be a too difficult task. You may want to implement some drawing function and screen init function using SDL. The GGI part written by Hu Yong can help you a lot. Many thanks, Zhang Le On 18/05/07, chen chong <by...@gm...> wrote: > These days, I have been searching on how Chinese works on Linux. > After read Zhocn code, now I think I have know its architecture. I > want to port Zhcon to X-window, using SDL, just as the TODO text said, > do you have any suggestions? > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Zhcon-devel mailing list > Zhc...@li... > https://lists.sourceforge.net/lists/listinfo/zhcon-devel > |
From: chen c. <by...@gm...> - 2007-05-18 08:41:17
|
These days, I have been searching on how Chinese works on Linux. After read Zhocn code, now I think I have know its architecture. I want to port Zhcon to X-window, using SDL, just as the TODO text said, do you have any suggestions? |
From: Hu Y. <ec...@ho...> - 2007-01-09 09:16:32
|
I should check the patch and try to merge it into. > Although zhcon support utf8 display, I found zhcon still use CJK as default > internal encodings. It seems a problem to font render and input method > porting. This is the big problem. Now the tty code(utf8) -> native code -> font code(utf8). But the modify may effect too many program, it should be consider carefully. ----- Original Message ----- From: Mat <mat...@gm...> To: zhc...@li... Cc: HuYong <hy...@ec...> Date: Tue, 9 Jan 2007 07:13:32 +0000 Subject: Re: [Zhcon-devel] IME support and PCF font > Dear zhcon's developers: > I have got pcf font a go. > This attachment is the screenshot for it. > And the patched source code is here: > > > http://wiki.tossug.org/UnicodeConsole?action=AttachFile&do=get&target=zhcon-patch.tar.gz > The wiki here are also welcome to you all: > http://wiki.tossug.org/UnicodeConsole > > Notes: > 1. I hacked the "big5decoder.cpp" to convert codes to unicode manually. > just for a short term test. (gb2312 is not changed.) > 2. I create "FT2Font" as a child intance of "Basefont", and use it to > substitude > the original DblFont... > 3. I found some bug in the fblinear16.cpp ( fblinear**.cpp, too) > "cdat++" can not guranteed to be the head of the next row. > > PCF fonts( in uncompressed format!! ) render good in my machine, even > it was processed via freetype. In my machine, the render speed is almost as > fast as PSF font, in 800x600 mode. > > Although zhcon support utf8 display, I found zhcon still use CJK as default > internal encodings. It seems a problem to font render and input method > porting. > > sincerely, Mat. > > On 1/8/07, Mat <mat...@gm...> wrote: > > > > Thank your for your reply, the infomation is really useful. > > > > On 1/8/07, HuYong < hy...@ec...> wrote: > > > > > > It is really the good news. > > > 1. Consider the situation of users, CJK console often used in some > > > system's modify and configuration, also may used in looking manual and > help. > > > So we always keep zhcon's input method simple, easy supplement, rapid > > > respone with low cost cpu and memory. > > > > > > 2. The unicon input method used zhcon before, seems die. Those extern > > > input method always make more problem when compile zhcon project. So if > > > you want feedback new input method as library, we recommand you use > open and > > > load library style. This way avoids most compile problems. As the > result, we > > > can use same method to load other input method used in zhcon before. > > > > > Do you mean to create an instance of InputServer with UCIMF? > > Or is there any formal input method API I can follow? > > > > btw, UCIMF is implemented as shared library, and IIIMF, OpenVanilla > > supports are implemented as dynamic loaded modules. I guess, it would not > be > > too difficult to port. > > > > UCIMF take about 1MB memory while excution, due to PCF font storage and > > modules it loads. It current run well on my i486 machine( that > > is,...Thinkpad 560X ). > > I will try to port first, and shrink it later when go further. > > > > > > 3. I want to use utf8 as native code in zhcon, but this needs much work. > > > This modify can solve some problem in zhcon, like half code of Japanese, > > > and so. > > > > > Great :-) > > > > I have built zhcon (svn version), and try to use it to connect IRC and > > also read some text. > > I found that LC_CTYPE is bound to be zh_CN.UTF-8. > > Some text can not be correctly displayed, especially with Traditional > > Chinese text. Due to lack of font? I guess :-o > > But it's really exciting to see UTF-8 in zhcon , I would like to help to > > make it better :-) > > > > 4. If we support pcf, zhcon can use wenquanyi as native Chinese font. This > > > will be great, because wqy is GPL. The attach file mybe help you. If > render > > > cause problem, this maybe not nessary in console tools like zhcon. As I > > > known, the render is not good solution especially when port zhcon to PDA > > > or embed device. > > > > > I try first to use freetype2 as font render backend. > > > > My current trick is to inherit BaseFont class( virtualize GetChar() > > first...), > > and implement it without lots of changes. I am not sure whether this way > > goes, > > so I conserve these detail and keep working. > > > > Something is need to be known. > > take "efont-unicode.pcf.gz" as example. > > PCF font renders quite good and fast, but only in flat file! > > While in compressed " pcf.gz", the font renders quite slow, due to lots of > > file_gzip_io_xxx. > > So "jfbterm" and some other program just unzip it, "freetype" and > > "libXfont" use buf to save memory, but "freetype" will become very slow, > > even 1/30 than "TTF". > > > > In common case, unicode pcf font file will take 2.2MB, and 700-800KB in > > compressed format. It doesn't hurt in comman desktops and laptops. I would > > suggest to use unicode > > font file in uncompress format. > > > > > > 5. At the end, I like to point which is zhcon's main target. > > > Full font support, at least CJK, no missing chars > > > More and even full display support, can display on different > > > moinitor, driver, and Linux env. > > > Simple input method, can input any char at least CJK. > > > All in GPL. > > > > > > We appeciate any work for zhcon, you are welcome. > > > > > > ----- Original Message ----- > > > *From:* Mat <mat...@gm...> > > > *To:* zhc...@li... > > > *Sent:* Friday, January 05, 2007 1:45 PM > > > *Subject:* [Zhcon-devel] IME support and PCF font > > > > > > Dear zhcon's developers: > > > I am developing an input method framework which provide IIIMF, > > > OpenVanilla, (even SCIM in the future) support for unicode console. > > > The project, which called UCIMF, now works with "jfbterm", which is a > > > linux unicode framebuffer console. > > > Here are project's hosts: > > > http://ucimf.csie.net/ > > > http://wiki.tossug.org/UCIMF > > > UCIMF's is designed to be a shared library, with a C/C++ API, aims to > > > privode IME independent of console program. > > > I have successful ported it to fbiterm, which is another unicode > > > framebuffer console, too. > > > > > > Actually... I use a lot of graphic driver layer of zhcon in UCIMF, and > > > the codes are really excellent, > > > and zhcon's program architeture teaches me a lot, during whole my work. > > > I often think, to do some feedback to the zhcon project. > > > > > > It's great to hear that zhcon support UTF-8 now ! > > > I am glad to port my program to support zhcon, and to support > > > TC/SC/KR/JP input methods in near future. > > > > > > By the way, I current write a article, to discuss why PCF rendering rate > > > is so much slower than TTF. > > > Here is the article( In Traditonal Chinese ): > > > http://wiki.tossug.org/TraceFreetype > > > http://wiki.tossug.org/TraceFreetype2 > > > So, I read some source code and some spec about PCF recently, and still > > > continue studying PCF font rendering issues. > > > > > > It's heard in the devel mailing-list that zhcon plans to support PCF > > > font, > > > I wonder whether I have the chance to help to develope, or even > > > cooperate. > > > > > > sincerely, Mat. > > > > > > > > > ------------------------------ > > > > > > > > > > ------------------------------------------------------------------------- > > > Take Surveys. Earn Cash. Influence the Future of IT > > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > > your > > > opinions on IT & business topics through brief surveys - and earn cash > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > > > > > > ------------------------------ > > > > > > _______________________________________________ > > > Zhcon-devel mailing list > > > Zhc...@li... > > > https://lists.sourceforge.net/lists/listinfo/zhcon-devel > > > > > > > > > > > > > _________________________________________________________________ 与联机的朋友进行交流,请使用 Live Messenger; http://get.live.com/messenger/overview |
From: Mat <mat...@gm...> - 2007-01-08 08:33:08
|
Thank your for your reply, the infomation is really useful. On 1/8/07, HuYong < hy...@ec...> wrote: > > It is really the good news. > 1. Consider the situation of users, CJK console often used in some > system's modify and configuration, also may used in looking manual and help. > So we always keep zhcon's input method simple, easy supplement, rapid > respone with low cost cpu and memory. > > 2. The unicon input method used zhcon before, seems die. Those extern > input method always make more problem when compile zhcon project. So if you > want feedback new input method as library, we recommand you use open and > load library style. This way avoids most compile problems. As the result, we > can use same method to load other input method used in zhcon before. > Do you mean to create an instance of InputServer with UCIMF? Or is there any formal input method API I can follow? btw, UCIMF is implemented as shared library, and IIIMF, OpenVanilla supports are implemented as dynamic loaded modules. I guess, it would not be too difficult to port. UCIMF take about 1MB memory while excution, due to PCF font storage and modules it loads. It current run well on my i486 machine( that is,...Thinkpad 560X ). I will try to port first, and shrink it later when go further. 3. I want to use utf8 as native code in zhcon, but this needs much work. > This modify can solve some problem in zhcon, like half code of Japanese, and > so. > Great :-) I have built zhcon (svn version), and try to use it to connect IRC and also read some text. I found that LC_CTYPE is bound to be zh_CN.UTF-8. Some text can not be correctly displayed, especially with Traditional Chinese text. Due to lack of font? I guess :-o But it's really exciting to see UTF-8 in zhcon , I would like to help to make it better :-) 4. If we support pcf, zhcon can use wenquanyi as native Chinese font. This > will be great, because wqy is GPL. The attach file mybe help you. If render > cause problem, this maybe not nessary in console tools like zhcon. As I > known, the render is not good solution especially when port zhcon to PDA or > embed device. > I try first to use freetype2 as font render backend. My current trick is to inherit BaseFont class( virtualize GetChar() first...), and implement it without lots of changes. I am not sure whether this way goes, so I conserve these detail and keep working. Something is need to be known. take "efont-unicode.pcf.gz" as example. PCF font renders quite good and fast, but only in flat file! While in compressed "pcf.gz", the font renders quite slow, due to lots of file_gzip_io_xxx. So "jfbterm" and some other program just unzip it, "freetype" and "libXfont" use buf to save memory, but "freetype" will become very slow, even 1/30 than "TTF". In common case, unicode pcf font file will take 2.2MB, and 700-800KB in compressed format. It doesn't hurt in comman desktops and laptops. I would suggest to use unicode font file in uncompress format. 5. At the end, I like to point which is zhcon's main target. > Full font support, at least CJK, no missing chars > More and even full display support, can display on different moinitor, > driver, and Linux env. > Simple input method, can input any char at least CJK. > All in GPL. > > We appeciate any work for zhcon, you are welcome. > > ----- Original Message ----- > *From:* Mat <mat...@gm...> > *To:* zhc...@li... > *Sent:* Friday, January 05, 2007 1:45 PM > *Subject:* [Zhcon-devel] IME support and PCF font > > Dear zhcon's developers: > I am developing an input method framework which provide IIIMF, > OpenVanilla, (even SCIM in the future) support for unicode console. > The project, which called UCIMF, now works with "jfbterm", which is a > linux unicode framebuffer console. > Here are project's hosts: > http://ucimf.csie.net/ > http://wiki.tossug.org/UCIMF > UCIMF's is designed to be a shared library, with a C/C++ API, aims to > privode IME independent of console program. > I have successful ported it to fbiterm, which is another unicode > framebuffer console, too. > > Actually... I use a lot of graphic driver layer of zhcon in UCIMF, and the > codes are really excellent, > and zhcon's program architeture teaches me a lot, during whole my work. I > often think, to do some feedback to the zhcon project. > > It's great to hear that zhcon support UTF-8 now ! > I am glad to port my program to support zhcon, and to support TC/SC/KR/JP > input methods in near future. > > By the way, I current write a article, to discuss why PCF rendering rate > is so much slower than TTF. > Here is the article( In Traditonal Chinese ): > http://wiki.tossug.org/TraceFreetype > http://wiki.tossug.org/TraceFreetype2 > So, I read some source code and some spec about PCF recently, and still > continue studying PCF font rendering issues. > > It's heard in the devel mailing-list that zhcon plans to support PCF font, > > I wonder whether I have the chance to help to develope, or even cooperate. > > sincerely, Mat. > > > ------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > ------------------------------ > > _______________________________________________ > Zhcon-devel mailing list > Zhc...@li... > https://lists.sourceforge.net/lists/listinfo/zhcon-devel > > > |
From: Zhang L. <zha...@gm...> - 2007-01-05 11:20:27
|
Dear Mat, Thanks for the encouraging email and for your effort in porting more input methods to zhcon. The development of zhcon has not been active for quite a while. I guess both Hu Yong and I are busy in some other things. Yet we can still discuss in the list. Your contribution will be well welcomed. Best wishes, Zhang Le |
From: Mat <mat...@gm...> - 2007-01-05 05:46:01
|
Dear zhcon's developers: I am developing an input method framework which provide IIIMF, OpenVanilla, (even SCIM in the future) support for unicode console. The project, which called UCIMF, now works with "jfbterm", which is a linux unicode framebuffer console. Here are project's hosts: http://ucimf.csie.net/ http://wiki.tossug.org/UCIMF UCIMF's is designed to be a shared library, with a C/C++ API, aims to privode IME independent of console program. I have successful ported it to fbiterm, which is another unicode framebuffer console, too. Actually... I use a lot of graphic driver layer of zhcon in UCIMF, and the codes are really excellent, and zhcon's program architeture teaches me a lot, during whole my work. I often think, to do some feedback to the zhcon project. It's great to hear that zhcon support UTF-8 now ! I am glad to port my program to support zhcon, and to support TC/SC/KR/JP input methods in near future. By the way, I current write a article, to discuss why PCF rendering rate is so much slower than TTF. Here is the article( In Traditonal Chinese ): http://wiki.tossug.org/TraceFreetype http://wiki.tossug.org/TraceFreetype2 So, I read some source code and some spec about PCF recently, and still continue studying PCF font rendering issues. It's heard in the devel mailing-list that zhcon plans to support PCF font, I wonder whether I have the chance to help to develope, or even cooperate. sincerely, Mat. |
From: Zhang L. <zha...@gm...> - 2006-08-30 06:49:47
|
Someone sent me an x86 patch a while ago that supposedly fixes this problem. It's not included in svn as I can not find an x86 machine to test it locally. It's on my todo list. Cheers, Zhang Le On 30/08/06, Funda Wang <fun...@li...> wrote: > Hello, > > Looking from iurt robot[1], zhcon doesn't build on x86-64 machines. > Is this patch useful? > > Regards > > [1] http://qa.mandriva.com/build/iurt//cooker/x86_64/main/log/zhcon-0.2.5-1mdv2007.0.src.rpm/build_zhcon-0.2.5-1mdv2007.0.src.rpm.0.20060828164613.log > [2] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/zhcon/zhcon-0.2.3-build.patch > __________ > Wanna know who is me? > http://my.opera.com/fundawang > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Zhcon-devel mailing list > Zhc...@li... > https://lists.sourceforge.net/lists/listinfo/zhcon-devel > |
From: Funda W. <fun...@li...> - 2006-08-30 06:22:45
|
Hello, Looking from iurt robot[1], zhcon doesn't build on x86-64 machines. Is this patch useful? Regards [1] http://qa.mandriva.com/build/iurt//cooker/x86_64/main/log/zhcon-0.2.5-1mdv2007.0.src.rpm/build_zhcon-0.2.5-1mdv2007.0.src.rpm.0.20060828164613.log [2] http://cvs.mandriva.com/cgi-bin/viewvc.cgi/SPECS/zhcon/zhcon-0.2.3-build.patch __________ Wanna know who is me? http://my.opera.com/fundawang |
From: Hu Y. <ec...@ho...> - 2006-08-19 02:14:50
|
We really plan to support pcf file for: 1. There are many GPL pcf font file 2. Use utf8 as zhcon native code 3. There is very good GPL pcf font file called WenQuanYi But I do not have much time for zhcon. If anyone want to working for pcf font, do not modify zhcon directly. You may make a small prog like bpsfedit in zhcon's homepage. The prog can display the pcf font. _________________________________________________________________ 与世界各地的朋友进行交流,免费下载 Live Messenger; http://get.live.com/messenger/overview |
From: Zhang L. <zha...@gm...> - 2006-08-18 15:51:27
|
On 18/08/06, Funda Wang <fun...@li...> wrote: > Hello, > > Is there a tool that can convert bdf/pcf fonts into the format that > zhcon uses? Or, we could expect zhcon read bdf files directly? No such tool is available. You need to write some program to do the conversion. Zhang Le |
From: Funda W. <fun...@li...> - 2006-08-18 10:53:06
|
Hello, Is there a tool that can convert bdf/pcf fonts into the format that zhcon uses? Or, we could expect zhcon read bdf files directly? Thanks. |
From: Zhang L. <zha...@gm...> - 2006-08-06 21:34:06
|
On 06/08/06, Funda Wang <fun...@li...> wrote: > > Well, I just use $prefix/etc. Previously it's /etc/ but I think it's > > too messy to put everything under /etc/. > But /usr/etc is too strange for an application. If you don't like > /etc, /etc/zhcon/zhcon.conf would be a better choice. I just assume the followings: For most users that compile from source, default /usr/local/etc/ is fine. For package maintainers, they will patch the makefile to use /etc/zhcon.conf anyway if it looks strange to compile whatever distro standard they use (such as debian) I'm open to suggestion on this. > > BTW, I'm compiling zhcon 0.2.6 under xorg 7.1 with gcc 4.1. It seems > that C-A-H doesn't work while it should pop up the help screen. And, I'm aware of this. > I cannot swtich the input method via C-Fn. The only working shortcut > is Ctrl+Space, it can be used to switch between Quanpin and En. It works fine for me when debugging under xwindow (vis libggi) so I just assume it will be fine when running on console. Too bad I do not have root access on the machine I use. I'm putting this to my check list. Thanks for reporting. Zhang Le |
From: William Xu <wil...@gm...> - 2006-08-06 14:31:44
|
Funda Wang <fun...@li...> writes: > Hello, > > Why does zhcon uses 'chmod' rather than more standard way 'install' command? > > src/Makefile.in, src/Makefile.am: > install-exec-local: > chmod 4755 $(bindir)/zhcon > > The result is when I build a package of zhcon, I got following errors: > chmod 4755 /usr/bin/zhcon: permission denied Maybe you should install it as root? -- William Don't let go of what you've got hold of, until you have hold of something else. -- First Rule of Wing Walking |
From: Zhang L. <zha...@gm...> - 2006-08-06 07:23:14
|
That's because chmod worked fine then so I did not bother "man install". Well, I still do not want to do a "man install" now so if anyone know how to do it using install please let me know. Cheers, Zhang Le On 05/08/06, Funda Wang <fun...@li...> wrote: > Hello, > > Why does zhcon uses 'chmod' rather than more standard way 'install' command? > > src/Makefile.in, src/Makefile.am: > install-exec-local: > chmod 4755 $(bindir)/zhcon > > The result is when I build a package of zhcon, I got following errors: > chmod 4755 /usr/bin/zhcon: permission denied > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Zhcon-devel mailing list > Zhc...@li... > https://lists.sourceforge.net/lists/listinfo/zhcon-devel > |
From: Funda W. <fun...@li...> - 2006-08-05 12:00:39
|
Hello, Why does zhcon uses 'chmod' rather than more standard way 'install' command? src/Makefile.in, src/Makefile.am: install-exec-local: chmod 4755 $(bindir)/zhcon The result is when I build a package of zhcon, I got following errors: chmod 4755 /usr/bin/zhcon: permission denied |
From: Zhang L. <zha...@gm...> - 2006-06-24 18:05:01
|
On 23/06/06, Funda Wang <fun...@li...> wrote: > > Actually, I'm thinking of only supporting simplified Chinese input in > > the future > Then, how about the make file patch? Or, did you do a chroot `make > install` of zhcon? for zhcon In the svn: if installed as root, suid bit will be set if installed as normal user, no chroot is required. Thanks, |
From: Funda W. <fun...@li...> - 2006-06-23 16:00:29
|
> Actually, I'm thinking of only supporting simplified Chinese input in > the future Then, how about the make file patch? Or, did you do a chroot `make install` of zhcon? Regards. |
From: Zhang L. <zha...@gm...> - 2006-06-23 15:47:51
|
PiBOb3QgcmVhbGx5LiBJbiB0aGUgb3JpZ2luYWwgdmVyc2lvbiwgaWYgeW91IGNvbmZpZ3VyZSB3 aXRoICIuL2NvbmZpZ3VyZQo+IC0tc3lzY29uZmRpcj0vd2hhdGV2ZXIiLCB0aGVuIHpoY29uIHdp bGwgbG9vayBmb3IgL3doYXRldmVyL2V0Yy96aGNvbi5jb25mCj4gaW5zdGVhZCBvZiAvd2hhdGV2 ZXIvemhjb24uY29uZi4gSSB0aGluayB0aGUgbGF0dGVyIHNob3VsZCBiZSB0aGUgbm9ybWFsCj4g Y2FzZSwgaXNuJ3QgaXQ/IHN5c2NvbmZkaXIgZGVmYXVsdHMgdG8gUFJFRklYL2V0Y6OsYnV0IGlm ICB3ZSBzcGVjaWZ5IGl0IHdoZW4KPiBjb25maWd1cmluZywgd2Ugc2hvdWxkIGJlIGFibGUgdG8g Y2hhbmdlIGl0IHRvIHdoYXRldmVyIHdlIHdhbnQuIFJpZ2h0PwpPaywgSSd2ZSBtYWRlIHRoZSBj aGFuZ2UgaW4gc3ZuLgpUaGFua3MgZm9yIHRoZSBzdWdnZXN0aW9uLgpDaGVlcnMsClpoYW5nIExl Cg== |