Created attachment 89732 [details]
messed up XF86Config file

What does the /etc/sysconfig/mouse contain after selecting a serial mouse in
mouseconfig?

FULLNAME="Generic - 2 Button Mouse (serial)"
MOUSETYPE="Microsoft"
XEMU3="yes"
XMOUSETYPE="generic"
DEVICE=/dev/ttyS0
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.

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.

Created attachment 89999 [details]
XF86Config.serial

Created attachment 90000 [details]
XF86Config.messed1

Created attachment 90001 [details]
XF86Config.messed2

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 )

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
like:

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.

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.

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.

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

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
confused.

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 ;)

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.

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;

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

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)

er..  there is no xf86parser.c

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.

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.

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.

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?

I'll confirm this when I'll get RHL 9, if nobody answers untils then

Closing as not a problem in RHL 9.  (CURRENTRELEASE)