BadRRCrtc (invalid Crtc parameter)

[aomader]

If I try to start the application I get the following error:

X Error of failed request:  BadRRCrtc (invalid Crtc parameter)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  20 (RRGetCrtcInfo)
  Crtc id in failed request: 0x0
  Serial number of failed request:  16
  Current serial number in output stream:  16

Some information about my system:

Linux endymion 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 GNU/Linux
01:00.0 VGA compatible controller: NVIDIA Corporation G94 [GeForce 9600 GT] (rev a1)
nvidia 331.38-2

Any ideas?

[lahwaacz]

This will be tough one, because I have an ATI card, not Nvidia... Could you test it with the nouveau driver to see if it's driver-specific, or is that out of question?
I could probably add some further checking and perhaps some fallback solution, but I don't know when and why this error occurs...

[wagnerpatriota]

@b52, could you solve it somehow?

[aomader]

I honestly never tried, since I currently don't have the urge to switch to nouveau just to test it. I stay with slock for now. Maybe I'll check it again once I got a bit spare time.

[bbenne10]

xrandr --output (output name) --primary
may solve this.

EDIT: I just tested this locally and saw exactly this behavior if xrandr didn't have a primary monitor or if the primary monitor was disconnected. Try the above solution. This was likely introduced with multimonitor handling (issue #1).

[lahwaacz]

There is a workaround for configurations without a primary output (see line 354), which works just fine with radeon driver. AFAIK it should work also on Nvidia cards, but it is not tested. Of course patches are welcome...
@bbenne10: which driver do you use? nvidia or nouveau?

[Reihar]

Hi, I tried @bbenne10 workaround and it worked with the nvidia driver.

[bbenne10]

Wow. I never replied to this...
I'm using the intel driver on all of the machinces on which I'm using sxlock.

[lahwaacz]

Should be fixed in 744e2f5, please test that it works.

[aomader]

Doesn't work. Though, I'm can't test it on the machine I initially had the problem on. But I just got another error trying it on my Intel powered notebook:

X Error of failed request:  BadRROutput (invalid Output parameter)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  9 (RRGetOutputInfo)
  Serial number of failed request:  15
  Current serial number in output stream:  15

[twwn]

Doesn't work for me either. In fact, I only get an error (the "invalid Output parameter" variant) with 744e2f5 applied.

(3.18-rc3, intel-git + xorg-git)

[lahwaacz]

The problem is that the behaviour of XRRGetOutputPrimary when there is no primary output is undocumented, but most likely undefined, because it behaves differently with different graphics vendors. Which leads to the next problem: I can only test it on one machine (currently with nvidia card). I could get my hands on cards of both of the other two big vendors, but not in the near future.

in d5104ee I'm checking if the output returned by XRRGetOutputPrimary is valid, which should finally solve this issue.

[combust3r]

I get this on Fedora 21 (primary output is not set)

X Error of failed request:  BadRROutput (invalid Output parameter)
  Major opcode of failed request:  139 (RANDR)
  Minor opcode of failed request:  9 (RRGetOutputInfo)
  Serial number of failed request:  16
  Current serial number in output stream:  16

On Arch Linux it works just fine. Workaround is to set the primary output:

xrandr -q
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 
DP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 509mm x 286mm
   1920x1080     60.00*+
   1680x1050     59.95  
   1600x900      59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x720      59.97  
   1024x768      60.00  
   800x600       60.32  
   640x480       60.00  
   720x400       70.08  
DP2 disconnected (normal left inverted right x axis y axis) 
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

xrandr --output DP1 --primary

Then it works. Also on Fedora 21 there is no fixed-medium font size 17:

xlsfonts | grep misc-fixed-medium-r- | grep 17 | grep 120 | grep iso8859-1
xlsfonts | grep misc-fixed-medium-r- | grep 18 | grep 120 | grep iso8859-1
-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso8859-1
-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso8859-14
-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso8859-15

But this is another issue entirely and is easily fixed with

opt_font = "-misc-fixed-medium-r-*--18-120-*-*-*-*-iso8859-1";

unless it breakes on another distros...

[lahwaacz]

Custom fonts can be set with the -f argument. I don't see size 17 in the xlsfonts output either, but it can be selected with xfontsel.

[sdanielch]

xrandr --output (output name) --primary

This fixed for me, thanks!

[bbenne10]

In the code (which is where i probably went to look up the solution to this problem the first time I looked at this 6 years ago :P), the output is only checked against 0 explicitly. I would venture to guess that null is also a reasonable return value here, which is what people are complaining about in usage against other cards. We could try to add an explicit null check, but that would be exploratory.

Honestly, the best solution here may very well be documentation. I just checked and there's no FAQ or similar in the README, so maybe a solution to get this problem closed could be to document there?

(If everyone that had this problem could simply run this under gdb and print value and type of output at line 364, we might get a much better understanding of the problem, but I feel that's too much to ask)

@lahwaacz: Which would you prefer? I can open a PR for either solution in like...5 minutes :)

[lahwaacz]

I don't know what is null, but NULL is equivalent to 0 in C... There is even a macro BadRROutput defined in X11/extensions/randr.h, which is also 0.

[bbenne10]

Sorry for the delay and the confusion. I'm a Python/JS developer by trade, so null is NULL but in another language :P

You're right, of course, so how are we seeing these failures?
Trying it out now (albeit with only one monitor attached), I see the following:

• If a non-attached monitor is marked as primary, we see the "Warning: no primary output detected, trying..." message
• If no monitor is marked primary at all (xrandr --noprimary), it works fine.

I don't seem to have a way to debug this effectively, as my multi-monitor setup is in another castle at the moment. The path forward, it seems to me, is to investigate the X11 error handling setup for this request (which is likely the default - I have not specifically checked) and maybe change it to force us down the "Warning: no primary output detected, trying..." path?

We can investigate a bit further here, maybe?

[lahwaacz]

The last report of failure was before the most recent commit referencing this issue (
639db05) so let's wait a few more years and if there is no new report, I'll close the issue. It is difficult to develop better error handling when everything works fine for me...