Re: What happened to the fonts?
Marc Aurele La France wrote: I don't know enough about this stuff to answer. Perhaps someone else will, and deal with http://www.mail-archive.com/devel%40xfree86.org/msg06114.html. In the meantime I've backed out the change that's causing this. I investigated this issue. In one of next messages Barry Scott mentioned I recall I was seeing code behind XutfTextExtents fail to return any info without the patch - I think it was Xutf8TextExtents. Therefore I guess he has problem with Xutf8* ouput functions in non-UTF8 locale. And it is a real issue. These functions don't work without changes he proposed. But after such changes Xmb* output functions don't work. Obviously, there is some difference in the interpretation of XLC_LOCALE data between these two families (Xutf8* and Xmb*). The traditional iso2022 based font system requires that any input string be separated into portions where all chars belong to one charset. Corresponded converters cut out such portions from a text, label them with charset name and pass to the next procedure that finds an appropriate font for this portion drawing. XLC_LOCALE file contains 'codeset' and 'fontset' records. The 'codeset' records describe rules for distinguishing chars of different charsets and chaset names suitable for each type of chars. The 'fontset' records just defines pairs 'charset name' - 'font encoding name' that tell what font should be used for each charset (the string labeled with this chaset name). What we see in iso8859-15 locale file (and in many other one-byte encoding locales)? There are two codeset records cs0 { sideGL:Default .. ct_encoding ISO8859-15:GL; ISO8859-1:GL } cs1 { sideGR:Default .. ct_encoding ISO8859-15:GR } and two fontset records fs0 { charset { nameISO8859-1:GL } font{ primary ISO8859-15:GL } } fs1 { charset { nameISO8859-15:GR } font{ primary ISO8859-15:GR } } The second records in both pairs is the simplest case. The codeset record says that all 'right side' chars (codes 127) belongs to the right side of ISO8859-15 charset and the fontset record says that the text portion labeled with 'right side of ISO8859-15 charset' can be drawn with some ISO8859-15 encoded font. The first fontset record is simple too. It says that 'ISO8859-1 left side' labeled string can be writen with ISO8859-15 encoded font. But the first codeset record is more complex. It contains two charset names for the same kind of chars ('left side', i.e. codes 128). And Xutf8* and Xmb* functions use different names from this pair. (I know why, and can explain. But here I omit those details.) Thus if one wants to output simple ASCII string like 'abcd', the 'mb' converter labels it as 'ISO8859-1: GL' whereas the 'utf8' converter labels it as 'ISO8859-15:GL'. And if the fontset record looks like 'charset: ISO8859-1 - font: ISO8859-15' the second step procedure successfuly finds appropriate font for 'mb' converter output string but can do nothing for 'utf8' converter output. And after Barry's changes we got a reverse situation: the first fontset record became 'charset: ISO8859-15 - font: ISO8859-15' that means that 'utf8' converter output has appropriate font but there is nothing useful for the 'mb' converter results. The worst thing is that there is significant difference in these converters internals and if even we force the 'utf8' converter to choose ISO8859-1 charset we will not get the the behavior similar to 'mb' converters one. In this case the 'utf8' converter makes the 'right side' chars labeled with ISO8859-1:GR (execept the Euro sign). But such name also has not appropriate chaset-font pair among fontset records. I would suggest a simple workaround: instead of changing the first fontset record add a similar one but with another charset name. I.e. the fontset section of XLC_LOCALE will look like: fs0 { charset { nameISO8859-1:GL } font{ primary ISO8859-15:GL }} fs1 { charset { nameISO8859-15:GR } font{ primary ISO8859-15:GR }} fs2 { charset { nameISO8859-15:GL } font{ primary ISO8859-15:GL }} In such case the first record would satisfy Xmb* functions and the third record would make Xutf8* functions happy. (Of course, I tested this solution. It works.) -- Ivan U. Pascal | e-mail: [EMAIL PROTECTED] Administrator of | Tomsk State University University Network | Tomsk, Russia ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRI on i810
On Mon, Jan 31, 2005 at 07:27:51PM -0500, David Dawes wrote: On Mon, Jan 31, 2005 at 09:20:06AM +, Alan Hourihane wrote: On Sun, Jan 30, 2005 at 08:11:38PM -0500, David Dawes wrote: Has anyone tried DRI on an i810 with the current tree? I get a ring buffer lockup almost immediately after running glxgears. This is with the current i810 DRM module built and loaded against an otherwise stock 2.4.24 kernel. I've not tried it for a while, but I might be able to give it a go. I'm also getting lockups with the i810 in 2D with DRI not enabled on at least one system. I haven't narrowed this down yet. I think this is down to the change I made moving LpRing to an allocated structure. The patch below should correct things. Alan. Index: i810_driver.c === RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c,v retrieving revision 1.109 diff -u -r1.109 i810_driver.c --- i810_driver.c 9 Jan 2005 20:47:19 - 1.109 +++ i810_driver.c 1 Feb 2005 20:11:01 - @@ -2069,6 +2069,13 @@ pI810 = I810PTR(pScrn); hwp = VGAHWPTR(pScrn); + pI810-LpRing = xcalloc(sizeof(I810RingBuffer),1); + if (!pI810-LpRing) { + xf86DrvMsg(pScrn-scrnIndex, X_ERROR, + Could not allocate lpring data structure.\n); + return FALSE; + } + miClearVisualTypes(); /* Re-implemented Direct Color support, -jens */ @@ -2487,6 +2494,9 @@ */ xf86GARTCloseScreen(scrnIndex); + xfree(pI810-LpRing); + pI810-LpRing = NULL; + pScrn-vtSema = FALSE; pScreen-CloseScreen = pI810-CloseScreen; return (*pScreen-CloseScreen) (scrnIndex, pScreen); ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: What happened to the fonts?
On Tue, 1 Feb 2005, Ivan Pascal wrote: Marc Aurele La France wrote: I don't know enough about this stuff to answer. Perhaps someone else will, and deal with http://www.mail-archive.com/devel%40xfree86.org/msg06114.html. In the meantime I've backed out the change that's causing this. I investigated this issue. In one of next messages Barry Scott mentioned I recall I was seeing code behind XutfTextExtents fail to return any info without the patch - I think it was Xutf8TextExtents. Therefore I guess he has problem with Xutf8* ouput functions in non-UTF8 locale. And it is a real issue. These functions don't work without changes he proposed. But after such changes Xmb* output functions don't work. Obviously, there is some difference in the interpretation of XLC_LOCALE data between these two families (Xutf8* and Xmb*). The traditional iso2022 based font system requires that any input string be separated into portions where all chars belong to one charset. Corresponded converters cut out such portions from a text, label them with charset name and pass to the next procedure that finds an appropriate font for this portion drawing. XLC_LOCALE file contains 'codeset' and 'fontset' records. The 'codeset' records describe rules for distinguishing chars of different charsets and chaset names suitable for each type of chars. The 'fontset' records just defines pairs 'charset name' - 'font encoding name' that tell what font should be used for each charset (the string labeled with this chaset name). What we see in iso8859-15 locale file (and in many other one-byte encoding locales)? There are two codeset records cs0 { sideGL:Default .. ct_encoding ISO8859-15:GL; ISO8859-1:GL } cs1 { sideGR:Default .. ct_encoding ISO8859-15:GR } and two fontset records fs0 { charset { nameISO8859-1:GL } font{ primary ISO8859-15:GL } } fs1 { charset { nameISO8859-15:GR } font{ primary ISO8859-15:GR } } The second records in both pairs is the simplest case. The codeset record says that all 'right side' chars (codes 127) belongs to the right side of ISO8859-15 charset and the fontset record says that the text portion labeled with 'right side of ISO8859-15 charset' can be drawn with some ISO8859-15 encoded font. The first fontset record is simple too. It says that 'ISO8859-1 left side' labeled string can be writen with ISO8859-15 encoded font. But the first codeset record is more complex. It contains two charset names for the same kind of chars ('left side', i.e. codes 128). And Xutf8* and Xmb* functions use different names from this pair. (I know why, and can explain. But here I omit those details.) Thus if one wants to output simple ASCII string like 'abcd', the 'mb' converter labels it as 'ISO8859-1: GL' whereas the 'utf8' converter labels it as 'ISO8859-15:GL'. And if the fontset record looks like 'charset: ISO8859-1 - font: ISO8859-15' the second step procedure successfuly finds appropriate font for 'mb' converter output string but can do nothing for 'utf8' converter output. And after Barry's changes we got a reverse situation: the first fontset record became 'charset: ISO8859-15 - font: ISO8859-15' that means that 'utf8' converter output has appropriate font but there is nothing useful for the 'mb' converter results. The worst thing is that there is significant difference in these converters internals and if even we force the 'utf8' converter to choose ISO8859-1 charset we will not get the the behavior similar to 'mb' converters one. In this case the 'utf8' converter makes the 'right side' chars labeled with ISO8859-1:GR (execept the Euro sign). But such name also has not appropriate chaset-font pair among fontset records. I would suggest a simple workaround: instead of changing the first fontset record add a similar one but with another charset name. I.e. the fontset section of XLC_LOCALE will look like: fs0 { charset { nameISO8859-1:GL } font{ primary ISO8859-15:GL }} fs1 { charset { nameISO8859-15:GR } font{ primary ISO8859-15:GR }} fs2 { charset { nameISO8859-15:GL } font{ primary ISO8859-15:GL }} In such case the first record would satisfy Xmb* functions and the third record would make Xutf8* functions happy. (Of course, I tested this solution. It works.) OK. This makes some sense to me. But should something like this be done to all affected locates? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta
Re: What happened to the fonts?
On Tue, 1 Feb 2005, Marc Aurele La France wrote: On Tue, 1 Feb 2005, Ivan Pascal wrote: Marc Aurele La France wrote: I don't know enough about this stuff to answer. Perhaps someone else will, and deal with http://www.mail-archive.com/devel%40xfree86.org/msg06114.html. In the meantime I've backed out the change that's causing this. I investigated this issue. In one of next messages Barry Scott mentioned I recall I was seeing code behind XutfTextExtents fail to return any info without the patch - I think it was Xutf8TextExtents. Therefore I guess he has problem with Xutf8* ouput functions in non-UTF8 locale. And it is a real issue. These functions don't work without changes he proposed. But after such changes Xmb* output functions don't work. Obviously, there is some difference in the interpretation of XLC_LOCALE data between these two families (Xutf8* and Xmb*). The traditional iso2022 based font system requires that any input string be separated into portions where all chars belong to one charset. Corresponded converters cut out such portions from a text, label them with charset name and pass to the next procedure that finds an appropriate font for this portion drawing. XLC_LOCALE file contains 'codeset' and 'fontset' records. The 'codeset' records describe rules for distinguishing chars of different charsets and chaset names suitable for each type of chars. The 'fontset' records just defines pairs 'charset name' - 'font encoding name' that tell what font should be used for each charset (the string labeled with this chaset name). What we see in iso8859-15 locale file (and in many other one-byte encoding locales)? There are two codeset records cs0 { sideGL:Default .. ct_encoding ISO8859-15:GL; ISO8859-1:GL } cs1 { sideGR:Default .. ct_encoding ISO8859-15:GR } and two fontset records fs0 { charset { nameISO8859-1:GL } font{ primary ISO8859-15:GL fs1 { charset { nameISO8859-15:GR } font{ primary ISO8859-15:GR } } The second records in both pairs is the simplest case. The codeset record says that all 'right side' chars (codes 127) belongs to the right side of ISO8859-15 charset and the fontset record says that the text portion labeled with 'right side of ISO8859-15 charset' can be drawn with some ISO8859-15 encoded font. The first fontset record is simple too. It says that 'ISO8859-1 left side' labeled string can be writen with ISO8859-15 encoded font. But the first codeset record is more complex. It contains two charset names for the same kind of chars ('left side', i.e. codes 128). And Xutf8* and Xmb* functions use different names from this pair. (I know why, and can explain. But here I omit those details.) Thus if one wants to output simple ASCII string like 'abcd', the 'mb' converter labels it as 'ISO8859-1: GL' whereas the 'utf8' converter labels it as 'ISO8859-15:GL'. And if the fontset record looks like 'charset: ISO8859-1 - font: ISO8859-15' the second step procedure successfuly finds appropriate font for 'mb' converter output string but can do nothing for 'utf8' converter output. And after Barry's changes we got a reverse situation: the first fontset record became 'charset: ISO8859-15 - font: ISO8859-15' that means that 'utf8' converter output has appropriate font but there is nothing useful for the 'mb' converter results. The worst thing is that there is significant difference in these converters internals and if even we force the 'utf8' converter to choose ISO8859-1 charset we will not get the the behavior similar to 'mb' converters one. In this case the 'utf8' converter makes the 'right side' chars labeled with ISO8859-1:GR (execept the Euro sign). But such name also has not appropriate chaset-font pair among fontset records. I would suggest a simple workaround: instead of changing the first fontset record add a similar one but with another charset name. I.e. the fontset section of XLC_LOCALE will look like: fs0 { charset { nameISO8859-1:GL } font{ primary ISO8859-15:GL }} fs1 { charset { nameISO8859-15:GR } font{ primary ISO8859-15:GR }} fs2 { charset { nameISO8859-15:GL } font{ primary ISO8859-15:GL }} In such case the first record would satisfy Xmb* functions and the third record would make Xutf8* functions happy. (Of course, I tested this solution. It works.) OK. This makes some sense to me. But should something like this be done to all affected locates? I meant locales, not locates. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] |
Re: DRI on i810
On Tue, Feb 01, 2005 at 08:11:35PM +, Alan Hourihane wrote: On Mon, Jan 31, 2005 at 07:27:51PM -0500, David Dawes wrote: On Mon, Jan 31, 2005 at 09:20:06AM +, Alan Hourihane wrote: On Sun, Jan 30, 2005 at 08:11:38PM -0500, David Dawes wrote: Has anyone tried DRI on an i810 with the current tree? I get a ring buffer lockup almost immediately after running glxgears. This is with the current i810 DRM module built and loaded against an otherwise stock 2.4.24 kernel. I've not tried it for a while, but I might be able to give it a go. I'm also getting lockups with the i810 in 2D with DRI not enabled on at least one system. I haven't narrowed this down yet. I think this is down to the change I made moving LpRing to an allocated structure. I already added code early in I810PreInit() to allocate the LpRing. Without that the driver was segfaulting in I810MapMem(). David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: fpit - fixes and passive-pen support
On Mon, Jan 31, 2005 at 09:33:40PM -0500, David M. Clay wrote: David Dawes wrote: On Mon, Jan 31, 2005 at 03:41:05PM -0500, David M. Clay wrote: Hello all. I am new at this, so please gently guide me through this wonderful process of open-source coding. I just recently purchased a Stylistic 3400 and found the current fpit driver did not support the passive pen of the 3400. So I modified the current driver to support the passive pen. I am looking to have my changes added to the latest source tree. What is the best was to have others test my changes on other systems with different hardware, especially the active-pen models? I am pretty sure that I have fixed several bugs that had to have affected the active-pen systems as well, and I hope that I haven't broken anything. I don't have access to any other Stylistic tablets so I am unable to test it myself. The driver does work beautifully on my Stylistic 3400 though. Are there any testers out there? Whats the best way for me to post the changes? Is there a preferred style for diff patches? Is there a FAQ for this? I don't recall seeing any feedback regarding this driver in the past, and from your decsription it sounds like you've fixed some real bugs and improved the driver. I'd suggest submitting your patches ('diff -u' format preferred), and we can look at getting them in for the coming release. You can either post them here, or submit them via bugs.xfree86.org. If anyone here is using the fpit driver, particularly with an active pen system, they should speak up now, and test your patches. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel Okay, here is my patch for the whole fpit directory. I edited the man page and readme file to reflect the changes. You will need to apply the patch in the xc/programs/Xserver/hw/xfree86/input/fpit directory and specify -p1 option. Forgive me if everyone already knows how to figure that out (I didn't). I'm committing your patch now. Thanks for the submission. David. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel