Open aomader opened 10 years ago
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...
@b52, could you solve it somehow?
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.
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).
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
?
Hi, I tried @bbenne10 workaround and it worked with the nvidia driver.
Wow. I never replied to this... I'm using the intel driver on all of the machinces on which I'm using sxlock.
Should be fixed in 744e2f5, please test that it works.
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
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)
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.
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...
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
.
xrandr --output (output name) --primary
This fixed for me, thanks!
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 :)
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
.
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:
primary
, we see the "Warning: no primary output detected, trying..." messagexrandr --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?
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...
If I try to start the application I get the following error:
Some information about my system:
Any ideas?