Looks like the root cause is the integration of the new 1.4.0 X server. This server does no longer require a ServerLayout section in xorg.conf - see that attached xorg.conf for the Alpha 5 live CD.
When starting displayconfig, the code calls /var/lib/python-support/python2.5/displayconfigabstraction.py which still tries to read the ServerLayout section of xorg.conf (line 124), but does not succeed and exits with a failure. This causes the uninitialized screen variables in the calling functions.
Seems like the concept of deducing the X server properties from xorg.conf is hopelessly broken with a mostly self-configuring X server as 1.4.0 (future servers will not even require an xorg.conf at all). There needs to be a smarter way to retrieve the current X server configuration.
A quick-and-dirty approach may be to retrieve the information from Xorg.0.log.
Seems like a _huge_ rework of that module is required anyway.
Looks like the root cause is the integration of the new 1.4.0 X server. This server does no longer require a ServerLayout section in xorg.conf - see that attached xorg.conf for the Alpha 5 live CD. python- support/ python2. 5/displayconfig abstraction. py which still tries to read the ServerLayout section of xorg.conf (line 124), but does not succeed and exits with a failure. This causes the uninitialized screen variables in the calling functions.
When starting displayconfig, the code calls /var/lib/
Seems like the concept of deducing the X server properties from xorg.conf is hopelessly broken with a mostly self-configuring X server as 1.4.0 (future servers will not even require an xorg.conf at all). There needs to be a smarter way to retrieve the current X server configuration.
A quick-and-dirty approach may be to retrieve the information from Xorg.0.log.
Seems like a _huge_ rework of that module is required anyway.