Bug 9008

Summary: arandr does not start, crashes during initialisation
Product: Mageia Reporter: Richard Walker <richard.j.walker>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: Normal CC: mageia, n54, shlomif
Version: CauldronKeywords: Triaged, UPSTREAM
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: arandr-0.1.6-2.mga3.src.rpm CVE:
Status comment:

Description Richard Walker 2013-02-09 03:35:29 CET
Description of problem:
Attempting to start arandr from the (LXDE) desktop Tools->System Tools menu fails with no indication of why. Executing it from a shell reveals the nature of the error.

Traceback (most recent call last):
  File "/bin/arandr", line 42, in <module>
    main()
  File "/usr/lib/python2.7/site-packages/screenlayout/gui.py", line 318, in main
    force_version=options.force_version
  File "/usr/lib/python2.7/site-packages/screenlayout/gui.py", line 159, in __init__
    self.filetemplate = self.widget.load_from_x()
  File "/usr/lib/python2.7/site-packages/screenlayout/widget.py", line 93, in load_from_x
    self._xrandr.load_from_x()
  File "/usr/lib/python2.7/site-packages/screenlayout/xrandr.py", line 150, in load_from_x
    o.modes.append(Size(int(a) for a in d.strip().split(" ")[0].split("x")))
  File "/usr/lib/python2.7/site-packages/screenlayout/auxiliary.py", line 53, in __new__
    arg = tuple(arg)
  File "/usr/lib/python2.7/site-packages/screenlayout/xrandr.py", line 150, in <genexpr>
    o.modes.append(Size(int(a) for a in d.strip().split(" ")[0].split("x")))
ValueError: invalid literal for int() with base 10: '768i'


Version-Release number of selected component (if applicable):


How reproducible:
Always fails

Steps to Reproduce:
1.Open lxterminal
2.Execute arandr
3.Read the error messages
Comment 1 Manuel Hiebel 2013-02-10 13:56:45 CET
upstream bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507521

and it seems there is a patch

Keywords: (none) => PATCH, UPSTREAM
CC: (none) => n54, sander.lepik

Comment 2 Richard Walker 2013-02-10 15:18:41 CET
That debian bug was 2 years ago. Mageia 2 arandr works just fine on the same hardware. I suspect that the arandr parse failure is more closely related to Bug 9009 than to the cause identified for the debian bug in 2010.

Perhaps if the second screen were to be successfully detected (as it is on the same hardware with Mageia 2) then the xrandr output would be less troublesome for arandr to parse.
Comment 3 Kamil Rytarowski 2013-02-10 16:17:53 CET
I cannot reproduce it.
Comment 4 Richard Walker 2013-02-10 22:11:47 CET
Kamil, do you have a test system with a second monitor connected through a KVM switch? I have just completed testing my MGA3 install on alternative hardware; still with a second monitor, but on my brother's (the test-) system it worked without fault - both bug 9008 an 9009 are not evident on his hardware. Both of his monitors are connected directly to the graphic card's ports with no KVM switch.

I have been using this two-PC, three-screen (one shared) system for many many years through several generations of Mandrake/Mandriva/Mageia and this is the first time the second (shared) screen has not been detected and initialised during boot (ref Bug 9009).

I suspect that this bug (9008) against arandr is not likely to be experienced by anyone who does not also experience failed monitor detection because of a KVM switch.

Is it appropriate to mark this one as being un-fixable and focus on 9009?
Comment 5 Richard Walker 2013-02-11 03:08:44 CET
The problem has gone away for now. Installing the RT kernel is enough to fix both this bug and Bug 9009
Comment 6 Richard Walker 2013-02-12 03:46:59 CET
I have discovered that kernel parameters can be passed to force named video outputs to be enabled and I can now use both connected screens on my PC with the desktop kernel (3.8.0) as well as the RT kernel (3.6.5).

However, the arandr "invalid literal for int()" is still triggered when using the desktop kernel.

Nevertheless, the script I run on starting the desktop to set up the 1680x1050 definition for the monitor connected through the KVM switch (hence the EDID cannot be read by software) and position it to the right of the DVI-connected CRT now works when using either of the two current kernels (RT and desktop). The script was originally hacked together to perform the same service for MGA2 and has not been altered for MGA3. So, I can do the job without arandr.

Richard
Comment 7 Samuel Verschelde 2013-08-26 16:35:54 CEST
Richard, if you can still reproduce the bug, it would be good to report it upstream to arandr devs. Looks like the update that was done for the debian bug some time ago still fails to handle some xrandr outputs.

What would be even better is check before that it still fails with arandr's latest version.

Keywords: PATCH => (none)

Comment 8 Richard Walker 2013-08-27 02:59:20 CEST
Samuel, 
It has been six months since I found a way to work around the problem and my memory of the discovery of the bug and the way to avoid it is lost in the mists.

The fix has survived many a kernel upgrade in my grub boot stanza and although I have forgotten how I found the solution, I think I remember that it is intimately linked with a change in the nouveau (or was it nvidia back then? it is certainly nvidia now) + kernel screen hardware detection which failed to initialise both the D-Sub VGA and the DVI VGA outputs (first time since ... forever).

I suspect that the problem first appeared while I was using the nouveau driver (throughout MGA2 and well into my use of MGA3) and I cannot remember why I switched (probably not just for foobillard as that works fine with nouveau) but if you think it might still be relevant I will have a go at breaking it again. Just hope I can remember how to fix it though! :~)

Can't promise it will be soon. I am VERY busy with a project for my day job, but I'll see if I can do the nasty at the weekend.

Richard
Comment 9 Samuel Verschelde 2013-08-28 10:03:00 CEST
It's up to you :), you were the one who got the bug, and I don't know if other people will get the same situation. From Mageia's point of view, the bug being an upstream one AND reported only once AND with a workaround means that it's not likely that we are going to hunt it down and fix it, unless someone finds or provides a patch. From arandr's point of view, this can make a useful contribution to the upstream project (or not, since maybe the problem is fixed already).

So here we have two options, and I let you choose:
- We let this bug report open in hope of an upstream fix that we can then backport (in case other people have the same problem), which is only likely if you report the bug conditions to arandr's project.
- We close it and hope that nobody else will be impacted and/or that it has been fixed in more recent versions of the packages involved or will be fixed by the upstream project.

I'm putting packagers who committed to this package in the past in copy in case they have a different opinion.

Keywords: (none) => Triaged
CC: (none) => boklm

Nicolas Vigier 2014-03-24 10:52:34 CET

CC: boklm => (none)

Comment 10 Shlomi Fish 2015-08-12 19:49:28 CEST
Closing due to inactivity. I am the package maintainer's now.

Status: NEW => RESOLVED
CC: (none) => shlomif
Resolution: (none) => FIXED