One doc improvement, two bugfixes

[bothie]

Three changes:

• For anyone not familiar with ant, add a hin to "ant all" and "ant jars" in readme
• Create directory bin (build actually fails otherwise on a fresh clone).
• Allow XRandR Modelines like "1920x1200_50.00 [...]" to be parsed.

[tfg13]

I see you found another possible output of XRandR. Just out of pure curiosity: Do you have a full output somewhere? And what distribution + desktop environment + video card (driver) produces this?

The XRandR patch looks fine, btw.

[bothie]

Actually, my xorg.conf »produces« this:

# cat /etc/X11/xorg.conf
[...]
Section "Monitor"
        Modeline       "1920x1200_50.00" 154.0 1920 1968 2000 2080 1200 1203 1209 1235 +HSync -Vsync # MD 20094 DVI-0
[...]

But it is some kind of semi-standard to encode frequency values like so (funny side note: That modeline results in 59.95 Hz not in 50.00 - probably a typo, should have been 60.00). For some reasons, the default "1920x1200" mode didn't work out for me out of the box, that's why I did add that ModeLine in an trial and error approach some time ago. Anyways, that's why I couldn't just call it "1920x1200" also.

Anyways, the underlaying problem is not doing the parsing the output of xrandr wrong (using -q --verbose, one can still find the width and height values from the modeline, see below), but conceptually to try parsing output of such a program in the first place. The output was designed to be consumed by humans, not scripts or java code ;). So the real solution is to create a jni for libxrandr and get the values from the structures directly. I'm not firm in jni, so I didn't just do that, yet.

# xrands -q
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384
DFP1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 550mm x 344mm
   1920x1200_50.00  59.95*+
   1920x1200     59.95 +
   1920x1080     60.00    59.94    60.00    59.94  
[...]

# xrandr -q --verbose
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 16384
DFP1 connected primary 1920x1200+0+0 (0x7c) normal (normal left inverted right x axis y axis) 550mm x 344mm
        Identifier: 0x79
        [...]
        ConnectorType: HDMI 
  1920x1200_50.00 (0x7c) 154.000MHz +HSync -VSync *current +preferred
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  74.04KHz
        v: height 1200 start 1203 end 1209 total 1235           clock  59.95Hz
  1920x1200 (0x7d) [...]

=> The values behind width and height are the pixel counts. Those values will always be "correct".

[tfg13]

"So the real solution is to create a jni for libxrandr and get the values from the structures directly"

Yes. However, this is non-trivial either. Older versions of LWJGL did that and the results obtained were just wrong. There is a longer explanation in one of the older tickets about this that shows why simply calling libxrandr will always produce incorrect values for certain multi-monitor setups - this is why the command line utility is used for most stuff now. (It is obviously possible to get the correct numbers from libxrandr somehow, since the command line utility uses it and displays correct values.) However, with LWJGL 3 incoming it was just simpler to fix the problems with the command line tool.

Since LWJGL 3 avoids all these problems there should be no need for large refactorings of LWJGL 2 code.