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
