Bug 83216 - xf86Parser messes the config on some locales
Summary: xf86Parser messes the config on some locales
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
Reported: 2003-01-31 11:53 UTC by Marius Andreiana
Modified: 2007-04-18 16:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-30 20:53:46 UTC

Attachments (Terms of Use)
messed up XF86Config file (3.47 KB, text/plain)
2003-01-31 12:09 UTC, Marius Andreiana
no flags Details
XF86Config.serial (3.19 KB, text/plain)
2003-02-11 17:02 UTC, Marius Andreiana
no flags Details
XF86Config.messed1 (3.28 KB, text/plain)
2003-02-11 17:03 UTC, Marius Andreiana
no flags Details
XF86Config.messed2 (3.56 KB, text/plain)
2003-02-11 17:03 UTC, Marius Andreiana
no flags Details

Description Marius Andreiana 2003-01-31 11:53:26 UTC
I've upgraded to kudzu 0.99.91 which fixes bug #82994.

To test it, I've removed the serial mouse, plugged in a ps/2 mouse. Kudzu didn't
detect it, so I ran mouseconfig by hand, which worked fine.
Tested with another ps/2 mouse, again running mouseconfig, again ok.

Put back the serial mouse, ran mouseconfig and selected serial, on exit it gave
these errors:
Parse error on line 94 of section Monitor in file /etc/X11/XF86Config
        Sorry. Too many horizontal sync intervals.
Traceback (most recent call last):
  File "/usr/share/redhat-config-mouse/redhat-config-mouse.py", line 59, in ?
  File "/usr/share/redhat-config-mouse/redhat-config-mouse.py", line 23, in
    app = mouse_tui.childWindow()
  File "/usr/share/redhat-config-mouse/mouse_tui.py", line 163, in __init__
  File "/usr/share/redhat-config-mouse/mouse_tui.py", line 178, in runConfig
    mouseBackend.modifyXconfig(xprotocol, rc.getDevice(), Xemu3)
  File "/usr/share/redhat-config-mouse/mouse_backend.py", line 56, in modifyXconfig
    Xmouse = xf86config.getCorePointer(xconfig)
  File "/usr/lib/python2.2/site-packages/xf86config.py", line 148, in getCorePointer
    for i in xconfig.layout[0].inputs:
AttributeError: 'NoneType' object has no attribute 'layout'

The Monitor section in XF86Config was messed up, I'll attach the file.

Comment 1 Marius Andreiana 2003-01-31 12:09:44 UTC
Created attachment 89732 [details]
messed up XF86Config file

Comment 2 Brent Fox 2003-01-31 20:53:31 UTC
What does the /etc/sysconfig/mouse contain after selecting a serial mouse in

Comment 3 Marius Andreiana 2003-02-05 11:39:12 UTC
FULLNAME="Generic - 2 Button Mouse (serial)"
OPTIONS="-t imps2 -m /dev/input/mice -M"

Today it happened again on another system. I've removed an USB mouse and put a
PS/2 one. mouseconfig trashed XF86Config ( with the same errors ) and also left
the old mouse configuration in XF86Config. I can't provide more info from that
system as the owner lives quite far from me.

Comment 4 Brent Fox 2003-02-10 20:43:41 UTC
When you are swapping the mice, is X running or are you in runlevel 3?

Also, did all those lines for "HorizSync" and "VertRefresh" in the monitor
section exist before you ran redhat-config-mouse?

I'm having a hard time duplicating this on my test machines.

Comment 5 Marius Andreiana 2003-02-11 17:02:58 UTC
Created attachment 89999 [details]

Comment 6 Marius Andreiana 2003-02-11 17:03:21 UTC
Created attachment 90000 [details]

Comment 7 Marius Andreiana 2003-02-11 17:03:43 UTC
Created attachment 90001 [details]

Comment 8 Marius Andreiana 2003-02-11 17:05:13 UTC
How I reproduce it (happens always with phoebe2) :

X is running ( runlevel 5 ) with serial mouse configured ( attached
XF86Config.serial )
the X config file has only the right refresh lines
remove serial mouse, plug ps/2
run mouseconfig, choose generic mouse ps/2 3 buttons
attached XF86Config.messed1 - contains extra lines like VertRefresh 0,0 - 0,0
mouseconfig is run again, more lines are added ( see XF86Config.messed2 )

Comment 9 Brent Fox 2003-02-11 18:52:14 UTC
After looking at your original file, I don't think that the problem has anything
to do with the mouse.  I think that you have a typo in your XF86Config file that
is causing the bug.

HorizSync    30,0 - 86,0
VertRefresh  50,0 - 180,0

I think that the commas are invalid.  You need to use periods instead of commas

HorizSync    30.0 - 86.0
VertRefresh  50.0 - 180.0

According to 'man XF86Config':

       HorizSync  horizsync range
              gives the range(s) of horizontal sync frequencies  supported  by
              the  monitor.   horizsync range may be a comma separated list of
              either discrete values or ranges of values. 

So you can't have *both* a comma separated list and a range.  Removing the
commas should fix the problem.

Comment 10 Marius Andreiana 2003-02-12 10:12:41 UTC
I'll try that.

Note the XF86Config files on those 2 systems were generated at install time
(phoebe2), I didn't edited them by hand.

Comment 11 Brent Fox 2003-02-12 16:50:29 UTC
I can't find any entries in /usr/share/hwdata/MonitorsDB that use commas instead
of periods, so I don't think that the commas got there that way.  

Can you run '/usr/sbin/ddcprobe' as root and attach the results?  Let's see what
the monitor's firmware thinks it can do.

Comment 12 Marius Andreiana 2003-02-15 15:04:37 UTC
In HWdata it's listed with dot, no commas:
Iiyama; Iiyama A705MT, VisionMaster Pro 411 /i70A; ivm174a; 30.0-86.0; 50.0-180.0; 1

ddcprobe output:
Videocard DDC probe results
Description:  NVidia Corporation Riva TNT
Memory (MB):  32
Monitor DDC probe results
ID: IVM174a
Name: Iiyama A705MT, VisionMaster Pro 411 /i70A
Horizontal Sync (kHZ): 30-86
Vertical Sync (HZ)  : 50-180
Width (mm): 320
Height(mm): 240

However, I changed the XF86Config to dot instead of comma, ran mouseconfig
and changed from serial to ps/2, it replaced the dots with commas.
(no extra entries). When ran again, it started to add entries with 0 values too.

I'd like to look on mouseconfig source to debug this, please let me know where
it is ( it wasn't in phoebe srpms, nor in rawhide ). Thanks

Comment 13 Brent Fox 2003-02-18 21:58:51 UTC
Really?  redhat-config-mouse shouldn't change anything involving the monitor in
XF86Config.  There is no code in redhat-config-mouse to do that.  I'm really

Comment 14 Marius Andreiana 2003-02-19 09:44:04 UTC
I didn't use redhat-config-mouse, I used mouseconfig ( text interface, this bug
is on mouseconfig ). I still can't find it's source, could yoo please put that
in rawhide srpms so I can have a look at it? Then you could spend your time on
more important bugs ;)

Comment 15 Brent Fox 2003-02-19 17:29:31 UTC
mouseconfig (the RPM) has been removed.  I added some code to
redhat-config-mouse so that running the 'mouseconfig' command brings up a
similar interface to what mouseconfig used to provide, but it's not the same
code as mouseconfig.

Run 'rpm -qf /usr/sbin/mouseconfig' to see that mouseconfig is coming from the
redhat-config-mouse codebase now.

Comment 16 Marius Andreiana 2003-02-20 10:11:50 UTC
Thanks for the info, I should've thought of that

Found the problem in XFree86 and it's because of locale.
You can replicate this by setting locale to ro_RO.UTF-8 or another one which
uses "," to separate integer part from fractional in float numbers.

In xf86Parser.h (used by pyxf86config) there is this code:

typedef struct
	int mon_n_hsync;
	parser_range mon_hsync[CONF_MAX_HSYNC];
	int mon_n_vrefresh;
	parser_range mon_vrefresh[CONF_MAX_VREFRESH];
XF86ConfMonitorRec, *XF86ConfMonitorPtr;

typedef struct
	float hi, lo;

parser_range has float ( should it be int? ) for ranges, and that is written to
XF86Config using locale info ( wrong, as it is a fixed format ).
I don't have the XFree86 source to look in xf86Parser.c, but that's where I
think the problem is.

PS: Very clean code in redhat-config-mouse, UI separation from backend is quite nice

Comment 17 Mike A. Harris 2003-02-28 08:36:43 UTC
Are you saying that xf86parser.c in libxf86config is writing out floating
point values to the config file using locale translation?  If that is the
case it is very crackheaded indeed.  ;o)

Comment 18 Mike A. Harris 2003-02-28 08:42:12 UTC
er..  there is no xf86parser.c

Comment 19 Mike A. Harris 2003-02-28 09:45:44 UTC
I just ran xf86cfg (which isn't included in our packages) and tested it under
multiple locales.  I tried en_US, de_DE (uses comma separator by default),
and ro_RO.UTF-8.  Regardless of what locale I was in, the xf86cfg tool, which
uses libxf86config properly wrote out the values in "C" locale style format
of x.y.

I tried inputting values using de_DE numeric format, and the dialog boxes
in xf86cfg clearly do not accept this format.  XFree86 configuration both
requires that users are using a decimal point for inputting floating point
values, and it requires that floating point values stored in the config
file are in decimal point format.   This means that "34.5" is valid for
meaning "thirty five and one half" and "34,5" is invalid.  The parser will
treat "34,5" as 2 separate integer values "34" and "5".  When inputting
values into xf86cfg to test how localization works, I tried inputting a
range for the vertical sync of "48,5 - 78,7".  It interpreted this as 3
separate sync ranges:  "48.0", "5.0 - 78.0", and "7.0" as seen below:

        Identifier   "Monitor0"
        VendorName   "Monitor Vendor"
        ModelName    "Monitor Model"
        HorizSync    30.0 - 107.0
        VertRefresh  48.0 - 48.0
        VertRefresh  5.0 - 78.0
        VertRefresh  7.0 - 7.0
        Option      "dpms"

At all times, regardless of what locale I was in when starting the xf86cfg
program up, decimal point values were written to the config file.  There
was never any values written as "xx,x" for floating point.  The library
routines do not call any routines anywhere for setting the locale that I
can see.  I grepped for "locale" in the sources of both the library, and
of xf86cfg which uses the libxf86config library and found nothing interesting.
It is possible some other locale interface is being used, but I wasn't
able to determine this by grep or a quick examination.

Since this problem doesn't occur with xf86cfg, we may have to fix it in
our own config tool by calling setlocale() prior to writing the config
file out.  I will contact the upstream maintainer of this code to see
what his thoughts are.  While it may be possible for us to patch the
library to do what we'd like, I don't want to maintain a fork of the
library which works differently.  If we can convince Paulo that this is
a bug and needs fixing, and he'll change something upstream, then that
is ok.  If not, then I vote for our config tool calling setlocale()
prior to writing the config file.  That is also a good quick workaround
solution for the short term, and might just be the easiest way all
around here.

Comment 20 Miloslav Trmac 2003-03-01 22:40:39 UTC
mharris, if the X tool never calls setlocale () (as you suggest), locale is
implicitly "C" regardless of environment variable settings and you can't
really test the behavior of the library under different locales.

Comment 21 Mike A. Harris 2003-03-01 23:00:11 UTC
You misunderstand me.  I'm saying that xf86cfg does not have this problem,
and it uses libxf86config.  Our tool DOES have this problem, and it uses
libxf86config.  That implies to me that our tool is calling setlocale()
and thus causing the library to react differently since it is linked to
our tool, but that xf86cfg does not do so, and so this problem doesn't
occur in xf86cfg.

This is only a theory.  I have not looked at our config tool source code,
and I probably wont have time to do so.  It's best if Brent looks at our
tool for now as he's maintaining it.  I've asked the upstream maintainer
a few things and not received a response back yet.

IMHO, when our tool calls the libxf86config routines to write the config
file out, it should use setlocale to set the locale to C first, then
restore it afterward.

Comment 22 Brent Fox 2003-04-03 22:03:02 UTC
Can anybody reproduce this with the packages that shipped with RHL 9?  I'm no
longer able to reproduce the problem.  I haven't changed anything, but maybe
something changed in pyxf86config?

Comment 23 Marius Andreiana 2003-04-04 05:40:29 UTC
I'll confirm this when I'll get RHL 9, if nobody answers untils then

Comment 24 Mike A. Harris 2003-04-30 20:53:46 UTC
Closing as not a problem in RHL 9.  (CURRENTRELEASE)

Note You need to log in before you can comment on or make changes to this bug.